I would like to use the build-in list under a different name like this
(defclass mylist (list)())
but this seems not possible. Maybe someone can enlighten me why it is this way.
Nils
Nils Stritzel <························@gmx.net> writes:
> I would like to use the build-in list under a different name like
> this (defclass mylist (list)()) but this seems not possible. Maybe
> someone can enlighten me why it is this way.
Indeed, it's not possible, because there is no list type in Lisp.
You could try CONS instead, but it's a TYPE, not a CLASS, so it won't
work with the default metaclass, and it would not do what you want
anyway because CONSes are used to build any kind of data structure,
not only lists.
So, forget it and just use: (defclass mylist () (first rest #|...|#))
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
(Should be a reply to the OP, not to this subreply.)
For most purposes, you don't need to. Just create the slots you want
in your class,
and let the implementation worry about how to represent them.
Or perhaps you have some special reason for using 'list' as a class?
There are ways to use defstruct to use a list a something like a
newly-defined
type, but they're fairly hairy and usually not worth it.
On Thu, 27 Jan 2005 17:04:01 +0100, Pascal Bourguignon wrote:
> Nils Stritzel <························@gmx.net> writes:
>
>> I would like to use the build-in list under a different name like
>> this (defclass mylist (list)()) but this seems not possible. Maybe
>> someone can enlighten me why it is this way.
>
> Indeed, it's not possible, because there is no list type in Lisp.
>
> You could try CONS instead, but it's a TYPE, not a CLASS, so it won't
> work with the default metaclass, and it would not do what you want
> anyway because CONSes are used to build any kind of data structure,
> not only lists.
>
>
> So, forget it and just use: (defclass mylist () (first rest #|...|#))
OK, I'm hopefully a little less of a Lisp newbie these days, but Lisp's
object system is still a little foreign to me (but in a good way!).
First off, "there is no list type in Lisp". Yup, I understand this in one
sense: lists are simply built from cons cells. But then why does the
HyperSpec say
"System Class LIST
Class Precedence List:
list, sequence, t"
That seems to be saying that LIST is a subclass of SEQUENCE, and that
there really is such a type, in some sense?
I'm not sure I can see why anyone would want to subclass LIST either,
really, but I can kind of see why one might want to subclass SEQUENCE: so
that one would be able to use lots of existing functions on the new class.
For example, I might want to subclass SEQUENCE to some class C that
represents a potentially infinite, lazily generated sequence. I would
like to think that if I defined the subclass, and then wrote methods for
things like ELT, then existing functions like FIND would magically work
with the new class C. Is this possible, or have I got hold of the wrong
end of the stick?
Cheers,
Bill.
From: Peter Seibel
Subject: Re: Newbie-Question concerning list and inheritance
Date:
Message-ID: <m3k6pywvem.fsf@javamonkey.com>
William Bland <·······@abstractnonsense.com> writes:
> On Thu, 27 Jan 2005 17:04:01 +0100, Pascal Bourguignon wrote:
>
>> Nils Stritzel <························@gmx.net> writes:
>>
>>> I would like to use the build-in list under a different name like
>>> this (defclass mylist (list)()) but this seems not possible. Maybe
>>> someone can enlighten me why it is this way.
>>
>> Indeed, it's not possible, because there is no list type in Lisp.
>>
>> You could try CONS instead, but it's a TYPE, not a CLASS, so it won't
>> work with the default metaclass, and it would not do what you want
>> anyway because CONSes are used to build any kind of data structure,
>> not only lists.
>>
>>
>> So, forget it and just use: (defclass mylist () (first rest #|...|#))
>
>
> OK, I'm hopefully a little less of a Lisp newbie these days, but Lisp's
> object system is still a little foreign to me (but in a good way!).
>
> First off, "there is no list type in Lisp". Yup, I understand this in one
> sense: lists are simply built from cons cells. But then why does the
> HyperSpec say
>
> "System Class LIST
> Class Precedence List:
> list, sequence, t"
>
> That seems to be saying that LIST is a subclass of SEQUENCE, and
> that there really is such a type, in some sense?
Yes. There is a class. But it's a system class. Which is not the same
as a user-defined class whose meta-class is STANDARD-CLASS. Notice
that STANDARD-OBJECT is not in that precedence list.
> I'm not sure I can see why anyone would want to subclass LIST
> either, really, but I can kind of see why one might want to subclass
> SEQUENCE: so that one would be able to use lots of existing
> functions on the new class.
>
> For example, I might want to subclass SEQUENCE to some class C that
> represents a potentially infinite, lazily generated sequence. I would
> like to think that if I defined the subclass, and then wrote methods for
> things like ELT, then existing functions like FIND would magically work
> with the new class C. Is this possible, or have I got hold of the wrong
> end of the stick?
It will not work because SEQUENCE is a "system class" which means you
can not subclass it. But that doesn't really matter. What matters is
that LENGTH, ELT, and (SETF ELT), the three foundational sequence
functions are not generic functions. (Of course if they were you'd
also need guarantees that all the *other* sequence functions were
implemented in terms of those. Which they're probably not though they
could be.)
Yes, it's sort of a pity that that rich library of sequence functions
can't be (easily[1]) applied to user-defined types.
[1] If you really want this, you can define your own package that
shadows all the names of the sequence functions and then define
generic functions with appropriate methods specialized on CL:SEQUENCE
implemented by calling the CL version. For example:
(defpackage :cl-with-extensible-sequences (:use :cl)
(:shadow :length :elt ...))
(defgeneric elt (sequence index))
(defgeneric length (sequence))
.
.
.
(defmethod elt ((sequence cl:sequence) index) (cl:elt sequence index))
(defmethod length ((sequence cl:sequence)) (cl:length sequence))
.
.
.
Then in your code:
(defpackage :my-package (:use :cl-with-extensible-sequences))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Thu, 27 Jan 2005 19:00:07 +0000, Peter Seibel wrote:
> William Bland <·······@abstractnonsense.com> writes:
>>
>> For example, I might want to subclass SEQUENCE to some class C that
>> represents a potentially infinite, lazily generated sequence. I would
>> like to think that if I defined the subclass, and then wrote methods for
>> things like ELT, then existing functions like FIND would magically work
>> with the new class C. Is this possible, or have I got hold of the wrong
>> end of the stick?
>
> It will not work because SEQUENCE is a "system class" which means you
> can not subclass it. But that doesn't really matter. What matters is
> that LENGTH, ELT, and (SETF ELT), the three foundational sequence
> functions are not generic functions. (Of course if they were you'd
> also need guarantees that all the *other* sequence functions were
> implemented in terms of those. Which they're probably not though they
> could be.)
>
> Yes, it's sort of a pity that that rich library of sequence functions
> can't be (easily[1]) applied to user-defined types.
Thanks Peter, I had been missing the distinction between system classes
and user classes. This does seem to go against the grain slightly - I'm
used to thinking of built-in and user-defined things in Lisp as having
equal status (or at least a lot more equal than many other languages). As
you pointed out though, it is possible to work around it, and I suppose it
does fit with Common Lisp's pragmatic design. I'm sure it's all for the
best ;-)
Thanks again,
Bill.
From: Peter Seibel
Subject: Re: Newbie-Question concerning list and inheritance
Date:
Message-ID: <m33bwmwtft.fsf@javamonkey.com>
William Bland <·······@abstractnonsense.com> writes:
> On Thu, 27 Jan 2005 19:00:07 +0000, Peter Seibel wrote:
>
>> William Bland <·······@abstractnonsense.com> writes:
>>>
>>> For example, I might want to subclass SEQUENCE to some class C that
>>> represents a potentially infinite, lazily generated sequence. I would
>>> like to think that if I defined the subclass, and then wrote methods for
>>> things like ELT, then existing functions like FIND would magically work
>>> with the new class C. Is this possible, or have I got hold of the wrong
>>> end of the stick?
>>
>> It will not work because SEQUENCE is a "system class" which means you
>> can not subclass it. But that doesn't really matter. What matters is
>> that LENGTH, ELT, and (SETF ELT), the three foundational sequence
>> functions are not generic functions. (Of course if they were you'd
>> also need guarantees that all the *other* sequence functions were
>> implemented in terms of those. Which they're probably not though they
>> could be.)
>>
>> Yes, it's sort of a pity that that rich library of sequence functions
>> can't be (easily[1]) applied to user-defined types.
>
> Thanks Peter, I had been missing the distinction between system classes
> and user classes. This does seem to go against the grain slightly - I'm
> used to thinking of built-in and user-defined things in Lisp as having
> equal status (or at least a lot more equal than many other languages). As
> you pointed out though, it is possible to work around it, and I suppose it
> does fit with Common Lisp's pragmatic design. I'm sure it's all for the
> best ;-)
Another way to think of it is that STANDARD-CLASS is an abstraction of
how to create an abstraction. That is, how do you define a new data
type? Well, one way is to define it in terms of a bunch of named slots
that make up instances of that data type. But it's not the only way.
How do you define an integer in terms of named slots. Or on array? Or,
to get back to the start of this thread, a list, since instances of
list are more or less an illusion. (You could, I'm sure, find a way to
force at least some of those types into a
instances-are-made-of-named-slots model if you had to. But it would be
a bit odd.)
What STANDARD-CLASS and DEFCLASS give you is a convenient way to
define new classes, taking care of a bunch of underlying machinery for
you. That the classes defined that way can be defined in relation to
other classes defined the same way is just part of the machinery. But
other classes, defined using different machinery, can't play in that
world. But that's probably okay because the cost of defining, say,
integers as STANDARD-OBJECTs would be too high (performance mostly)
relative to the gain (whooee--I can subclass integer! Now what.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> [...]
> How do you define an integer in terms of named slots. Or an array?
Easy
> (You could, I'm sure, find a way to force at least some of those types
> into a instances-are-made-of-named-slots model if you had to.
An elemental way would be to name each bit used to represent the type,
or to use lists (or binary trees) of bits or more elemental data types.
> But it would be a bit odd.)
Not at all. You'd just write the source for your machine. You could
compile it with your normal compiler and get a virtual machine, or you
could compile it with your prefered FGPA or silicium compiler and get
a real lisp machine processor.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: Peter Seibel
Subject: Re: Newbie-Question concerning list and inheritance
Date:
Message-ID: <m3ekg5s806.fsf@javamonkey.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>> [...]
>> How do you define an integer in terms of named slots. Or an array?
>
> Easy
>
>> (You could, I'm sure, find a way to force at least some of those types
>> into a instances-are-made-of-named-slots model if you had to.
>
> An elemental way would be to name each bit used to represent the type,
> or to use lists (or binary trees) of bits or more elemental data types.
But what are the names of those slots. bit-1, bit-2, bit-3, ... Paging
Kenny.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Paul F. Dietz
Subject: Re: Newbie-Question concerning list and inheritance
Date:
Message-ID: <a-GdnWltcrMXEGbcRVn-iA@dls.net>
Peter Seibel wrote:
> It will not work because SEQUENCE is a "system class" which means you
> can not subclass it. But that doesn't really matter. What matters is
> that LENGTH, ELT, and (SETF ELT), the three foundational sequence
> functions are not generic functions. (Of course if they were you'd
> also need guarantees that all the *other* sequence functions were
> implemented in terms of those. Which they're probably not though they
> could be.)
Actually, it's conforming for an implementation to allow the user
to subclass SEQUENCE and its various subclasses, and to make the
sequence functions generic and allowing the user to add methods
for them. No conforming program can depend on the implementation
allowing this behavior, though.
Paul
On Thu, 27 Jan 2005 19:00:07 +0000, Peter Seibel wrote:
>
> [1] If you really want this, you can define your own package that
> shadows all the names of the sequence functions and then define
> generic functions with appropriate methods specialized on CL:SEQUENCE
> implemented by calling the CL version.
>
I attempted (badly) a start at an implementation of this idea, and rambled
some more about it on #Lisp tonight, just in case anyone's interested:
http://meme.b9.com/~114a4bf9cb8faf74b6d9c6a9~/cview.html?channel=lisp&date=050129
(search for my user-name, awksedgrep, within that page).
Feel free to flame me to a crisp for stubbornly refusing to become
enlightened ;-)
Cheers,
Bill.