Embeddable Common-Lisp

On 13 Feb 2006, at 06:57, Dan Debertin wrote:

> I'm trying out MOP features on various Lisps lately.

You might be interested in the Closer Project. See http://common- 
lisp.net/project/closer/

> Actually, if it's generally known that MOP on ECL is not well- 
> implemented or
> doesn't work, a simple "no, go away" will suffice ;-).

AFAIK, it's indeed the case that ECL doesn't support the MOP very well.


Pascal

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

On Mon, 2006-02-13 at 05:57 +0000, Dan Debertin wrote:
> It looks like classes using STANDARD-CLASS as the metaclass get a slot =
called
> SLOT-INDEX-TABLE, but classes using other metaclasses, including descen=
dants of
> STANDARD-CLASS (in my case, MY-TEST), do not.

This slot should be inherited by all subclasses of standard-class.

> Is this a bug? Is anyone working on it, or should I dig into it?

It would be nice if you found what is really happening.

> Actually, if it's generally known that MOP on ECL is not well-implement=
ed or
> doesn't work, a simple "no, go away" will suffice ;-).

The problem with ECL is that it got a "castrated" version of CLOS which
aimed for simplicity and easy bootstrapping. I am now reimplementing the
parts of the MOP which were missing. Lot has been done:
finalize-inheritance, change-class, etc. But there might be still some
bugs left and there are definitely things to do such as reimplementing
methods in a more standard way.

Juanjo

--=20
Max-Planck-Institut f=C3=BCr Quantenoptik
Hans-Kopfermann-Str. 1, Garching, D-85748, Germany
Phone: +49 89 32905 345   Fax: +49 89 32905 336
http://www.mpq.mpg.de/Theorygroup/CIRAC/

Pascal Costanza <pc@...> writes:

> 
> 
> On 13 Feb 2006, at 06:57, Dan Debertin wrote:
> 
> > I'm trying out MOP features on various Lisps lately.
> 
> You might be interested in the Closer Project. See http://common- 
> lisp.net/project/closer/

I am aware of Closer and think it's a good idea. What I'm looking for, though,
is a native-executable-compiling (via C is fine) Lisp with good MOP support,
which means GCL or ECL. Both have problems with the MOP, and aren't supported by
Closer.

-Dan

Juan Jose Garcia Ripoll <lisp@...> writes:

> 
> On Mon, 2006-02-13 at 05:57 +0000, Dan Debertin wrote:
> > It looks like classes using STANDARD-CLASS as the metaclass get a slot
> > called SLOT-INDEX-TABLE, but classes using other metaclasses, including 
> > descendants of STANDARD-CLASS (in my case, MY-TEST), do not.
> 
> This slot should be inherited by all subclasses of standard-class.

Okay, glad I was right in my assessment.
> 
> > Is this a bug? Is anyone working on it, or should I dig into it?
> 
> It would be nice if you found what is really happening.

