Paul N <gw7rib@aol.com> writes:

> On Monday, February 6, 2023 at 10:43:27 PM UTC, Keith Thompson wrote:
>> Kaz Kylheku <864-11...@kylheku.com> writes:
>> > On 2023-02-04, Richard Damon <Ric...@Damon-Family.org> wrote:
>> >> The key difference is that in C, the results of the conditional operator
>> >> is always an r-value, and thus not suitable for an assignment operator.
>> >
>> > Interestingly, unlike C++, ISO C doesn't use the term rvalue (only
>> > lvalue). However: the term was used in the reference manual for the B
>> > language, predecessor to C.
>> >
>> > A footnote (I'm looking at C99, where it is note #53 on P. 46) says
>> > "What is sometimes called ‘‘rvalue’’ is in this International Standard
>> > described as the ‘‘value of an expression’’."
>> >
>> > Every regular here knows this trivia; just dredging it up a bit here.
>> Right, and the way C (non-normatively) defines "rvalue" is a bit odd.
>> An lvalue is a kind of expression, but an rvalue is the result of
>> evaluating an expression.
>>
>> Historically, lvalues and rvalues were kinds of values. An expression
>> could be "evaluated for its lvalue" or "evaluated for its rvalue",
>> depending on the context in which it appears. In particular, the left
>> hand side of an assignment is evaluated for its lvalue (the identify of
>> the object it designates), and the right hand side of an assignment is
>> evaluated for its rvalue. Some expressions, such as 42, have rvalues
>> but not lvalues; thus 42 cannot appear on the LHS of an assignment.
>> This probably goes back to BCPL, or perhaps even CPL.
>
> Yes, that is how it worked in BCPL. In fact, BCPL has keywords LV and
> RV which can be used to evaluate an expression in its other context,

That was very early BCPL. By the time the book was published (and when
I first used it) all references to rvalues and lvalues had gone! I
think the very detailed distinction made early on was probably a
hangover from CPL and was subsequently found to be unnecessarily fussy.

> but the symbols @ and ! can also do this - I guess the symbols were
> added later and people used them instead,

The early manual (with _lv_ and _rv_ operators) is of the old-school
type where the syntax is given using presentation symbols (often
underlined) that will map to some concrete representation in a
particular implementation. I never used BCPL that old, so I don't know
what was used for _rv_ and _lv_ in practice. Other underlined symbols
were usually written in upper case so I'd guess RV and LV. Did you use
(or even see) BCPL of the era? Though off-topic, I'd love to see some!

I'm not 100% sure that the later @ (essentially "address-of") and unary
! (essentially "dereference") are exactly what the 1967 manual writes as
_rv_ and _lv_. There are enough other differences in that early version
(and the example code at the end is sadly missing) for it to be unclear,
at least to me. Do you know if they were, in fact, just concrete
representations of those keywords?

> leading to C's @ and *.

You mean C's & and *. In the later BCPL, ! was also binary with a!b
being, essentially, C's a[b]. Early BCPL (which is the form that
influenced B and C) used the very clumsy a*[b] form because []s were
also used for function calls. That syntax, sin[pi], definitely comes
from CPL.

--
Ben.

Muttley@dastardlyhq.com writes:
> On Mon, 06 Feb 2023 13:03:11 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>>C's grammar is not trivial to parse, due to typedefs. A typedef
>>effectively creates a context-specific keyword, which means the parser
>>has to interact with the symbol table. (Historically, this is because
>>typedefs were introduced relatively late in the evolution of C.)
>
> Could it not cheat and simply treat a typedef as a kind of macro?

No, typedefs have scope, and a declaration in an inner scope can hide a
typedef in an outer scope.

#include <stdio.h>
int main(void) {
typedef int Integer;
{
int Integer = 10;
printf("Integer = %d\n", Integer);
}
// int Integer = 20; // would be a syntax error
}

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Muttley@dastardlyhq.com writes:

