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
>>>>
>>>