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?
On 22 June 2010 03:18, John Lask
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?
At a guess: because no-one has implemented such functionality yet. Are you volunteering? :p -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Jun 21, 2010, at 10:18 AM, John Lask wrote:
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?
Why can't you just use let notation do deal with the recursion? I thought "lets" in do blocks were just a little bit of syntactic sugar for "regular" let expressions, which do allow mutual recursion. I could be totally wrong though. I'm thinking of something like: do a <- getChar let b = c >>= return . f let c = b >>= return . g c >>= putChar b
On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote:
do a <- getChar let b = c >>= return . f let c = b >>= return . g c >>= putChar b ________________
Correction: by your construction, f and g are already in the Kliesli category, so you don't need the return compositions. I still don't know if the construction is admissible though.
On 20/06/2010 6:32 PM, Alexander Solla wrote: in your example c will not be in scope in the expression (let b = c >>= return . f) - that's the purpose of the recursive do construct (mdo, now "do .. rec ..") jvl
On Jun 20, 2010, at 6:24 PM, Alexander Solla wrote:
do a <- getChar let b = c >>= return . f let c = b >>= return . g c >>= putChar b ________________
Correction: by your construction, f and g are already in the Kliesli category, so you don't need the return compositions. I still don't know if the construction is admissible though.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sunday 20 June 2010 9:24:54 pm Alexander Solla wrote:
Why can't you just use let notation do deal with the recursion? I thought "lets" in do blocks were just a little bit of syntactic sugar for "regular" let expressions, which do allow mutual recursion. I could be totally wrong though. I'm thinking of something like:
do a <- getChar let b = c >>= return . f let c = b >>= return . g c >>= putChar b
This is not what recursive do does. For instance: do rec l <- (:l) <$> getChar return l will read one character, and return an infinite list with that character as the elements. By contrast: let l = (:) <$> getChar <*> l in l will, for one, never complete, and two, call getChar an infinite number of times. In general, it is based on the fixed point: mfix :: (MonadFix m) => (a -> m a) -> m a where the function given may not be separable into a pure function and return at all, which is what would be necessary to implement using let, via the identity: mfix (return . f) = return (fix f) The implementation of mfix is specific to the 'm' in question, not something you can write for all monads. -- Dan
participants (4)
-
Alexander Solla -
Dan Doel -
Ivan Miljenovic -
John Lask