[Openmcl-devel] Re: "leaking" call-method

[Marco Baringer]

"Hamilton Link" <helink at sandia.gov> writes:

> 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).

how major? how hard would it be to copy/restore openmcl's stack? (this
is idle curioustiy way way way beyond my current capabilities so feel
free to ignore this request).

> 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?

i accepted the first point as soon as i started. it took me a while
but i eventually realized that i'll need to lose call-next-method and,
therefore, :around (it is not by accident that my test case does not
pass all the primary methods to call-method but only the first). i
think i can work around the call-next-method limitiation by teaching
my cps transformer about it, but i'll leave that for later.

> 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).

fortunetly i can require that all the methods be defined with my macro
and not defgeneric/defmethod, so (i hope) no one will try to do that.

-- 
-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