> On Mon, 06 Feb 2023 13:03:11 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
<cut>
>>C's grammar is not trivial to parse, due to typedefs. A typedef
>>effectively creates a context-specific keyword, which means the parser
>>has to interact with the symbol table. (Historically, this is because
>>typedefs were introduced relatively late in the evolution of C.)
>
> Could it not cheat and simply treat a typedef as a kind of macro?

Keith has mentioned the scope issue, but there are other problems with a
simple textual substitution. For example, after

typedef int *T;

the declaration const T x; gives x a const-qualified type (i.e. you
can't assign to x). A simple substitution of "T" for "int *" does not
have the same effect at all.

--
Ben.

On Tue, 07 Feb 2023 11:08:23 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Muttley@dastardlyhq.com writes:
>> On Mon, 06 Feb 2023 13:03:11 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>[...]
>>>C's grammar is not trivial to parse, due to typedefs. A typedef
>>>effectively creates a context-specific keyword, which means the parser
>>>has to interact with the symbol table. (Historically, this is because
>>>typedefs were introduced relatively late in the evolution of C.)
>>
>> Could it not cheat and simply treat a typedef as a kind of macro?
>
>No, typedefs have scope, and a declaration in an inner scope can hide a
>typedef in an outer scope.
>
>#include <stdio.h>
>int main(void) {
> typedef int Integer;
> {
> int Integer = 10;
> printf("Integer = %d\n", Integer);
> }
> // int Integer = 20; // would be a syntax error
>}

Do you know I never knew you could do that with C. I thought it was C++ only.
Learnt something new today!

On Tuesday, February 7, 2023 at 4:25:44 PM UTC, Ben Bacarisse wrote:
> Paul N <gw7...@aol.com> writes:
>
> > On Monday, February 6, 2023 at 10:43:27 PM UTC, Keith Thompson wrote:
> >> Right, and the way C (non-normatively) defines "rvalue" is a bit odd.
> >> An lvalue is a kind of expression, but an rvalue is the result of
> >> evaluating an expression.
> >>
> >> Historically, lvalues and rvalues were kinds of values. An expression
> >> could be "evaluated for its lvalue" or "evaluated for its rvalue",
> >> depending on the context in which it appears. In particular, the left
> >> hand side of an assignment is evaluated for its lvalue (the identify of
> >> the object it designates), and the right hand side of an assignment is
> >> evaluated for its rvalue. Some expressions, such as 42, have rvalues
> >> but not lvalues; thus 42 cannot appear on the LHS of an assignment.
> >> This probably goes back to BCPL, or perhaps even CPL.
> >
> > Yes, that is how it worked in BCPL. In fact, BCPL has keywords LV and
> > RV which can be used to evaluate an expression in its other context,
> That was very early BCPL. By the time the book was published (and when
> I first used it) all references to rvalues and lvalues had gone! I
> think the very detailed distinction made early on was probably a
> hangover from CPL and was subsequently found to be unnecessarily fussy.

I got my information from two books. One, entitled "Programming electronic switching systems" and dated 1976, briefly discusses various programming languages and mentions the two types of evaluation as a key feature of the language, together with keywords RV and LV. It describes an array access as either RV (E1 + E2) or as E1 ↓ E2 (a downward arrow). It's possible the authors had not kept up with recent developments in the language, which is but one of over a dozen described.

The other book is "BCPL: The language and its compiler", dated 1980, printed 1986. As you say, there appears to be no mention of lvalues or rvalues, and no discussion of LV and RV, but the latter are shown in the sample code for the language's syntax analyser. LV seems identical to @ but RV and ! are different as the latter can also be used for arrays, which are now E1 ! E2 as you say below.

> > but the symbols @ and ! can also do this - I guess the symbols were
> > added later and people used them instead,
> The early manual (with _lv_ and _rv_ operators) is of the old-school
> type where the syntax is given using presentation symbols (often
> underlined) that will map to some concrete representation in a
> particular implementation. I never used BCPL that old, so I don't know
> what was used for _rv_ and _lv_ in practice. Other underlined symbols
> were usually written in upper case so I'd guess RV and LV. Did you use
> (or even see) BCPL of the era? Though off-topic, I'd love to see some!

I don't think there are any underlines of any sort in the book. Full stops seem to be the preferred character for concatenating words into a single identifier.

> I'm not 100% sure that the later @ (essentially "address-of") and unary
> ! (essentially "dereference") are exactly what the 1967 manual writes as
> _rv_ and _lv_. There are enough other differences in that early version
> (and the example code at the end is sadly missing) for it to be unclear,
> at least to me. Do you know if they were, in fact, just concrete
> representations of those keywords?

As I said, the older book certainly seems to say that the keywords were simply RV and LV, in capitals.

> > leading to C's @ and *.
> You mean C's & and *.

Mea culpa!

> In the later BCPL, ! was also binary with a!b
> being, essentially, C's a[b]. Early BCPL (which is the form that
> influenced B and C) used the very clumsy a*[b] form because []s were
> also used for function calls. That syntax, sin[pi], definitely comes
> from CPL.

