From: Friedrich Dominicus
Subject: diverse MOP packages?
Date: 
Message-ID: <87vf1e7cqb.fsf@flarge.here>
Well while looking for a "portable" solution to export accessors,
writers or readers from classes I stumbeled upon at least 4 Portable
MOP packages. 

1) in McCLIM
2) in arnesi 
3) closer-mop
4) in cl-sql

I guess there are a few more. Has anyone an idea on how similiar,
different or complete the different things are?

Regards
Friedrich

-- 
Please remove just-for-news- to reply via e-mail.

From: Thomas F. Burdick
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <xcv4q8ympss.fsf@conquest.OCF.Berkeley.EDU>
Friedrich Dominicus <···················@q-software-solutions.de> writes:

> Well while looking for a "portable" solution to export accessors,
> writers or readers from classes I stumbeled upon at least 4 Portable
> MOP packages. 
> 
> 1) in McCLIM
> 2) in arnesi 
> 3) closer-mop
> 4) in cl-sql
> 
> I guess there are a few more. Has anyone an idea on how similiar,
> different or complete the different things are?

Notice your "in" for 1, 2, and 4.  Many projects contain a
MOP-portability layer that covers those parts of the MOP that they
need, to the extend that that project needs it.  As far as I know,
Closer to MOP is the only MOP portability layer that is meant to be
general-purpose.  And it's fairly new, hence the large number of
project-specific MOP layers.  If you're looking to do new, portable
MOP development, Closer looks like the best choice.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Pascal Costanza
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <3o5apgF49o2jU1@individual.net>
Friedrich Dominicus wrote:
> Well while looking for a "portable" solution to export accessors,
> writers or readers from classes I stumbeled upon at least 4 Portable
> MOP packages. 
> 
> 1) in McCLIM
> 2) in arnesi 
> 3) closer-mop
> 4) in cl-sql
> 
> I guess there are a few more. Has anyone an idea on how similiar,
> different or complete the different things are?

What is it that you want to do? ("Exporting accessors" is somewhat vague.)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
From: Friedrich Dominicus
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <87r7c273ts.fsf@flarge.here>
Pascal Costanza <··@p-cos.net> writes:

> Friedrich Dominicus wrote:
>> Well while looking for a "portable" solution to export accessors,
>> writers or readers from classes I stumbeled upon at least 4 Portable
>> MOP packages. 1) in McCLIM
>> 2) in arnesi 3) closer-mop
>> 4) in cl-sql
>> I guess there are a few more. Has anyone an idea on how similiar,
>> different or complete the different things are?
>
> What is it that you want to do? ("Exporting accessors" is somewhat
> vague.)
sorry for beeing vague. I was thinking about a way to automate the
export of accessor functions from packages. Once for LW I wrote the
following hack:

