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

[Geoffrey Alan Washburn]

Vesa Karvonen wrote:
> Hmm...  Does value restriction really become an issue?  I mean, when you
> implement zero, the monad type should be concrete and you will be able to
> make zero a value.  Value restriction becomes an issue when the type is
> abstract, but that shouldn't be the case here.
    If you are defining a MONADP from scratch, no I don't think it can 
ever be a problem.  However, if you are interested in writing monad 
transformers, say

functor MkErrorMonad (M : MONAD_CORE) :> MONADP_CORE =
struct
  type 'a monad = ('a option) M.monad
  fun return x = M.return (SOME x)
  fun op >>= (aM, f) =
      M.>>= (aM, fn SOME a => M.>>= (f a, return) | NONE => M.return NONE)
  val zero = return NONE
  fun op <|> (aM, bM) =
      M.>>= (aM, fn SOME a => return a | NONE => bM)
end

You'll run into problems.  It may be conceivable that the above could be 
rewritten with

    type 'a monad = 'a M.monad option

but it is either not possible to write bind for this type or my brain 
has called it a day already.


-- 
[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/20070404/e09d5e9f/attachment.htm