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

On 08/09/2024 16:22, Janis Papanagnou wrote:

On 08.09.2024 12:18, Bart wrote:

On 08/09/2024 04:44, Janis Papanagnou wrote:

On 06.09.2024 13:34, Bart wrote:

>
     (c ? a : b) = x;

>
In Algol 68 you can write
>
      IF c THEN a ELSE b FI := x
>
or, in a shorter form, as
>
      ( c | a | b ) := x
>
if you prefer.

>
But the feature (using them in lvalue contexts) was rarely used.

 Sure.
 

[...]
This is only a "visual" symmetry, not a semantical one.
>
The LHS of the Algol 68 example is of 'REF' (lvalue) type, as it would
be the case with a language that supports a syntax as you show it here.

>
This is where I differ from Algol68,

 Since Algol 68 is conceptually an extremely well designed language
I don't expect such formally elaborated and consistent design in
any language of much lower level.

It is ridiculously over-engineered. It requires the user to have too much knowledge of its internal workings.
A higher level HLL should make life simpler not harder!

where I had to considerably
simplify the semantics to get something I could understand and implement.
>
Take this C:
>
     int A, B;
>
     A = B;
>
There are two types associated with the LHS: 'int*' which is the type
the name A (its address), and 'int' which is the type of A's value.

 Erm, no. The LHS of the assignment is a 'ref' 'int'; in "C" and in
(almost) all other languages I encountered.

The LHS of an an assignment needs to be an LVALUE. It has little to do with types, other than, if the LHS has type T, you might use the ability to turn it into REF T by a hypothetical application of &, to determine lvalueness.
Here is a fragment of C code:
     int a, b;
     a = b;
Here is the typed AST my compiler produces for it:
    int----1 assign:
    int- --|---1 name: a
    int----|---2 name: b
On the left is the type of each node. Where is the 'int*' or ref int' type? I can't see it.
You might notice that LHS and RHS both have the same type.

- If you have an issue
in seeing that, and with your decades of engagement with computers,
you may now have a serious practical effort to fix that view.

Why? My decades have been partly spent devising compilers for systems languages. If my views were wrong, then they simply wouldn't work!

This is where I think Algol68 got it badly wrong.

 I strongly suspect you have no clue.

Algol68 was famous for its hard-to-grasp concepts. That's what it got wrong.

Algol 68 as probably the formally mostly elaborated and consistent
language defines the assignment semantics not differently from any
other of the many existing languages that work with variables.

Here's some syntax in my language which defines 3 ranks of names:
                           Type of name:      Print shows
   const int A = 100;      int                100
   int       B := 200;     ref int            200
   ref int   C := &B;      ref ref int        0x123456 (address of B)
Here it is in Algol68 (I've swapped letter case for consistency):
                           Type of name:      Print shows
   int       A = 100;      int                100
   int       B := 200;     ref int            200
   ref int   C := B;       ref ref int        200
The middle column shows the types of the /names/ A B C. For B, C, it would be the type of &B and &C in my language and in C.
In both cases, A is a constant, not a variable. It is not an lvalue, and you can't assign to it. Yet the declaration uses the same 'int' rank as B.
You will see the difference though if you look at the middle column.
The Print column shows the results of applying Print to A/B/C. A doesn't need a dereference. B has that first 'ref' dereferenced automatically as is common for variables in nearly every HLL.
But In Algol 68 however, both of those 'ref ref' for C are dereferenced to get at the underlying int value. That happens with C used as an rvalue, but to assign to C, the RHS must have 'ref ref int' type; it's is unbalanced.
So my language, like C, needs explicit & operators and explicit derefoperators when dealing with pointers. Here, C is a pointer; B is just a variable. That extra 'ref' in the middle is hidden like in every HLL.
Algol68 as I see it has a bunch of arcane rules that you need to understand. I couldn't tell you for example how to get it to display the actual address contained within C (ie. the address of B), or how to display the address of C itself.
In my language it has been exactly this for 40 years:
     print C                shows contents of C (address of B)
     print C^               (deref) shows what C points to (200)
     print &C               shows address of C
It is incredibly simple. So, you still think that Algol68 got it right?