(defvar *which-key-words* '(:reader :writer :all))
#+LispWorks
(defun export-accessors (class &key (which :all) (test nil))
  (assert (find which *which-key-words*))
  (dolist (method (class-direct-methods (find-class class)))
    (cond
     ((and (or (eq which :all)
               (eq which :reader))
           (typep method 'standard-reader-method))
      (if test
          (format t "Would export ~a~%" (generic-function-name (method-generic-function method)))
        (export (generic-function-name (method-generic-function method)))))
     ((and (or (eq which :all)
               (eq which :writer))
           (typep method 'standard-writer-method))
      (if test
          (format t "Would export ~a~%" (cadr (generic-function-name (method-generic-function method))))
        (export (cadr (generic-function-name (method-generic-function method))))))
    (t
     (error "Should not happen")))))

Well of course this just works for LispWorks (at least as I tried
here), but now I'm using SBCL and wanted to write something
similar. So I delved into the MOP-stuff and found a lot of different
packages. Probably they all? have something to help me with it. I do not
know really how portable the posted code is, it just "happens" to work
for me here. 

In the end I find it to tedious to put all the accessor function in
the package description. It's easy to forget one and it's even easier
to mispell a name.

Regards
Friedrich

-- 
Please remove just-for-news- to reply via e-mail.
From: Pascal Costanza
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <3o5ka2F4bht1U1@individual.net>
Friedrich Dominicus wrote:

> Pascal Costanza <··@p-cos.net> writes:
> 
>>Friedrich Dominicus wrote:
>>
>>>Well while looking for a "portable" solution to export accessors,
>>>writers or readers from classes I stumbeled upon at least 4 Portable
>>>MOP packages. 1) in McCLIM
>>>2) in arnesi 3) closer-mop
>>>4) in cl-sql
>>>I guess there are a few more. Has anyone an idea on how similiar,
>>>different or complete the different things are?
>>
>>What is it that you want to do? ("Exporting accessors" is somewhat
>>vague.)
> 
> sorry for beeing vague. I was thinking about a way to automate the
> export of accessor functions from packages. Once for LW I wrote the
> following hack:
> 
> (defvar *which-key-words* '(:reader :writer :all))
> #+LispWorks
> (defun export-accessors (class &key (which :all) (test nil))
>   (assert (find which *which-key-words*))
>   (dolist (method (class-direct-methods (find-class class)))
>     (cond
>      ((and (or (eq which :all)
>                (eq which :reader))
>            (typep method 'standard-reader-method))
>       (if test
>           (format t "Would export ~a~%" (generic-function-name (method-generic-function method)))
>         (export (generic-function-name (method-generic-function method)))))
>      ((and (or (eq which :all)
>                (eq which :writer))
>            (typep method 'standard-writer-method))
>       (if test
>           (format t "Would export ~a~%" (cadr (generic-function-name (method-generic-function method))))
>         (export (cadr (generic-function-name (method-generic-function method))))))
>     (t
>      (error "Should not happen")))))
> 
> Well of course this just works for LispWorks (at least as I tried
> here), but now I'm using SBCL and wanted to write something
> similar. So I delved into the MOP-stuff and found a lot of different
> packages. Probably they all? have something to help me with it. I do not
> know really how portable the posted code is, it just "happens" to work
> for me here. 
> 
> In the end I find it to tedious to put all the accessor function in
> the package description. It's easy to forget one and it's even easier
> to mispell a name.

OK, this basically means that you only want to use the introspective 
functions of the CLOS MOP that query properties of predefined metaobject 
classes (like standard-class, standard-generic-function, etc.). For 
this, it's sufficient to just import the symbols (class-direct-methods, 
generic-function-name, etc.) from the right packages in the various CLOS 
MOP implementations, because they are all mostly complete and work well 
in that regard.

The package names are:

"MOP", "CLOS" or "ACLMOP" for Allegro Common Lisp
"CLOS" for clisp
"CLOS-MOP" or "MOP" for CMU CL
"CLOS" for LispWorks
"CCL" for MCL and OpenMCL
"SB-MOP" for SBCL

Closer to MOP becomes interesting when you want to implement your own 
metaobject classes, i.e., when you want to use the intercessive features 
that change the behavior of CLOS. Of course, you could also use Closer 
to MOP just for the introspective features which gives you the advantage 
of having to use just a single package name for all supported CL 
implementations.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
From: R. Mattes
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <pan.2005.09.06.13.43.34.934418@mh-freiburg.de>
On Tue, 06 Sep 2005 15:36:00 +0200, Pascal Costanza wrote:

> [...]
> The package names are:
> 
> "MOP", "CLOS" or "ACLMOP" for Allegro Common Lisp
> "CLOS" for clisp
> "CLOS-MOP" or "MOP" for CMU CL
> "CLOS" for LispWorks
> "CCL" for MCL and OpenMCL
> "SB-MOP" for SBCL

You got me here :-) 
I just ported the MOP code of Lisa to SBCL and currently try to do
the same for OpenMCL, but i used the 'OPENMCL-MOP' package. Any idea
about how this relates to CCL? 

BTW, the current lisa MOP code claims to be a parial copy of some PORT
module from  the CLOCC project, http://clocc.sourceforge.net (so, yet
another MOP wrapper).

 Cheers Ralf Mattes

> Closer to MOP becomes interesting when you want to implement your own
> metaobject classes, i.e., when you want to use the intercessive
> features that change the behavior of CLOS. Of course, you could also use
> Closer to MOP just for the introspective features which gives you the
> advantage of having to use just a single package name for all supported
> CL implementations.
> 
> 
> Pascal
From: Pascal Costanza
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <3o5o5eF4c78uU1@individual.net>
R. Mattes wrote:

> On Tue, 06 Sep 2005 15:36:00 +0200, Pascal Costanza wrote:
> 
>>[...]
>>The package names are:
>>
>>"MOP", "CLOS" or "ACLMOP" for Allegro Common Lisp
>>"CLOS" for clisp
>>"CLOS-MOP" or "MOP" for CMU CL
>>"CLOS" for LispWorks
>>"CCL" for MCL and OpenMCL
>>"SB-MOP" for SBCL
> 
> You got me here :-) 
> I just ported the MOP code of Lisa to SBCL and currently try to do
> the same for OpenMCL, but i used the 'OPENMCL-MOP' package. Any idea
> about how this relates to CCL? 

Indeed, there is an openmcl-mop package, and there is also an mcl-mop 
package in MCL 5.1. So it's probably better to use them instead of ccl. 
ccl seems to be a package that collects all kinds of extensions so that 
you can more easily tie yourself to MCL by just using ccl. ;)

> BTW, the current lisa MOP code claims to be a parial copy of some PORT
> module from  the CLOCC project, http://clocc.sourceforge.net (so, yet
> another MOP wrapper).

