[Openmcl-devel] "leaking" call-method

[Hamilton Link]

I'd be a little surprised if this could be made to work without major 
kludges, unless you constrain your use more fully (and possibly not 
even then).

Can you live with
- only doing call/cc in the context of a generic function you've 
created with that in mind?
- not having around methods wrapping calls to call/cc?

Say I've written some methods using standard method combination, and 
you want to override a primary and do this. By the time you're in your 
method that uses call/cc there will already be someone who's planning 
to call those after methods. And I suspect there'd be no way of 
grabbing the remaining bits of any around methods that are on the stack 
(short of "real" call/cc support).

More than likely you've already thought of this, I just wanted to check 
before I thought about the wrong solution.

h

On Jun 1, 2005, at 11:21 AM, Marco Baringer wrote:

>
> i'm attempting to create a method combination so that my call/cc
> implementation (which is nothing more thas a cps transformer) does the
> right thing with before and after methods. This requires me to be bale
> to, inside the body of a particular method, be it a primary or after
> method, get at a closure which wraps up all the remaning methods to
> call. here's my current attempt:
>
> --------------------------------
> (in-package :common-lisp-user)
>
> (define-method-combination test-combination ()
>   ((after (:after))
>    (primary () :required t))
>   `(let ((*after* ,(when after
>                      `(lambda ()
>                         (call-method ,(first after))))))
>      (declare (special *after*))
>      (call-method ,(first primary))))
>
> (defgeneric foo (a)
>   (:method-combination test-combination)
>   (:method (a)
>     (declare (special *after*))
>     *after*)
>   (:method :after (a)
>     'after))
>
> (funcall (foo 4))
> --------------------------------
>
> and here's what happens when i run it:
>
> --------------------------------
> Can't construct argument list from (-528351542 . -528351540).
>    [Condition of type CCL::CANT-CONSTRUCT-ARGLIST]
>
> Restarts:
>   0: [ABORT] Abort handling SLIME request.
>   1: [ABORT-BREAK] Reset this process
>   2: [ABORT] Kill this process
>
> Backtrace:
>   0: (CCL::%%CALL-METHOD* #<STANDARD-METHOD FOO :AFTER (T)> 'NIL 
> #<CONNECTION  #x66C6B46>)
>       Locals:
>         METHOD = #<STANDARD-METHOD FOO :AFTER (T)>
>         CCL::NEXT-METHODS = NIL
>         CCL::BITS = 276824321
>       [No catch-tags]
>   1: (FUNCALL #<COMPILED-LEXICAL-CLOSURE #x67EFBDE>)
>       Locals:
>         CCL::FN = #<COMPILED-LEXICAL-CLOSURE #x67EFBDE>
>         CCL::ARGS = NIL
>       [No catch-tags]
>   2: (CCL::CALL-CHECK-REGS 'FUNCALL)
>   3: (#<Anonymous Function #x652809E> "(funcall (foo 4))
> ")
> --------------------------------
>
> the exact values of the cons cell in cant-construct-arglist vary from
> one invocation to the next. this make me think something which has
> been declared dynamic-extent shouldn't be, but i'm unable to figure
> out what.
>
> p.s. - i'm pretty sure this is unspecified behaviour so openmcl is
> correct is barfing up, but it would be convenient.
>
> -- 
> -Marco
> Ring the bells that still can ring.
> Forget the perfect offering.
> There is a crack in everything.
> That's how the light gets in.
> 	-Leonard Cohen
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>