Syntax extensions: mdo and do...rec

Brandon Michael Moore brandon at its.caltech.edu
Wed Sep 17 12:41:24 EDT 2003


> hello,

> i have no strong feelings about that either way,
> however since in haskell we do not have "let" vs "let rec" distinctions,
> perhaps we should not have "do" vs "do rec" distinction.
> this of course would break programs relying on shadowing
> (and at least i write quite a few of those, but that is mostly habit).
> i doubt that this will cause many backward compatability problems,
> as one can compile old modules (not using recursive do) without
> the flag enabling recursive dos.
>

I think you have a great idea here.

The problem with that is that not all monads support recursive bindings.
We can deal with that, but the desuagring of a do statement wouldn't be so
trivial any more. The most sensible approach I can think of is to analyze
the bindings and generate a translation involving mfix if the bindings are
recursive, and a translation without if they are not. I don't like
complicating the translation, but at least it is still purely syntactic.

I'm also worried about making the typing of a statement depend on the
binding structure, rather than just the types of subexpressions and how
they are used. It's probably a bit simpler than the normal mental
typechecking we do, but it is different. If we do this we should try for
nice warnings about recursively defined variables if failures to staisfy
the MonadFix constraint suggest the do statement was wrong.

In any case, I don't see the need for explicit rec groups. Can't GHC just
find the strongly connected components like it already does with let
bindings? Don't the laws for loop and mfix justify the transformation? If
you really need to specify the binding groups (or at least provide an
upper bound on their size) you can use explicit nested mdo statements.

I don't think we should force the programmer to explicitly identify groups
of recursive bindings. It's probably not even worth providing synatx
beyond nested mdo statements uness is is frequently necessary. I agree
with Iavor that we should try for simplicity and consistency. Are there
any gaping holes in my musings on his proposal?

Brandon



More information about the Haskell mailing list