[clean-list] Monad Type Classes and Uniqueness Typing

[Fabien Todescato]

Ha, thanks Arjen for these enlightening remarks. Let me please add a few
comments more :

	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.

True, I didn't even consider using monads returning unique values. I am
specifically interested in state monads threading a unique state in the
background, while conforming to a general monadic framework with overloaded
monadic operators.

	Your monad doesn't need to be unique to contain a (non-unqiue)
function 
	that works on a unique state.

This remark does certainly make sense on a general ground, but I had to work
a little to find a suitable definition for such a unique state threading
monad :).

	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.

Wow ! This sounds extremely interesting ! If I understand you well you use a
state monad to thread in the background your queue of pending continuations,
and perform at each bind a round-roubin turn. You give me glimpses of
wonders :)


Sincerely yours, Fabien

> -----Message d'origine-----
> De:	Arjen van Weelden [SMTP:arjenw@cs.kun.nl]
> Date:	vendredi 28 juin 2002 14:07
> À:	Clean mailing list (Adresse de messagerie)
> Objet:	Re: [clean-list] Monad Type Classes and Uniqueness Typing
> 
> 
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list