Right, I see your concern. I'd argue that's a bad _use_ of
continuations! You can think of a (delimited) continuation as being
some chunk of the call stack: a chunk that you may execute multiple
times. So if the chunk of stack that you have says "set this mutex"
and you run it three times, it'll set that mutex three times. If you
throw the continuation away, that mutex never gets set.

So this ends up being a discussion about side effectful code versus
purely functional code: sincecontinuations means taking "take this bit
of code, and run it 0 or more times" you naturally need to be careful
of changing the state of things.

You see the same when you use a continuation and a DynamicVariable
(class name because I'm talking about the implementation details),
where you end up with the DynamicVariable having an unexpected value.
(In fact it's worse with continuations + DynamicVariable: they
_cannot_ work sensibly together, which is why I've been pushing people
towards my Control library, or to the #on:do: + #resume: idiom, both
of which yield _delimited_ dynamic variables, which  _do_ play nicely
with everything.)

frank

On 15 January 2014 19:09, Chris Muller <asqueaker at gmail.com> wrote:
> I was talking about class Continuation and how its used in the context
> of Seaside.  In that context, I have observed, for example, a critical
> block being entered prior to snipping a Continuation off the stack (to
> be resumed later), thus leaving Mutex's on the stack stuck in their
> wait state, and blocking subsequent requests.
>
> On Wed, Jan 15, 2014 at 11:23 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> No they don't. Continuations have nothing to with mutexes at all. I'm
>> not sure that we're talking about the same thing when we say
>> "continuation".
>>
>> When _I_ say "continuation" I mean, effectively, the call stack: it's
>> the thing to which the result of the current activation record will
>> return a result. You can thus consider a _delimited_ continuation as a
>> chunk of stack. #on:do: delimits the stack using a primitive (19?). An
>> _undelimited_ continuation is the entire call stack from the very
>> beginning of a program. thisContext + all its senders is the closest
>> we have to such a thing in Smalltalk: since all call stacks eventually
>> hit nil, they're all delimited by _something_.
>>
>> And we use continuations _all the time_ in Smalltalk, or things that
>> may be trivially expressed in delimited continuations: from a CS
>> perspective delimited continuations and resumable exceptions are
>> equivalent, in the sense that each may implement the other.
>>
>> frank
>>
>> On 15 January 2014 16:30, Chris Muller <ma.chris.m at gmail.com> wrote:
>>> Continuations are also bad because they leave Mutex's in their wait
>>> state.  That, alone, is a show-stopper for me for using continuations.
>>>
>>> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>> Yes, I know. But that just means that implementing a bad idea (modal
>>>> dialogs) with some random piece of tech (continuations) is a bad idea.
>>>>
>>>> I thought you meant that continuations _implied_ something negative
>>>> about UI design by their very nature. But it sounds like that's not
>>>> what you meant. Which is good :).
>>>>
>>>> frank
>>>>
>>>> On 15 January 2014 15:56, Chris Muller <asqueaker at gmail.com> wrote:
>>>>> Frank, by my limited knowledge, the call: / answer API of Seaside used
>>>>> a Continuation to allow a modal component to be rendered on top of
>>>>> other components until #answer: is sent by one of the callbacks.  That
>>>>> provides stateless web-apps the ability to do desktop-like modal
>>>>> "dialog" boxes that can return values to the calling component.
>>>>>
>>>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>> On 15 January 2014 03:10, Chris Muller <asqueaker at gmail.com> wrote:
>>>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <colin at wiresong.com> wrote:
>>>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>>>>>
>>>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>>>>>> the replacement for Seaside?
>>>>>>>>
>>>>>>>>
>>>>>>>> It's not that there's a replacement. It's more that the problem it solves
>>>>>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>>>>>> that were basically dynamically generated web pages connected via links and
>>>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>>>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>>>>>> client-server model: the UI rendering and interface logic is all done in
>>>>>>>> Javascript running in the browser, and it communicates with the server by
>>>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>>>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>>>>>> significant.
>>>>>>>
>>>>>>> Continuations were never good for UI design anyway.  Modal.
>>>>>>
>>>>>> I don't understand - what does UI modal-ness got to do with with
>>>>>> continuations? (Or: the whole of Squeak is fundamentally built on
>>>>>> continuations (Process, ContextPart).)
>>>>>>
>>>>>> frank
>>>>>>
>>>>>
>>
>