Re: is LISP the ultimate prgram language?
On Oct 21, 10:39 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
James Kanze <james.ka...@gmail.com> writes:
=BB2=AB is a literal and and expression denoting an r-value,
=BB"abc"=AB is a literal and expression denoting an r-value
of pointer type.
Agreed for the first (and it doesn't have an address).
=BB"abc"=AB, however, is an lvalue, of type =BBchar const[4]=AB.
You are right, indeed:
=BBA string literal is an lvalue=AB
ISO/IEC 14882:2003(E), 5.1p2
I, however, do not understand why a string literal is an
lvalue. I would expect that an lvalue can be used on the
left side of an assignment operator, but I cannot see sense
in
"abc" = ...
.
That requires a modifiable lvalue:-). An lvalue can be used in
the circumstances where the standard says an lvalue is required
(and because of the implicit lvalue to rvalue conversion, also
in the circumstances where an rvalue is required). In C++, you
can almost consider lvalue-ness as a more or less arbitrary
attribute, associated with expressions according to the operator
and the type, and required (or not) for certain expressions.
Intuitively, one could say that an lvalue is something that has
an address, except that rvalues of class type also have
addresses.
Array types do convert to pointers in a lot of circumstances,
If =BBa=AB is an expression of array type, I surely understand
that =BBa[ i ]=AB is an lvalue, I just do not understand, why
the bare =BBa=AB should be an lvalue, too. After all, the
following statement is not allowed:
{ int x[ 5 ], y[ 5 ]; x = y; }
That's because arrays are second class citizens in C++. There
was some discussion in the committee, long before C++89, about
trying to correct this, but in the end, the consensus was that C
style arrays were so broken that really fixing them could only
be done at the expense of breaking most existing programs, which
wasn't acceptable, and that there was no point in small hacks.
C++ has std::vector, and the intent was that new code not use C
style arrays at all. Except that in practice, there are cases
(like "abc") where they're unavoidable.
As for messages... That's really just a question of vocabulary.
To me, the notion of a message includes run-time
polymorphism, that is, dynamic dispatch. Any object can
receive any message and decides at run time what to do with
the message, depending on the message selector and the
message arguments.
Which is a recepe for disaster, since most objects can't
reasonable to anything with most messages except declare an
error. Better static type checking, to ensure that the error is
caught at compile time, when it costs a lot less to correct.
--
James Kanze