I don't see anything that that suggests it fits into any part of the
meta object protocol though I can imagine you'd need a function like
this to implement the initialization argument validity checking
described in Sec 7.1.2. Is that it?
Or is it a historical artifact of some earlier Lisp that was kept
around for compatibility? Or something else?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> I don't see anything that that suggests it fits into any part of the
> meta object protocol though I can imagine you'd need a function like
> this to implement the initialization argument validity checking
> described in Sec 7.1.2. Is that it?
Could be. (FWIW, and I'm sure that's not much, I've never needed it.)
> Or is it a historical artifact of some earlier Lisp that was kept
> around for compatibility?
I doubt "of some earlier Lisp" is correct. It might be an artifact of
some later Lisp kept around for compatibility. (Read on to see how that
might be possible.)
> Or something else?
Always possible.
Btw, not that everyone agrees with me on this, but I have a personal
distaste for this approach to learning the language of trying to learn
how each operator is to be used. When one sees a function they don't
see a use for, I think the right thing is not to try to invent uses
for it, it's just to file some superficial info about the fact that it
might be used later and then to not use it. The reason for this is that
people often talk about the language as complex because of how many things
it has in it, but not all of those things are day-to-day things. Some are
extraordinarily specialized and just not needed for everyone.
One thing to know about CLOS in general is that it was presented as a
whole to the committee for acceptance, but it was a 3-chapter text.
We accepted the first chapter, and not the other two, if I recall. (Or
maybe it was the first two but not the third.) In any case, it was
approximately the non-MOP part. But it was easier and design-wise
safer in that historical context just to take an intact chapter than
to do surgery to remove parts of it that were really not needed
without the other 2. (You should know that while I did substantial
surgery on the text of the rest of the document, a great deal of the
CLOS stuff is taken verbatim from the original proposal and I was
forbidden from doing even superficial modification because so much
blood was already spilt among the CLOS committee getting the necessary
compromises for agreement that no one wanted to risk additional blood
spilt again in a redundant process of integration into the spec as a
whole.) So it's extremely probable that there are several things in
this section whose purpose is not apparent without considering the MOP
substrate as part of the system, which it was assumed would come
later, and which, in effect, did come later since the MOP (or, as I
like to say, punning badly on the book title, "a MOP" if not "the
MOP", since there might be some variation among MOPs and the definite
article might be ill-used here) Certainly there are other pieces, like
the METHOD-COMBINATION class, that are like this.
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > I don't see anything that that suggests it fits into any part of the
> > meta object protocol though I can imagine you'd need a function like
> > this to implement the initialization argument validity checking
> > described in Sec 7.1.2. Is that it?
>
> Could be. (FWIW, and I'm sure that's not much, I've never needed it.)
>
> > Or is it a historical artifact of some earlier Lisp that was kept
> > around for compatibility?
>
> I doubt "of some earlier Lisp" is correct. It might be an artifact of
> some later Lisp kept around for compatibility. (Read on to see how that
> might be possible.)
>
> > Or something else?
>
> Always possible.
>
> Btw, not that everyone agrees with me on this, but I have a personal
> distaste for this approach to learning the language of trying to learn
> how each operator is to be used. When one sees a function they don't
> see a use for, I think the right thing is not to try to invent uses
> for it, it's just to file some superficial info about the fact that it
> might be used later and then to not use it. The reason for this is that
> people often talk about the language as complex because of how many things
> it has in it, but not all of those things are day-to-day things. Some are
> extraordinarily specialized and just not needed for everyone.
FWIW, I get that last point absolutely--I'm trying to understand how
different things fit together; which ones are day-to-day and in what
contexts the extraordinarily specialized ones actually *are* used.
When I "invent" uses I'm just theorizing--trying out a theory and
seeing if it fits with the rest of what I know about the language.
Anyway, I do appreciate you giving me the benefit of your knowledege
of how things came about even if you disapprove of my approach.
> One thing to know about CLOS in general is that it was presented as a
> whole to the committee for acceptance, but it was a 3-chapter text.
> We accepted the first chapter, and not the other two, if I recall. (Or
> maybe it was the first two but not the third.) In any case, it was
> approximately the non-MOP part. But it was easier and design-wise
> safer in that historical context just to take an intact chapter than
> to do surgery to remove parts of it that were really not needed
> without the other 2. (You should know that while I did substantial
> surgery on the text of the rest of the document, a great deal of the
> CLOS stuff is taken verbatim from the original proposal and I was
> forbidden from doing even superficial modification because so much
> blood was already spilt among the CLOS committee getting the necessary
> compromises for agreement that no one wanted to risk additional blood
> spilt again in a redundant process of integration into the spec as a
> whole.) So it's extremely probable that there are several things in
> this section whose purpose is not apparent without considering the MOP
> substrate as part of the system, which it was assumed would come
> later, and which, in effect, did come later since the MOP (or, as I
> like to say, punning badly on the book title, "a MOP" if not "the
> MOP", since there might be some variation among MOPs and the definite
> article might be ill-used here) Certainly there are other pieces, like
> the METHOD-COMBINATION class, that are like this.
I had actually looked for FUNCTION-KEYWORDS in _The Art of the
Metaobject Protocol_ before I posted my original question. At any rate
it wasn't in the index or in Chapter 6.
Anyway thanks for your help.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> wrote:
> I don't see anything that that suggests it fits into any part of the
> meta object protocol though I can imagine you'd need a function like
> this to implement the initialization argument validity checking
> described in Sec 7.1.2. Is that it?
>
> Or is it a historical artifact of some earlier Lisp that was kept
> around for compatibility? Or something else?
It looks like PCL uses it for pretty-printing, and nothing else that either
I or 'grep' can see.
--
sean