Okay, I will find some time to fix it. But given what I've seen of
src/clos/*.lsp, it looks like even if I fix this one problem, use of MOP in
general is going to be a bit of a chore. At least right now.

> The problem with ECL is that it got a "castrated" version of CLOS which
> aimed for simplicity and easy bootstrapping. 

Is ECL's CLOS a derivative of PCL? If not, would replacing it with an adaptation
of PCL be possible or desirable? Everybody else is using it....

Thanks for your response,

-Dan

> The problem with ECL is that it got a "castrated" version of CLOS which
> aimed for simplicity and easy bootstrapping. I am now reimplementing the
> parts of the MOP which were missing. Lot has been done:
> finalize-inheritance, change-class, etc. But there might be still some
> bugs left and there are definitely things to do such as reimplementing
> methods in a more standard way.

In investigating a GBBopen port to ECL, I found that the latest CVS 
version of defclass does not allow additional class options associated 
with a metaclass (see #+cant-assume-this below, in this excerpt from 
defclass).  Some mechanism (such as an option-validation method) needs 
to be provided to allow class-option extensions.

>     (dolist (option args)
>       (let ((option-name (first option))
>             option-value)
>         (if (member option-name processed-options)
>             (si:simple-program-error
>              "Option ~s for DEFCLASS specified more than once"
>              option-name)
>             (push option-name processed-options))
>         (setq option-value
>           (case option-name
>             ((:metaclass :documentation)
>              (list 'quote (second option)))
>             (:default-initargs
>                 (setf option-name :direct-default-initargs)
>                 (parse-default-initargs (rest option)))
>             #+cant-assume-this
>             (otherwise
>              (si:simple-program-error "~S is not a valid DEFCLASS option"
>                                       option-name))))
>         (setf options (list* option-name option-value options))))

Also, I was surprised that only the following symbols were exported from 
the CLOS package:

clos:slot-definition-documentation
clos:slot-definition
clos:slot-definition-allocation
clos:slot-definition-name
clos:slot-definition-initfunction
clos:slot-definition-initargs
clos:slot-definition-initform
clos:slot-definition-readers
clos:slot-definition-type
clos:slot-definition-writers

I expected that all the AMOP symbols would be exported.

-- Dan

On 13 Feb 2006, at 19:46, Daniel Debertin wrote:

> Pascal Costanza <pc@...> writes:
>
>> On 13 Feb 2006, at 06:57, Dan Debertin wrote:
>>
>>> I'm trying out MOP features on various Lisps lately.
>>
>> You might be interested in the Closer Project. See http://common-
>> lisp.net/project/closer/
>
> I am aware of Closer and think it's a good idea. What I'm looking  
> for, though,
> is a native-executable-compiling (via C is fine) Lisp with good MOP  
> support,
> which means GCL or ECL. Both have problems with the MOP, and aren't  
> supported by
> Closer.

GCL isn't supported yet because it isn't officially ANSI-compliant  
yet. Last time I have checked (abou a year ago, or so) not even my  
package definitions worked out of the box, so I didn't want work  
around such limitations but instead have chosen to wait for 2.7  
(that's when GCL is planned to be ANSI-compliant). As soon as that's  
the case, I will add GCL.

ECL didn't claim to be MOP compliant in the first place, so I didn't  
take it into account. It would be no problem to make the necessary  
changes to the MOP Feature Tests test suite to support ECL so that  
you have a good idea which features are already supported and which  
are missing. Please let me know if you're interested.


Pascal

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

On Mon, 2006-02-13 at 18:53 +0000, Daniel Debertin wrote:
> Is ECL's CLOS a derivative of PCL? If not, would replacing it with an
> adaptation of PCL be possible or desirable?

I am not sure that replacing it with PCL would help. ECL=B4s objects are
deeply integrated into the C core, which is good. Working out the
details of PCL is probably just as difficult as implementing what is
left. Or maybe not. In any case I would not _replace_ it but probably
just add it as an option. PCL is far too heavy and assumes that the lisp
has a decent compiler. ECL's implementation does some things (method
combinations) in a probably saner way.

> Everybody else is using it....

Not really. I think commercial implementations have their own CLOS
system, and CLISP does as well.

Regards,

Juanjo

P.S.: Sorry for the delay. I mistyped the address and the message
bounced while I was abroad.

Pascal Costanza <pc@...> writes:

> On 13 Feb 2006, at 19:46, Daniel Debertin wrote:

>> [ ... Closer to MOP project doesn't support GCL ... ]

> GCL isn't supported yet because it isn't officially ANSI-compliant  
> yet. Last time I have checked (abou a year ago, or so) not even my  
> package definitions worked out of the box, so I didn't want work  
> around such limitations but instead have chosen to wait for 2.7  
> (that's when GCL is planned to be ANSI-compliant). As soon as that's  
> the case, I will add GCL.

The CVS version of GCL is 2.7.0 and does claim to be ANSI-compliant when
./configure'd with the --enable-ansi flag (which should be the default IMO...).
It comes with the full ANSI test suite by Paul Dietz. So it might be worth
another look.

-Dan

On 16 Feb 2006, at 20:01, Daniel Debertin wrote:

> Pascal Costanza <pc@...> writes:
>
>> On 13 Feb 2006, at 19:46, Daniel Debertin wrote:
>
>>> [ ... Closer to MOP project doesn't support GCL ... ]
>
>> GCL isn't supported yet because it isn't officially ANSI-compliant
>> yet. Last time I have checked (abou a year ago, or so) not even my
>> package definitions worked out of the box, so I didn't want work
>> around such limitations but instead have chosen to wait for 2.7
>> (that's when GCL is planned to be ANSI-compliant). As soon as that's
>> the case, I will add GCL.
>
> The CVS version of GCL is 2.7.0 and does claim to be ANSI-compliant  
> when
> ./configure'd with the --enable-ansi flag (which should be the  
> default IMO...).
> It comes with the full ANSI test suite by Paul Dietz. So it might  
> be worth
> another look.

OK, but the next problem is: I cannot get it compiled on Mac OS X.  
Damn...


Pascal

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

On 14 Feb 2006, at 4:45, Pascal Costanza wrote:

> ECL didn't claim to be MOP compliant in the first place, so I  
> didn't take it into account. It would be no problem to make the  
> necessary changes to the MOP Feature Tests test suite to support  
> ECL so that you have a good idea which features are already  
> supported and which are missing. Please let me know if you're  
> interested.

I would definitely be interested in this. At work we use CL- 
Containers, which uses Moptilities, which recently added a dependency  
on Closer. So, we're currently not up-to-date because there is no  
Closer support on ECL.

I've started to work on this, but there are always more pressing  
projects at work, so I haven't gotten very far.

On 19 Feb 2006, at 02:24, Gregory Martin Pfeil wrote:

> On 14 Feb 2006, at 4:45, Pascal Costanza wrote:
>
>> ECL didn't claim to be MOP compliant in the first place, so I  
>> didn't take it into account. It would be no problem to make the  
>> necessary changes to the MOP Feature Tests test suite to support  
>> ECL so that you have a good idea which features are already  
>> supported and which are missing. Please let me know if you're  
>> interested.
>
> I would definitely be interested in this. At work we use CL- 
> Containers, which uses Moptilities, which recently added a  
> dependency on Closer. So, we're currently not up-to-date because  
> there is no Closer support on ECL.
>
> I've started to work on this, but there are always more pressing  
> projects at work, so I haven't gotten very far.

OK, I'll see what I can do in the next few days. (I expect there to  
be some problems ahead, though...)


Cheers,
Pascal

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