Hm, ok. It would be interesting to port the various programs that use 
different MOP wrappers to just use a common one. On the other hand, it 
may be not interesting enough, because if it ain't broken, don't fix it. 
However, I do think that Closer to MOP is probably stable enough to be 
used for new projects.


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
From: Friedrich Dominicus
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <8764te71l9.fsf@flarge.here>
Pascal Costanza <··@p-cos.net> writes:

>
> OK, this basically means that you only want to use the introspective
> functions of the CLOS MOP that query properties of predefined
> metaobject classes (like standard-class, standard-generic-function,
> etc.). For this, it's sufficient to just import the symbols
> (class-direct-methods, generic-function-name, etc.) 
well would like to do that but:

(find-symbol "CLASS-DIRECT-METHODS" (find-package :sb-mop))
yields 
nil 
nil 

Is not there in SBCL 0.9.4.x. 

There exists something like
SB-MOP:SPECIALIZER-DIRECT-METHODS (fbound)
SB-MOP:GENERIC-FUNCTION-METHODS (fbound)

the first seems to be the nearest to 'class-direct-methods...

Regards
Friedrich

-- 
Please remove just-for-news- to reply via e-mail.
From: Pascal Costanza
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <3o5oeuF4c78uU2@individual.net>
Friedrich Dominicus wrote:
> Pascal Costanza <··@p-cos.net> writes:
> 
> 
>>OK, this basically means that you only want to use the introspective
>>functions of the CLOS MOP that query properties of predefined
>>metaobject classes (like standard-class, standard-generic-function,
>>etc.). For this, it's sufficient to just import the symbols
>>(class-direct-methods, generic-function-name, etc.) 
> 
> well would like to do that but:
> 
> (find-symbol "CLASS-DIRECT-METHODS" (find-package :sb-mop))
> yields 
> nil 
> nil 
> 
> Is not there in SBCL 0.9.4.x. 
> 
> There exists something like
> SB-MOP:SPECIALIZER-DIRECT-METHODS (fbound)
> SB-MOP:GENERIC-FUNCTION-METHODS (fbound)
> 
> the first seems to be the nearest to 'class-direct-methods...

Well, I said "mostly complete". ;) (Sorry for the fuzz.)

You're right, class-direct-methods is a bad example. It is not specified 
in AMOP, and indeed, specializer-direct-methods should be used instead. 
LispWorks doesn't provide specializer-direct-methods, though.

With Closer to MOP, you can use specializer-direct-methods in all 
supported CL implementations.

(It's called specializer-direct-methods because it is supposed to work 
on eql specializers as well, and they are not classes!)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
From: Pascal Costanza
Subject: Re: diverse MOP packages?
Date: 
Message-ID: <3o5p5gF4c16tU1@individual.net>
Pascal Costanza wrote:
> Friedrich Dominicus wrote:
> 
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>
>>> OK, this basically means that you only want to use the introspective
>>> functions of the CLOS MOP that query properties of predefined
>>> metaobject classes (like standard-class, standard-generic-function,
>>> etc.). For this, it's sufficient to just import the symbols
>>> (class-direct-methods, generic-function-name, etc.) 
>>
>>
>> well would like to do that but:
>>
>> (find-symbol "CLASS-DIRECT-METHODS" (find-package :sb-mop))
>> yields nil nil
>> Is not there in SBCL 0.9.4.x.
>> There exists something like
>> SB-MOP:SPECIALIZER-DIRECT-METHODS (fbound)
>> SB-MOP:GENERIC-FUNCTION-METHODS (fbound)
>>
>> the first seems to be the nearest to 'class-direct-methods...
> 
> Well, I said "mostly complete". ;) (Sorry for the fuzz.)
> 
> You're right, class-direct-methods is a bad example. It is not specified 
> in AMOP, and indeed, specializer-direct-methods should be used instead. 
> LispWorks doesn't provide specializer-direct-methods, though.

I should check more carefully before clicking the send button: LispWorks 
provides both class-direct-methods and specializer-direct-methods (but 
specializer-direct-methods is only defined on classes).

> With Closer to MOP, you can use specializer-direct-methods in all 
> supported CL implementations.
> 
> (It's called specializer-direct-methods because it is supposed to work 
> on eql specializers as well, and they are not classes!)

...and in the version of Closer to MOP for LispWorks, 
specializer-direct-methods also works on eql specializers. (Support for 
eql specializers is not fully AMOP-compliant, though, but should be good 
enough for practical purposes.)


Pascal

-- 
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++