[plt-scheme] call/cc, set!, and fluid-let

On Jun 15, 2005, at 9:47 AM, Jay McCarthy wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> On 6/15/05, John Clements <clements at brinckerhoff.org> wrote:
>
>> Taking this back to the list, hope that's okay.
>>
>> After thinking about this for a bit, I see two things:
>>
>> 1) I can just about imagine a situation like this where you want a
>> change to be "permanent" for the rest of the computation but to be
>> unwound when you hit the back button.
>
> That's the ticket.
>
>> 2) I don't understand why you need a thing like this for the situation
>> you're describing.  I think I would just use a tail-call. Here's how I
>> would structure the code, if I understand you correctly:
>>
>> (define (sorting-proc-a l) ...)
>> (define (sorting-proc-b l) ...)
>> (define (sorting-proc-c l) ...)
>>
>> (define (show-list l)
>>    (send-suspend/callback-thingy (make-page l)
>>       ; if user clicks "sort a":
>>       => (show-list (sorting-proc-a l))
>>       ; if user clicks "sort b":
>>       => (show-list (sorting-proc-b l))
>>       ; if user clicks "sort c":
>>       => (show-list (sorting-proc-c l))
>>       ; if user clicks something else:
>>       => (call-to-somewhere-else ...)))
>
> Add to this example that reclicking "sort a" goes in reverse, and that
> clicking "sort a", "sort b" causes the list to be sorted by b with a
> as the tie breaker. See how the code needs future-of-the-computation
> state.

If you want things unwound, you don't want explicit state. Instead, you 
want to pass around the values in a store-passing sense. So I am with 
Eli and John until you show me more.

-- Matthias (who suggested fluid-let as a session equivalent to SK)