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

On 28/08/2024 15:57, Ben Bacarisse wrote:

Bart <bc@freeuk.com> writes:
 

On 28/08/2024 00:49, Ben Bacarisse wrote:

 

Indeed, and BLISS is not like that.  I had hoped to shed some light on
why there is some logic to BLISS's rather idiosyncratic design.
>

Given a declaration like 'int A' then:
>
                             BLISS   C
>
Read or write A's value   .A       A

I don't think that's right.  To change the value at address A (what I
think you mean by "write A's value") you write
    A = 42;
in BLISS.  And to add one to the value at address A you write
    A = .A + 1;

>
OK. That's just makes it more bizarre than I'd thought.

 Curious.  It's what makes it consistent, though it is definitely an
uncommon approach.
 

The example I saw
included these lines:
>
     GETNUM(X);            ! returns a value via X
     Y = STEP(.X);
     PUTNUM(.Y)
>
So in an rvalue context:  X reads its address; while .X reads its
value.

 The whole point is to remove the two contexts.  A variable name is
/always/ an lvalue (which is why it can be assigned).  C has an implicit
lvalue to rvalue conversion in the contexts you have come to expect it.
BLISS does not.  You always need a dot to convert to an rvalue.

This is the kind of thing I meant a few posts back. You don't need to take A (which refers to some place where you can store values), and tell it to fetch that value. Most HLLs will do that without being told.
(My point was that that was a distinguishing feature of HLLs, which is missing in Forth for example.)

But in an lvalue one:     Y writes its value; .Y may not be defined
>
It looks asymmetric. C like most languages is symmetric, you write 'A = A'
with the same syntax on both sides.

 Since assignment is inherently asymmetric (you can't write 3 = A but you
can write A = 3) C's syntactic symmetry hides a semantic difference.
What is needed on the two sides is not the same.

I would argue that it is exactly the same. You seem to imply that lvalues and rvalues involve different levels of indirection.
In most HLLs you use the same syntax whether for lvalue or rvalue (eg. A = A).
In intermediate representations it is also the same:
     Push A
     Pop A
And in most assemblers you use the same syntax too:
     LOAD  R, [A]             # A is in memory
     STORE [A], R
     MOVE R, Ra               # A is in a register
     MOVE Ra, R
You will likely see similarities in instruction encodings too.
The same applies when the terms are complex: P.m = P.m, A[i] = A[i], *Q = *Q.
What's different between LHS and RHS is lvalues having an extra constraint. For example you might require an LHS to support an & operation, and require it to be mutable.
So assigning to 42, or (A+B), won't work. Or it shouldn't do (anybody can implement a crazy language where these can either be given a meaning, or it just does something weird).

 

I assume that in BLISS, A = A is legal, but does something odd like copy
A's address into itself.

 What's odd about that?  And why call is a copy operation?  Do you think
of A = 42 as a copy operation?  BLISS is a low-level system language.

Why do you mean by call? But if this is valid in BLISS:
   A = A
then what /does/ it do except what I said? My point is that most people will except this to copy the value of A to itself, in which case they've forgotten to write '.A' on the RHS.
It is uncommon to want to do the equivalent of 'A = &A' and usually doesn't work with static typing anyway.