[MLton-user] Extended Basis Library: Suggested change to the MONADP signature

[Geoffrey Alan Washburn]

Vesa Karvonen wrote:
> BTW, while trying this I noticed that the subexpression
>
>   M.>>= (f a, return)
>
> should be just
>
>  f a
>
> (IIRC - I don't have the corrected code at this point as I kept 
> editing...)

    Ah, yes, that would be true by the monad laws. 

> I see.  However, an alternative to having a parameterized zero would 
> be to
> simply introduce additional thunking in the monad transformer.  Here is
> how it would look like (the following code compiles fine):
>
> functor MkErrorMonad (M : MONAD_CORE) :> MONADP_CORE = struct
>   type 'a monad = 'a Option.t M.monad Thunk.t
>   fun return x () = M.return (SOME x)
>   fun zero () = M.return NONE
>   fun op <|> (aM, bM) () =
>       M.>>= (aM (),
>              fn SOME a => M.return (SOME a)
>               | NONE   => bM ())
>   fun op >>= (aM, a2bM) () =
>       M.>>= (aM (),
>              fn SOME a => a2bM a ()
>               | NONE   => M.return NONE)
> end
>
> So, it seems that it is always possible to work around the value
> restriction in this context (which is when implementing MONADP_CORE).
>
> In a sense, even when implementing a monad transformer, you are
> implementing a MONADP from scratch, because you get to decide the
> type of the resulting monad.

    Okay, after thinking about your solution some more you are correct.  
Because thunks themselves form a monad, it should always be possible to 
transform problematic definition into one using thunks.  Clearly I 
should have spent more time thinking about this first. 

-- 
[Geoff Washburn|geoffw at cis.upenn.edu|http://www.cis.upenn.edu/~geoffw/]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20070406/27cea57d/attachment.htm