Re: partial k design

Chris Double wrote:

> On Tue, 16 Nov 2004 23:28:57 +0000, "Matthias Radestock"
> <[email protected]> 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.



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8