Yes, both round and square brackets are function calls.

Glad to find someone who is interested!

Paul N <gw7rib@aol.com> writes:

> On Tuesday, February 7, 2023 at 4:25:44 PM UTC, Ben Bacarisse wrote:
>> Paul N <gw7...@aol.com> writes:
>>
>> > On Monday, February 6, 2023 at 10:43:27 PM UTC, Keith Thompson wrote:
>> >> Right, and the way C (non-normatively) defines "rvalue" is a bit odd.
>> >> An lvalue is a kind of expression, but an rvalue is the result of
>> >> evaluating an expression.
>> >>
>> >> Historically, lvalues and rvalues were kinds of values. An expression
>> >> could be "evaluated for its lvalue" or "evaluated for its rvalue",
>> >> depending on the context in which it appears. In particular, the left
>> >> hand side of an assignment is evaluated for its lvalue (the identify of
>> >> the object it designates), and the right hand side of an assignment is
>> >> evaluated for its rvalue. Some expressions, such as 42, have rvalues
>> >> but not lvalues; thus 42 cannot appear on the LHS of an assignment.
>> >> This probably goes back to BCPL, or perhaps even CPL.
>> >
>> > Yes, that is how it worked in BCPL. In fact, BCPL has keywords LV and
>> > RV which can be used to evaluate an expression in its other context,
>> That was very early BCPL. By the time the book was published (and when
>> I first used it) all references to rvalues and lvalues had gone! I
>> think the very detailed distinction made early on was probably a
>> hangover from CPL and was subsequently found to be unnecessarily fussy.
>
> I got my information from two books. One, entitled "Programming
> electronic switching systems" and dated 1976, briefly discusses
> various programming languages and mentions the two types of evaluation
> as a key feature of the language, together with keywords RV and LV. It
> describes an array access as either RV (E1 + E2) or as E1 ↓ E2 (a
> downward arrow). It's possible the authors had not kept up with recent
> developments in the language, which is but one of over a dozen
> described.
>
> The other book is "BCPL: The language and its compiler", dated 1980,
> printed 1986. As you say, there appears to be no mention of lvalues or
> rvalues, and no discussion of LV and RV, but the latter are shown in
> the sample code for the language's syntax analyser. LV seems identical
> to @ but RV and ! are different as the latter can also be used for
> arrays, which are now E1 ! E2 as you say below.

I've got that one (well, had that one would be more accurate) and it
describes what I would call "modern BCPL", if anything from last century
can be modern!

Binary ! is a separate thing. I was wondering if rv and lv are exactly
unary ! and @ in modern BCPL. I need to find more examples of rv and lv
being used in code to be sure.

>> > but the symbols @ and ! can also do this - I guess the symbols were
>> > added later and people used them instead,
>>
>> The early manual (with _lv_ and _rv_ operators) is of the old-school
>> type where the syntax is given using presentation symbols (often
>> underlined) that will map to some concrete representation in a
>> particular implementation. I never used BCPL that old, so I don't know
>> what was used for _rv_ and _lv_ in practice. Other underlined symbols
>> were usually written in upper case so I'd guess RV and LV. Did you use
>> (or even see) BCPL of the era? Though off-topic, I'd love to see some!
>
> I don't think there are any underlines of any sort in the book.

