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: Thu, 12 Sep 2024 12:27:05 +0100
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vbuj67$733i$2@dont-email.me>
References: <vab101$3er$1@reader1.panix.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> <vbtik7$38tme$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2024 13:27:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3a3e703b62fd17d38a4df729837e6247";
	logging-data="232562"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18HsRTNTSxKX4xbyZfykiBK"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AIvG/auzY1ET3oHOVvukYBXPcd8=
Content-Language: en-GB
In-Reply-To: <vbtik7$38tme$1@paganini.bofh.team>
Bytes: 6507

On 12/09/2024 03:11, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> On 10/09/2024 15:24, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>> I don't know if you were deliberately twisting the term because you are
>>> now 100% committed to some false symmetry in assignments, or whether you
>>> are just very loose in your use of terms, but rvalue expressions (C does
>>> not really use the term, but it's better than non-lvalue expressions)
>>> can't have "references" to them.  That was all that Waldek Hebisch was
>>> saying.  Did you think for a second that he did not know that if you put
>>> an int value into an object you can take the pointer to that object?
>>
>> He took the symmetry I was claiming for assignment, and created an
>> asymmetric counter-example where the dereferencing part of the LHS was
>> moved into a function, necessitating the creation of a discrete
>> reference for the LHS.
>>
>> I created a counter-counter-example where dereferences on both sides
>> were moved into the function, so restoring the symmetry.
> 
> Really not.  My point was about conceptual model and important
> part is to keep such model simple.  You used complex language
> construct which defeats the purose of conceptual model.

I've seen countless proposals in the Reddit PL forum with people trying 
to turn everything into a function (but it is very FP oriented anyway).

To my mind that makes a language much more complicated. You can't really 
implement 'if' and 'while' statements via functions without closures for 
example.

So I'd prefer to keep assignment as low-tech as possible.


>> 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.
> 
> Well, gcc implements assignment in similar way to you (or at least
> did that in the past, I have not checked if recent version do the
> same).  To be more precise, gcc parser when seeing a variable
> creates read reference to this variable.  When parser realizes that
> already recognized part of expression is the left hand side of an
> assignment it converts it to write access.  So your approach is
> no worse than gcc.  But it creates troubles, process of changing
> subexpression with read references into write access is more
> complicated than replacing read instruction by write instruction.
> One, they need to recognize things which are invalid.

It's not that complicated, not with C anyway.

Because in C, if you take the 3-4 categories of LHS in assignments 
(ignore the esoteric ones, and [] and . are really the same), there is 
only one top-level lvalue node to consider.

That's the only thing that needs to 'change', which I don't think is 
onerous anyway.

With more elaborate LHSs, for example like this:

     (A[i], B[i], (x ? C.m : D.m) = Y();

There can be both multiple and nested lvalue nodes. So 'lvalueness' has 
to somehow propagate down into those branches after parsing has been done.

And yet, I was doing that in the 1980s on my toy compilers. So that's 
not that hard either.

(Now, try implementing this assignment with a function!)

>  Second,
> from the very beginning gcc transforms its intermediate representation.
> But some transforms valid on right hand side are invalid on the
> left hand side, so gcc needs to postpone them and do later.
> Third, intermdiate form contains extra information and that
> needs to be handled later.
> 
> So your (and gcc) approach is: "let us pretend that assigment
> operator is symmetric and fix asymetry (that is left hand side)
> later".  That works, and I can imagine good reasons to proceed
> that way.  Or intead of "fixing" one can first generate intemediate
> for and then pass right hand side to "right hand side code
> generator" and left hand side to "left hand side code generator".
> One way or another, in this approach left hand side of assigment
> must be handled differently than right hand side.  But saying that
> assignment operator is really symmetric is wrong.  Different
> treatement treatment of sizes shows this.  And once you accept
> that assignment operator is asymetric, then in Bliss you can handle
> both sides in exactly the same way.  In C, there is implict
> lvalue convertion

What exactly /is/ lvalue conversion? What is converted to what?

I do an lvalue /check/ (so variable 'A' yes, const 6, no). But nothing 
is actually converted.

What /sometimes/ happens in elaborate cases, is that & is applied to 
multiple terms, balanced by a single * elsewhere. But that is not a 
conversion, and is usually not needed for C which only has a single 
lvalue node on the LHS.