Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Thu, 29 Aug 2024 18:08:13 +0100
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vaq9tu$1te8$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <vaf7f0$k51$2@reader1.panix.com>
 <vafgb2$1to4v$2@dont-email.me>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 29 Aug 2024 19:08:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f25609d88f29f3eda9765667c5ab1831";
	logging-data="62920"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rf07uH6OIvQNSPkMdOekj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4YBHuW0Kl1Gfn6mRI+AWHPy/UnI=
Content-Language: en-GB
In-Reply-To: <87mskvuxe9.fsf@bsb.me.uk>
Bytes: 5667

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;

(In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A' is 
also valid, there is a hidden mismatch in indirection levels between 
left and right. It is asymmetric while in C it is symmetric, although 
seem to disagree on that latter point.)

 > A C program that has the wrong syntax (for example x+1) on the left hand
 > side of an assignment must be rejected.

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.

So will this:

    x = z;

when x and y have incompatible types, even though you must agree the 
syntax is valid, and even when x is a valid lvalue.