+ The cl-cont webpage says that defgeneric and defmethod are currently not supported. However, if I understand correctly, it should be possible to say this:
(defmethod foo (...) (with-call/cc ...))
Correct? Or is that also not supported? (Some quick-shot experiment seems to indicate that this works.)
+ If this is indeed supported, it can happen that an invocation of call-next-method is implicitly captured in a continuation. (So it can in principle even be invoked several times.) Did such capturing of a call-next-method for later invocation ever occur in practice? Was this ever a problem? (I'm not particularly interested in multiple invocations, just in the capturing as such.)
+ Does this even occur regularly as part of weblocks?
Thanks a lot for any hints!
Best, Pascal
P.S.: The cl-cont webpage also says that catch, throw, progv and unwind-protect are not supported. It should be possible to make that work with the first-class dynamic environments support in ContextL (only in the repository version at the moment)...
On Mon, Apr 13, 2009 at 10:21 AM, Pascal Costanza <p...@p-cos.net> wrote: > The cl-cont webpage says that defgeneric and defmethod are currently > not supported.
Yes, what I meant is that there is no defgeneric/cc and defmethod/cc. I had no need for them, and for reasons that I can't remember now writing a transformer for defmethod/cc was a little bit tricky (I don't think it was too tricky, I just didn't have a reason to spend the time writing it).
> However, if I understand correctly, it should be > possible to say this:
> (defmethod foo (...) > (with-call/cc ...))
Sure, that will work. But strictly speaking, it's not a "full" continuation, because, for example, (foo :after) will be lost. I think to get this working so that people don't encounter surprises most of the time is tricky.
> If this is indeed supported, it can happen that an invocation of > call-next-method is implicitly captured in a continuation.
I've never done anything like this, defun/cc is usually more than enough for me. I don't think it happens in Weblocks codebase. But of course this would also need to be worked out. I think there are some subtle issues here.
> P.S.: The cl-cont webpage also says that catch, throw, progv and > unwind-protect are not supported. It should be possible to make that > work with the first-class dynamic environments support in ContextL > (only in the repository version at the moment)...
Cool! I'm not sure what the semantics would be for some of these constructs, I'd have to look into it in more detail. Hopefully someone else does it before I get the chance to :)
On 13 Apr 2009, at 18:11, Vyacheslav Akhmechet wrote:
> On Mon, Apr 13, 2009 at 10:21 AM, Pascal Costanza <p...@p-cos.net> > wrote: >> The cl-cont webpage says that defgeneric and defmethod are currently >> not supported. > Yes, what I meant is that there is no defgeneric/cc and defmethod/cc. > I had no need for them, and for reasons that I can't remember now > writing a transformer for defmethod/cc was a little bit tricky (I > don't think it was too tricky, I just didn't have a reason to spend > the time writing it).
ok
>> However, if I understand correctly, it should be >> possible to say this:
>> (defmethod foo (...) >> (with-call/cc ...)) > Sure, that will work. But strictly speaking, it's not a "full" > continuation, because, for example, (foo :after) will be lost. I think > to get this working so that people don't encounter surprises most of > the time is tricky.
ok, I can imagine.
>> If this is indeed supported, it can happen that an invocation of >> call-next-method is implicitly captured in a continuation. > I've never done anything like this, defun/cc is usually more than > enough for me. I don't think it happens in Weblocks codebase. But of > course this would also need to be worked out. I think there are some > subtle issues here.
ok
>> P.S.: The cl-cont webpage also says that catch, throw, progv and >> unwind-protect are not supported. It should be possible to make that >> work with the first-class dynamic environments support in ContextL >> (only in the repository version at the moment)... > Cool! I'm not sure what the semantics would be for some of these > constructs, I'd have to look into it in more detail. Hopefully someone > else does it before I get the chance to :)
Essentially, ContextL now provides a dynamic-wind construct, so that you can say something like this:
(dynamic-wind (unwind-protect (proceed some protected code) (some cleanup code)))
...and then later do a (capture-dynamic-environment) such that you can reinstall such 'behavioral' dynamic bindings.
It's still in a somewhat experimental stage, I'm not 100% sure that everything works as it should. That's why I agree: Someone should do it, so that we all get feedback... ;)
On Mon, Apr 13, 2009 at 6:14 PM, Pascal Costanza <p...@p-cos.net> wrote: > Someone should do it, so that we all get feedback... ;)
Actually, it would be pretty cool to make support for these constructs in cl-cont optional, so that if ContextL is loaded prior to cl-cont, catch, throw, etc. can be supported. This way we don't force to depend on ContextL if they don't need the additional features.
On 14 Apr 2009, at 00:30, Vyacheslav Akhmechet wrote:
> On Mon, Apr 13, 2009 at 6:14 PM, Pascal Costanza <p...@p-cos.net> wrote: >> Someone should do it, so that we all get feedback... ;) > Actually, it would be pretty cool to make support for these constructs > in cl-cont optional, so that if ContextL is loaded prior to cl-cont, > catch, throw, etc. can be supported. This way we don't force to depend > on ContextL if they don't need the additional features.
OK, I made a small change to ContextL such that :contextl is now on the *features* list when ContextL is loaded. This should help.
