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

On 29/08/2024 17:06, Ben Bacarisse wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:
 

On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>

On 2024-08-29, Ben Bacarisse <ben@bsb.me.uk> wrote:

Bart <bc@freeuk.com> writes:
>

On 29/08/2024 13:35, Ben Bacarisse wrote:

Bart <bc@freeuk.com> writes:

>

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.

So you use "exactly the same" to mean "exactly the same except for the
differences".

>
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.
>
There are no differences other than where the type system says your code is
invalid. So are no differences when considering only valid programs.
>
This program in my language:
>
      42 := 42
>
is valid syntax.

>
So what?  We were talking about assignment in C.  You cut the two
previous quotes where it was clear we were talking about C.  This is not
an honest thing to do.  You are arguing for the sake if it, and in a
dishonest way too.

>
It's also valid syntax in C, with a constraint violation that can be
"caught later on" in an implementation of C, just like in Bart's
language.

>
Have you taken Bart's bait and are now discussing a narrower context?
>
The claim that C's assignment is symmetric and what is required on the
two sides is exactly the same is junk.  C's assignment has different
syntax on each side, and what is required is even more strict.

>
In the ISO C grammar for assignment, there is a "unary expression" on
the left and an "assignment expression" on the right. That's just a
particular factoring of the grammar that implementors don't have to
follow, if the correct results are produced.

 I can't see what it is you object to in what I wrote.  I don't disagree
with anything you are saying (the "correct result" being to reject a
program that has, syntactically, the wrong thing on the left hand side).
 

Under a parser generator tool we could have a production rule like
expr '=' expr , where the '=' token has an elsewhere-declared
associativity and precedence.
>
The basic idea that the same syntactic kind of thing is on both sides of
a C assignment (with an additional lvalue constraint) is valid;
it's just not literally true if we are discussing the details of how
ISO C expresses the grammar.

 A C program that has the wrong syntax (for example x+1) on the left hand
side of an assignment must be rejected.  I'm not relying on some fussy
definition about how the syntax is written but making a point that what
is required on each side is not the exactly same thing.  Do you really
disagree with that?
 

So what exactly is different about the LHS and RHS here:
    A = A;
(In BLISS, doing the same thing requires 'A = .A' AIUI; while 'A = A' is also valid, there is a hidden mismatch in indirection levels between left and right. It is asymmetric while in C it is symmetric, although seem to disagree on that latter point.)
 > A C program that has the wrong syntax (for example x+1) on the left hand
 > side of an assignment must be rejected.
I think that these (with x, y having compatible scalar types):
    x + 1 = y;
    (x + 1) = y;               // in case above was parsed differently
are both valid syntax in C. It will fail for a different reason: an '+' term is not a valid lvalue.
So will this:
    x = z;
when x and y have incompatible types, even though you must agree the syntax is valid, and even when x is a valid lvalue.