Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!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 01:39:04 +0100
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <valrj7$367a8$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 28 Aug 2024 02:39:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1407973ec3a2d1c19c9aff4f00a8367c";
	logging-data="3349832"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19+HtXJzgQYUA8QMyz80v6r"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VkTyUWcLL7dwLOaaN+urd1IZJik=
In-Reply-To: <874j75zftu.fsf@bsb.me.uk>
Content-Language: en-GB
Bytes: 4600

On 28/08/2024 00:49, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 26/08/2024 13:30, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> BLISS is a rather strange language. For something supposedly low level than
>>>> C, it doesn't have 'goto'.
>>>>
>>>> It is also typeless.
>>>>
>>>> There is also a key feature that sets it apart from most HLLs: usually if
>>>> you declare a variable A, then you can access A's value just by writing A;
>>>> its address is automatically dereferenced.
>>> Not always.  This is where left- and right-evaluation came in.  On the
>>> left of an assignment A denotes a "place" to receive a value.  On the
>>> right, it denotes a value obtained from a place.  CPL used the terms and
>>> C got them via BCPL's documentation.  Viewed like this, BLISS just makes
>>> "evaluation" a universal concept.
>>
>> That doesn't explain why one language requires an explcition dereference in
>> the source code, and the other doesn't.
> 
> It does for me.  If you think I can help, maybe you could ask some more
> questions as I don't know what else to say.  BLISS uses addresses
> explicitly, so the rvalue/lvalue distincion is not a perfect match for
> what's going on, but it's close enough that I find it helpful.
> 
>> By "access A's value" I mean either read or write access.
>>
>>> A denotes a "place" to receive a value.  On the
>>> right, it denotes a value obtained from a place.
>>
>> This /is/ confusing as it suggests a different rank for A depending on
>> whether it is an lvalue or rvalue, eg. some difference in level of
>> indirection. In fact that is the same on both sides.
> 
> I don't know what you mean by rank here.  The whole point of two
> different evaluations -- as an rvalue or an lvalue -- can be seen
> (rather too crudely I fear) as adding one more level of indirection so
> that what we expect to happen (when we've got used to modern programming
> languages), happens.
> 
>> My point was that HLLs typically read or write values of variables without
>> extra syntax.
> 
> 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. 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.

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.

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