From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mhh8h$gkq@web.nmti.com>
In article <············@masala.cc.uh.edu>,
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
> Peter da Silva (·····@nmti.com) wrote:
> : In article <············@masala.cc.uh.edu>,
> : ········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
> : > I think the question goes further to "do we even need to obtain and
> : > dereference them?". I'm using Scheme, and before that Haskell -- 2
> : > languages without pointers, and I've yet to run into a situation
> : > where I even remotely missed them much less thought about them.
> : Last I checked, Scheme was a very close Lisp variant. Now, Lisp has pointers
> : and pointer operations (CAR, CDR, RPLACA, RPLACD, ...). Doesn't Scheme?
> However car, cdr, etc... implement their operations is a non-issue,
You're right, but I'm not talking about the implementation.
It's not that the Lisp cell is implemented as a pair of pointers.
It's that the lisp cell *is* a pair of pointers.
You can do everything with these pointers that you can do with pointers in
any other language, except perform arithmetic on them. Which was the point
of the message you're responding to in <············@masala.cc.uh.edu>.
> This entire genre of operations is abstracted away from us, we are
> given a view of lists.
Nonsense. You can build arbitrary structures with these pointers using
the five basic operations (CONS, CAR, CDR, RPLACA, RPLACD). You obtain
a pair of pointers with CONS, assign them with RPLACA and RPLACD, and
dereference them with CAR and CDR.
There's really not much more to lisp than that. Toss in COND, SET, LAMBDA,
and EVAL and I think you've got it. (Don't beat me up too hard if I missed
something, it's been a while since I did a lot of lisp). And I'll bet you
could implement SET by CARing and CDRing around in OBLIST.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86wwojd3jg.fsf@g.pet.cam.ac.uk>
Peter da Silva wrote:
> It's not that the Lisp cell is implemented as a pair of pointers.
>
> It's that the lisp cell *is* a pair of pointers.
>
> You can do everything with these pointers that you can do with pointers in
> any other language, except perform arithmetic on them. Which was the point
> of the message you're responding to in <············@masala.cc.uh.edu>.
This is true to almost exactly the same extent as is the statement
"Every Lisp object is a pointer". In particular, you say one can
do everything with half-cons-cells that one can with pointers,
except arithmetic; well, actually there isn't much that one can
do with pointers, except arithmetic :-), but in any case you
can't e.g. build an array of pointers using this technology.
You can, of course, build an array of Lisp objects, but you don't
do so by going via cons cells.
Really, the main useful thing one can do with pointers is to
compare them, yielding a notion of object identity. And Lisp
provides the EQ predicate for any pair of objects, not just
half-cons-cells.
> Nonsense. You can build arbitrary structures with these pointers using
> the five basic operations (CONS, CAR, CDR, RPLACA, RPLACD). You obtain
> a pair of pointers with CONS, assign them with RPLACA and RPLACD, and
> dereference them with CAR and CDR.
>
> There's really not much more to lisp than that. Toss in COND, SET, LAMBDA,
> and EVAL and I think you've got it. (Don't beat me up too hard if I missed
> something, it's been a while since I did a lot of lisp). And I'll bet you
> could implement SET by CARing and CDRing around in OBLIST.
Er. It seems like "a while" means "since the days of Lisp 1.5, or
earlier"; or is this a troll?
Common Lisp provides arrays, hash tables, characters, strings,
I/O streams, conditions, closures, classes, and so on and
on and on.
Even Scheme, which is about as minimal as you'll find these days,
has arrays as well as cons cells; and most Scheme implementations
provide hash tables and things too, I believe.
And I don't remember the last time I used a Lisp implementation
that had OBLIST.
HIBT?
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Peter da Silva
Subject: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mht5n$pk3@web.nmti.com>
In article <··············@g.pet.cam.ac.uk>,
Gareth McCaughan <·····@dpmms.cam.ac.uk> wrote:
> Peter da Silva wrote:
> > It's not that the Lisp cell is implemented as a pair of pointers.
> >
> > It's that the lisp cell *is* a pair of pointers.
> >
> > You can do everything with these pointers that you can do with pointers in
> > any other language, except perform arithmetic on them. Which was the point
> > of the message you're responding to in <············@masala.cc.uh.edu>.
> This is true to almost exactly the same extent as is the statement
> "Every Lisp object is a pointer".
Depending on the definition of "pointer", sure.
Look, let's put this in a wee bit of context.
The message that spawned this side-thread said something like "the only
problem with C pointers is that they support arithmetic, what if all you
could do was allocate and dereference them?". And, presumably, assign
them... otherwise there's nothing to dereference.
So this guy at UH said he didn't even want pointers that did that much, and
pointed to scheme as a pointerless language.
The point I'm trying to make is, that if you take out the arithmetic, but
still call what's left a "pointer", then scheme does have pointers. Now you
can argue that what's left isn't really a pointer any more. That's quite
legitimate, but then it's sort of hard to understand the original objection,
because they're not pointers when they're embedded in C either.
> Er. It seems like "a while" means "since the days of Lisp 1.5, or
> earlier"; or is this a troll?
Is Lisp 1.5 still lisp?
> Common Lisp provides arrays, hash tables, characters, strings,
> I/O streams, conditions, closures, classes, and so on and
> on and on.
But those things don't define what Lisp is. They're elaborations. Lisp, at
the bottom level, is the list. The ability to express programs and data in
the same format, and manipulate it using list operations, is what really
defines a language as being part of the lisp family.
> HIBT?
No. I'm simply ignoring a lot of irrelevant issues that, while they make the
language more efficient and convenient, don't change its essential nature.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3073836438931858@naggum.no>
* Peter da Silva
| But those things don't define what Lisp is. They're elaborations. Lisp,
| at the bottom level, is the list. The ability to express programs and
| data in the same format, and manipulate it using list operations, is what
| really defines a language as being part of the lisp family.
it's a persistent myth that Lisp has only one data type, the list.
(obviously, there must be a list of _something_, but hey, myths don't
generally respect logic any day of the week.) I don't think it's wise to
keep that myth alive.
another persistent myth is that Lisp programs are lists. they aren't.
Lisp _source_ code uses lists. _compiled_, it is another data type, like a
code vector, which includes native machine code or perhaps byte code.
what defines the Lisp family to me, after I have had the opportunity to
refine my definition over time, is READ/WRITE CONSISTENCY. all languages
in the extended Lisp family have this in common, and no languages outside
the Lisp family can sport anything like it. that is, the ability to print
(write) some object out in text form and read it back in again (or the
other way around, depending on where the object is originating).
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mi5vn$2kf@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> * Peter da Silva
> | But those things don't define what Lisp is. They're elaborations. Lisp,
> | at the bottom level, is the list. The ability to express programs and
> | data in the same format, and manipulate it using list operations, is what
> | really defines a language as being part of the lisp family.
> it's a persistent myth that Lisp has only one data type, the list.
Of course it doesn't *just* have one data type, any more than APL just has
arrays. But it is the list that defines what Lisp is.
> another persistent myth is that Lisp programs are lists. they aren't.
Sure they are. Compilation is just an optimization. If you know that you're
never going to manipulate a chunk of code, it's a perfectly reasonable
optimization to generate a more efficient representation of the same code.
(this is an extension of the aphorism that "all programming is an excersize
in caching)
But semantically compilation has no effect on understanding a Lisp program.
> what defines the Lisp family to me, after I have had the opportunity to
> refine my definition over time, is READ/WRITE CONSISTENCY. all languages
> in the extended Lisp family have this in common, and no languages outside
> the Lisp family can sport anything like it. that is, the ability to print
> (write) some object out in text form and read it back in again (or the
> other way around, depending on where the object is originating).
You mean like in APL? I don't consider APL part of the extended Lisp family
but it has this property. It's been a while since I've dug into Smalltalk
but I'm pretty sure it has this property as well. If not, it would not be
hard to extend Smalltalk to have it (simply add a "dump" method to the each
primitive object, and define it for collections).
This property is a natural consequence of the original structure of lisp, and
it's been extended with lisp because it's a useful property, but I think it's
a metaphenomenon, one of the many delightful results of the core structure of
the language.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86n2p9ktd0.fsf@g.pet.cam.ac.uk>
Peter da Silva wrote:
> > another persistent myth is that Lisp programs are lists. they aren't.
>
> Sure they are. Compilation is just an optimization. If you know that you're
> never going to manipulate a chunk of code, it's a perfectly reasonable
> optimization to generate a more efficient representation of the same code.
Sure, Lisp programs are lists in that sense. And they're also strings,
as are programs in C, APL, COBOL and anything else. Not to mention that
Lisp programs are also bit-vectors, and (perhaps) disc files.
Is this really a helpful way of looking at things? It doesn't seem like it
to me.
I should add that I don't think it really matters all that much.
Incidentally, in the article to which that was a reply, Erik Naggum wrote
> it's a persistent myth that Lisp has only one data type, the list.
> (obviously, there must be a list of _something_, but hey, myths don't
> generally respect logic any day of the week.)
As a professional pedant I'd like to point out that since the
empty list is a list, there's no inherent absurdity in the idea
of a language whose only data type is the list. Working in it
would be a bit like doing mathematics in terms of pure ZF set theory,
I suppose. (That is: horrible.)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
In article <··············@g.pet.cam.ac.uk> Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
>> > another persistent myth is that Lisp programs are lists. they aren't.
>>
>> Sure they are. Compilation is just an optimization. If you know that you're
>> never going to manipulate a chunk of code, it's a perfectly reasonable
>> optimization to generate a more efficient representation of the same code.
>
>Sure, Lisp programs are lists in that sense. And they're also strings,
>as are programs in C, APL, COBOL and anything else. Not to mention that
>Lisp programs are also bit-vectors, and (perhaps) disc files.
>
>Is this really a helpful way of looking at things? It doesn't seem like it
>to me.
I think it might be helpful, because
a) They look like Lisp lists in the source code
b) They behave like lists when writing macros.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86hgfmgpgd.fsf@g.pet.cam.ac.uk>
Peter da Silva wrote:
> The message that spawned this side-thread said something like "the only
> problem with C pointers is that they support arithmetic, what if all you
> could do was allocate and dereference them?". And, presumably, assign
> them... otherwise there's nothing to dereference.
>
> So this guy at UH said he didn't even want pointers that did that much, and
> pointed to scheme as a pointerless language.
>
> The point I'm trying to make is, that if you take out the arithmetic, but
> still call what's left a "pointer", then scheme does have pointers.
OK, fine. But this doesn't really have anything to do with cons cells.
It's the objects stored inside the cons cells that are pointers, and
they aren't made any different by having "cons" applied to them.
It seems to me that if you remove the ability to do arithmetic on
pointers (let's include comparison under the heading of "arithmetic")
then the only really distinctive thing that's left is that they give
you some sort of notion of object identity. Well, how do you do that
with your cons cell implementation? Answer: you can tell whether e.g.
the objects referenced in the CAR of A and the CAR of B are the same
object by calling (eq (car a) (car b)). At which point, what's been
gained by the consing? you could just have called (eq a b). What
gives Lisp something like pointers is not cons cells, but EQ.
You can see it doesn't really have anything to do with cons cells,
because the same arguments would apply equally well using arrays
(you "make a pointer" to X by doing (vector x), and you "dereference"
it by doing (aref x 0)), or hash tables, or structures, or, or, ... .
In fact, I'd argue that boxing things in cons cells makes Lisp
objects *less* like pointers; because the natural ways of
comparing them no longer have semantics like those of pointer
comparison in languages like C. (eq (cons a nil) (cons b nil))
isn't a pointer comparison between A and B; nor is
(equal (cons a nil) (cons b nil)); what you need is
just (eq a b).
> > Er. It seems like "a while" means "since the days of Lisp 1.5, or
> > earlier"; or is this a troll?
>
> Is Lisp 1.5 still lisp?
Yeah, of course. But it's not what most people mean by "Lisp", and
speaking of it in the present tense is a bit eccentric (although
I'm sure there still *are* a few 1.5ish systems around).
It's a bit like making statements about "Unix" without qualification
when it turns out that you mean Version 6.
> But those things don't define what Lisp is. They're elaborations. Lisp, at
> the bottom level, is the list. The ability to express programs and data in
> the same format, and manipulate it using list operations, is what really
> defines a language as being part of the lisp family.
That might be true historically, but I'm not sure it's true now.
Sure, Lisp without s-expressions wouldn't be Lisp; but I'm not sure
that Lisp without dynamic typing, or Lisp without closures (which
1.5 didn't have...) would really be Lisp either.
> No. I'm simply ignoring a lot of irrelevant issues that, while they make the
> language more efficient and convenient, don't change its essential nature.
I'm not sure I believe in essential natures. Really, what makes Lisp
Lisp is the fact that it's descended from something else that was
Lisp, which was descended from <etc>...
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86g1v6gor9.fsf@g.pet.cam.ac.uk>
I wrote:
> It seems to me that if you remove the ability to do arithmetic on
> pointers (let's include comparison under the heading of "arithmetic")
> then the only really distinctive thing that's left is that they give
> you some sort of notion of object identity.
Oh, I forgot. The other thing pointers buy you is the ability to
refer to bits of existing data structures and mutate them; thus,
in C you can say
foo = &bar[123];
mangle(foo);
++*foo;
and so on. This, again, is something that cons cells don't do.
(If you're itching to say "What about RPLACA?", the answer is
that you've missed the point; I'll be glad to explain this if
you disagree.)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Fergus Henderson
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mm1j5$9vq@mulga.cs.mu.OZ.AU>
Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
>Oh, I forgot. The other thing pointers buy you is the ability to
>refer to bits of existing data structures and mutate them; thus,
>in C you can say
>
> foo = &bar[123];
> mangle(foo);
> ++*foo;
>
>and so on.
Standard Pascal has pointers, but you can't do that in standard Pascal.
Perhaps you meant "The other thing C/C++ pointers buy you ..."?
^^^^^
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86afldl43k.fsf@g.pet.cam.ac.uk>
Fergus Henderson wrote:
[getting pointers to bits of structures]
> Standard Pascal has pointers, but you can't do that in standard Pascal.
>
> Perhaps you meant "The other thing C/C++ pointers buy you ..."?
> ^^^^^
Perhaps. I thought this whole thing started with some question
along the lines of "Would C's pointers be any use if they didn't
have arithmetic operations?", so I was going along with what
seemed to be the most suitable notion of "pointer".
Anyway, I'm still racking my brains trying to come up with any
use of pointers for which cons cells are any advance on plain
Lisp objects, and I can't think of many... Maybe my problem is
that I don't know what pointers are used for in languages where
they exist but are (compared to C) heavily restricted. I can
think of the following uses for pointers:
- giving a small object to pass around, thus avoiding large
copying operations etc
. (Lisp objects themselves have this sort of semantics)
- giving a notion of object identity
. (Lisp objects themselves have this, with EQ)
- making pass-by-reference possible when it doesn't
otherwise exist
. (Lisp doesn't provide any way to do that with functions;
you can define macros to get sort-of-similar results;
none of this is helped by putting things in extra cons
cells)
- making it possible for things to get side-effected in
non-obvious ways, thus introducing bugs
. (Lisp may or may not have this, but putting things in
cons cells doesn't make much difference)
- making it possible to store objects of varying types
in a single uniform structure
. (Lisp has this anyway, without fiddling with pointers)
- providing access to the underlying hardware's notion
of "address"
. (Lisp doesn't generally do this; if it does it's via
an entirely separate datatype.)
- accessing array elements etc marginally more efficiently
. (Lisp doesn't do this; it's regarded as a compiler issue.)
- allowing recursive structured types
. (Lisp allows this without requiring messing about with
pointers; again, this drops out as a consequence of the
fact that Lisp objects either are pointers or don't
need pointers.)
I just can't think of a single case where I would use pointers
in C, or references in Pascal or Modula-3, or any other such
thing, and where, if I had to do the same thing in Lisp, I'd
introduce a cons-cell layer in the way Peter da Silva describes.
Doubtless my imagination is lacking; please educate me.
Incidentally, I don't disagree with Peter da Silva's claim that
Lisp and its friends "have pointers"; I just don't think that
cons cells are the place to look for them. The object is the
pointer. What Lisp *doesn't* have is any separate notion of a
pointer type (unless you count SETF places, which aren't
first-class); all the things you do with pointers in other
languages are done by other means in Lisp, or else can't be
done (and are regarded as a Bad Thing).
Also incidentally, a question: is there any good reason for the
fact that Common Lisp has DEFINE-MODIFY-MACRO but not anything
like
(updatef #'(lambda (x) (* x 3)) (aref (car foo) (fibonacci 12)))
? It seems a bit like providing DEFUN but not LAMBDA.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5ml6lq$h7@web.nmti.com>
In article <··············@g.pet.cam.ac.uk>,
Gareth McCaughan <·····@dpmms.cam.ac.uk> wrote:
> It's a bit like making statements about "Unix" without qualification
> when it turns out that you mean Version 6.
You mean like when I say something like "neither the Berkeley socket interface
nor the TLI interface really conform to the normal UNIX API"?
It helps to have a sense of history. Honest.
> I'm not sure I believe in essential natures.
Ah. An unbeliever.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86k9khfzbr.fsf@g.pet.cam.ac.uk>
Peter da Silva wrote:
> It helps to have a sense of history. Honest.
Sure. But history isn't something that ends N years in the
past; it's a thing that progresses and continues, and recent
history is just as much history as old history. So I contend
that someone saying "Basically, Lisp is just cons cells"
is showing a lack of sense of history.
Anyway, this particular debate is getting some way from the
original question. Did you decline to answer any of my
real points because they weren't worth responding to, or
because you didn't have anything to say, or because I should
be reading your responses to Erik Naggum?
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Gareth McCaughan
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <86pvu87roy.fsf@g.pet.cam.ac.uk>
Peter da Silva wrote:
> Which ones?
>
> Honestly, I don't know which points you're referring to.
>
> It's possible that they're ones I've already answered in other parts of
> this thread (which I really expected would be a brief side-issue), or
> they're addressing an issue that I never brought up... you just think I
> did. There's a lot of that going around. On all sides.
>
> For example, people keep telling me that other objects in Lisp also act as
> pointers. I've never denied it, I just brought up CONS cells because they're
> the best example of a data structure that's uniformly available in lisps
> that can be used as "an opaque reference" (avoiding using the P word here).
Well, I think the most important points were:
1. The original context was a claim that Lisp has objects that
provide what C pointers do, minus pointer arithmetic; there
is more to that than "opaque references".
2. The point isn't that other types of containers provide the
same opaque-reference features as cons cells; it's that
cons cells don't provide any opaque reference features.
The pointerishness of Lisp objects simply doesn't come
from being put in cons cells, it comes from the behaviour
of Lisp objects.
It's as if you'd said "But C *does* have word-sized integers;
they're called structure members. You can say
struct foo { int t; } x;
and use x.t when you want to work with an integer". You can,
but it's not any more an integer for being wrapped in a
struct.
None of this is desperately important. We're agreed (I think)
that Lisp provides features that let you do some of what C's
pointers will do, and we're agreed (I think) that there are
important features of C pointers that Lisp objects (or, if you
must, cons cells) don't share, *other than arithmetic*. So
at this point we're arguing about side issues; I'm perfectly
content to stop here (and perfectly clear to carry on arguing
if you want).
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3074059083251570@naggum.no>
* Peter da Silva
| For example, people keep telling me that other objects in Lisp also act
| as pointers. I've never denied it, I just brought up CONS cells because
| they're the best example of a data structure that's uniformly available
| in lisps that can be used as "an opaque reference" (avoiding using the P
| word here).
dragging in the cons cell is like dragging a red herring across your path
to confuse anybody who might be trying to follow your point.
the cons cell holds two Lisp objects. any Lisp variable can hold one Lisp
object. what's the big deal with cons cells that isn't true of variables?
the general machine representation of a Lisp object is a machine word (in
all implementations I know and have heard about), which, if it can hold the
value, holds the value, otherwise it holds the machine address of the value
plus some administrative information like type tags. the typical values
that fit in a machine word are small integers (fixnums) and characters.
other values have to be "boxed", i.e., put in some other memory and a
reference (pointer!) to that memory passed around as the value. `eq'
compares the machine representation of these objects. assignment copies
the machine representation of the Lisp object, which is this pointer or
value-that-fits-in-a-machine-word. with the exception of the values that
fit in a machine word, this has the traditional C pointer semantics. (I
have already granted Peter this point several times over. please get it!)
it's worth noting that (cons 1 2) yields a pointer (!) to a cons cell that
contains two fixnums, not two pointers. where this pointer concept differs
from C's pointer concept is that you can't make a new pointer to a
different part of memory by doing arithmetic on an existing pointer, you
can't obtain the address of an object that doesn't already have a pointer
to it, and you can't treat the pointed-to object and the object as two
distinct types or values.
somebody requested a definition. the defining property of a pointer qua
language construct is that the language supports a type that is a pointer
to another of its supported types. Common Lisp does not have this property
for any of its types. C does have it for all of its types. (however, some
Lisps support locatives, which have a type that is a pointer to another
type.) as far as language semantics goes, Lisp does _not_ have pointers.
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mpa5t$m5u@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> the cons cell holds two Lisp objects. any Lisp variable can hold one Lisp
> object. what's the big deal with cons cells that isn't true of variables?
You can treat a variable as a pointer, too. I could have picked that as my
example just as easily, and you would have been beating up on me for that.
That "there are other objects in lisp that can be treated as a pointer" is
a red herring.
> the machine representation of the Lisp object, which is this pointer or
> value-that-fits-in-a-machine-word. with the exception of the values that
> fit in a machine word, this has the traditional C pointer semantics. (I
> have already granted Peter this point several times over. please get it!)
I accept that you've granted that point, the problem is that it's got nothing
to do with anything I've said. You can implement a lisp that doesn't use
machine words to store objects. On an IBM 1620 you wouldn't be able to
implement a lisp that way (because you can't store *anything* in a single
machine word, pretty much... it's a BCD machine).
(and, yes, there are a few IBM 1620s still running, nearly 40 years after
they were discontinued)
> it's worth noting that (cons 1 2) yields a pointer (!) to a cons cell that
> contains two fixnums, not two pointers.
I didn't say it *contained* two pointers. I said it *was* two pointers. If
you put 1 into it, the implementation may not explicitly allocate a separate
word for 1 with the address of that cell in the first word of a two word
object. It doesn't matter if it does or not... the cons cell still behaves
at the language level as a pointer to the value 1. There is no operation
you can perform in lisp to tell that there is, or that there is not, an
explicit machine address to a unique cell containing the value 1.
So the hardware implementation of the cons cell is irrelevant. OK? It's another
red herring.
> somebody requested a definition. the defining property of a pointer qua
> language construct is that the language supports a type that is a pointer
> to another of its supported types. Common Lisp does not have this property
> for any of its types.
A cons cell is a type that is a pointer to any other of the supported types.
So is a variable.
So is an array.
> as far as language semantics goes, Lisp does _not_ have pointers.
The semantic difference between cons cells and (say) Pascal pointers (other
than a cons cell being able to point to two objects... a property that can
be ignored by not using one of the values) still eludes me.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3074090789056407@naggum.no>
* Peter da Silva
| A cons cell is a type that is a pointer to any other of the supported types.
| So is a variable.
| So is an array.
Peter, you really don't know what you're talking about.
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
Erik Naggum <····@naggum.no> wrote:
+---------------
| it's worth noting that (cons 1 2) yields a pointer (!) to a cons cell that
| contains two fixnums, not two pointers.
+---------------
Not in all Lisps. For example, in SIOD Scheme *all* objects are boxed,
thus a cons cell is two pointers, period.
-Rob
p.s. Yes, there is a small amount of magic in the corners that avoids
allocating in the heap for the most common small numbers by preallocating
a few "inums" in fixed locations, and arranging so that arithmetic results
in that range share such an instance if it exists.
p.p.s. And yes, SIOD cons cells also have a type field. But that's not a
Lisp/Scheme requirement either, since you can always use BiBOP for typing.
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 415-933-1673 FAX: 415-933-4392
2011 N. Shoreline Blvd. [after 8/2/1997 ==> 650-933-xxxx]
Mountain View, CA 94043 PP-ASEL-IA
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3073830464727184@naggum.no>
* Peter da Silva
| There's really not much more to lisp than that. Toss in COND, SET, LAMBDA,
| and EVAL and I think you've got it. (Don't beat me up too hard if I missed
| something, it's been a while since I did a lot of lisp). And I'll bet you
| could implement SET by CARing and CDRing around in OBLIST.
"a while"? looks like it was 25 years since you last saw Lisp. *sigh*
in Common Lisp (since 1984), you could use hash tables for sets.
as for your theory of dereferencing pointers, a CONS is an object with two
slots. CAR returns the _contents_ of the first slot, CDR the second. if
you pass an object not created by CONS to CAR, you get a type error.
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
From: Peter da Silva
Subject: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mi2j9$dc@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> in Common Lisp (since 1984), you could use hash tables for sets.
But a language without hash tables is still a lisp. A language without
lists isn't a lisp.
> as for your theory of dereferencing pointers, a CONS is an object with two
> slots.
What's the difference between a slot and a pointer, semantically?
> CAR returns the _contents_ of the first slot, CDR the second.
"Returning the contents of" is "dereferencing". That's what the word
means, taking a reference to an object and returning the object itself.
Whether the words you use are "a slot containing an object" or "a pointer
to an object", semantically the operation is the same one.
> if you pass an object not created by CONS to CAR, you get a type error.
Yes, they're safe. That's cool. That's also true of pointers in Pascal.
If I say "var a: int" and then later "a^" it'll give me a type error. Should
the pointers in Pascal be called "slots" instead?
Let's say I defined a C-like language with "slots" instead of "pointers". If
the operations on the "slots" are restricted to exclude arithmetic (which means
excluding casting, because that allows you to perform arithmetic), then are
they somehow no longer pointers? If not, how do they differ from the "slots"
you're talking about above?
(remember, I'm just responding to an assertion that pointers, as defined above,
don't exist in scheme)
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3073883060789102@naggum.no>
* Peter da Silva
| What's the difference between a slot and a pointer, semantically?
hello? the same difference as between a struct member and pointer.
| "Returning the contents of" is "dereferencing".
really? suppose a cons is defined as struct cons { Object car, cdr; }; and
a struct cons foo and exists. the C expression `foo.car' returns the
contents of the `car' slot (struct member). suppose that struct cons *bar
is a pointer. while `*bar' dereferences the pointer, `bar->car' and
(*bar).car returns the contents of the `car' slot in the pointed-to cons.
| Let's say I defined a C-like language with "slots" instead of "pointers".
I wonder, have you never seen the word "slot" before? Lisps have had
`defstruct' in various shapes and forms for a _very_ long time. the word
"slot" is used for the individual objects that go into a structure.
| (remember, I'm just responding to an assertion that pointers, as defined
| above, don't exist in scheme)
I think your responses on Lisp in general and this issue in particular are
very weak.
in a language like C that has a type that is a pointer to another type, and
the programmer is able to manipulate the pointer as a value, "dereferencing"
has meaning. in a language like Scheme or Lisp where you cannot take the
address of objects, and you cannot manipulate the pointer itself, it has no
meaning to talk of "derefencing" even though it would have been meaningful
if you had implemented this language in a C-like language.
of course Scheme _uses_ pointers in the C sense for its memory accesses,
but Scheme itself doesn't expose them to the programmer. it's a slightly
confusing issue, obviously, but it's worth noting that a Scheme programmer
who doesn't understand that he's dealing with pointers to objects will be
very confused by the language, and a Scheme programmer who thinks in terms
of pointers will have a hard time writing serious code in in Scheme -- he
wouldn't see the data structure because of all the pointers.
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mk16a$gtn@web.nmti.com>
You're getting into the implementation level again. I'm talking about the
semantics of dotted pairs. Leave all the rest of the language aside for the
moment, and consider an ideal "pure" lisp with only cells and atoms.
Also, I'm not talking about pointers in the "C" sense. The message that
started this side issue was dealing more with pascal-like pointers. No
arithmetic, no casting.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> of course Scheme _uses_ pointers in the C sense for its memory accesses,
> but Scheme itself doesn't expose them to the programmer. it's a slightly
> confusing issue, obviously, but it's worth noting that a Scheme programmer
> who doesn't understand that he's dealing with pointers to objects will be
> very confused by the language, and a Scheme programmer who thinks in terms
> of pointers will have a hard time writing serious code in in Scheme -- he
> wouldn't see the data structure because of all the pointers.
I didn't say that it's *useful* to program lisp (or scheme) as if it had
pointers.
In fact building circular data structures with RPLACA and RPLACD is very
very dangerous. You can get into a lot of trouble by decomposing lists
back into pointer pairs. But if you sit back and look at the semantics at
the language level... not the implementation level... of lisp itself..
that's what they are.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
Peter da Silva writes:
>You're getting into the implementation level again. I'm talking about the
>semantics of dotted pairs. Leave all the rest of the language aside for the
>moment, and consider an ideal "pure" lisp with only cells and atoms.
Well, the fact that there's a well-known implementation of cons, car
and cdr in scheme using just functions would seem to imply that
`pointers' are the implementation detail.
(Taken from SICP, first edition, pg. 83):
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1 -- CONS") m)))
dispatch)
(define (car z) (z 0))
(define (cdr z) (z 1))
Here's the surrounding text:
...Consider the notion of a pair, which we used in order to define our
rational numbers. We never actually said what a pair was, only that
the language supplied operators CONS, CAR and CDR for operating on
pairs. But the only thing we need to know about these three operators
is that if we glue two objects together using CONS we can retrieve the
objects using CAR and CDR. That is, the operators satisfy the
condition that, for any objects X and Y, if Z is (CONS X Y) then (CAR
Z) is X and (CDR Z) is Y. Indeed, we mentioned that these three
operators are included as primitives in our language. However, any
triple of procedures that satisfies the above condition can be used as
the basis for implementing pairs. This point is illustrated
strikingly by the fact that we could implement CONS, CAR and CDR
without using any data structures at all but only using procedures....
--
-Fred Gilham ······@csl.sri.com
Fred Gilham <······@japonica.csl.sri.com> writes:
> (define (cons x y)
> (define (dispatch m)
> (cond ((= m 0) x)
> ((= m 1) y)
> (else (error "Argument not 0 or 1 -- CONS") m)))
> dispatch)
>
> (define (car z) (z 0))
>
> (define (cdr z) (z 1))
This is an interesting example. In Common Lisp it would look like
this:
(defun mycons (el1 el2)
#'(lambda (what)
(ecase what
(0 el1) (1 el2))))
(defun mycar (x) (funcall x 0))
(defun mycdr (x) (funcall x 1))
;; Tested on Allegro CL for Linux and CMU CL
(setq hey (mycons 'oh 'well)
=> #<Interpreted Closure (:INTERNAL MYCONS) @ #x83c7a72>
(mycar hey)
=> OH
(mycdr hey)
=> WELL
One point is worth noting, though -- I have no idea how to implement
RPLACA and RPLACD using this scheme.
> ...Consider the notion of a pair, which we used in order to define our
> rational numbers. We never actually said what a pair was, only that
> the language supplied operators CONS, CAR and CDR for operating on
> pairs. But the only thing we need to know about these three operators
> is that if we glue two objects together using CONS we can retrieve the
> objects using CAR and CDR. That is, the operators satisfy the
> condition that, for any objects X and Y, if Z is (CONS X Y) then (CAR
> Z) is X and (CDR Z) is Y. Indeed, we mentioned that these three
> operators are included as primitives in our language. However, any
> triple of procedures that satisfies the above condition can be used
> as the basis for implementing pairs. This point is illustrated
> strikingly by the fact that we could implement CONS, CAR and CDR
> without using any data structures at all but only using
> procedures....
This is not a complete description of Lisp conses. In Lisp you can
also change the CAR or the CDR of a cons.
P.S.
CMU CL gurus might be able to help me -- is the following example a
bug:
(setq el1 (mycons 'oh 'well))
Warning: Declaring EL1 special.
=> #<Interpreted Function "LAMBDA (EL1 EL2)" {9017311}>
(mycar el1) ; I expect OH
=> #<Interpreted Function "LAMBDA (EL1 EL2)" {9017311}>
(mycdr el1)
=> WELL
Shouldn't the inner binding of EL1 as a function argument take
precedence of the global special binding? This stinks of dynamical
scoping, and Allegro fares better in this example (`(mycar el1)'
yields OH, as expected).
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"
In article <···············@jagor.srce.hr>,
Hrvoje Niksic <·······@srce.hr> wrote:
>
>This is an interesting example. In Common Lisp it would look like
>this:
>
>(defun mycons (el1 el2)
> #'(lambda (what)
> (ecase what
> (0 el1) (1 el2))))
>
>(defun mycar (x) (funcall x 0))
>
>(defun mycdr (x) (funcall x 1))
>
>
>One point is worth noting, though -- I have no idea how to implement
>RPLACA and RPLACD using this scheme.
>
This is simple, I am pretty sure something similar to the following
can be found in "Abelson H., Sussman G.J., Sussman J.: Structure and
Interpretation of Computer Programs, MIT Press, Cambridge, MA, 1985."
(yes, I know there is a new edition out, but I only have the old
pointer handy :-(
The only complication is due to the requirement of returning the
"cons-cell" as a result from rplaca/d
(defun mycons (car cdr)
(let (cons-cell)
(setq cons-cell #'(lambda (opcode &optional new-contents)
(ecase opcode
(0 car)
(1 cdr)
(2 (setq car new-contents)
cons-cell)
(3 (setq cdr new-contents)
cons-cell))))))
(defun mycar (x) (funcall x 0))
(defun mycdr (x) (funcall x 1))
(defun myrplaca (x new-car) (funcall x 2 new-car))
(defun myrplacd (x new-cdr) (funcall x 3 new-cdr))
Hope that helps,
--
Bernhard Pfahringer
···············@cs.waikato.ac.nz http://www.ai.univie.ac.at/~bernhard
In article <···············@jagor.srce.hr>,
Hrvoje Niksic <·······@srce.hr> wrote:
>
>This is an interesting example. In Common Lisp it would look like
>this:
>
>(defun mycons (el1 el2)
> #'(lambda (what)
> (ecase what
> (0 el1) (1 el2))))
>
>(defun mycar (x) (funcall x 0))
>
>(defun mycdr (x) (funcall x 1))
>
>
>One point is worth noting, though -- I have no idea how to implement
>RPLACA and RPLACD using this scheme.
>
This is no problem, by a straightforward extension:
(defun mycons (x y)
#'(lambda (cdrp setp val)
(if setp
(if cdrp
(setq y val)
(setq x val))
(if cdrp y x))))
(defun mycar (a) (funcall a nil nil nil))
(defun mycdr (a) (funcall a t nil nil))
(defun myrplaca (a val) (funcall a nil t val))
(defun myrplacd (a val) (funcall a t t val))
;; or without conditionals (and IMO more elegant):
(defun mycons (x y)
#'(lambda (fun)
(multiple-value-bind (res newx newy) (funcall fun x y)
(setq x newx y newy)
res)))
(defun mycar (a) (funcall a #'(lambda (x y) (values x x y))))
(defun mycdr (a) (funcall a #'(lambda (x y) (values y x y))))
(defun myrplaca (a val) (funcall a #'(lambda (x y) (values val val y))))
(defun myrplacd (a val) (funcall a #'(lambda (x y) (values val x val))))
Any data structure can be implemented along these lines - if you don't
need mutability, pure lambda-calculus is sufficient, although that is
fully lazy as well.
__Mark
[ ·····@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]
Hrvoje Niksic <·······@srce.hr> writes:
> Fred Gilham <······@japonica.csl.sri.com> writes:
>
> > [example of cons cells as closures deleted]
>
> This is an interesting example. In Common Lisp it would look like
> this:
>
> (defun mycons (el1 el2)
> #'(lambda (what)
> (ecase what
> (0 el1) (1 el2))))
>
> (defun mycar (x) (funcall x 0))
>
> (defun mycdr (x) (funcall x 1))
This is exactly how one would do it it "modern" scheme. SICP
scheme (1st ed.) is a little out of date.
>
> One point is worth noting, though -- I have no idea how to implement
> RPLACA and RPLACD using this scheme.
Just more dispatching:
(defun mycons (car cdr &aux cell)
(setf cell #'(lambda (op &optional (arg nil have-arg))
(case op
(car (if have-arg (error "too many arguments to car") car))
(cdr (if have-arg (error "too many arguments to car") cdr))
(rplaca (if have-arg
(progn
(setf car arg)
cell)
(error "too few arguments to rplaca")))
(rplacd (if have-arg
(progn
(setf cdr arg)
cell)
(setf cdr arg)
(error "too few arguments to rplacd")))
(otherwise (error "unknown operation ~A" op))))))
(defun mycar (cell) (funcall cell 'car))
(defun mycdr (cell) (funcall cell 'cdr))
(defun myrplaca (cell new-car) (funcall cell 'rplaca new-car))
(defun myrplacd (cell new-cdr) (funcall cell 'rplacd new-cdr))
Now, it's clear to me that in the following code, the compiler
can easily inline mycar, etc. and, if it KNOWS that it's calling
the closure returned by mycons, then in almost all cases it can
inline/optimize the funcall away, leaving just a reference (or
assignment) into the closure's environment. So, this
representation of cons cells has the potential to have as little
overhead as the traditional one, given the caveat that the
compiler knows what it's about to funcall.
My question then becomes, "How likely is a good compiler to
figure this out, and is there some way we could declaim a symbol
that would tell the compiler that it could do that?" Ideally,
with high speed and middling safety, a call like
(mycar foo)
could compile into
(cond
((myconsp foo) (closure-reference foo 0))
(t (funcall foo 'car)))
or even just
(closure-reference foo 0)
(assuming that closure-reference takes a closure and an offset
into the environment).
> (defun mycons (car cdr &aux cell)
> (setf cell #'(lambda (op &optional (arg nil have-arg))
> (case op
> (car (if have-arg (error "too many arguments to car") car))
> (cdr (if have-arg (error "too many arguments to car") cdr))
> (rplaca (if have-arg
> (progn
> (setf car arg)
> cell)
> (error "too few arguments to rplaca")))
> (rplacd (if have-arg
> (progn
> (setf cdr arg)
> cell)
> (setf cdr arg)
> (error "too few arguments to rplacd")))
> (otherwise (error "unknown operation ~A" op))))))
>
> (defun mycar (cell) (funcall cell 'car))
> (defun mycdr (cell) (funcall cell 'cdr))
> (defun myrplaca (cell new-car) (funcall cell 'rplaca new-car))
> (defun myrplacd (cell new-cdr) (funcall cell 'rplacd new-cdr))
From: Erik Naggum
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <3073917302219164@naggum.no>
* Peter da Silva
| You're getting into the implementation level again.
Peter, at least allow room for the possibility that I know what I'm doing
better than you do.
it is at the implementation level that Lisp and C have pointers. at the
language level, C has a pointer concept, and Lisp has not. end of story.
#\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.
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
* Peter da Silva
| You're getting into the implementation level again.
it is at the implementation level that Lisp and C have pointers. at the
language level, C has a pointer concept, and Lisp has not. end of story.
Somehow it is my feeling that this whole silly debate would end as
soon as everybody would state precisely what they mean when they say
"pointer".
Regards,
--
-Matthias
From: ········@bayou.uh.edu
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mmjjp$95j$1@Masala.CC.UH.EDU>
Matthias Blume (·····@mocha.cs.princeton.edu) wrote:
[Snip]
: Somehow it is my feeling that this whole silly debate would end as
: soon as everybody would state precisely what they mean when they say
: "pointer".
Been there. Done that. Still arguing.
: Regards,
: --
: -Matthias
--
Cya,
Ahmed
Everywhere I go they all talk the same,
They don't even have to try to make me feel so lame
"Argyle" by the Bouncing Souls
In article <··············@mocha.CS.Princeton.EDU>,
·····@mocha.cs.princeton.edu (Matthias Blume) wrote:
> In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
>
> * Peter da Silva
> | You're getting into the implementation level again.
>
...deleted
>
> Somehow it is my feeling that this whole silly debate would end as
> soon as everybody would state precisely what they mean when they say
> "pointer".
Shhhh! Don't make them stop :-)
--
Best Wishes, Bengt
Email: ······@damek.kth.se
From: Mukesh Prasad
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <338D6641.7A52@polaroid.com>
Erik Naggum wrote:
>
> * Peter da Silva
> | There's really not much more to lisp than that. Toss in COND, SET, LAMBDA,
> | and EVAL and I think you've got it. (Don't beat me up too hard if I missed
> | something, it's been a while since I did a lot of lisp). And I'll bet you
> | could implement SET by CARing and CDRing around in OBLIST.
>
> "a while"? looks like it was 25 years since you last saw Lisp. *sigh*
>
> in Common Lisp (since 1984), you could use hash tables for sets.
set? Like wow, man! marvels of modern technology...
From: Hrvoje Niksic
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <kigraerdzs8.fsf@jagor.srce.hr>
·····@nmti.com (Peter da Silva) writes:
> You're right, but I'm not talking about the implementation. It's
> not that the Lisp cell is implemented as a pair of pointers. It's
> that the lisp cell *is* a pair of pointers.
[... you can implement everything as a list ...]
> There's really not much more to lisp than that. Toss in COND, SET,
> LAMBDA, and EVAL and I think you've got it. (Don't beat me up too
> hard if I missed something, it's been a while since I did a lot of
> lisp). And I'll bet you could implement SET by CARing and CDRing
> around in OBLIST.
This is a joke, of course?
<URL:http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/
html/cltl/clm/node1.html>
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Unspeakable horrors from outer space paralyze the living and
resurrect the dead!
From: Mukesh Prasad
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <338D67AA.354B@polaroid.com>
Hrvoje Niksic wrote:
>
> ·····@nmti.com (Peter da Silva) writes:
>
> > You're right, but I'm not talking about the implementation. It's
> > not that the Lisp cell is implemented as a pair of pointers. It's
> > that the lisp cell *is* a pair of pointers.
> [... you can implement everything as a list ...]
> > There's really not much more to lisp than that. Toss in COND, SET,
> > LAMBDA, and EVAL and I think you've got it. (Don't beat me up too
> > hard if I missed something, it's been a while since I did a lot of
> > lisp). And I'll bet you could implement SET by CARing and CDRing
> > around in OBLIST.
>
> This is a joke, of course?
No. "set" is a version (more pure form) of "setq". You can
implement set (or setq if you don't know from set) manually
as long as the symbol table is exposed under some name. "oblist"
is apparently the name used to expose the symbol table in the
Lisp implementation ·····@nmti.com is referring to (Maclisp, maybe?).
Mukesh Prasad <·······@polaroid.com> writes:
> No. "set" is a version (more pure form) of "setq".
I didn't refer to implementing SET in terms of OBARRAY a possible
joke, but to Peter's assertion that is not much more to Lisp than
lists.
As Erik Naggum pointed out, data types that have nothing to do with
lists, varying from vectors and arrays to hash-tables and structures,
have been an part of Lisp for a long long time. While it is very true
that, even so, Lisp code can be represented as a list (albeit very
inefficiently), operations with such data types definitely cannot be
implemented in terms of lists. Therefore, there is much much more to
Lisp than just lists.
Another branch of the thread is Peter and Erik arguing about the
semantics of pointers. I'm not sure exactly what they are arguing
about, but as far as I am concerned, lisp objects basically *are*
similar to C pointers. They have the following qualities:
1) they can be compared (EQ vs. not EQ; not unlike == and !=);
2) they can be dereferenced (whenever they are accessed);
3) they are type-safe -- a Lisp objects knows the type of the object
it holds (or points to).
The properties of C pointers not attributable to Lisp objects are:
a) arithmetic properties -- pointers can be treated similar to
numbers, which incrementing, comparison, *and* casting;
b) little or no type information. Some type information is available
at compile-time (for example, the compiler "knows" that `int *'
should point to an int, but that knowledge is of little worth other
than for pointer-arithmetic computations).
While qualities a) and b) buy you some speed and space, and make
accessing data more straightforward (bypassing runtime checks), they
make it much harder (if not impossible) to implement tagged types,
runtime type-safety and probing, garbage collection (or whatever form
of automatic memory management), and other parts normal to find in a
Lisp system.
So yes, one can call say that after evaluating:
(setq a (vector 1 2 3))
`A' is a "pointer" to the vector, but only if he is careful to define
what he understands as a pointer, and how it may differ from someone
else's understanding of the terms. Lack of such definition may have
lead Peter and Erik to the wrong path; to me it seems that they argue
about the same thing in different words.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth
Hrvoje Niksic wrote:
[snip]
> Another branch of the thread is Peter and Erik arguing about the
> semantics of pointers. I'm not sure exactly what they are arguing
> about, but as far as I am concerned, lisp objects basically *are*
> similar to C pointers. They have the following qualities:
>
> 1) they can be compared (EQ vs. not EQ; not unlike == and !=);
>
> 2) they can be dereferenced (whenever they are accessed);
>
> 3) they are type-safe -- a Lisp objects knows the type of the object
> it holds (or points to).
>
> The properties of C pointers not attributable to Lisp objects are:
>
> a) arithmetic properties -- pointers can be treated similar to
> numbers, which incrementing, comparison, *and* casting;
>
> b) little or no type information. Some type information is available
> at compile-time (for example, the compiler "knows" that `int *'
> should point to an int, but that knowledge is of little worth other
> than for pointer-arithmetic computations).
>
But when you program in Lisp, you never think of the
address of an object. When you program in C, you do
think of a pointer as the address of an integer, a
character, an array... and you as the programmer decide
when and if to dereference a pointer or to get a pointer
to an object. Which is the fundamental difference.
The similarities and differences you are pointing out,
look quite irrelevant to me, sort of like arguing that
the difference between "car" and "strcpy" consists
of the letters a vs the letters s,t,p,y. Literally true,
but insightless.
Mukesh Prasad <·······@polaroid.com> writes:
> But when you program in Lisp, you never think of the address of an
> object. When you program in C, you do think of a pointer as the
> address of an integer, a character, an array... and you as the
> programmer decide when and if to dereference a pointer or to get a
> pointer to an object. Which is the fundamental difference.
It's a matter of preference. To me, a pointer is not necessarily
connected to addresses. This is more obvious in Pascal than in C.
I argue that the properties shared by references Lisp objects and C
pointers are numerous enough to be able to call Lisp objects
"pointers", provided that I define what exactly I am talking about.
It is certainly wrong to just say "Lisp has pointers too", without
giving a useful context.
> The similarities and differences you are pointing out, look quite
> irrelevant to me, sort of like arguing that the difference between
> "car" and "strcpy" consists of the letters a vs the letters s,t,p,y.
> Literally true, but insightless.
Uhm. Well, we disagree then.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.
Hrvoje Niksic wrote:
>
> Mukesh Prasad <·······@polaroid.com> writes:
>
> > But when you program in Lisp, you never think of the address of an
> > object. When you program in C, you do think of a pointer as the
> > address of an integer, a character, an array... and you as the
> > programmer decide when and if to dereference a pointer or to get a
> > pointer to an object. Which is the fundamental difference.
>
> It's a matter of preference. To me, a pointer is not necessarily
> connected to addresses. This is more obvious in Pascal than in C.
Ah! So your argument is "To me, Lisp has pointers same as C"?
This is not a statement I think anybody would disagree with.
In C, the intent of the language is that pointers be
used as addresses. However, anybody is free to
choose a different usage as long as it is consistent.
But the preference part needs to be made explicit.
Mukesh Prasad <·······@polaroid.com> writes:
> Ah! So your argument is "To me, Lisp has pointers same as C"?
> This is not a statement I think anybody would disagree with.
You got it.
> But the preference part needs to be made explicit.
Agreed, definitely.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
From: Peter da Silva
Subject: Re: Lisp objects as pointers (was: Briar patch)
Date:
Message-ID: <5mk196$h0p@web.nmti.com>
In article <··················@jagor.srce.hr>,
Hrvoje Niksic <·······@srce.hr> wrote:
> else's understanding of the terms. Lack of such definition may have
> lead Peter and Erik to the wrong path; to me it seems that they argue
> about the same thing in different words.
I think you're exactly right.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.