headers
Pascal Costanza | 9 May 2006 21:43

Closer to MOP for ecl

Hi everyone,

The darcs repository for the Closer project contains some first  
support for ecl. This includes MOP Feature Tests, Closer to MOP,  
ContextL and AspectL. Only some of the test cases work, but maybe the  
current version is good enough to provide some level of portability  
from/to other CLOS MOP implementations.

The tests were performed on a PowerBook G4 with Mac OS X 10.4.6 using  
the current CVS version of ecl.

Cheers,
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
Permalink | Reply | 25 comments |
headers
Greg Pfeil | 10 May 2006 00:22
Picon

Re: Closer to MOP for ecl

On 9 May 2006, at 12:43, Pascal Costanza wrote:

> The darcs repository for the Closer project contains some first 
> support for ecl. This includes MOP Feature Tests, Closer to MOP, 
> ContextL and AspectL. Only some of the test cases work, but maybe the 
> current version is good enough to provide some level of portability 
> from/to other CLOS MOP implementations.

I'm very excited by how this is coming along. Unfortunately, I still 
can't use a current CL-Containers, since it depends on Moptilities, 
which requires STANDARD-READER-METHOD, which ECL still doesn't have. Is 
this correct, Pascal, or should S-R-M be there, and I've got something 
wrong elsewhere?

I can still use old CL-Containers, though, which is fine ... I just 
want to make sure that I'm not running into some other problem that I 
may be able to work around.

Thanks.

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply | 22 comments |
headers
Pascal Costanza | 10 May 2006 17:41

Re: [Ecls-list] Closer to MOP for ecl


On 10 May 2006, at 00:22, Greg Pfeil wrote:

> On 9 May 2006, at 12:43, Pascal Costanza wrote:
>
>> The darcs repository for the Closer project contains some first  
>> support for ecl. This includes MOP Feature Tests, Closer to MOP,  
>> ContextL and AspectL. Only some of the test cases work, but maybe  
>> the current version is good enough to provide some level of  
>> portability from/to other CLOS MOP implementations.
>
> I'm very excited by how this is coming along. Unfortunately, I  
> still can't use a current CL-Containers, since it depends on  
> Moptilities, which requires STANDARD-READER-METHOD, which ECL still  
> doesn't have. Is this correct, Pascal, or should S-R-M be there,  
> and I've got something wrong elsewhere?

This is correct, standard-accessor-method and its subclasses are not  
available. Maybe you can just define them by saying (defclass  
c2mop::standard-accessor-method (standard-method) ()), etc., export  
standard-accessor-method, etc., from c2mop, and then see if you get  
farther than before.

If this does the trick, I will just add these class definitions to  
Closer to MOP. ECL currently doesn't use these classes, but it  
shouldn't hurt anyone if the classes are available nevertheless.

Pascal

--

--
(Continue reading)

Permalink | Reply | 20 comments |
headers
Greg Pfeil | 10 May 2006 19:49
Picon

Re: Closer to MOP for ecl

On 10 May 2006, at 8:41, Pascal Costanza wrote:

> On 10 May 2006, at 00:22, Greg Pfeil wrote:
>
>> I'm very excited by how this is coming along. Unfortunately, I still 
>> can't use a current CL-Containers, since it depends on Moptilities, 
>> which requires STANDARD-READER-METHOD, which ECL still doesn't have. 
>> Is this correct, Pascal, or should S-R-M be there, and I've got 
>> something wrong elsewhere?
>
> This is correct, standard-accessor-method and its subclasses are not 
> available. Maybe you can just define them by saying (defclass 
> c2mop::standard-accessor-method (standard-method) ()), etc., export 
> standard-accessor-method, etc., from c2mop, and then see if you get 
> farther than before.

Yep, that worked. I had to do the same for EQL-SPECIALIZER to get 
through Moptilities. I've got another problem with CL-Containers now, 
but it appears to be non-MOP related :)

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply | 18 comments |
headers
Pascal Costanza | 11 May 2006 10:53

Re: [Ecls-list] Closer to MOP for ecl


On 10 May 2006, at 19:49, Greg Pfeil wrote:

> On 10 May 2006, at 8:41, Pascal Costanza wrote:
>
>> On 10 May 2006, at 00:22, Greg Pfeil wrote:
>>
>>> I'm very excited by how this is coming along. Unfortunately, I  
>>> still can't use a current CL-Containers, since it depends on  
>>> Moptilities, which requires STANDARD-READER-METHOD, which ECL  
>>> still doesn't have. Is this correct, Pascal, or should S-R-M be  
>>> there, and I've got something wrong elsewhere?
>>
>> This is correct, standard-accessor-method and its subclasses are  
>> not available. Maybe you can just define them by saying (defclass  
>> c2mop::standard-accessor-method (standard-method) ()), etc.,  
>> export standard-accessor-method, etc., from c2mop, and then see if  
>> you get farther than before.
>
> Yep, that worked. I had to do the same for EQL-SPECIALIZER to get  
> through Moptilities. I've got another problem with CL-Containers  
> now, but it appears to be non-MOP related :)

OK, I will probably add the accessor-method-related classes. For eql- 
specializer, I don't think it's a good idea to define a class because  
I define eql-specializer as a type instead. So there is probably now  
a nameclash between the type and the class here.

I have used the type definition for eql-specializer already in other  
CLOS MOP implementations, so Moptilities probably already has the
(Continue reading)

Permalink | Reply | 16 comments |
headers
Gary King | 11 May 2006 15:36
Favicon
Gravatar

Re: Re: [Ecls-list] Closer to MOP for ecl

