Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.c
Subject: Re: lvalues
Message-ID: <530@aw.sei.cmu.edu.sei.cmu.edu>
Date: Mon, 19-Jan-87 15:57:46 EST
Article-I.D.: aw.530
Posted: Mon Jan 19 15:57:46 1987
Date-Received: Tue, 20-Jan-87 04:53:22 EST
References: <6539@alice.uUCp>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 69

In article <6539@alice.uUCp> dmr@alice.UUCP writes:
>The question of lvalues has arisen recently both in the context
>of the silly C book review, and also in relation to the operand
>of ++.  The term is old (it comes from BCPL or earlier) and
>just denotes the things that can appear on the left (`l') of
>an assignment.
>

The current BCPL Standard does not use the terms Lvalue and
Rvalue.  It talks of "lmode evaluation" and "rmode evaluation".
The latter mode yields a value; the former mode yields a
value with the special property that it represents the address
of a "cell", ie a storage location able to hold a BCPL value.

L-expressions occur in two contexts: as the LHS of an assignment
and after the address construction operator ('@' in BCPL, '&'
in C)

>The White Book and the current ANSI draft both waffle about whether
>the term is formal or descriptive; they introduce it by, respectively,
>"an expression referring to an object [which is a] manipulatable
>region of storage;" and "an expression that designates an object."

The concept is part of the understanding of the execution semantics
of the language; in particular, the semantics of the abstract store.
Hence, it seems better to explain it in semantic, ie descriptive terms.

>It might cause less confusion if the definition were explicitly syntactic,
>and only certain lvalues were permitted by the semantics to be
>assigned to.  In this scheme, an lvalue (eliding precedence) is defined
>as one of
>
>	identifier
>	( lvalue )
>	lvalue . identifier
>	* expression
>
>Also, by applying equivalence rules,
>
>	expression[expression]     =>    *(expression + expression)
>	expression->identifier     =>    (*expression).identifier
>

I would find this most unhelpful: it tells you nothing about what an
Lvalue actually IS!  Syntactic sugar is empty calories - understanding
a concept comes first; the rules for writing things down come later.

>Only some lvalues can appear on the left of `=' (e.g.: not array,
>not const, not function).  Even more restrictions apply to operands
>of `&': not register, not bit-field.
>

Rather, the C language has evolved to a degree of complexity where
concepts such as lvalues are no longer fully appropriate.  Assignment
to a bit-field cannot be explained in terms of lvalue and rvalue,
but only in terms of extractor/updater functions.  The expression
designating a bit-field cannot be evaluated to yield a context-free
representable "value" that can be passed around, stored &c.  Hence there
is no lvalue of a bit-field.

>This suggestion doesn't change the language, but it makes it
>clearer what an lvalue actually is.  Both the old and new
>reference manuals make it hard for the reader to enumerate the possible
>lvalues.
>
>		Dennis Ritchie
>		research!dmr

Robert Firth