Subject: Re: C++ briar patch (Was: Object IDs are bad)
From: Erik Naggum <>
Date: 1997/05/29
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++
Message-ID: <>

* Peter da Silva
| Eric, I'm not calling you names or demeaning your intelligence just
| because I'm getting frustrated with your insistence on complicating the
| issue. I'd really appreciate it if you could be similarly polite. Thanks.

Peter, you're being grossly unfair.  I'm not calling you names, and I'm not
demeaning your intelligence.  I'm showing you that you lack the knowledge
prerequisite to making the claims you try to make.

you're trying to say, as far as I understand, and please correct me if I'm
wrong, that the Lisp family has a pointer concept just like C has, except
that Lisp pointers cannot be manipulated in the same ways in C and Lisp.
still, I gather that you contend, the "pointer" concept is equally valid
for both C and Lisp.

however, I offer a rebuttal to this claim that the pointer is an
implementation issue because is not specified in the language what it
should be like.  in Lisp, it is not even available to the programmer,
although an implementation would necessarily need to use some machine
representation that pointers in C would also use.  I contend that you
cannot make a pointer to an existing object in Lisp except by copying an
existing pointer, but that you can in C.  I contend that you cannot avoid
dereferencing a pointer i Lisp, but that you can in C.  these differences
are very, very important to understand.

| Anyway, I'd just like to point out, again, that I'm not talking about any
| implementation of lisp or the details of what a compiler can or can not
| do...

but you _are_!  the only way your argument could be valid was if we peek
under the proverbial hood of both C and Lisp and look at machine
representation of their respective programmer-level concepts and find that,
lo and behold, there are machine words that contain what must be machine
addresses under _both_ hoods.  I maintain that this is entirely irrelevant
to the _language_ discussions.

| I'm looking at the semantics of the underlying language. For example:
| In article <>, Erik Naggum  <> wrote:
| > the allocation here occurs at read-time, not run-time.
| The distinction between "read time" and "run time" is an implementation
| detail, it's just an optimization. Compilation is just an optimization.

the semantics of the Common Lisp language is in fact that modifying a
quoted constant is undefined precisely _because_ a number of what you call
"optimizations" _shall_ be possible.  the problem I'm trying to communicate
to you is that _you_ are abusing an implementation detail when you modify a
quoted constant -- namely that such action actually has a meaning, when in
the language specification it has not.

to be specific, since you seem to know C and not Lisp at all, a C compiler
is allowed to store constant strings in read-only memory and coalesce all
string constants.  _therefore_, a portable C program cannot modify a string
constant.  via the wonders of the `const' keyword and the un-const-ing
casting operator, it is impossible for the compiler to complain, and
through the tradition of C run-time systems, it is customary for a running
program to do what you asked, and _not_ trap this violation of the language
semantics.  if it works, _that_ is an implementation detail.

| It doesn't effect language semantics at all, and I could certainly
| construct an expression that didn't allow you to perform that
| optimization.

I wish you would be less disrespectful, Peter.  I'm trying to tell you
something that you don't know.  I'm really trying to be factual all the
time, but instead of trying to listen, you react by thinking I'm calling
you names and demeaning your intelligence.  now, if you don't want to
accept new information to update the clearly very obsolete version you
carry around with you, feel free, but say so, and don't blame _me_ for it!

a software manager is a person who, upon reports of the existence of
icebergs, launches a major operation to remove the tip, yet refuses to
listen to experts who say that when the tip is removed, the rest of the
iceberg will float up.  such a manager was in charge on the Titanic.