Here is an announcement of the Closer Project. This project is an
umbrella project for a few subprojects whose aim is to improve the
usability of the CLOS MOP across different Common Lisp implementations.
The project website is at http://common-lisp.net/project/closer/
The first step (which already exists to a large degree) is a library
that checks what features of the AMOP specification is supported by a
given CL implementation. This results in a number of keywords that
describe the various aspects of a MOP which can, for example, be used to
conditionalize one's source code (when added to *features*). Currently,
the following Common Lisp implementations are supported:
* Allegro Common Lisp, 6.2 Trial Version
* CLisp, 2.33.80
* CMU CL, experimental port to Mac OS X, 2004-01-28-020
* LispWorks 4.3 for Macintosh, Personal Edition
* OpenMCL 0.14.2-p1
* SBCL 0.8.18
...and some other implementation that I am not allowed to talk about.
The second step (which exists as a rough sketch) is a compatibility
library that provides a package that adds missing features and/or
replaces existing features with versions that better reflect the AMOP
specs. If the latter is not possible, I try to provide utility functions
that allow one to work around restrictions.
Finally, the Closer project should host a few example metaclasses,
including some of the examples given in AMOP, and probably others as
well. For example, my goal is to move some of the stuff from AspectL to
the Closer project in order to turn this into a more coherent library.
It is important to provide example applications of the MOP because they
implicitly provide test cases against which new MOP implementations can
be checked for compatibility.
So in the long run, the Closer project should help to bring the MOP into
a shape that Common Lisp programmers can better rely on across many
implementations.
Pascal
Disclaimer: This project is in a very early stage. Don't publish any
findings about existing MOP implementations based on the software
offered there with the implicit suggestion that they are facts. It is
very likely that the code includes bugs and misinterpretations of the
AMOP specification. You have been warned!
Pascal Costanza wrote:
> Here is an announcement of the Closer Project. This project is an
> umbrella project for a few subprojects whose aim is to improve the
> usability of the CLOS MOP across different Common Lisp implementations.
> The project website is at http://common-lisp.net/project/closer/
>
Just wanted to make sure you've seen Marco Baringer's MOPP library (part
of arnesi, which i use as part of UCW.
(http://common-lisp.net/project/bese/arnesi.html).
He also posted to source to small-cl-sources (or whatever it's non-gmane
name is).
This is very cool BTW, i've been thinking of doing something similar
once i have a better handle on the MOP.
drewc
>
> The first step (which already exists to a large degree) is a library
> that checks what features of the AMOP specification is supported by a
> given CL implementation. This results in a number of keywords that
> describe the various aspects of a MOP which can, for example, be used to
> conditionalize one's source code (when added to *features*). Currently,
> the following Common Lisp implementations are supported:
>
> * Allegro Common Lisp, 6.2 Trial Version
> * CLisp, 2.33.80
> * CMU CL, experimental port to Mac OS X, 2004-01-28-020
> * LispWorks 4.3 for Macintosh, Personal Edition
> * OpenMCL 0.14.2-p1
> * SBCL 0.8.18
>
> ...and some other implementation that I am not allowed to talk about.
>
>
> The second step (which exists as a rough sketch) is a compatibility
> library that provides a package that adds missing features and/or
> replaces existing features with versions that better reflect the AMOP
> specs. If the latter is not possible, I try to provide utility functions
> that allow one to work around restrictions.
>
>
> Finally, the Closer project should host a few example metaclasses,
> including some of the examples given in AMOP, and probably others as
> well. For example, my goal is to move some of the stuff from AspectL to
> the Closer project in order to turn this into a more coherent library.
> It is important to provide example applications of the MOP because they
> implicitly provide test cases against which new MOP implementations can
> be checked for compatibility.
>
> So in the long run, the Closer project should help to bring the MOP into
> a shape that Common Lisp programmers can better rely on across many
> implementations.
>
>
> Pascal
>
> Disclaimer: This project is in a very early stage. Don't publish any
> findings about existing MOP implementations based on the software
> offered there with the implicit suggestion that they are facts. It is
> very likely that the code includes bugs and misinterpretations of the
> AMOP specification. You have been warned!
drewc wrote:
> Pascal Costanza wrote:
>
>> Here is an announcement of the Closer Project. This project is an
>> umbrella project for a few subprojects whose aim is to improve the
>> usability of the CLOS MOP across different Common Lisp
>> implementations. The project website is at
>> http://common-lisp.net/project/closer/
>
> Just wanted to make sure you've seen Marco Baringer's MOPP library (part
> of arnesi, which i use as part of UCW.
> (http://common-lisp.net/project/bese/arnesi.html).
Now that you have posted it. ;)
But after a first skim through the source it seems to me that he
basically provides a single package that makes the necessary symbols
available, no matter where they are in the host implementation. That's
only part of the solution. The real issues are: Are the right functions
called correctly in the right protocols, etc.? The various MOP
implementations usually deviate in one regard or the other. That's what
i am trying to fix.
> He also posted to source to small-cl-sources (or whatever it's non-gmane
> name is).
I won't try to track them. I will rather contact him directly. ;)
> This is very cool BTW, i've been thinking of doing something similar
> once i have a better handle on the MOP.
I hope to have the compatibility stuff online soon, and then there will
probably be enough work left to get things into shape. ;)
Pascal
Pascal Costanza <ยทยท@p-cos.net> writes:
> But after a first skim through the source it seems to me that he
> basically provides a single package that makes the necessary symbols
> available, no matter where they are in the host implementation. That's
> only part of the solution. The real issues are: Are the right
> functions called correctly in the right protocols, etc.? The various
> MOP implementations usually deviate in one regard or the other. That's
> what i am trying to fix.
>
>> He also posted to source to small-cl-sources (or whatever it's
>> non-gmane name is).
>
> I won't try to track them. I will rather contact him directly. ;)
don't bother. my mopp library only ensures that cretain symbols exist
and can be found in a particular package (mopp). as a testament to the
various mop implementations this very simple technique has been enough
to get UCW (which uses meta classes, custom slot definitions and
custom method combinations) running.
the only problems i have run into are: 1) on lispworks eql
specializers are implemented with lists; 2) different implementations
deal differently with initargs passed multiple times to a
direct-slot-definition.
i look forward to helping you with closer [especially since that means
i can bug you when bugs occur instead of having to fix them myself
:)].
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Pascal Costanza wrote:
> drewc wrote:
>> Just wanted to make sure you've seen Marco Baringer's MOPP library
>> (part of arnesi, which i use as part of UCW.
>> (http://common-lisp.net/project/bese/arnesi.html).
>
>
> Now that you have posted it. ;)
Well, i should mention clim-mop as well, as Andy Hefner let out a big
sigh when i mentioned your project on #lisp yesterday :)
drewc