Path: ...!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: Wed, 28 Aug 2024 19:26:24 +0100
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <vanq4h$3iieb$1@dont-email.me>
References: <vab101$3er$1@reader1.panix.com>
 <vad7ns$1g27b$1@raubtier-asyl.eternal-september.org>
 <vad8lr$1fv5u$1@dont-email.me> <vaf7f0$k51$2@reader1.panix.com>
 <vafgb2$1to4v$2@dont-email.me>
 <92ab79736a70ea1563691d22a9b396a20629d8cf@i2pn2.org>
 <vafim7$1ubg8$1@dont-email.me> <vah4hr$2b9i8$5@dont-email.me>
 <vahngt$2dtm9$1@dont-email.me> <87r0abzcsj.fsf@bsb.me.uk>
 <vai1ec$2fns2$1@dont-email.me> <874j75zftu.fsf@bsb.me.uk>
 <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 28 Aug 2024 20:26:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1407973ec3a2d1c19c9aff4f00a8367c";
	logging-data="3754443"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+juGgxPVOtGcO/Hn3j23Fz"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:5af+Xpzh2EvBB4eE0UV839UlDSI=
In-Reply-To: <87mskwy9t1.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 5152

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.