Path: ...!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: Mon, 2 Sep 2024 20:43:44 +0100
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <vb54hg$2vf04$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <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>
 <20240829191404.887@kylheku.com> <87h6aytg7k.fsf@bsb.me.uk>
 <vb4blq$2rf0l$1@dont-email.me> <87jzfum66a.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 02 Sep 2024 21:43:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5aba6719cfbcb81fa74e87ed5976fcca";
	logging-data="3128324"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19egMUeFsJLEIJ88PgtLeNj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1sYW3/rGITgE86+1env5n46aHrw=
In-Reply-To: <87jzfum66a.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 6127

On 02/09/2024 16:22, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 02/09/2024 13:03, Ben Bacarisse wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>
>>>> On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:
>>> ...
>>>>> 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.
>>> Your intervention derailed the discussion into one of syntax.  Bart then
>>> simply stopped talking about his original claim.  Way back I pointed
>>> out that:
>>> || What is needed on the two sides is not the same.
>>> And he replied
>>> | I would argue that it is exactly the same.
>>> He did, later, say that is was "exactly the same" except for the
>>> differences but then went back to "I do mean exactly the same".
>>
>>
>> I said this:
>>
>>> 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.
>>
>> You then sarcastically suggested:
>>
>>> So you use "exactly the same" to mean "exactly the same except for the
>>> differences".
>>
>> I then clarified:
>>
>>> 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.
>>> ...So are no differences when considering only valid programs.
> 
> I wonder what it was you were really objecting to in the original remark
> that I made.  Since ignoring the differences in what is required on the
> LHS and RHS all result in invalid programs your summary is (to a first
> approximation) correct, but it does not render mine wrong in any
> interesting way.
> 
> I note that you have, again, indulged in strategic snipping.  The "..."
> was "There are no differences other than where the type system says your
> code is invalid.".  What is it about the type system of C that makes
> 
> int main(void) {
>    extern char *p;
>    *p = 0;
> }
> 
> invalid?  Because sometimes it is,

This is always valid, when compiling this translation unit. If 'p' is 
defined wrongly elsewhere, then that's outside the remit of the compiler.

This is separate issue with C, in that it's not possible to check 
consistency across translation units of declarations for shared symbols.

(My language solves that for the modules comprising a program, but it 
can still exist between programs rather than between modules.)

But this is venturing away from the question of whether the left and 
right sides of an assignment are compatible, or the same, or symmetric.

Obviously, one side is written to and the other is read; the RHS can 
also contain a wider range of terms than the left side.

But usually what can be legally on the left side on an assignment, can 
also written on the right, and with the same syntax, and the same levels 
of indirection.

> depending on what p is in some other
> translation unit.  Are you using your own meaning for "type system"?  If
> so what is it?
> 
> And as for your remarks about typical implementations, does your C
> parser /really/ accept an assignment expression on both sides of an =
> operator?  What does that even look like in the code?  I have written
> one C parser, contributed to one other and (over the years) examined at
> least two more, and none of them do what you seem to be suggesting is
> typical.
> 

Few of the compilers I tried reported a syntax error.

For assignment expressions, my code is something like this:

     func readassignexpr =
         p := readcondexpr()               # p is an ast node

         if token is an assign operator then
             ....
             q := readassignexpr()
             combine p and q into a new p assignment node
         end

         return p
     end

This is for top-down recursive descent. If I'd called 'readunaryexpr' 
instead, it would not recognise lots of expressions when what is being 
read isn't the LHS of an assignment.

What did yours look like?