> 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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
