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

On 05/09/2024 16:21, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

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

 You seem to miss the point that assigment operator is fundamentally
assymetic.

If you've followed the subthread then you will know that nobody disputes that assignment reads from side of '=' and writes to the other.
The symmetry is to do with syntax when the same term appears on both sides of '=', the type associated with each side, and, typically, the internal representations too.
Clearly the '=' operation is not reversible (or cummutative), as binary '+' might be, but not binary '-'. That is not what I'm claiming.

 This is quite visible at low level, where typical
machine has 'store' instruction.  Store takes address (memory location)
as left argument, but a _value_ as right argument.  Your example
introdices fake symmetry, you ealuate right hand side using
a load ant this may look symmetric with store.

Low level can reveal symmetry too. If 'A' is stored in a register 'Ra', then copying A to itself can be done like this on x64:
     mov Ra, Ra
(Whether data movement is RTL or LTR depends on the assembly syntax, but in this example it doesn't matter.)
If A is in memory then it could be the same on 2-address architectures:
     mov [A], [A]
but more typically it needs two instructions (here using RTL):
    mov R, [A]
    mov [A], R
Here, [A] appears in both instructions, it means the same thing, and refers to the same location. Only the position (left vs. right operand, exactly the same as in A = A) tells you if it's reading or writing.

 But even here
there is asymetry, which is better visible with naive compiler.
You may get code like
     compute addres of A
    load
    compute address of A
    store
 The last step implement '=', the second 'compute address' corresponds
to A on the left had side.  First 'compute address' corresponds to
A on the right hand side.  Now you see that beside address computation
there is also load corresponding to A on the right hand side.

So clearly in most languages treatment of sides is assymetric:
extra loads are inserted due to 'lvalue convertion'.

There is a Load on one operand and a balancing Store on the other. Two loads or two stores would not make sense here.
If you want to go to a lower level, look at how a simple microprocessor works. It will generate a /WR signal on memory accesses that tells a RAM device whether to use the data bus as input or output.
Note that Load and Store can also be considered symmetric: each Load reads data from somewhere and writes it somewhere else. Just like Store does. So some instruction sets use the same mnemonic for both.

 To put in more general context: early success of C was related
to exposing address computations, so that programmers could
do optimization by hand (and consequently non-optimizing compiler
could produce reasonably fast object code).  This has a cost:
need for explicit point dereferences not needed in other langiages.
Bliss went slightly further and requires explicit derefernces
to get values of variables.  My point is that this is logical
regardless if you like it or not.

And /my/ point was that in virtually every HLL, that dereference to turn a variable's address, denoted by its name, into either a read or write access of its value, is implicit.
I said this was a definining characteristic of HLLs, but which BLISS does not have, or has it lop-sidedly: you need the explicit dereference in an rvalue context, but not an lvalue one, like RHS and LHS of an assignment. I considered that assymetric, but most who took part decided that that was made it symmetric!