Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Fri, 30 Aug 2024 02:34:27 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <20240829191404.887@kylheku.com>
References: <vab101$3er$1@reader1.panix.com>
 <92ab79736a70ea1563691d22a9b396a20629d8cf@i2pn2.org>
 <vafim7$1ubg8$1@dont-email.me> <vah4hr$2b9i8$5@dont-email.me>
 <vahngt$2dtm9$1@dont-email.me> <87r0abzcsj.fsf@bsb.me.uk>
 <vai1ec$2fns2$1@dont-email.me> <874j75zftu.fsf@bsb.me.uk>
 <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk>
 <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk>
 <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk>
 <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk>
 <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk>
 <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk>
 <vaq9tu$1te8$1@dont-email.me> <875xrivrg0.fsf@bsb.me.uk>
Injection-Date: Fri, 30 Aug 2024 04:34:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cbe2877523f20dda3b599fd18e2277a3";
	logging-data="358446"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181+eHkrw/IKgjprP1Rawf7Is07f2k3uf8="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:XoArS7AGC37yDFT1Y+vqxHP0+yg=
Bytes: 7034

On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 29/08/2024 17:06, Ben Bacarisse wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>> 
>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>>
>>>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>
>>>>>>>> On 29/08/2024 13:35, Ben Bacarisse wrote:
>>>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>>
>>>>>>>>>> I explained that. LHS and RHS can be identical terms for assignment in
>>>>>>>>>> pretty much every aspect, but there are extra constraints on the LHS.
>>>>>>>>> So you use "exactly the same" to mean "exactly the same except for the
>>>>>>>>> differences".
>>>>>>>>
>>>>>>>> No, I do mean exactly the same, both in terms of syntax and (in my
>>>>>>>> implementations, which are likely typical) internal
>>>>>>>> representation of those
>>>>>>>> terms.
>>>>>>>>
>>>>>>>> There are no differences other than where the type system says
>>>>>>>> your code is
>>>>>>>> invalid. So are no differences when considering only valid programs.
>>>>>>>>
>>>>>>>> This program in my language:
>>>>>>>>
>>>>>>>>       42 := 42
>>>>>>>>
>>>>>>>> is valid syntax.
>>>>>>>
>>>>>>> So what?  We were talking about assignment in C.  You cut the two
>>>>>>> previous quotes where it was clear we were talking about C.  This is not
>>>>>>> an honest thing to do.  You are arguing for the sake if it, and in a
>>>>>>> dishonest way too.
>>>>>>
>>>>>> It's also valid syntax in C, with a constraint violation that can be
>>>>>> "caught later on" in an implementation of C, just like in Bart's
>>>>>> language.
>>>>>
>>>>> Have you taken Bart's bait and are now discussing a narrower context?
>>>>>
>>>>> The claim that C's assignment is symmetric and what is required on the
>>>>> two sides is exactly the same is junk.  C's assignment has different
>>>>> syntax on each side, and what is required is even more strict.
>>>>
>>>> In the ISO C grammar for assignment, there is a "unary expression" on
>>>> the left and an "assignment expression" on the right. That's just a
>>>> particular factoring of the grammar that implementors don't have to
>>>> follow, if the correct results are produced.
>>> I can't see what it is you object to in what I wrote.  I don't disagree
>>> with anything you are saying (the "correct result" being to reject a
>>> program that has, syntactically, the wrong thing on the left hand side).
>>> 
>>>> Under a parser generator tool we could have a production rule like
>>>> expr '=' expr , where the '=' token has an elsewhere-declared
>>>> associativity and precedence.
>>>>
>>>> The basic idea that the same syntactic kind of thing is on both sides of
>>>> a C assignment (with an additional lvalue constraint) is valid;
>>>> it's just not literally true if we are discussing the details of how
>>>> ISO C expresses the grammar.
>>> A C program that has the wrong syntax (for example x+1) on the left hand
>>> side of an assignment must be rejected.  I'm not relying on some fussy
>>> definition about how the syntax is written but making a point that what
>>> is required on each side is not the exactly same thing.  Do you really
>>> disagree with that?
>>
>> So what exactly is different about the LHS and RHS here:
>>
>>    A = A;
>
> Do you think (or claim) that what is /required/ on each side of an
> assignment in C is exactly the same thing?  The expression on the LHS is
> required to be a modifiable lvalue expression.  That does not apply to
> the expression on right hand side.

"modifiable lvalue" is a semantic attribute which depends on type
and qualification. An array is an lvalue, but not modifiable.
A const-qualified expression is also not a modififiable lvalue.

Bart is insisting that these attributes are not a matter of syntax.

If you regard the processing of these semantic attributes to be part of
syntax (under the model of an attribute grammar), then it can be
regarded as syntax.

I think that what ISO C means by syntax does rule that out.

That also applies in more trivial situations. For instance,
the grammar rules for declaration specifiers admit this as valid
syntax:

  unsigned double float char x;

It's an invalid combination of specifiers ruled out by a constraints
paragraph.  The constraint can be readily identified as syntactic (it
governs combinations of tokens), yet in ISO C, it is outside of the
formal syntax.

>> I think that these (with x, y having compatible scalar types):
>>
>>    x + 1 = y;
>>    (x + 1) = y;               // in case above was parsed differently
>>
>> are both valid syntax in C. It will fail for a different reason: an '+'
>> term is not a valid lvalue.
>
> The compiler must tell you that neither is valid C.  That's because what
> is required on each side of assignment is not exactly the same thing.
> It's a distraction to argue about why each is not valid C as both have
> errors that require diagnostic at compile time.

Bart is only saying that it's valid syntax, not that it's valid C.

According to the ISO C syntax (not taking into account contraints, which
are not syntax) that view is justified.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca