Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Fri, 6 Sep 2024 14:48:54 +0100 Organization: A noiseless patient Spider Lines: 97 Message-ID: References: <874j75zftu.fsf@bsb.me.uk> <87mskwy9t1.fsf@bsb.me.uk> <875xrkxlgo.fsf@bsb.me.uk> <87o75bwlp8.fsf@bsb.me.uk> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> <86cylhngkx.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 06 Sep 2024 15:48:55 +0200 (CEST) Injection-Info: dont-email.me; posting-host="65207103517559065843f2ba43b77097"; logging-data="897443"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196QhDZwg0eHiL3h0NJpySI" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:bJWVj3T/dH4oFHE6QzxSQ7X3dcQ= In-Reply-To: <86cylhngkx.fsf@linuxsc.com> Content-Language: en-GB Bytes: 5628 On 06/09/2024 12:53, Tim Rentsch wrote: > Bart writes: > >> On 05/09/2024 16:21, Waldek Hebisch wrote: >> >>> Bart 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. It will rarely be intended to mean the name itself (ie. its address) without extra denotations, other in special cases (eg. names of functions, or names of arrays in C). The implementation may sometimes need to use the address instead, but that is hidden. (For example in evaluating x.m, you don't want to load a 500KB struct just to extract one small element). I'm not sure what you mean by object-locating expression, but any anonymous intermediate results (I call them transient values) generally are considered rvalues in the HLL. They would need an explicit pointer deref op to perform any stores. > Those meanings > are very different; among other things, they have different > types (if one type is 'int' the other is 'int *'). > > In Bliss, by contrast, the meaning of an identifier is the same > no matter where it appears in the syntax tree: it always means > the address of the object. The meaning is independent of where > the term appears in the input, which is to say the meaning is > consistent from place to place. In BLISS both A and .A rvalues apparently have the same type. Both A = A and A = .A are apparently valid, but do different things. (But I don't know if ..A would work. In C, A = **A is invalid because of the type system, but there isn't one in BLISS. However, when A is an integer array, then i[A][A][A] does famously work - with suitable data values.) > In C the meaning is not consistent - in some places it means the > address, in other places whatever is stored at the address. > > 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. Then decide whether anything else needs to be done. The rules a little more elaborate, but then C is a more complicated language. You can try this in C source too: *&A = *&B; although the compiler is likely to cancel out both those sets of operations (symmetrically on both sides).