From pc at p-cos.net Tue May 9 19:43:00 2006 From: pc at p-cos.net (Pascal Costanza) Date: Tue, 9 May 2006 21:43:00 +0200 Subject: [closer-devel] Closer to MOP for ecl Message-ID: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> 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 From sellout42 at mac.com Tue May 9 22:22:42 2006 From: sellout42 at mac.com (Greg Pfeil) Date: Tue, 9 May 2006 15:22:42 -0700 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> Message-ID: <8955defd33e0c8cb096b04ea9dd4370c@mac.com> 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. From pc at p-cos.net Wed May 10 15:41:17 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 10 May 2006 17:41:17 +0200 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <8955defd33e0c8cb096b04ea9dd4370c@mac.com> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> Message-ID: 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 -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From sellout42 at mac.com Wed May 10 17:49:20 2006 From: sellout42 at mac.com (Greg Pfeil) Date: Wed, 10 May 2006 10:49:20 -0700 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> Message-ID: <46cebfbac304f861afa6c54b83e4e2f1@mac.com> 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 :) From pc at p-cos.net Thu May 11 08:53:54 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 11 May 2006 10:53:54 +0200 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <46cebfbac304f861afa6c54b83e4e2f1@mac.com> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> Message-ID: 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 conditionalization that would only be needed to be switched on for ecl. (But I am just guessing.) Maybe ask Gary King about this. 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 From gwking at metabang.com Thu May 11 13:36:42 2006 From: gwking at metabang.com (Gary King) Date: Thu, 11 May 2006 09:36:42 -0400 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> Message-ID: 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 > 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 conditionalization that would only be needed to be switched on > for ecl. (But I am just guessing.) Maybe ask Gary King about this. > > > 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 > > > > > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally) From sellout42 at mac.com Thu May 11 15:48:38 2006 From: sellout42 at mac.com (Gregory Martin Pfeil) Date: Thu, 11 May 2006 08:48:38 -0700 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> Message-ID: 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 (defgeneric eql-specializer-p (obj) (:documentation "") (:method (obj) (typep obj 'eql-specializer))) From sellout42 at mac.com Thu May 11 17:40:12 2006 From: sellout42 at mac.com (Greg Pfeil) Date: Thu, 11 May 2006 10:40:12 -0700 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> Message-ID: <3da2502f29a573e0ecbd21a3ee459ae9@mac.com> 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. From gwking at metabang.com Thu May 11 18:15:23 2006 From: gwking at metabang.com (Gary King) Date: Thu, 11 May 2006 14:15:23 -0400 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> Message-ID: <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> 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 \).") > #-(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. > -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally) From pc at p-cos.net Thu May 11 18:39:06 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 11 May 2006 20:39:06 +0200 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> Message-ID: <8BF11826-589D-4FA5-95AA-E5CF4989E12F@p-cos.net> On 11 May 2006, at 20: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. 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 \).") >> #-(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? The "correct" way is to implement eql specializers as a class, so there would be no need to implement eql-specializer-p because (typep thing 'eql-specializer) should already do what you want. LispWorks and ecl are the only implementations that implement eql specializers as lists (wich, btw, better complies with ANSI Common Lisp, but that's another story). LispWorks provides eql-specializer- p, which I just use in Closer to MOP. In ecl, I have defined it internall, but haven't exported it. I don't want to implement eql-specializer as a class in Closer to MOP because I fear this would lead to unexpected behavior and hard-to- find bugs. Imagine someone writes a method like this: (defmethod foo ((thing eql-specializer)) ...) Since eql specializers are actually lists in LW and ecl, this method wouldn't work. So I prefer my current solution, where defining this method already issues an error. I could indeed provide eql-specializer-p across all CL implementations if this helps. That's what you're telling me, if I understand correctly, right? Pascal > 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. > > > -- > Gary Warren King > metabang.com > http://www.metabang.com/ > (413) 210 7511 > gwking on #lisp (occasionally) > > -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From pc at p-cos.net Thu May 11 18:43:47 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 11 May 2006 20:43:47 +0200 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <8BF11826-589D-4FA5-95AA-E5CF4989E12F@p-cos.net> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> <8BF11826-589D-4FA5-95AA-E5CF4989E12F@p-cos.net> Message-ID: <56F53E5D-CBDB-4FC8-A007-608645D6B65A@p-cos.net> On 11 May 2006, at 20:39, Pascal Costanza wrote: > I could indeed provide eql-specializer-p across all CL > implementations if this helps. That's what you're telling me, if I > understand correctly, right? ...but I just realized that this wouldn't buy you much, because (type object 'eql-specializer) already works across all CL implementations. So what do you want? ;) 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 From sellout42 at mac.com Thu May 11 18:38:49 2006 From: sellout42 at mac.com (Greg Pfeil) Date: Thu, 11 May 2006 11:38:49 -0700 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> Message-ID: <3a1527647db470c0d4d263825d4de92d@mac.com> 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: ;;; Compiling (DEFCLASS CONTENTS-AS-HASHTABLE-MIXIN ...). ;;; Warning: Class KEY-VALUE-ITERATABLE-CONTAINER-MIXIN has been forward referenced. There is no method on the generic function CONTENTS that agrees on qualifiers NIL and specializers (#) Broken at LAMBDA. which I'm going to consider a good thing ;) Continuing our conversation from IRC ... I don't see a problem with the defclass at all ... it seems like ECL is seeing the :accessor argument, and looking up the method as opposed to defining it. I'm not sure why this is, as other DEFCLASS* forms are behaving. (defclass* contents-as-hashtable-mixin (uses-contents-mixin key-value-iteratable-container-mixin findable-container-mixin) ((contents :unbound :accessor contents) ;; unbound for make-ht-for-container )) From gwking at metabang.com Thu May 11 19:20:57 2006 From: gwking at metabang.com (Gary King) Date: Thu, 11 May 2006 15:20:57 -0400 Subject: [closer-devel] Re: [Ecls-list] Closer to MOP for ecl In-Reply-To: <56F53E5D-CBDB-4FC8-A007-608645D6B65A@p-cos.net> References: <821459FD-6A47-41EC-B2DD-5D24F69C6ABF@p-cos.net> <8955defd33e0c8cb096b04ea9dd4370c@mac.com> <46cebfbac304f861afa6c54b83e4e2f1@mac.com> <75EA5844-6234-42B2-9FD3-43C3F264B740@metabang.com> <8BF11826-589D-4FA5-95AA-E5CF4989E12F@p-cos.net> <56F53E5D-CBDB-4FC8-A007-608645D6B65A@p-cos.net> Message-ID: On May 11, 2006, at 2:43 PM, Pascal Costanza wrote: > ...but I just realized that this wouldn't buy you much, because > (type object 'eql-specializer) already works across all CL > implementations. > > So what do you want? ;) Ah, good point. I think I'll just convert my eql-specializer-p into a defun and go with that as a handy (?) abbreviation. thanks, -- Gary Warren King metabang.com http://www.metabang.com/ (413) 210 7511 gwking on #lisp (occasionally)