From: Thaddeus L Olczyk
Subject: Does CLOS automatically have a MOP?
Date: 
Message-ID: <3aa23906.118431890@nntp.interaccess.com>
I was meeting with some fellow programmers yesterday, and two things
came up:
some said that CLOS by definition has a MOP builtin,
I said that a MOP is a layer built "on top of" CLOS
( obviously you do have to have significant access to the internals )
and that just because you are using CLOS does not mean you 
have access to a MOP.
This comes from my understanding ( what little there is of it, sigh ) 
of The Art of.... book.

Also some of us were wondering if we can get a full CLOS with MOP to
play with. Any idea of a free implementation ( Linux and/or Windows).
Also what do single user licenses go for for the commercial versions.

From: Tim Bradshaw
Subject: Re: Does CLOS automatically have a MOP?
Date: 
Message-ID: <nkjzofehcdr.fsf@tfeb.org>
······@interaccess.com (Thaddeus L Olczyk) writes:

> I was meeting with some fellow programmers yesterday, and two things
> came up:
> some said that CLOS by definition has a MOP builtin,
> I said that a MOP is a layer built "on top of" CLOS
> ( obviously you do have to have significant access to the internals )
> and that just because you are using CLOS does not mean you 
> have access to a MOP.

That's right -- the standard doesn't specify more than a tiny amount
of the MOP.  It does specify that classes are objects and what the
default class of classes defined with DEFCLASS is and so on, but not
much more than that.  I think it would be more correct to say that
CLOS is built on top of the MOP rather than the other way around
though (:-).

--tim
From: Kent M Pitman
Subject: Re: Does CLOS automatically have a MOP?
Date: 
Message-ID: <sfw66i2wre4.fsf@world.std.com>
······@interaccess.com (Thaddeus L Olczyk) writes:

> I was meeting with some fellow programmers yesterday, and two things
> came up:
> some said that CLOS by definition has a MOP builtin,
> I said that a MOP is a layer built "on top of" CLOS
> ( obviously you do have to have significant access to the internals )
> and that just because you are using CLOS does not mean you 
> have access to a MOP.
> This comes from my understanding ( what little there is of it, sigh ) 
> of The Art of.... book.

The point I often try to get across to people is the unintended pun of
Gregor having discussed "AMOP".  All CLOS implementations tend, by 
accident or necessity, but not by definition, to have "a MOP".  However,
they do not always have "the MOP" that Gregor describes in AMOP.

What AMOP is about is defining a SPECIFIC protocol to talk to the 
internals of any adhering implementation.  He happened to describe 
something that was compatible with a particularly popular reference
implementation (PCL) that many implementations are historically based
on, either in terms of code or in terms of design compatibility.  So his
MOP happens to be consistent with a broad number of implementations.
 
The MOP specification of CL, were there an official one, would probably
want to be split in two parts:  things that are descriptive of 
implementation and things that are just inquiry functions.  The reason
you're wondering if it's above or below CLOS is that the inquiry stuff
can logically be above, but the descriptive stuff must be below--there
is, or can be, some of both.  Notably, the Symbolics implementation of
CLOS does not implement the CLOS slot accessors using all the 
SLOT-VALUE-USING-CLASS stuff; hence, the stuff in AMOP that "describes" 
the effect of SLOT-VALUE by appealing to a reference implementation 
involving SLOT-VALUE-USING-CLASS isn't true of Symbolics.  It's hard to
retrofit a new design like this without possibly perturbing speed of
deployed implementations and without costing certain vendors lots of $$.
But things that inquire of a class what it slot descriptions are,
for example, can  be easily implemented by any implementation even if 
the information is already stored in some other way; those are the
"inquiry" functions that it's easy to layer later even if you have an
incompatible implementation.

> Also some of us were wondering if we can get a full CLOS with MOP to
> play with. Any idea of a free implementation ( Linux and/or Windows).
> Also what do single user licenses go for for the commercial versions.

Most implementations of CLOS are full and have a MOP.

Some "free" implementations don't have CLOS and so don't have a MOP.
You can, for them, get PCL.

Probably the ALU web site has info on this.  http://www.alu.org/

I haven't checked, but I'd be surprised if the "free" (gratis, not gpl)
implementations of Lisp from the main commercial vendors (Xanalys and
Franz) don't have both a full CLOS and full MOP.
From: Rainer Joswig
Subject: Re: Does CLOS automatically have a MOP?
Date: 
Message-ID: <joswig-DDE144.18265322022001@goliath.news.is-europe.net>
In article <··················@nntp.interaccess.com>,
 ······@interaccess.com (Thaddeus L Olczyk) wrote:

> I was meeting with some fellow programmers yesterday, and two things
> came up:
> some said that CLOS by definition has a MOP builtin,

Common Lisp has part of a MOP in the ANSI Common Lisp standard.
DEFCLASS has for example a :METACLASS option.
It has some standard meta-classes (standard-class, built-in-class,
structure-class). It has meta-objects like
STANDARD-OBJECT, etc.

Several implementations are extending this. There is
"introspective" MOP functionality.

And then there is the "full" MOP, similar to the one specified
in AMOP ("The Art of the Metaobject Protocol"). Some
implementations are providing it.

> I said that a MOP is a layer built "on top of" CLOS

It is not really built "on top". It is more like CLOS
implementing itself (on-top, below, and within ;-) ).

> ( obviously you do have to have significant access to the internals )
> and that just because you are using CLOS does not mean you 
> have access to a MOP.

See above.

> This comes from my understanding ( what little there is of it, sigh ) 
> of The Art of.... book.
> Also some of us were wondering if we can get a full CLOS with MOP to
> play with.

PCL is a "portable" implementation of CLOS. It is freely
available. The code from AMOP is also available.
See:

http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/0.html


> Any idea of a free implementation ( Linux and/or Windows).

CMUCL is such a implementation, available for Linux/Unix. CMUCL
uses PCL. See:

http://www.cons.org/cmucl/


> Also what do single user licenses go for for the commercial versions.

Commercial Common Lisp implementations with good MOP support
are for example Allegro Common Lisp (Franz) and LispWorks (Xanalys).
For LispWorks pricing see
http://www.xanalys.com/software_tools/buy/index.html .
For both trial versions are available.
From: Thaddeus L Olczyk
Subject: Re: Does CLOS automatically have a MOP?
Date: 
Message-ID: <3aa4b46b.150020640@nntp.interaccess.com>
On Thu, 22 Feb 2001 16:40:30 GMT, ······@interaccess.com (Thaddeus L
Olczyk) wrote:

>I was meeting with some fellow programmers yesterday, and two things
>came up:
>some said that CLOS by definition has a MOP builtin,
>I said that a MOP is a layer built "on top of" CLOS
Let me clarify here what intended to say,
I intended to say that a person buy a "standard" version
of CLOS is not   guaranteed of having MOP capabilities.
From the responses I gather that I was partially right.
An implementation of CLOS has to come with some MOP
capabilities, but they are very meager, not quite as powerful
as a "full" version.
In other words toget a fully functional MOP ( yep those janitorial
jobs are really attractive ) you have toget something in addition to
CLOS.
>( obviously you do have to have significant access to the internals )
>and that just because you are using CLOS does not mean you 
>have access to a MOP.
>This comes from my understanding ( what little there is of it, sigh ) 
>of The Art of.... book.
Here is where I generated the confusion. My understanding is that in
TAoMOP, he built a language description of a CLOS MOP on top
of CLOS.