#4148: improve new recursive do syntax
---------------------------------+------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: low | Milestone: 7.6.1
Component: Compiler | Version: 6.12.3
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by lerkok):
[No apologies needed Simon; Iavor and I have been confused for each other
several times before..]
Regarding use of `rec` within `mdo`: My concern was more about the
confusion it would create, and it seems unnecessary. However, supporting
it like you described might be the easiest thing to do.
Simon M: Regarding `do rec` simplifying things: My personal opinion is
that this is not the case. In the original translation we've described and
implemented in GHC, there was no mention of `rec` anywhere, presenting a
simple construct for the user that did all the necessary
analysis/translation. As I've described above and documented elsewhere, I
think segmentation is a necessary part of the translation, and is
analogous to the segmentation you perform when typing recursive binding
groups to improve polymorphism. (The analogy is not exact, but motivation
is the same.)
I believe the `rec` keyword came into play when Ross implemented the arrow
syntax with `proc` and `do`; which did not have an explicit recursive
counterpart; thus also needing a `rec` form. Once he introduced that, it
created an obvious clash with `mdo`, as they were seemingly doing the same
thing. But as argued previously in this ticket, they are quite different,
and I do believe a single `mdo` construct is more appropriate then `do`
with user-marked `rec` sections. Individual opinions might of course
differ, as evidenced by this whole thread.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4148#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
