Subject: Re: C++ briar patch (Was: Object IDs are bad) From: Erik Naggum <erik@naggum.no> Date: 1997/05/29 Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ Message-ID: <3073895616785722@naggum.no> * Peter da Silva | That's just it. The message you were responding to wasn't talking about a | generalized "C" pointer, but a more restricted construct that's very much | closer to half a lisp "cons" cell than anything in "C". I fail to understand what "half a lisp `cons' cell" even means. most (but not all) Lisp objects would be represented by a pointer if you wrote it in C. a cons cell _contains_ two such Lisp objects. there's nothing magic about the cons cell at all. the magic, if any, is in any variable or slot that holds a Lisp object that requires a "pointer" to it in C terminology. | If you're not talking about with this more limited and safer pointer, | then there's nothing much to talk about. Do let me know. | | > Arbitrary structures of these _LISTS_ are nothing more than _LISTS_ of | > _LISTS_. | | No, they're not. They're general directed graphs, of which a list is a | specific case. You can use RPLACA and RPLACD to build circular structures | that can't be expressed in list notation: | | (set 'a '(a b)) | (rplacd a a) | | (well, you can't express that in list notation in finite time) sigh. Peter, get yourself out of the 60's Lisp and play with a 90's Lisp system. you have nothing to lose but your chains. user(1): (setq *print-circle* t) t user(2): (setq a (cons 'a 'b)) (a . b) user(3): (setf (cdr a) a) #1=(a . #1#) | > Again there is no resemblence to the traditional pointer -- | > we don't allocate to it, | | (set 'a '(a b)) | | Yes, the memory allocation is implicit, not explicit. And you don't need | to explicitly deallocate it. the allocation here occurs at read-time, not run-time. a compiler is free to pre-allocate (quoted) constants in read-only memory and share them with all its users. your `rplacd' above is a violation of this freedom. if you want a non-constant list, you allocate and initialize memory for it (in C terms) with `cons' or `list'. since you cannot de-couple BTW, `set' is deprecated. (set x y) == (setf (symbol-value x) y), which is only meaningful for special (dynamic) variables, not lexical variables, since the latter are not stored in the value slot of symbols. (yes, Lisp has lexical variables. what a concept!) use `setq' or `setf', instead. | (car a) | | This is an issue of syntax, not semantics. You could write a macro that | converted "*a" into "(car a)" or "(cdr a)". I really hope you understand the difference between * and . in (*bar).car even though they come rolled up in a single -> as in bar->car, which is what (car bar) would be doing. | > When you can show me an example of Lisp code that dereferences pointers | > ala C or Pascal then I'll believe you, until then, you have proven | > nothing. | | See above. you have proven nothing, Peter. (if I were less generous, I could point out that you _have_ proven something, but I'll let it pass for now. :) #\Erik -- if we work harder, will obsolescence be farther ahead or closer?