I would like to construct dynamically a list of bases for a class.
The idea is kind of like this:
(defmacro defclass-eval-bases (name bases &rest rest)
`(defclass ,name ,(eval bases) ,@rest))
But it seems that this would prevent the compiler from expanding the
defclass macro call. I think that might be the least unacceptable
solution. What are the practical consequences of compiled code
expanding macros?
Would a compiler be able to expand defclass, even with the eval, if it
notices that the bases argument is only used as a function argument in
the expansion, and not otherwise played with (which, for example,
CMUCL does)? I imagine most implementations would expand defclass
this way.
Of course, it would be nice if there were a good way to do this.
Thanks,
CARL BANKS
In article <····························@posting.google.com>,
Carl Banks <·······@aerojockey.com> wrote:
>I would like to construct dynamically a list of bases for a class.
>The idea is kind of like this:
>
>(defmacro defclass-eval-bases (name bases &rest rest)
> `(defclass ,name ,(eval bases) ,@rest))
>
>But it seems that this would prevent the compiler from expanding the
>defclass macro call.
Why do you think that? The compiler always expands macro invocations.
> I think that might be the least unacceptable
>solution. What are the practical consequences of compiled code
>expanding macros?
>
>Would a compiler be able to expand defclass, even with the eval, if it
>notices that the bases argument is only used as a function argument in
>the expansion, and not otherwise played with (which, for example,
>CMUCL does)? I imagine most implementations would expand defclass
>this way.
I don't understand your question.
The real problem is that (eval bases) will be done at macro-expansion time
which is compile time if you're compiling, so it won't really be able to
use dynamic values of runtime variables. If you want to be able to compute
a DEFCLASS form dynamically, you have eval the whole DEFCLASS after
substituting in the dynamic bases. Here's an untested version (I'm not too
confident that I have the nested backquotes right):
(defmacro defclass-eval-bases (name bases &rest rest)
`(eval `(defclass ,name ,,bases ,@rest)))
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Carl Banks" <·······@aerojockey.com> wrote in message
·································@posting.google.com...
> I would like to construct dynamically a list of bases for a class.
> The idea is kind of like this:
>
> (defmacro defclass-eval-bases (name bases &rest rest)
> `(defclass ,name ,(eval bases) ,@rest))
>
If I understand what you want to do, what's wrong with:
(defmacro defclass-eval-bases (name bases &rest rest)
`(defclass ,name (,@bases) ,@rest))
If its because you want to define the class at runtime then you should make
defclass-eval-bases a function:
(defun defclass-eval-bases (name bases &rest rest)
(eval `(defclass ,name (,@bases) ,@rest)))
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Carl Banks" <·······@aerojockey.com> wrote in message
> ·································@posting.google.com...
> > I would like to construct dynamically a list of bases for a class.
> > The idea is kind of like this:
> >
> > (defmacro defclass-eval-bases (name bases &rest rest)
> > `(defclass ,name ,(eval bases) ,@rest))
> >
>
> If I understand what you want to do, what's wrong with:
>
> (defmacro defclass-eval-bases (name bases &rest rest)
> `(defclass ,name (,@bases) ,@rest))
This is (assuming bases is always a list) the same as
(defmacro defclass-eval-bases (name bases &rest rest)
`(defclass ,name ,bases ,@rest))
and so is the same as asking why ,(eval bases) can't be replaced with ,bases.
> If its because you want to define the class at runtime then you should make
> defclass-eval-bases a function:
>
> (defun defclass-eval-bases (name bases &rest rest)
> (eval `(defclass ,name (,@bases) ,@rest)))
Yes.
But don't do it.
Helping a person shoot himself in the foot is not always the right
thing, though. This is the place where one asks "what are you REALLY
trying to do?"
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > If its because you want to define the class at runtime then you should make
> > defclass-eval-bases a function:
> >
> > (defun defclass-eval-bases (name bases &rest rest)
> > (eval `(defclass ,name (,@bases) ,@rest)))
>
> Yes.
>
> But don't do it.
>
> Helping a person shoot himself in the foot is not always the right
> thing, though. This is the place where one asks "what are you REALLY
> trying to do?"
I'm trying to define a class where the bases are not known at compile
time. (In fact, the base classes depend on the input.) It seems that
doing this is not possible in Common Lisp without this eval hack.
The solution above isn't what I want, anyways. First of all, I want
to to eval the bases argument as a form, and use the list of symbols
it returns as bases for my class, like (for example) this:
(defclass-eval-bases name (mapcar #'whatever prebases) ...)
I don't want to evaluate then name nor the rest of the forms, so I
can't use a function. This is why I gave as an example of what I was
doing:
(defmacro defclass-eval-bases (name basesform &rest rest)
`(defclass ,name (eval ',basesform) ,@rest))
I changed the second argument to basesform to emphasize that it's not
a list of bases, but a form when evaluated returns a list of bases.
This does work when interpretted, and seems to work when compiled.
Yet, it gives me an icky feeling. Obviously, it uses eval, and I
assume that it prevents the compiler from expanding the defclass,
meaning that the expansion has to be done at run time. Am I right?
Second, the eval doesn't see the lexical scope. I think that can be
worked around, maybe using something like the solution above as an
auxillary function in the macro.
What I'd really like is a way to do it without eval.
And if I have to use it, I'd like to know how I can minimize the
damage.
--
CARL BANKS
·······@aerojockey.com (Carl Banks) writes:
> I'm trying to define a class where the bases are not known at compile
> time. (In fact, the base classes depend on the input.) It seems that
> doing this is not possible in Common Lisp without this eval hack.
Ah, you want to use the MOP. Check out MOP:ENSURE-CLASS. This is
such a lightweight use of the MOP, it shouldn't be at all of a
problem.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> ·······@aerojockey.com (Carl Banks) writes:
>
> > I'm trying to define a class where the bases are not known at compile
> > time. (In fact, the base classes depend on the input.) It seems that
> > doing this is not possible in Common Lisp without this eval hack.
>
> Ah, you want to use the MOP.
Ah, I don't really. :)
> Check out MOP:ENSURE-CLASS. This is
> such a lightweight use of the MOP, it shouldn't be at all of a
> problem.
I'll have a look, if I can find a description. Maybe I'll use this if
it's available, and fall back on eval if it's not. Thanks a lot for
your help.
--
CARL BANKS
·······@aerojockey.com (Carl Banks) wrote in message news:<····························@posting.google.com>...
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > If its because you want to define the class at runtime then you should make
> > > defclass-eval-bases a function:
> > >
> > > (defun defclass-eval-bases (name bases &rest rest)
> > > (eval `(defclass ,name (,@bases) ,@rest)))
> >
> > Yes.
> >
> > But don't do it.
> >
> > Helping a person shoot himself in the foot is not always the right
> > thing, though. This is the place where one asks "what are you REALLY
> > trying to do?"
>
>
> I'm trying to define a class where the bases are not known at compile
> time. (In fact, the base classes depend on the input.) It seems that
> doing this is not possible in Common Lisp without this eval hack.
You are doing it through the wrong interface. The DEFCLASS macro is a
convenience which provides a simplified programmer interface for
defining classes. It creates a class object and associates it with a
name; this is normally done at the top level.
This is analogous to defined functions and closures. If you want to
create a function dynamically, you apply the FUNCTION operator to a
LAMBDA expression. You don't fudge around with a wrapper around the
DEFUN macro; that macro is an interface to support the concept of
top-level function defining as part of a program's body.
Find out how your lisp macro-expands a (DEFCLASS ...) form and then
use the expansion as a guide. See what pieces are generated, and try
to find if any of it is documented. The Meta-Object protocol says that
DEFCLASS works in terms of a method called ENSURE-CLASS; your
implementation may do it in that way, or in some way that is similar.
"Carl Banks" <·······@aerojockey.com> wrote in message
·································@posting.google.com...
> Kent M Pitman <······@world.std.com> wrote in message
news:<···············@shell01.TheWorld.com>...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > If its because you want to define the class at runtime then you should
make
> > > defclass-eval-bases a function:
> > >
> > > (defun defclass-eval-bases (name bases &rest rest)
> > > (eval `(defclass ,name (,@bases) ,@rest)))
> >
> > Yes.
> >
> > But don't do it.
> >
> > Helping a person shoot himself in the foot is not always the right
> > thing, though. This is the place where one asks "what are you REALLY
> > trying to do?"
>
> I'm trying to define a class where the bases are not known at compile
> time.
I don't think that is what Kent meant by "what are you REALLY trying to do?"
that still just answers "what are you trying to do" ;)
> The solution above isn't what I want, anyways. First of all, I want
> to to eval the bases argument as a form, and use the list of symbols
> it returns as bases for my class, like (for example) this:
>
> (defclass-eval-bases name (mapcar #'whatever prebases) ...)
>
> I don't want to evaluate then name nor the rest of the forms, so I
> can't use a function.
Yes you can, just pass quoted arguments for name & rest
> Yet, it gives me an icky feeling. Obviously, it uses eval, and I
> assume that it prevents the compiler from expanding the defclass,
> meaning that the expansion has to be done at run time. Am I right?
Yes, it won't happen until eval is called.
> Second, the eval doesn't see the lexical scope.
Nor does any other function you might call, are you sure it should be a
special problem?
>
> What I'd really like is a way to do it without eval.
You can't do what you are trying to do without eval, but perhaps you can do
what you REALLY want to do! :)
>
> And if I have to use it, I'd like to know how I can minimize the
> damage.
If eval is the right thing, just use it, it is not that dangerous.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message news:<············@otis.netspace.net.au>...
> "Carl Banks" <·······@aerojockey.com> wrote in message
> ·································@posting.google.com...
> > Kent M Pitman <······@world.std.com> wrote in message
> news:<···············@shell01.TheWorld.com>...
> > > "Coby Beck" <·····@mercury.bc.ca> writes:
> > >
> > > > If its because you want to define the class at runtime then you should
> make
> > > > defclass-eval-bases a function:
> > > >
> > > > (defun defclass-eval-bases (name bases &rest rest)
> > > > (eval `(defclass ,name (,@bases) ,@rest)))
> > >
> > > Yes.
> > >
> > > But don't do it.
> > >
> > > Helping a person shoot himself in the foot is not always the right
> > > thing, though. This is the place where one asks "what are you REALLY
> > > trying to do?"
> >
> > I'm trying to define a class where the bases are not known at compile
> > time.
>
> I don't think that is what Kent meant by "what are you REALLY trying to do?"
> that still just answers "what are you trying to do" ;)
I really don't know what else to tell you other than I have to define
classes whose bases depend on user input. I won't and can't know them
until run time.
> > The solution above isn't what I want, anyways. First of all, I want
> > to to eval the bases argument as a form, and use the list of symbols
> > it returns as bases for my class, like (for example) this:
> >
> > (defclass-eval-bases name (mapcar #'whatever prebases) ...)
> >
> > I don't want to evaluate then name nor the rest of the forms, so I
> > can't use a function.
>
> Yes you can, just pass quoted arguments for name & rest
Well, yes. I don't want to though.
> > Yet, it gives me an icky feeling. Obviously, it uses eval, and I
> > assume that it prevents the compiler from expanding the defclass,
> > meaning that the expansion has to be done at run time. Am I right?
>
> Yes, it won't happen until eval is called.
I wonder whether some compilers can expand it if the macro expansion
doesn't do anything funny with bases, but just evaluates it once and
doesn't branch on it.
> > Second, the eval doesn't see the lexical scope.
>
> Nor does any other function you might call, are you sure it should be a
> special problem?
Well, for a macro it is. It's not too hard to work around, though. I
think something like this will do it (except I'm not sure how to nest
backquotes, since I've yet to do it; I'll look it up later):
(defmacro defclass-eval-bases (name basesforms &rest rest)
(let ((bases (gensym)))
`(let ((,bases ,basesforms))
(eval `(defclass ,name ,,bases ,@rest)))))
> > What I'd really like is a way to do it without eval.
>
> You can't do what you are trying to do without eval, but perhaps you can do
> what you REALLY want to do! :)
>
> > And if I have to use it, I'd like to know how I can minimize the
> > damage.
>
> If eval is the right thing, just use it, it is not that dangerous.
All right. Thanks a lot for your help.
--
CARL BANKS
·······@aerojockey.com (Carl Banks) writes:
> Kent M Pitman <······@world.std.com> wrote [...]
>
> > Helping a person shoot himself in the foot is not always the right
> > thing, though. This is the place where one asks "what are you REALLY
> > trying to do?"
>
>
> I'm trying to define a class where the bases are not known at compile
> time.
This is a linguistic goal, not an application goal.
I suspect you are using the language wrong to achieve your application
needs. Please step back and try to describe your intended need.
> (In fact, the base classes depend on the input.) It seems that
> doing this is not possible in Common Lisp without this eval hack.
Are you sure you're not just looking to make a "mixin class" that can be
mixed later into other objects to be defined later?
> The solution above isn't what I want, anyways. First of all, I want
> to to eval the bases argument as a form, and use the list of symbols
> it returns as bases for my class, like (for example) this:
>
> (defclass-eval-bases name (mapcar #'whatever prebases) ...)
Why do you want to make an instance of something you have never seen until
runtime? There can't be any methods on such a thing, for example.
Furthermore, have you given thought to questions of whether, if there were
two things that had the same list of "prebases", they should have the same
class or different classes?
There is something seriously amiss here.
You can call EVAL at runtime to accomodate some of this, but that still
doesn't address the question of whether you SHOULD do that, and I'm
unconvinced that you've got a clear theory of what you're trying to
accomplish.
...
> Yet, it gives me an icky feeling. Obviously, it uses eval, and I
> assume that it prevents the compiler from expanding the defclass,
> meaning that the expansion has to be done at run time. Am I right?
Sure, but nothing bad comes of that. It doesn't mean that dispatch on
the objects is going to happen any slower. The real question is whether
you're going to get something that's semantically meaningful, not whether
it's going to be efficient.
> Second, the eval doesn't see the lexical scope.
Whose lexical scope?
> I think that can be
> worked around, maybe using something like the solution above as an
> auxillary function in the macro.
>
> What I'd really like is a way to do it without eval.
You still haven't said what. That's why no one can help you.
> And if I have to use it, I'd like to know how I can minimize the
> damage.
Once we know what you're trying to accomplish in your application,
we can better help you with that.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Why do you want to make an instance of something you have never seen until
>runtime? There can't be any methods on such a thing, for example.
Sure there can: all the methods that are inherited from the superclasses
that are being mixed together.
Presumably, the caller of this interface is expected to ensure that he
provides the right kind of class mixture that implements all the required
protocols for the application.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> wrote in message news:<·················@paloalto-snr1.gtei.net>...
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Why do you want to make an instance of something you have never seen until
> >runtime? There can't be any methods on such a thing, for example.
>
> Sure there can: all the methods that are inherited from the superclasses
> that are being mixed together.
>
> Presumably, the caller of this interface is expected to ensure that he
> provides the right kind of class mixture that implements all the required
> protocols for the application.
Actually, there will be some methods on the new classes, automatically
defined. Now that I realize that this can't be done at compile time,
either, I don't mind using eval so much.
Thanks,
--
CARL BANKS
Barry Margolin <······@genuity.net> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Why do you want to make an instance of something you have never seen until
> >runtime? There can't be any methods on such a thing, for example.
>
> Sure there can: all the methods that are inherited from the superclasses
> that are being mixed together.
>
> Presumably, the caller of this interface is expected to ensure that he
> provides the right kind of class mixture that implements all the required
> protocols for the application.
No, I meant on the ultimate class. Sure, I agree there can be functionality.
There is still something odd about defining "classes" where you don't know if
the identity of the class matters. You need to, at minimum, determine if
these "classes" should be interned or not...
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> ·······@aerojockey.com (Carl Banks) writes:
>
> > Kent M Pitman <······@world.std.com> wrote [...]
> >
> > > Helping a person shoot himself in the foot is not always the right
> > > thing, though. This is the place where one asks "what are you REALLY
> > > trying to do?"
> >
> >
> > I'm trying to define a class where the bases are not known at compile
> > time.
>
> This is a linguistic goal, not an application goal.
>
> I suspect you are using the language wrong to achieve your application
> needs. Please step back and try to describe your intended need.
I really don't think I have to. I understand what you're saying, but
I'm not interested in questions about whether this is the right thing
to do. I just want the question answered (which it already has been
to my satisfaction, but of course I'll listen to any other good
advice).
--
CARL BANKS
·······@aerojockey.com (Carl Banks) writes:
> I really don't think I have to. I understand what you're saying, but
> I'm not interested in questions about whether this is the right thing
> to do. I just want the question answered
I'm sorry. You've mistaken me for a free question-answering service.
Don't expect any future answers to questions from me, at least.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> ·······@aerojockey.com (Carl Banks) writes:
>
> > I really don't think I have to. I understand what you're saying, but
> > I'm not interested in questions about whether this is the right thing
> > to do. I just want the question answered
>
> I'm sorry. You've mistaken me for a free question-answering service.
> Don't expect any future answers to questions from me, at least.
Fine. That'll save me from having to stomach you presumptuousness
should I ever have another question.
--
CARL BANKS
In article <····························@posting.google.com>,
Carl Banks <·······@aerojockey.com> wrote:
>Kent M Pitman <······@world.std.com> wrote in message
>news:<···············@shell01.TheWorld.com>...
>> ·······@aerojockey.com (Carl Banks) writes:
>>
>> > I really don't think I have to. I understand what you're saying, but
>> > I'm not interested in questions about whether this is the right thing
>> > to do. I just want the question answered
>>
>> I'm sorry. You've mistaken me for a free question-answering service.
>> Don't expect any future answers to questions from me, at least.
>
>Fine. That'll save me from having to stomach you presumptuousness
>should I ever have another question.
Well, you should get used to it anyway. Kent's approach to answering
questions is very common on Usenet. If you ask a question and it's clear
that you're going about things wrong in the first place, you'll often get
advice rather than answers.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
·······@aerojockey.com (Carl Banks) wrote in message news:<····························@posting.google.com>...
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> > I suspect you are using the language wrong to achieve your application
> > needs. Please step back and try to describe your intended need.
>
> I really don't think I have to.
Of course you don't. No need to get all huffy about it, tho. Kent was
offering the best help he knew how (which happens to be about as good
as you could hope for), by chance the same help I thought to offer,
viz. lay out the requirement behind the stated requirement and maybe
we can help find a /better/ solution not involving 'eval.
This is the hardware store tradition: "do you carry Xes?" "what do you
want it for". The wise customer answers. Maybe the clerk says, "Oh,
yes, you need an X". Maybe not, and maybe the clerk saves the customer
a lot of time and money.
> ...I'm not interested in questions about whether this is the right thing
> to do. I just want the question answered ...
Super. Now most of the best answerers will ignore you.
> (which it already has been
> to my satisfaction, but of course I'll listen to any other good
> advice).
You just didn't.
Anyway, there was a fairly mature project called "Capabilities" (the
only link I have is Google <g>) in which the developer had worked out
a scheme by which /instances/ could have superclasses added and
removed at runtime. This does not answer your question, so you are not
interested in it, but I wager it could be made to serve.