Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #6210

Re: Adjacent string literals

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.std.c
Subject Re: Adjacent string literals
Date 2021-01-28 03:05 +0000
Organization A noiseless patient Spider
Message-ID <87y2gdsqvf.fsf@bsb.me.uk> (permalink)
References (4 earlier) <ruq8il$g95$1@dont-email.me> <87lfcftc18.fsf@bsb.me.uk> <ruqnqh$7ie$1@dont-email.me> <87ft2mtmae.fsf@bsb.me.uk> <rus3ss$57c$1@dont-email.me>

Show all headers | View raw


James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/27/21 10:46 AM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> 
>>> On 1/26/21 8:16 PM, Ben Bacarisse wrote:
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> ...
>>>>> Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are
>>>>> not, because both are adjacent to some white-space instead.
>>>>
>>>> Adjacent does not mean with nothing in between (thought it can, of
>>>> course).  What's more, things can be adjacent to each other, and also
>>>> adjacent to something in between.  I can say that there was a fire in
>>>> the house adjacent to mine.  The two house are adjacent.  But both are
>>>> adjacent to the lane separating them.
>>>
>>> It takes at least two dimensions for the issue you raise to come up.
>> 
>> I don't follow.  1 and 2 are adjacent integers on the real line
>> (i.e. despite having other kinds of number between them).  In addition,
>> they are both integers adjacent to 1/2.
>
> I'm not familiar with any meaning that could reasonably be attached to
> "adjacent" which would make either of those statements true.

That's and interesting view, but probably so off-topic that it would not be
reasonable to investigate it here.

> In the future, I will try to remember that there's at least one person
> who does attach such a meaning to that word - but it would make it
> easier for me to understand how you could say such a thing if you
> would specify that definition.

I am not a lexicographer, and not skilled at writing definitions.  So I
looked in the two dictionaries on the shelf here.  The OED says:

  "Lying near to; adjoining; bordering. (Not necessarily touching.)"

and Collins says

  "being near or close, esp. having a common boundary; adjoining;
  contiguous."

These are pretty close to what I feel the word means.

For comparison, what is your understanding of the word?

> When using a meaning that allows 1 and 2 to be both adjacent to 1/2,
> while also being adjacent to each other, how do you interpret "adjacent
> string literal" so that it doesn't apply to
>
>     ptrdiff_t d = "Ben"-"Bacarisse";
>
> It seems to me that, despite having no idea how you could possibly mean
> what you seem to have said, I can make a direct analogy, matching 1 with
> "Ben", 1/2 with '-', and 2 with "Bacarisse". So, how does that analogy
> break down? Or are you claiming that they should be concatenated?

It depends on what is the considered significant and what is merely a
separator or common boundary.

On the number line, we can stress what we want to focus on.  "Adjacent
/integers/" relegates everything else to being a mere separating
boundary.

So, to push the point to the edge of reason, if I choose to read the key
sentence as "Adjacent /string literal/ tokens are concatenated", I
could, at a pinch, make the case that "Ben" and "Bacarisse" are, in your
example, adjacent.  The context would have to be such that considering
another token as a mere boundary or separator would be reasonable.  The
C standard is not such a context.

But if I read it as "Adjacent string literal /tokens/ are concatenated",
then the intervening token stops them being adjacent.  When tokenising a
character stream, all the tokens matter, so I believe there is only one
reasonable way to read that sentence.

> ...
>>> Moving the first sentence of translation phase 7 to be the first
>>> sentence of translation phase 6 would remove all ambiguity, and have, as
>>> far as I can see, no other consequence.
>> 
>> I think the strongest case for the possibility of misunderstanding comes
>> from this sentence being where it is.  I don't see any problem with the
>> word "adjacent", but I can imagine someone wondering why this sentence
>> is where it is if not to do what you are suggesting.
>
> I think you just agreed with me, but you didn't quite say so directly.

Agreement is not binary.  I don't find your argument based on what
adjacent means to be compelling, but I agree that the presence of that
sentence one phase too late muddies the waters a bit.

I've tried to express the extent and the nature of my agreement (and
disagreement) as directly as I can.  I'm sorry if you think I have been
oblique.

TL;DR: The fact that adjacent means something in the cluster of ideas
around "being near to" and "having a common boundary, but not
necessarily touching" means that I don't think there is any problem with
"a" "b" being described as adjacent string literal tokens.

-- 
Ben.

Back to comp.std.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 10:15 -0500
  Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 12:22 +0000
    Re: Adjacent string literals Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-01-26 13:48 +0100
      Re: Adjacent string literals Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-26 13:05 -0800
      Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 21:40 +0000
        Re: Adjacent string literals Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-01-28 09:53 +0100
          Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 05:45 -0500
    Re: Adjacent string literals Richard Damon <Richard@Damon-Family.org> - 2021-01-26 07:52 -0500
    Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-26 09:29 -0500
      Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 21:46 +0000
        Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-26 18:28 -0500
          Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-27 01:16 +0000
            Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-26 22:48 -0500
              Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-27 15:46 +0000
                Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-27 11:20 -0500
                Re: Adjacent string literals Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-28 03:05 +0000
  Re: Adjacent string literals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 08:49 -0700
    Re: Adjacent string literals Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-10 14:58 -0700
      Re: Adjacent string literals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-22 10:29 -0700
    Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-11 11:41 -0700
      Re: Adjacent string literals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-22 15:26 -0700
        Re: Adjacent string literals James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-07-22 17:29 -0700
          Re: Adjacent string literals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 05:29 -0800

csiph-web