Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Wed, 28 Aug 2024 00:49:49 +0100
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <874j75zftu.fsf@bsb.me.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 28 Aug 2024 01:49:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="237f3e3432f89091aec497bdbc144a02";
	logging-data="3332620"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+T7qwtnk6jx2y0GgzQiRZsrBK/dM9lWE4="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:8CKTGmetuXthjGfuO5LeSSGG5gk=
	sha1:GmEzNHJiIWv9YPynzgFB1iRss1Y=
X-BSB-Auth: 1.ab46f39ff37027e7ee43.20240828004949BST.874j75zftu.fsf@bsb.me.uk
Bytes: 3893

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;

> Get A's address            A      &A

-- 
Ben.