Okay, let me see if this is right now. In the expression
(list (call-with-current-continuation func) (+ 4 14)), you want the addition to be done before the call-with-current-continuation, as opposed to being part of the continuation. Right? Noah On Wed, Jan 4, 2012 at 9:00 AM, David Kastrup <d...@gnu.org> wrote: > Noah Lavine <noah.b.lav...@gmail.com> writes: > >>> On Wed, Jan 4, 2012 at 8:16 AM, David Kastrup <d...@gnu.org> wrote: >>>> >>>> Hi, >>>> >>>> I was just wondering about the ability for using multiple continuations >>>> in contexts that don't guarantee an order of execution. Functions like >>>> map, list and other structure builders. >>>> >>>> If one uses those for building a structure, and some paths of execution >>>> hit a call-with-current-continuation, is it feasible to have Guile >>>> refrain from actually taking the continuation before all other paths of >>>> execution have finished or reached a call-with-current-continuation as >>>> well? >>>> >>>> Meaning that if one takes the whole set of continuations as a template >>>> for creating a data structure from values that are not known at the time >>>> of building the template, that one can fill in the whole set with actual >>>> values/actions/calculations, and have only the actions depending on >>>> those variables be redone. >>>> >>>> Sort of like constant expression folding (some sort of quasi-quoting >>>> superset) on steroids. >> >> Let me see if I understand what you mean. I think you're talking about >> an expression like this: >> >> (cons (call/cc store-this-continuation) (call/cc store-this-continuation)) >> >> and you want a way to distinguish the first and the second call/cc, by >> guaranteeing the order they are hit. This will let you choose which >> value to put in the car and which to put in the cdr. >> >> Is that right? > > No. I exactly _don't_ want to have an order dependency. The end > application is more or less supposed to be similar to lambda with > everything not depending on a function parameter being preexecuted. > When doing sequential operations, the preexecution will stop at the > point in sequence where call/cc is hit the first time. But when doing > parallelizable operations without a guaranteed order of operations, one > could let the preexecution continue on independent operations until > _every_ parallelizable operation has reached the point of call/cc. > > -- > David Kastrup > >