Subject: Re: C++ briar patch (Was: Object IDs are bad) From: Erik Naggum <email@example.com> Date: 1997/05/29 Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ Message-ID: <firstname.lastname@example.org> * 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 <email@example.com>, Erik Naggum <firstname.lastname@example.org> 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! #\Erik -- 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.