MOP question

MOP question

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]


The Goops MOP for generic application is basically undocumented.  I
tried to figure it out looking at goops.scm, but am a little lost.
Specifically, I can't quite figure out how apply-method is supposed to
work.  Mostly, how (next-method) gets bound.  

It looks to me like it's supposed to be passed as an argument to the
body of the method, but nothing I can see does that.

On top of that, calling apply-method directly doesn't work
(complaining about as I would expect, the wrong number of args to the
method body):

(use-modules (oop goops))

(define-class <foo> ()
  (slot1))

(define-class <bar> (<foo>)
  (slot2))

(define-method (baz (foo <foo>)) foo)
(define-method (baz (foo <bar>)) foo)

(define l (compute-applicable-methods baz (list (make <bar>))))

(define m1 (car l))
(define m2 (cadr l))

;
; stolen from apply-methods
;

(define next (lambda (procs args)
		   (lambda new-args
		     (let ((a (if (null? new-args) args new-args)))
		       (if (null? procs)
			   (no-next-method gf a)
			   (apply-method gf procs next a))))))

(apply-method baz l next (list (make <bar>)))     


-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: MOP question

[Thien-Thi Nguyen]

   From: Eric E Moore <e.e.moore@sheffield.ac.uk>
   Date: Mon, 15 Apr 2002 00:38:44 +0100


   The Goops MOP for generic application is basically undocumented.  I
   tried to figure it out looking at goops.scm, but am a little lost.

   Specifically, I can't quite figure out how apply-method is supposed
   to work.  Mostly, how (next-method) gets bound.

next-method is bound in libguile/goops.c, from which these two comments
may be helpful:

 * This implementation provides
 *	- generic functions (with class specializers)
 *	- multi-methods
 *	- next-method
 *	- a hard-coded MOP for standard gf, which can be overloaded for non-std gf

and
 
 * Protocol for calling a generic fumction
 * This protocol is roughly equivalent to (parameter are a little bit different
 * for efficiency reasons):
 *
 * 	+ apply-generic (gf args)
 *		+ compute-applicable-methods (gf args ...)
 *			+ sort-applicable-methods (methods args)
 *		+ apply-methods (gf methods args)
 *
 * apply-methods calls make-next-method to build the "continuation" of a a
 * method.  Applying a next-method will call apply-next-method which in
 * turn will call  apply again to call effectively the following method.

also note that "scm_slots_exists_p" has been changed recently in cvs to
"scm_slot_exists_p".

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: MOP question

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> next-method is bound in libguile/goops.c, 

After getting your message, I did manage to track it down, by, in
desperation, grepping the source code for next-method, then working
backwards to find where it's bound.  It is bound by modifying the
source in compile-method (in oop/goops/compile.scm), which is called,
by way of some other functions, in memoize-method! (in dispatch.scm)
which is called from the C code (in eval.c via scm_memoize_method)

[...]

>  *	- a hard-coded MOP for standard gf, which can be overloaded for non-std gf

[...]

>  * Protocol for calling a generic fumction
>  * This protocol is roughly equivalent to (parameter are a little bit different
>  * for efficiency reasons):
>  *
>  * 	+ apply-generic (gf args)
>  *		+ compute-applicable-methods (gf args ...)
>  *			+ sort-applicable-methods (methods args)
>  *		+ apply-methods (gf methods args)
>  *
>  * apply-methods calls make-next-method to build the "continuation" of a a
>  * method.  Applying a next-method will call apply-next-method which in
>  * turn will call  apply again to call effectively the following method.

apply-generic does not seem to ever be called, so I'm not sure what
overriding it would do.  (since calling apply-generic on a gf directly
doesn't work, I suspect it's not being called is currently a good
thing).  apply-methods doesn't work either...  Nor can I even get:

(use-modules (oop goops))
(define-class <my-generic> (<generic>))
(define a-my-generic (make <my-generic> #:name 'a-my-generic))
(define m (make <method> 
            #:specializers (list <top>)
            #:procedure (lambda (x) 'foo)))
(add-method! a-my-generic m)

to work, as it complains about:

ERROR: In procedure %invalidate-method-cache!:
ERROR: Wrong type argument in position 1: #<<my-generic> a-my-generic (1)>
ABORT: (wrong-type-arg)

Fundamentally, it seems to me that the whole MOP for gf application is
broken, the method cache, and other optimizations in the C code have
bitrotted it into unusability.  I could be wrong, in which case I
would love someone to post code that does work :)

If I'm right, and if it can't be fixed soon (which looks like a bit of
a big task) maybe a note could go in the docs saying that it's not
working right now?

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]