Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Fri, 30 Aug 2024 00:29:19 +0100
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <875xrivrg0.fsf@bsb.me.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 30 Aug 2024 01:29:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="eebafb89c0a8b9905bd58ebf99ea830d";
	logging-data="180995"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18C5mvLQiEex6Pl7mlRSRJtyvijRV+7AVo="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:R/nORu0AbZRnWBJZ7z0my4NOa/4=
	sha1:KcHJ6pD9boLsoFfxEYrRTNcYyaM=
X-BSB-Auth: 1.0b2610254a13c4d2aca7.20240830002919BST.875xrivrg0.fsf@bsb.me.uk
Bytes: 6048

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.

A = A; might or might not be valid C because different kinds of
expression are required on each side and assignment.  If A not a
modifiable lvalue, it can appear on the RHS but not on the LHS.

>> 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.

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.

-- 
Ben.