Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sun, 8 Sep 2024 19:01:32 +0100
Organization: A noiseless patient Spider
Lines: 142
Message-ID: <vbkopr$20j8e$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com> <valrj7$367a8$2@dont-email.me>
 <87mskwy9t1.fsf@bsb.me.uk> <vanq4h$3iieb$1@dont-email.me>
 <875xrkxlgo.fsf@bsb.me.uk> <vapitn$3u1ub$1@dont-email.me>
 <87o75bwlp8.fsf@bsb.me.uk> <vaps06$3vg8l$1@dont-email.me>
 <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com>
 <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com>
 <87mskvuxe9.fsf@bsb.me.uk> <vaq9tu$1te8$1@dont-email.me>
 <vbci8r$1c9e8$1@paganini.bofh.team> <vbcs65$eabn$1@dont-email.me>
 <vbekut$1kd24$1@paganini.bofh.team> <vbepcb$q6p2$1@dont-email.me>
 <vbj6ii$1q6mh$1@dont-email.me> <vbjtmi$1sqao$1@dont-email.me>
 <vbkff0$1vge6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 08 Sep 2024 20:01:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ad79b9a69b5377684053ea6685c7dbff";
	logging-data="2116878"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Y/NBCMVn40ZdwzSbbMBqN"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:f61Otn6OI0P+Z+ISiX1U4/BdkLo=
In-Reply-To: <vbkff0$1vge6$1@dont-email.me>
Content-Language: en-GB
Bytes: 6644

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?