Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.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: Wed, 11 Sep 2024 16:51:36 +0100
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <vbsea8$3l9od$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <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> <vbci8r$1c9e8$1@paganini.bofh.team>
 <vbcs65$eabn$1@dont-email.me> <vbekut$1kd24$1@paganini.bofh.team>
 <vbepcb$q6p2$1@dont-email.me> <vbgb5q$1ruv8$1@paganini.bofh.team>
 <vbhbbb$1blt4$1@dont-email.me> <87tteqktr8.fsf@bsb.me.uk>
 <vbkjqk$201ms$1@dont-email.me> <87ttenk2nq.fsf@bsb.me.uk>
 <vbps3c$31s4d$1@dont-email.me> <875xr3jaz0.fsf@bsb.me.uk>
 <vbro72$3gqes$1@dont-email.me> <20240911080107.74@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 Sep 2024 17:51:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b0e60afe09774e8e7cecec025f09afc9";
	logging-data="3843853"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19X0IqU4efZSjoSU9/LdsGy"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:WqIF6DMSJzjE35MfO/i8EV53qUs=
In-Reply-To: <20240911080107.74@kylheku.com>
Content-Language: en-GB
Bytes: 6491

On 11/09/2024 16:15, Kaz Kylheku wrote:
> On 2024-09-11, Bart <bc@freeuk.com> wrote:
>> On 11/09/2024 01:22, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> And yes I'm still committed to that symmetry. I'ved used it for countless
>>>> language implementations. C is little different other than it has a
>>>> 700-page standard that suggests a recommended model of how it's supposed to
>>>> work.
>>>>
>>>> You can't really use that to bash me about the head with and maintain that
>>>> all my ideas about language implementation are wrong because C views
>>>> assignment in its own idiosyncratic manner.
>>>
>>> I don't want to bash you about the head, but what C says about
>>> assignment has /always/ been the point, and your implementation of C
>>> will be wrong if you don't follow the rules about C's assignments.  You
>>> /know/ the LH and RH side of a C assignment have different constraints
>>> (you have said so yourself) yet you persist in defending your original
>>> claim that what is needed on the two sides "is exactly the same".
>>
>> I've listed the aspects that I said are the same.
>>
>> That is, if something is a legal LHS term, then its syntax, and its
>> type, are identical to that term appearing on the RHS.
> 
> But the converse isn't true.

I'm not claiming that. Only that legal LHS terms are the same on the 
RHS. Most RHS expressions wouldn't be valid on the left.

> "a = b" is a valid RHS term, yet isn't
> always valid on the LHS without parentheses on it;

But, it isn't valid on the LHS even with parentheses! '(a = b) = c;' is 
an error.

> and this isn't
> something that is due to a glitch in the ISO C grammar that is removable
> by a compiler implementor, since a = b = c means a = (b = c).
> 
> Assignment is syntactially symmetric at the AST level only, where
> parentheses don't matter any more.
> 
> It's possible to generate an AST that has an '=' node with any kind
> of expressions as left and right children, and then check it for
> valid left sides as a matter of syntax.
> 
> If the surface language before the AST is some Lisp-like, then
> the symmetry extends to that syntax also, which can just be (set <expr>
> <expr>); it parses regardless of what the expressions are.

(That's what I do anyway. Apparently I don't do extensive lvalue testing 
during type analysis; some of this stuff is picked up during code 
generation. My type analysers are long due for an overhaul.)


> Unless you take symmetry too literally: obviously (set <expr-1>
> <expr-2>) is not symmetric with regard to (<expr-2> <expr-1> set).  :)
> Not to mention (<2-rpxe> <1-rpxe> tes). :)

Suppose there were two symbols for assignment, ':=' and '=:' for RTL and 
LTR data movement respectively. Then if you had this:

     A := B[i]

(assign element of B to A), you could reverse the assignment - assuming 
both sides could be valid lvalues - by switching the symbol:

     A =: B[i]           # Store A in B[i]

I call that symmetric. You'd have trouble doing that when one side of an 
assignment needs a special symbol to access the value of X, and other 
doesn't. So instead of 'A := B' and 'A =: B', you'd need to swap also 
that symbol:

     A := .B
    .A =:  B

> The "assignment is symmetric at the syntax level" is a kind of Lisp
> mindset, which has banished precedence and associativity.
> 
> In Common Lisp (and some other dialects), the application program
> can extend the repertoire of what kind of expression is a "place";
> i.e. can appear as the left argument of an assignment operator,
> and be used in other related operators.
> 
> In Common Lisp, I can make (setf (+ a 1) 42) do something. For
> instance, I can have it set a to 41, so that (+ a 1) yields 42.


> Note that if I chose this specific semantics, it will still not allow
> (setf (+ 2 2) 42). The + expression will have to contain at least one
> term that is itself a place.

You example is not viable. Apart from expressions which do not involve 
any locations, there could be a dozen such locations.

> (Perhaps we can choose the leftmost
> place as the one to operate on so that (setf (+ a b) ...) will
> operate on a).

What about when the leftmost is itself a nested term, that may be a 
function call?

> I belong to the Lisp mindset, so I tend to agree with the basic gist
> of your idea.  Tou've chosen to work in languages where your intuitions
> do not work out to being literally true, though. :)

Actually they do. I've given an example where an assignment in 
intermediate code is literally identical to the HLL code (A := B in HLL 
ends up as A := B in three-address-code).