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

[Vesa Karvonen]

On 4/1/07, Geoffrey Alan Washburn <geoffw at cis.upenn.edu> wrote:
>      In any event, I just finally got around to trying to revise my code so
> that I can change the definition of MONADP's zero from
>
>          val zero : errval -> 'a monad
>
>  to
>
>          val zero : 'a monad

Did you encounter problems while trying to revise your code?

> and it occurred to me that with the value restriction my version might
> actually be the better choice.  As it stands it is only possible to define
> zero in terms of values.  Which is mostly okay, except that the usual
> eta-expansion trick cannot be applied unless your monad is implemented as a
> functional type.

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.

> Therefore I am thinking that it might be good to change the MONAP_CORE
> signature to be
>
>  signature MONADP_CORE = sig
>     include MONAD_CORE
>     type errval
>     val zero : errval -> 'a monad
>     val <|> : 'a monad BinOp.t
>  end

I'm not convinced, at least not without further motivation, that the extra
"flexibility" offered by adding a parameter to zero in MONADP_CORE is
worth it.  The main reason for not being convinced is that assuming my
intuition about the value restriction problem not applying to this case is
true, then one can always implement a zero.  Given that, one can then
(re)use the functors from EB and that work is not lost and need not be
duplicated.  When one needs to have a parameterized zero, it can be
introduced as an extension (just like MONADP is an extension of MONAD) and
such an extension can even be introduced outside the EB.

Thus, AFAICS, the current design allows you to have zeroes with and
without parameters.  Adding a parameter to zero would mean that it would
be there always.  IOW, adding a parameter to zero actually makes the
design less flexible.

BTW, I wonder if it makes sense to parameterize the errval type (and it
would probably be a good idea to use a prefix):

  type 'a monad_errval
  val mkZero : 'a monad_errval -> 'a monad

-Vesa Karvonen