I used Usenet _underline_ notation for putting an line under a word.
Some clients will _underline_ and make *bold* and /italic/ text using _,
* and / characters. I think that ended up confusing the matter.

And I was referring only the very old reference manuals. They were
typically typed with a mechanical typewriter and used underlining to
denote abstract symbols like rv, if, let etc.. In such a notation, a
keyword like let would be underlined and the reader would not
automatically assume that a variable could not be named let. An
implementation would specify how these symbols should really be written
in actual program texts. In the BCPL I used, keywords were written in
UPPER CASE, so you could have

LET let = 42; // not a good idea

Algol 68 used a similar system with bold keywords that could be
represented in several ways. Upper case was one, but sometimes you
could use quotes or single dots: WHILE, 'while', .while were all seen
where the report used bold while. (This was called stropping, but I
don't know why. A metaphorical 'sharpening'?)

I think this convention had died out by the 1980s.

> Full stops seem to be the preferred character for concatenating words
> into a single identifier.

Yes, I think that's always been the case. I was not talking about
that. My post was confusing.

>> I'm not 100% sure that the later @ (essentially "address-of") and unary
>> ! (essentially "dereference") are exactly what the 1967 manual writes as
>> _rv_ and _lv_. There are enough other differences in that early version
>> (and the example code at the end is sadly missing) for it to be unclear,
>> at least to me. Do you know if they were, in fact, just concrete
>> representations of those keywords?
>
> As I said, the older book certainly seems to say that the keywords
> were simply RV and LV, in capitals.
>
>> > leading to C's @ and *.
>> You mean C's & and *.
>
> Mea culpa!
>
>> In the later BCPL, ! was also binary with a!b
>> being, essentially, C's a[b]. Early BCPL (which is the form that
>> influenced B and C) used the very clumsy a*[b] form because []s were
>> also used for function calls. That syntax, sin[pi], definitely comes
>> from CPL.
>
> Yes, both round and square brackets are function calls.
>
> Glad to find someone who is interested!

Thanks for posting. I'd forgotten all about the original RV and LV
symbols.

I was very fond of programming in BCPL and I think a fast, clean
typeless language would still find place these days. It's and odd
fondness since I also like very strict typing as in, say, Haskell. Have
you had a look at Richard's MCPL? Very interesting...

And, as an aside, somewhere along the line BCPL acquired a%b the byte
offset version of a!b. You might remember that string operations were
rather painful without it.

--
Ben.

On 2/7/23 14:08, Keith Thompson wrote:
> Muttley@dastardlyhq.com writes:
>> On Mon, 06 Feb 2023 13:03:11 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> [...]
>>> C's grammar is not trivial to parse, due to typedefs. A typedef
>>> effectively creates a context-specific keyword, which means the parser
>>> has to interact with the symbol table. (Historically, this is because
>>> typedefs were introduced relatively late in the evolution of C.)
>>
>> Could it not cheat and simply treat a typedef as a kind of macro?
>
> No, typedefs have scope, and a declaration in an inner scope can hide a
> typedef in an outer scope.
>
​So could it treat it as a macro that gets `#undef`ed at the end of a scope?
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

On 2/8/23 22:13, Blue-Maned_Hawk wrote:
> On 2/7/23 14:08, Keith Thompson wrote:
>> Muttley@dastardlyhq.com writes:
>>> On Mon, 06 Feb 2023 13:03:11 -0800
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> [...]
>>>> C's grammar is not trivial to parse, due to typedefs. A typedef
>>>> effectively creates a context-specific keyword, which means the parser
>>>> has to interact with the symbol table. (Historically, this is because
>>>> typedefs were introduced relatively late in the evolution of C.)
>>>
>>> Could it not cheat and simply treat a typedef as a kind of macro?
>>
>> No, typedefs have scope, and a declaration in an inner scope can hide a
>> typedef in an outer scope.
>>
>
> ​So could it treat it as a macro that gets `#undef`ed at the end of a
> scope?

