Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 09 Sep 2024 17:57:08 -0700
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <86seu8iavv.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <vai1ec$2fns2$1@dont-email.me> <874j75zftu.fsf@bsb.me.uk> <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> <86cylhngkx.fsf@linuxsc.com> <vbf187$rcd3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 10 Sep 2024 02:57:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2716f454c4dece03d014ce5d7a2dd1ff";
	logging-data="2745340"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18f8IVTMDtJU1gSImVKdEuFgvHA+gP2GxI="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:nv0olc8qJlccirZLSAFpSg0+eF4=
	sha1:Bkpo/wj9pEfaC3nt1ufP7RRAIrs=
Bytes: 4123

Bart <bc@freeuk.com> writes:

> On 06/09/2024 12:53, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 05/09/2024 16:21, Waldek Hebisch wrote:
>>>
>>>> Bart <bc@freeuk.com> wrote:
>>>>
>>>>> So what exactly is different about the LHS and RHS here:
>>>>>
>>>>>      A = A;
>>>>>
>>>>> (In BLISS, doing the same thing requires 'A = .A' AIUI;  while
>>>>> 'A = A' is also valid, there is a hidden mismatch in indirection
>>>>> levels between left and right.  It is asymmetric while in C it
>>>>> is symmetric, although seem to disagree on that latter point.)
>>>>
>>>> You seem to miss the point that assigment operator is
>>>> fundamentally assymetic.
>>>
>>> If you've followed the subthread then you will know that nobody
>>> disputes that assignment reads from side of '=' and writes to the
>>> other.
>>>
>>> The symmetry is to do with syntax when the same term appears on
>>> both sides of '=', the type associated with each side, and,
>>> typically, the internal representations too.
>>
>> Maybe it would help if you would stop thinking in terms of the
>> word symmetry (clearly assignment is not symmetrical) and instead
>> think about consistency.
>>
>> In C, the meaning of an identifier or object-locating expression
>> depends on where it is in the syntax tree.  In some places it
>> means the address of the object;  in other places it means the
>> contents of whatever is stored in the object.
>
> In a HLL, a named object (ie. a variable name) is nearly always meant
> to to refer to an object's value, either its current value or what
> will be its new value.

BLISS is different.

>> Considering the point of view of a compiler writer, it's easier
>> to write a compiler for Bliss than for C.  In Bliss, upon seeing
>> an identifier, always simply put its address in a register.  If
>> an object's value needs to be loaded, there will be a '.' to take
>> the address produced by the sub-expression and fetch the word
>> stored at that address.  On the other hand, in C, upon seeing an
>> identifier, the compiler needs to consider the context of where
>> the identifier appears:
>
> You can do the same thing in a C compiler:  always load the
> address of any identifier associated with the location of
> value.

Sure, but that doesn't change the basic point that in C some
additional information needs to be taken into account, and
possibly additional code generated, when looking at the parse
node for an identifier.  In BLISS the action is always just
to load the address, and no other action is ever needed.