Re: continuations and linear types

[Allen Short <washort@xxxxxxxxxxxxxxxxx>]

On Fri, 2002-04-19 at 03:06, James Knight wrote:

> After an initial reading of that paper, I'm quite unconvinced that 
> linear types as described there are a useful concept. As far as I can 
> tell, the main argument for them is to make it impossible for one to be 
> accessed by multiple threads. However, this is a _*great*_ cost in 
> complexity for single-threaded programs. I can tell you right now I'd 
> hate to use a language that makes me go through the hoops described in 
> that paper.

well, yes -- *non*-linear types are extremely useful as well, i'm
certainly not advocating a linear-types-only language, as Mr Baker does
in the "lively linear lisp" paper. 

> The rest of the 
> arguments seem to me like they're basically premature optimizations 
> exposed to the programmer.

Hmm. how so? to my mind, linearity is a property that would be hard to
recover via inference. I dont see any disadvantages to allowing its
explicit declaration.

> 
> However, I do believe that a similar concept, not applied to number of
> references, but rather, to number of *different threads that have 
> references* is a great idea. In fact, I'm currently a proponent of the
>concept that objects should *always* be linear-with-respect-to-threads.
> That is, two threads cannot ever hold a reference to the same object 
> [[at least, as far as they can tell]]. Make RPC the only method of 
> communication, but make it very optimized. In my experience, when 
> writing a threaded program, you pretty much need to work that way 
>anyways if you're going to stay sane, but its just a lot easier toscrew
> up and allow a reference to escape to another thread when you didn't 
> intend to.
> 

Hmm. How would this "linearity-with-respect-to-threads" be accomplished?
what do you mean by "as far as they can tell"?


> Single-shot continuations have a lot going for them, but unless I'm 
> missing something, being able to be stack-allocated is not one of them. 

Linear continuations are different from single-shot continuations:
single-shot continuations are still capturable and can be referenced
multiple times; I have been told that multi-shot continuations can be
built from single-shot ones (but still cannot track down the paper in
which this is demonstrated). However, linear continuations have no
implicit continuation -- that is, the function called by call/lc cannot
return, it must call the continuation passed to it at some point.
Thus, you dont have the time-travel effects that prevent
stack-allocation of continuations.

> it makes me think that what you really want to have for web-applications 
> is fork().

Exactly. in a linear-continuations system, you'd have to explicitly copy
the current continuation to get a new thread.

-- 
Allen Short        Programmer-Archaeologist       
washort@twistedmatrix.com
"Campus sidewalks never exist as the straightest line
            between two points." -- M. M. Johnston