The same identifier can be two different typedefs in two different
nested scopes. The typedef in the inner scope hides the typedef in the
outer scope, but the typedef in the outer scope becomes visible again at
the end of the inner scope. Therefore, you'd have to have an #undef at
the end of the inner scope immediately followed by a #define.

Note: macro replacement occurs during translation phase 4. Scopes don't
even exist until translation phase 7, and can be affected by some of the
transformations that can occur during translation phase 4. That is to
say, conditional compilation, #include directives or the expansion of a
macro could create or eliminate scopes that would not have been
identified as such in the code as it existed prior to translation phase 4.

Basically, to do something similar to what you're suggesting, you need
to first perform all phase 4, 5, and 6 transformations properly, then
start translation phase 7 parsing to identify where scopes start and
end. Then you have to insert #define and #undef directives in the
appropriate places to implement typedefs, and carry out a
mini-translation phase 4 limited to recognizing those #define and #undef
directives. I don't think that this late phase 4 processing would have
any significant advantage over just biting the bullet and implementing
typedefs correctly during translation phase 7.

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> On 2/7/23 14:08, Keith Thompson wrote:
>> Muttley@dastardlyhq.com writes:
>>> On Mon, 06 Feb 2023 13:03:11 -0800
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> [...]
>>>> C's grammar is not trivial to parse, due to typedefs. A typedef
>>>> effectively creates a context-specific keyword, which means the parser
>>>> has to interact with the symbol table. (Historically, this is because
>>>> typedefs were introduced relatively late in the evolution of C.)
>>>
>>> Could it not cheat and simply treat a typedef as a kind of macro?
>> No, typedefs have scope, and a declaration in an inner scope can
>> hide a
>> typedef in an outer scope.
>
> ​So could it treat it as a macro that gets `#undef`ed at the end of a scope?

No, that wouldn't even work for the example I posted. The "macro"
wouldn't be undefined until the end of main.

#include <stdio.h>
int main(void) {
typedef int Integer;
{
int Integer = 10;
printf("Integer = %d\n", Integer);
}
// int Integer = 20; // would be a syntax error
}

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 02/04/23 7:30 AM, Muttley@dastardlyhq.com wrote:
> Can anyone explain the "official" explanation from whichever standard as to
> why the first assignment only compiles in C++ but not C:

Because C is not C++, and C++ is not C.

This is one of the fundamental core differences between the languages,
which is present in all potentially applicable contexts. You just
stumbled upon one of them - the `?`: operator. There are others:

* Assignment (and compound assignment) in C++ preserves lvalue-ness of
the result

int a, b = 1;
(a = b) = 2;
// Invalid in C, valid in C++
// (and starting from C++11 the behavior is well-defined)

* Prefix increment and decrement in C++ preserves lvalue-ness of the result

int i = 0;
++(++i);
// Invalid in C, valid in C++
// (and starting from C++11 the behavior is well-defined)

C language from the very beginning never cared about preserving the
lvalue-ness of expression results. In C dereference operator (unary `*`)
and its direct derivatives (e.g. `[]` and `->`) are the only operators
that produce lvalue results. Everything else produces rvalues.

C++ completely abandoned and reworked that approach. C++ does the
opposite: it goes to great lengths in order to preserve lvalue-ness of
the result whenever possible. You can see it especially well with `?:`
operator where lvalue-preservation is obviously tricky, since the types
(and value categories) of the second and third operands might not match.
The behavior of `?:` in C++ is defined by a long set of rather
convoluted rules, which depend on how well the types and categories of
the second and third operands match. This illustrates how much effort
C++ is willing to spend on preserving something that C just discarded
nonchalantly.

On can possibly argue that the rationale behind this is introduction of
reference types in C++ (and I'd say that references is just small part
of the story), but the bottom line here is that C and C++ are languages
that adhere to diametrically opposite philosophies wrt that core issue.
These are two completely different languages. The matter can only seem
surprising to those who believe in silly myths, like "C is subset of
C++" and such.

--
Best regards,
Andrey