[clean-list] Monad Type Classes and Uniqueness Typing

[Arjen van Weelden]

Hello Fabien,

Fabien Todescato wrote:

>Thank you Arjen for your most welcome comments.
>
>As you honestly point out, your approach may prove to be a little too
>restrictive for my purposes, namely to have a monadic programming framework
>with overloaded monadic operators. Whereas you come up with bind :: u:(m .a)
>v:(.a -> u:(m .b)) -> u:(m .b), [v <= u], I have class (mBind) infixl 4 m ::
>( m a ) ( a -> ( m b ) ) -> m b, which - as I understand the type system -
>is applicable to a larger class of monads. From this I hope to build a
>monadic programming library where stateful computations with unique state
>are integrated in a uniform manner.
>  
>
I wonder if your monads can return values with a unique type. But 
perhaps you don't use unique objects when programming in a monadic 
style, so this may not be important. I needed the attributed type, that 
shows the type checker that the bind doesn't perform sharing, because I 
 wanted to partially apply threads (monads) to unqiue objects which 
result in closures that may not be shared.

>Honestly, I am still surprised that the mBind combinator without uniqueness
>typing constraints can be overloaded for a state-transformer monad handling
>unique states. Unless I build myself a formal proof that indeed such is the
>case, I will still suspect a bug in the Clean 2.0 typechecker :)
>  
>
Your monad doesn't need to be unique to contain a (non-unqiue) function 
that works on a unique state.

>Now, please, in order to enlighten me about the use of continuations for
>concurrent thread implementation, I would be very glad if you could provide
>me with some pointers to papers :) I am at the moment reading the beautiful
>thesis by Magnus Carlsson and Thomas Hallgren "Fudgets - Purely Functional
>Processes with Applications to Graphical User Interfaces" where the use of
>continuations seems to be an essential ingredient.
>  
>
I can only find some older papers that use catch and call/cc (at least 
one by M. Wand).
Personally, I use a scheduler with a queue of continuations/threads. 
These continuations are composed using a bind that performs its left 
argument on the unique state (World), suspends its right argument (the 
tail of the continuation/thread) in the scheduler queue and returns the 
state yielded by the left argument. Then the scheduler selects a new 
continuation to evaluate and so on. This leads to a system with 
cooperative threads that are interleaved at their binds, taking turns at 
updating the unique state.

kind regards,
    Arjen van Weelden