#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 ross):
Replying to [comment:10 ryani]:
> I would suggest never doing dependency analysis with rec (I was actually
unaware that this happened and thought that was the whole point of
migrating to 'rec' over 'mdo').
>
> I second the suggestion that we translate
>
> {{{ do { ... ; rec { ...; e } } }}}
>
> (i.e. 'rec' as the last statement in a do block) into
>
> {{{ do { ... ; rec { ...; fresh <- e} ; return fresh } }}}
The two are connected. With segmentation, this will then be transformed
to the equivalent of
> {{{ do { ... ; rec { ... } ; fresh <- e ; return fresh } }}}
which may have different semantics. Certainly it will feed back a smaller
tuple. Without segmentation, you might not want to do that.
I'd rather {{{rec}}} wasn't subject to segmentation, as that would be
simpler and more predictable. Levent made an analogy with ordinary
recursive definitions; I'd make one with the common reluctance to rely on
the compiler for transformations that improve the big-O complexity, except
that termination is a bigger deal. Unfortunately that change will cause
some programs not to terminate, with no hint from the compiler. I expect
(but cannot prove) that Simon's right that this is fairly rare though.
Having done my bit to complicate GHC, I'm naturally somewhat in favour of
maximal simplicity elsewhere, which would mean no segmentation, no moving
final expressions out of rec, and no mdo.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4148#comment:17>
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
