new recursive do notation (ghc 6.12.x) spoils layout

Whilst I have nothing against the change in syntax for recursive do aka http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html Instead of writing mdo a <- getChar b <- f c c <- g b putChar c return b you would write do a <- getChar rec { b <- f c ; c <- g b } putChar c return b it does spoil the nice layout - it would be nice to just be able to write (which does not parse) do rec a <- getChar b <- f c c <- g b putChar c return b I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised "do rec" as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/21/10 13:18 , John Lask wrote:
it does spoil the nice layout - it would be nice to just be able to write (which does not parse)
do rec a <- getChar b <- f c c <- g b putChar c return b
I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised "do rec" as a recursive group it would have been a drop in replacement and taken me one tenth of the time.
I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the "r" of "rec". - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkweuP0ACgkQIn7hlCsL25XifQCgzvfvf9utQxkb2gdmVRPyhea2 iIUAnRT8XUhTKds0wrVkFaccyzAKTA9v =YjX6 -----END PGP SIGNATURE-----

I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the "r" of "rec".
for the record ...
t2 = do rec a <- getChar b <- f c c <- g b putChar c return b
f = return . (const 'a') g = return
eg.lhs:23:6: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. so I suppose it is not so far from "recognising" the construct and yet too far!

There's also an underlying semantic issue, which is not yet resolved. The GHC implementation of mdo (following Levent and John's paper) performs a dependency analysis on the statements in the mdo to apply mfix to the shortest possible subsegments of statements. For example, mdo a <- f b b <- g b c <- h b d <- k d return d is translated to the equivalent of do (a,b) <- mfix $ \ (a,b) -> do a <- f b b <- g b return (a,b) c <- h b d <- mfix $ \ d -> d <- k d return d return d As the User's Guide notes, the choice of segments can change the semantics with some monads. When rec was added to GHC, the implementation used the same code and thus also did automatic segmentation. The original idea of rec (in arrow notation) was that it would give the programmer direct control over these segments: the loop/mfix combinators would go wherever the programmer put a rec, but I didn't realize Simon had done it the other way until he mentioned it last October. So: * if rec is to continue to do automatic segmentation, it might as well be a modifier on the do keyword (though this would break backward compatibility of arrow notation), * but I want to argue against automatic segmentation, because I don't think the compiler should be making subtle changes to the program's semantics on its own. It would simplify the compiler a bit too.
participants (3)
-
Brandon S Allbery KF8NH
-
John Lask
-
Ross Paterson