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

[Pascal Costanza]

On 23 Jun 2006, at 16:49, Jack Unrue wrote:


> On 6/23/06, Pascal Costanza <pc at p-cos.net> wrote:
>
>>
>> Fortunately, delete-package is only used in the test suite to provide
>> a clean room for each test case. The simplest workaround I can think
>> of is to provide a new package for each test case. (Currently, they
>> all run in the same package, but between each run, that package is
>> deleted and recreated again.)
>>
>
> OK.
>
>
>> Before putting too much work into this, it would make more sense to
>> first check whether a port of Closer to MOP to Corman Lisp is
>> actually feasible. The last time I have checked, Corman Lisp's CLOS
>> implementation was largely incompatible with the CLOS MOP spec. They
>> have based their implementation on Closette, as provided in the AMOP
>> book, and tweaked it to make it more ANSI-compliant. However,
>> Closette is compatible with the CLOS MOP only in very few areas.
>> Closer to MOP only provides fixes for CLOS implementations that
>> attempt to be already somewhat close to the CLOS MOP specification.
>> An attempt to fix an implementation that deviates too much doesn't
>> make a lot of sense, because this would largely mean to more or less
>> implement it from scratch. In that case, one could rather start to
>> think about porting PCL. ;)
>>
>
> Thanks for the info, I appreciate it. I was going to try porting  
> Closer
> so that I could then work on porting my Graphic-Forms library to the
> new release of Corman.
>
> I use Closer in my code to define subclasses of an event handler
> base class and implement one or more methods for associated
> generic functions, on behalf of application code. So, in addition
> to possibly porting PCL (which I realize is potentially a major  
> project
> not to be lightly taken on :-), another alternative is to change my
> code such that I don't use Closer any more -- but this means
> disrupting a feature that is working just fine on other Lisps.
>
> As a result, I'm probably going to prioritize Corman Lisp lower
> again and work on something else.
>

Hm, hold your horses. ;) If these are indeed the only two features  
you need, they should probably be relatively straightforward to support.

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.

Do people have any specific opinions wrt this topic?


>> So the interesting question is this: Has Corman Lisp considerably
>> changed their CLOS implementation to be more CLOS-MOP-compliant? (Do
>> you have a link/pointer available where I could check this?)
>>
>
> To get an "official" statement, I've posted a note to one of Corman's
> forums asking about this and will followup here with a link to any  
> reply.
> But comments in the clos.lisp source file in the beta I have indicates
> that it is still based on Closette.
>

I would be surprised otherwise. Porting PCL _is_ a major undertaking. ;)


Pascal

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