Re: [SISC-devel] partial k design
Brought to you by:
mradestock,
scgmille
From: Matthias R. <mat...@so...> - 2004-11-17 08:30:07
|
Chris Double wrote: > On Tue, 16 Nov 2004 23:28:57 +0000, "Matthias Radestock" > <mat...@so...> said: > >>I haven't made up my mind on this issue yet though. Any "real world" >>examples of the utility of the extended functionality are very much >>appreciated. > > Of the top of my head, the only 'real world' case I'd use partial > continuations for is in web apps and that wouldn't require the ability > to nest. In fact the addition of a 'mark' means that it needs to be > stored globally so that call/pc and abort can access it (At least that's > what I had to do here > http://www.double.co.nz/scheme/partial-continuations/partial-continuations.html > when trying the idea out. > I see. Btw, you write "... The main reason for using partial continuations is efficiency. Capturing a full continuation will capture a lot of state that is not required if we only want the smaller partial continuation. Given a native implementation of partial continuations in the programming languge this would be a faster operation and less memory intensive. ..." which, sadly, is not universally true. In SISC, for instance, ordinary k capture involves no copying, whereas partial k capture does. Furthermore, ordinary k invocation does lazy copying, whereas partial k invocation does eager copying. So partial ks will be both slower and more memory intensive than ordinary ks. That's of course assuming we follow my implementation proposal rather than doing an encoding in call/cc. In the latter case time and space complexity would be in the same ballpark as ordinary ks, but we'd lose the ability to serialize partial ks more compactly and safely (i.e. rather than serializing lots of stuff in the full k which may include unserializable or large objects). > Adding a 'mark' would enable the ability to do some of the 'tricks' > mentioned in Oleg's comp.lang.scheme articles on bshift/breset: > > http://groups.google.com/groups?hl=en&lr=&selm=7eb8ac3e.0402131819.46d2bbb4%40posting.google.com > http://groups.google.com/groups?hl=en&lr=&selm=7eb8ac3e.0406151456.3aa58a25%40posting.google.com > http://groups.google.com/groups?hl=en&lr=&selm=7eb8ac3e.0312172046.6d817907%40posting.google.com > > Could bshift/breset be implemented using the partial continuation > support? I doubt that I'd use that in the real world though. The *core* behaviour of bshift/breset are trivial to implement in the version with explict marks, but not in the original proposal. Interestingly, bshift does provide a semantics for the case where the mark is not in the continuation. The behaviour is most bizarre. Consider the following examples: (let ([mark #f]) (breset k (begin (set! mark k) 1)) (bshift mark k 2)) (let ([mark #f]) (breset k (begin (set! mark k) 1)) (bshift mark k (k 2))) Top marks :) for anyone who can tell me what happens. As far as I can tell, this edge case behaviour of bshift/breset is inconsistent with a view of partial continuations as segments of the stack/future, so it would be difficult/impossible to implement in the framework I was proposing. matthias. |