[closer-devel] starting work on a port to Corman Lisp

[Pascal Costanza]

Hi everybody,

In the recent days, I have taken a look at how these things could be  
broken up into digestible chunks. However, I am afraid that it  
doesn't make a lot of sense. The incompatibilities across CL  
implementations are rather random, and the whole picture looks more  
like Swiss Cheese [1] to me than anything you could reasonably  
explain. So this looks like a lot of work without any real benefit.  
(A nice benefit would have been if you could have stated requirements  
what features you need for a particular metaprogram, and this would  
have yielded the Common Lisp implementations that you could use.  
Unfortunately, things aren't by far that simple...)

The obvious separation of introspection and intercession is, well,  
obvious. So making it more formal doesn't buy us a lot either, I think.

Since I think I can spend my time on issues that will turn out more  
useful for CLOS MOP users, I will drop this idea.

Is there still interest to include support for Corman Lisp? I think  
we could get some (very limited) support into Closer to MOP, similar  
to the one we currently have for ECL. I would have to change the  
handling of packages in MOP Feature Tests, and then we could see how  
to proceed from there. Please let me know if you're interested...



Cheers,
Pascal

[1] lots of holes

On 29 Jun 2006, at 19:54, Gary King wrote:

> I think that having two or more reasonable conformance "levels"  
> would make sense. I also think that breaking MOP support into  
> introspection and semantics (implementation altering) makes sense.  
> I don't know much of anything about the consistency of MOP  
> implementations but it work to have something like (warning, ASCII  
> art ahead):
>
> MOP Support
> |
> +-------------------- introspection
> |                                |
> |                               +-------------------- level 1
> |                               +-------------------- level 2
> |
> +-------------------- implementation
>                                  |
>                                 +-------------------- level 1
>                                 +-------------------- level 2
>
> Where the levels lie will depend on how the MOP implementations  
> carve "nature at its joints". That Plato, he had such a way with  
> words. <smile>
>
>> Because of my own work with the CLOS MOP, I typically think of the  
>> more advanced features of the CLOS MOP. But I start to get the  
>> impression that people find Closer to MOP useful for the very  
>> basic features - and that makes a lot of sense, of course. Maybe I  
>> should restructure the library to make it easier to distinguish  
>> the base features for which we can have at least some guarantee  
>> that all covered CLOS implementations support them, and the other  
>> more advanced ones.
>>
>> For example, the pure introspective features are covered very well  
>> almost everywhere. It's only the semantics-changing features  
>> especially in the generic function invocation protocol that are  
>> problematic across CLOS implementations - but that's also the part  
>> where there actually seems to be very little demand.
>
>
> -- 
> Gary Warren King
> metabang.com
> http://www.metabang.com/
> (413) 210 7511
> gwking on #lisp (occasionally)
>
>
> _______________________________________________
> closer-devel mailing list
> closer-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium