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

Bart <bc@freeuk.com> writes:

On 12/09/2024 20:38, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
[...]

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.

I agree, there's only one thing to consider.  The LHS of an
assignment is a modifiable lvalue.
We've spent a lot of time arguing about how any "categories" there
are for the LHS of an assignment.  If I recall correctly, the whole
thing started when you stated that "the LHS of an assignment is
one of four categories", leading to a debate about whether four
is the correct number.
Enumerating the kinds of expressions that can be modifiable
lvalues is interesting, I suppose, but are A and (A) in different
"categories"?  Is it important to count generic selections and
compound literals?
Who cares, and why?

>
If you go back far enough, someone was questioning the use of a 2-way
selection (what in C would be expressed using ?:) on the left of an
assignment, in an example from another language.

Ok.

In C it's called a conditional expression, or informally a ternary
expression (because it happen to be the only operator that takes three
operands).

A conditional expression (more precisely, an expression whose top
level operator is ?:) is not an lvalue in C.  It could have been,
and it is in C++ if the second and third operands are both lvalues.
I have no particular opinion about whether some future C should
support conditional expressions as lvalues.  That's probably about
all that can be meaningfully said on the subject.

So my set of categories were in the context of what /was/ allowed in C
on the left of an assignment.
>
People made too much of it.

Agreed.  Let's stop doing that.  (Your specific statement that there are
*four* categories triggered a lot of the "too much".)

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

Ok, it's not that hard to implement things that are not valid C.

>
And my comments were in reply to this from WH:
>

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.

>
This suggests a complexity that does not really exist, certainly not
for C with its simple LHSs, and I said that it's not that hard even
with more elaborate languages.
>
So your reply is taking my remark of contest. Or were you just trying
to write something clever? According to that, any entire language X
would be easy to implement because it's not valid C?

I did not mean to suggest that *all* things that are not valid C
are easy to implement.  *Some* things that are not valid C would
be easy to implement in a C or C-like implementation.

I thought you might be suggesting that things that are easy to implement
should be added to C.  Perhaps that's not what you meant.

Upthread, you wrote:

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

Would you like to clarify what you think needs to change?

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

This is specified in the C standard (6.3.2.1p2 in C11, 6.3.3.1p2
in C23 drafts).  I suggest you read it.
An lvalue (an expression that designates an object) is converted
to the value stored in the designated object.  This conversion
(adjustment) does not occur on the LHS of an assignment or in
several other contexts.
It might have been clearer to say that the expression is adjusted
from an expression that designates an object (an lvalue) to an
expression that yields the value of that object (not an lvalue)
Note that this is not a run-time conversion,

>
Well quite. WH was trying to make it out it's a big deal, but it's
usually a no-op (ie. nothing needs to be done in an actual compiler).

Nothing needs to be done??

An actual compiler has to recognize whether an expression that's
an lvalue designates an object or yields the value of the object.
But this is likely to get back to the discussion about whether
assignment is "symmetric", and I've already said I won't waste any
more time debating that.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */