Re: Continuation sets and order-independency

[Noah Lavine]

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 <address@hidden> wrote:
> 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
>
>