I'm following this discussion and will look into how I do things  
later today...

On May 11, 2006, at 4:53 AM, Pascal Costanza wrote:

>
> On 10 May 2006, at 19:49, Greg Pfeil wrote:
>
>> On 10 May 2006, at 8:41, Pascal Costanza wrote:
>>
>>> On 10 May 2006, at 00:22, Greg Pfeil wrote:
>>>
>>>> I'm very excited by how this is coming along. Unfortunately, I  
>>>> still can't use a current CL-Containers, since it depends on  
>>>> Moptilities, which requires STANDARD-READER-METHOD, which ECL  
>>>> still doesn't have. Is this correct, Pascal, or should S-R-M be  
>>>> there, and I've got something wrong elsewhere?
>>>
>>> This is correct, standard-accessor-method and its subclasses are  
>>> not available. Maybe you can just define them by saying (defclass  
>>> c2mop::standard-accessor-method (standard-method) ()), etc.,  
>>> export standard-accessor-method, etc., from c2mop, and then see  
>>> if you get farther than before.
>>
>> Yep, that worked. I had to do the same for EQL-SPECIALIZER to get  
>> through Moptilities. I've got another problem with CL-Containers  
>> now, but it appears to be non-MOP related :)
>
> OK, I will probably add the accessor-method-related classes. For  
> eql-specializer, I don't think it's a good idea to define a class
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gregory Martin Pfeil | 11 May 2006 17:48
Picon

Re: [closer-devel] Re: Closer to MOP for ecl

On 11 May 2006, at 6:36, Gary King wrote:

> I'm following this discussion and will look into how I do things  
> later today...
>
> On May 11, 2006, at 4:53 AM, Pascal Costanza wrote:
>
>> OK, I will probably add the accessor-method-related classes. For  
>> eql-specializer, I don't think it's a good idea to define a class  
>> because I define eql-specializer as a type instead. So there is  
>> probably now a nameclash between the type and the class here.

Well, I didn't see eql-specializer imported into closer-mop, or  
implemented (but it was exported, IIRC).

>> I have used the type definition for eql-specializer already in  
>> other CLOS MOP implementations, so Moptilities probably already  
>> has the conditionalization that would only be needed to be  
>> switched on for ecl. (But I am just guessing.) Maybe ask Gary King  
>> about this.

I think moptilities is using it like this:

(defgeneric eql-specializer-p (obj)
   (:documentation "")
   (:method ((obj eql-specializer)) t)
   (:method (obj) nil))

which, since eql-specializer is a type should probably be changed to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Pfeil | 11 May 2006 19:40
Picon

Re: [closer-devel] Re: Closer to MOP for ecl


On 11 May 2006, at 8:48, Gregory Martin Pfeil wrote:

> Well, I didn't see eql-specializer imported into closer-mop, or 
> implemented (but it was exported, IIRC).

Sorry, I do see eql-specializer defined. That's what I get for replying 
without checking first.

Also, closer-mop implements eql-specializer-p, so it looks like the 
implementation in moptilities is redundant.

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply | 0 comments |
headers
Gary King | 11 May 2006 20:15
Favicon
Gravatar

Re: [closer-devel] Re: Closer to MOP for ecl

I'm not sure what to do. Some Lisps (such as OpenMCL and SBCL) define  
eql-specializer as a class. Others (such as LispWorks) do not  
(AFAICT). Also, I don't see eql-specializer-p being exported or  
defined in Closer to MOP. It's used in ECL and LispWorks but not  
defined. I think what I want is

> (defgeneric eql-specializer-p (thing)
>   (:documentation "If thing is an eql-specializer, returns a  
> representation of thing as \(eql <object>\).")
>   #-(or lispworks ecl)
>   (:method ((thing eql-specializer))
>            (list 'eql (eql-specializer-object thing)))
>   (:method ((thing t))
>            #-(or lispworks ecl)
>            (values nil)
>            #+(or lispworks ecl)
>            (typep obj 'eql-specializer))
>   #+digitool
>   (:method ((thing cons))
>            ;; don't ask, don't tell
>            thing))

comments?

On May 11, 2006, at 4:53 AM, Pascal Costanza wrote:

> I have used the type definition for eql-specializer already in  
> other CLOS MOP implementations, so Moptilities probably already has  
> the conditionalization that would only be needed to be switched on  
> for ecl. (But I am just guessing.) Maybe ask Gary King about this.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Greg Pfeil | 11 May 2006 20:38
Picon

Re: [closer-devel] Re: Closer to MOP for ecl

On 11 May 2006, at 11:15, Gary King wrote:

> I'm not sure what to do. Some Lisps (such as OpenMCL and SBCL) define 
> eql-specializer as a class. Others (such as LispWorks) do not 
> (AFAICT). Also, I don't see eql-specializer-p being exported or 
> defined in Closer to MOP. It's used in ECL and LispWorks but not 
> defined.

In the current darcs for Closer-MOP, I see this in ecl/closer-mop.lisp:

(defun eql-specializer-p (cons)
   (and (consp cons)
        (eq (car cons) 'eql)
        (null (cddr cons))))

(deftype eql-specializer ()
   '(or eql-specializer*
        (satisfies eql-specializer-p)))

(cl:defgeneric eql-specializer-object (eql-specializer)
   (:method ((cons cons))    (if (eql-specializer-p cons)
        (cadr cons)
      (error "~S is not an eql-specializer." cons))))

and a few other definitions. I didn't look at it for other impls, 
though.

I just changed the version in Moptilities to what was in your last 
mail, and now I'm back to the cl-containers error I was getting 
yesterday:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane