Re: Continuation sets and order-independency

[David Kastrup]

Noah Lavine <address@hidden> writes:

>> On Wed, Jan 4, 2012 at 8:16 AM, David Kastrup <address@hidden> 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