Yes, I used macroexpand, but didn't understand why I was getting the
results I was. Why doesn't the second expand to T?
(test #'+) => `,(functionp (function +)) => T
I guess my problem is in the evaluation of the argument to the macro.
When does this happen? Thanks for the reply.
Jeff
"Jeff" <···@insightbb.com> writes:
> I guess my problem is in the evaluation of the argument to the macro.
> When does this happen? Thanks for the reply.
(test #'+) ==> `,(functionp '#'+) ==> (functionp '#'+) ==> NIL
the macro is passed _source code_ and must return _source code_, lisp
source code can only be one of two things: a list or an atom, never a
function (except in those rare cases where it is).
if this still doesn't make sense then maybe this will help:
CL-USER> (defmacro test (x)
(describe x)
`,(functionp x))
TEST
CL-USER> (macroexpand '(test #'+))
#'+
Type: CONS
Class: #<BUILT-IN-CLASS CONS>
Normal List
Length: 2
0: FUNCTION
1: +
NIL
T
CL-USER>
p.s. - `,x == x
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer <··@bese.it> writes:
> "Jeff" <···@insightbb.com> writes:
>
> > I guess my problem is in the evaluation of the argument to the macro.
> > When does this happen? Thanks for the reply.
>
> (test #'+) ==> `,(functionp '#'+) ==> (functionp '#'+) ==> NIL
>
> the macro is passed _source code_ and must return _source code_, lisp
> source code can only be one of two things: a list or an atom, never a
> function (except in those rare cases where it is).
(atom (function +)) --> T
In lisp, AFAIK, everything is either a list or an atom.
> if this still doesn't make sense then maybe this will help:
>
> CL-USER> (defmacro test (x)
> (describe x)
> `,(functionp x))
> TEST
> CL-USER> (macroexpand '(test #'+))
> #'+
> Type: CONS
> Class: #<BUILT-IN-CLASS CONS>
> Normal List
> Length: 2
> 0: FUNCTION
> 1: +
> NIL
> T
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
You might have a point (sort of)
The importan property however is that nil is the only object that is not a
subclass of t.
On Fri, 13 Aug 2004 01:13:30 +0300, Kalle Olavi Niemitalo <···@iki.fi>
wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> In lisp, AFAIK, everything is either a list or an atom.
>
> NIL is both.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> The importan property however is that nil is the only object that is
> not a subclass of t.
What do you mean? The number 42 is not a class, so it cannot be
a subclass of T either.
Perhaps you meant "generalized instance" rather than "subclass",
but that doesn't hold either: NIL is an instance of the system
class named NULL, which is a subclass of the system class named T.
42 is a subclass of number which is t.
The basis of the lisp logic system is what is known as generalized bolean.
All objects, be it numbers or strings whatever, are a subclass of t.
(I mean t that is the name of the superclass)
only nil is not a member. (what is this about null, null is (void * 0) in
c)
On Fri, 13 Aug 2004 10:23:16 +0300, Kalle Olavi Niemitalo <···@iki.fi>
wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>> The importan property however is that nil is the only object that is
>> not a subclass of t.
>
> What do you mean? The number 42 is not a class, so it cannot be
> a subclass of T either.
>
> Perhaps you meant "generalized instance" rather than "subclass",
> but that doesn't hold either: NIL is an instance of the system
> class named NULL, which is a subclass of the system class named T.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> 42 is a subclass of number which is t.
> The basis of the lisp logic system is what is known as generalized bolean.
> All objects, be it numbers or strings whatever, are a subclass of t.
> (I mean t that is the name of the superclass)
> only nil is not a member. (what is this about null, null is (void * 0)
> in c)
I'm afraid you're very confused, at least about the terminology.
Every statement you have made other than the second one is wrong.
- 42 is *not* a subclass of NUMBER.
- NUMBER is not T, nor is 42. Both are "true, when considered
as a generalized boolean", which is an entirely different thing.
- Objects other than class objects are *not* subclasses of T.
Not any of them. Not even if they're true when considered
as generalized booleans.
- There is no class of things-that-are-true-as-generalized-booleans,
and in particular T is not the name of any such class.
- There is a class whose name is T. *Every* Lisp value,
including NIL, is an instance of it.
- NULL has two perfectly good meanings in Lisp. It is a function
that checks for equality to NIL, and (more relevantly here) it
is a class whose only instance is the value NIL.
"A is a subclass of B" means: "A and B are classes, and A inherits
from B". More generally, "A is a subtype of B" means "A and B are
types, and everything of type A is also of type B". Neither of these
correctly describes the relationship between 42 and the class NUMBER;
the relationship you're looking for is that of *instance*. 42 is an
instance of NUMBER, not a subclass of it. 42 is not the right kind of
thing to be a subclass or a subtype of anything.
(The relationship between types and classes is subtle.
In CL terminology, a type is a set of objects; types
are not Lisp objects themselves, although they can be
described in Lisp and given names. A class is a Lisp
object that (among other things) defines a certain set
of objects called its "instances"; that is, it defines
a type. So there is a type for every class, but many
types have no corresponding class; classes are always
Lisp objects themselves, and types never are. In some
OO programming systems, but not in Common Lisp, some
objects are not instances of classes. In some OO programming
systems, but not in Common Lisp, all classes have more or
less the same kind of structure. In CL, the notion of
"class" is broader than in those languages.)
Again, every Lisp object is an instance of class T. The only Lisp
objects that are subclasses of T are class objects; every class
object is a subclass of T. This applies even to the classes NULL
(whose only instance is NIL) and NIL (which has no instances).
You are correct that NIL is the only thing that is not true
when considered as a generalized boolean. But you are incorrect
to try to express this in terms of types and classes, and even
more incorrect to use the word "subclass" when what you mean
is "instance".
--
Gareth McCaughan
.sig under construc
You are right... I am very comfused :<
On Fri, 13 Aug 2004 09:47:51 GMT, Gareth McCaughan
<················@pobox.com> wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>> 42 is a subclass of number which is t.
>> The basis of the lisp logic system is what is known as generalized
>> bolean.
>> All objects, be it numbers or strings whatever, are a subclass of t.
>> (I mean t that is the name of the superclass)
>> only nil is not a member. (what is this about null, null is (void * 0)
>> in c)
>
> I'm afraid you're very confused, at least about the terminology.
> Every statement you have made other than the second one is wrong.
>
> - 42 is *not* a subclass of NUMBER.
>
> - NUMBER is not T, nor is 42. Both are "true, when considered
> as a generalized boolean", which is an entirely different thing.
>
> - Objects other than class objects are *not* subclasses of T.
> Not any of them. Not even if they're true when considered
> as generalized booleans.
>
> - There is no class of things-that-are-true-as-generalized-booleans,
> and in particular T is not the name of any such class.
>
> - There is a class whose name is T. *Every* Lisp value,
> including NIL, is an instance of it.
>
> - NULL has two perfectly good meanings in Lisp. It is a function
> that checks for equality to NIL, and (more relevantly here) it
> is a class whose only instance is the value NIL.
>
> "A is a subclass of B" means: "A and B are classes, and A inherits
> from B". More generally, "A is a subtype of B" means "A and B are
> types, and everything of type A is also of type B". Neither of these
> correctly describes the relationship between 42 and the class NUMBER;
> the relationship you're looking for is that of *instance*. 42 is an
> instance of NUMBER, not a subclass of it. 42 is not the right kind of
> thing to be a subclass or a subtype of anything.
>
> (The relationship between types and classes is subtle.
> In CL terminology, a type is a set of objects; types
> are not Lisp objects themselves, although they can be
> described in Lisp and given names. A class is a Lisp
> object that (among other things) defines a certain set
> of objects called its "instances"; that is, it defines
> a type. So there is a type for every class, but many
> types have no corresponding class; classes are always
> Lisp objects themselves, and types never are. In some
> OO programming systems, but not in Common Lisp, some
> objects are not instances of classes. In some OO programming
> systems, but not in Common Lisp, all classes have more or
> less the same kind of structure. In CL, the notion of
> "class" is broader than in those languages.)
>
> Again, every Lisp object is an instance of class T. The only Lisp
> objects that are subclasses of T are class objects; every class
> object is a subclass of T. This applies even to the classes NULL
> (whose only instance is NIL) and NIL (which has no instances).
>
> You are correct that NIL is the only thing that is not true
> when considered as a generalized boolean. But you are incorrect
> to try to express this in terms of types and classes, and even
> more incorrect to use the word "subclass" when what you mean
> is "instance".
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Gareth McCaughan <················@pobox.com> writes:
> Again, every Lisp object is an instance of class T. The only Lisp
> objects that are subclasses of T are class objects; every class
> object is a subclass of T. This applies even to the classes NULL
> (whose only instance is NIL) and NIL (which has no instances).
It is also important to understand that T the object and the class
named T are different objects. That is the value T is a constant
symbol whose value is itself while the class is a class object whose
*name* is the symbol T. Thus:
(eq t 't) ==> T
(eq t (symbol-value 't)) ==> T
(eq 't (symbol-value 't)) ==> T
(class-of t) ==> #<BUILT-IN-CLASS SYMBOL>
(find-class 't) ==> #<BUILT-IN-CLASS T>
(eq t (find-class 't)) ==> NIL
Gareth, I'm sure, understands that but it is perhaps worth belaboring
for folks following along at home since it's easy to loose track of
which T we're talking about--the object or the class. For instance if
Gareth had been feeling incredibly pedantic he could have written the
second sentence quoted above as:
The only Lisp objects that are subclasses of the class whose name is
the symbol T are class objects; every class object is a subclass of
the class whose name is the symbol T.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Thank you for making this clear for me.
For a while I was very comfused.
On Fri, 13 Aug 2004 16:56:52 GMT, Peter Seibel <·····@javamonkey.com>
wrote:
> Gareth McCaughan <················@pobox.com> writes:
>
>> Again, every Lisp object is an instance of class T. The only Lisp
>> objects that are subclasses of T are class objects; every class
>> object is a subclass of T. This applies even to the classes NULL
>> (whose only instance is NIL) and NIL (which has no instances).
>
> It is also important to understand that T the object and the class
> named T are different objects. That is the value T is a constant
> symbol whose value is itself while the class is a class object whose
> *name* is the symbol T. Thus:
>
> (eq t 't) ==> T
> (eq t (symbol-value 't)) ==> T
> (eq 't (symbol-value 't)) ==> T
> (class-of t) ==> #<BUILT-IN-CLASS SYMBOL>
> (find-class 't) ==> #<BUILT-IN-CLASS T>
> (eq t (find-class 't)) ==> NIL
>
> Gareth, I'm sure, understands that but it is perhaps worth belaboring
> for folks following along at home since it's easy to loose track of
> which T we're talking about--the object or the class. For instance if
> Gareth had been feeling incredibly pedantic he could have written the
> second sentence quoted above as:
>
> The only Lisp objects that are subclasses of the class whose name is
> the symbol T are class objects; every class object is a subclass of
> the class whose name is the symbol T.
>
> -Peter
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Peter Seibel wrote:
> It is also important to understand that T the object and the class
> named T are different objects.
[etc]
Right. I should have been clearer about that.
--
Gareth McCaughan
.sig under construc
Jeff <···@insightbb.com> wrote:
> Yes, I used macroexpand, but didn't understand why I was getting the
> results I was. Why doesn't the second expand to T?
>
> (test #'+) => `,(functionp (function +)) => T
>
> I guess my problem is in the evaluation of the argument to the macro.
> When does this happen? Thanks for the reply.
three notes:
#'... is a shortcut for (function ...)
in `, the comma neutralises the backquote.
please always consider that macro parameters are never evaluated (unless
you do it in the macro-expansion).