Path: ...!weretis.net!feeder8.news.weretis.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 15:57:30 +0100
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <87mskwy9t1.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> <874j75zftu.fsf@bsb.me.uk>
	<valrj7$367a8$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 28 Aug 2024 16:57:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="237f3e3432f89091aec497bdbc144a02";
	logging-data="3689870"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XIUHq03Ci0oq1NFkDQHOdcdDiyJY/Ops="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:Kt91dl/nWBgHDj95K49is9JXx1s=
	sha1:j36FL04/tvVYcsmuGViv6PaGKTg=
X-BSB-Auth: 1.5378a3815d2dffb9834e.20240828155730BST.87mskwy9t1.fsf@bsb.me.uk
Bytes: 3350

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.

> 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 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.

-- 
Ben.