Deutsch   English   Français   Italiano  
<878qwf9ec4.fsf@nosuchdomain.example.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Thu, 29 Aug 2024 15:03:23 -0700
Organization: None to speak of
Lines: 70
Message-ID: <878qwf9ec4.fsf@nosuchdomain.example.com>
References: <vab101$3er$1@reader1.panix.com> <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>
	<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>
	<87h6b39imm.fsf@nosuchdomain.example.com>
	<vaqp83$4jjo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 30 Aug 2024 00:03:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="06fc674f2ef62846f0d6137618397abc";
	logging-data="164144"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+6Uq78pc9/IBGF53j/+paA"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:buTcoOQIc0B0GzGd5XcpirzLaDc=
	sha1:ns2lsXgimqhlv6ngCyKTNlEH4Tk=
Bytes: 4459

Bart <bc@freeuk.com> writes:
> On 29/08/2024 21:30, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> So what exactly is different about the LHS and RHS here:
>>>
>>>     A = A;
>> The RHS is evaluated to determine the current value stored in the
>> object
>> named A.  The LHS is evaluated to determine the object that's designated
>> by the name A; its current value is irrelevant.
>
> Sure, but the same thing happens on both sides: one ends up performing
> a Read via that Lvalue, and the other does a Write via that Lvalue.

The read is done by converting the lvalue to its value, which is not an
lvalue.  Please read the discussion of "lvalue conversion" in the C
standard.

>> In C terms, the RHS undergoes *lvalue conversion*, where an expression
>> that's an lvalue is converted to the value stored in the designated
>> object.  The LHS does not undergo lvalue conversion.
>> 
>>> (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.)
>> Because BLISS, unlike C, does not have implicit lvalue conversion;
>> the
>> prefix "." operator performs explicit lvalue conversion.  I presume the
>> "." operator isn't specific to assignments.
>
> But it must have that conversion on the LHS, otherwise it's A's
> address that is written to rather than its value, which doesn't make
> sense. That's why I said it was asymmetric; the RHS needs an explicit
> operator, the LHS doesn't.

No, the address isn't written.  The object is written.

The RHS evaluation determines the value currently stored in the object.
The LHS evaluation does not.  That's the asymmetry.

In BLISS, the evaluation of the expression A determines the object that
the name A designates.  In C, it can either do that *or* it can extract
the value currently stored in that object.

> I'd initially thought that both sides needed it.
>
>> In C, the LHS and RHS are evaluated differently.  In BLISS, they're
>> evaluated in the same way, requiring an explicit operator to do what
>> done implicitly by context in C.  I'd call the former asymmetric and the
>> latter symmetric.
>
> It sounds like you've got it backwards.
>
> How can A = B be asymmetric, but A = .B be symmetric?

We're talking about the "=" operator, not about a particular instance of
it.

The "=" operation in C is asymmetric because it treats the two operands
differently based on their context.  The "=" operation is BLISS is
symmetric because it treats them the same (requiring an explicit lvalue
conversion on the RHS if you want the value of A).

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */