Re: Top 10 most common hard skills listed on resumes...

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