Re: Update on GHC 6.12.1
Is there a good motivating example for recursive do? So far, I haven't grokked the various use cases, which are pretty terse. Maybe the syntax sugar gets in the way (dangling lets are a good case in point). It's a bit like grokking a Monad: it's the way to alter state, through a chain of binds, culminating in a return, where values can't escape outside the Monad itself. Using IO as the example w/the (hidden) realworld parameter makes the explanation more opaque than it need be. -scooter Sent from my Verizon Wireless BlackBerry -Original Message- From: Greg Fitzgerald Date: Thu, 29 Oct 2009 10:24:23 To: Simon Peyton-Jones Cc: GHC users Subject: Re: Update on GHC 6.12.1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
> Another minor question is whether "-XDoRec" is a good > name for the flag. We can't really use "-XRecursiveDo" > because that's the one we are deprecating! "-XReDo" :) -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Update on GHC 6.12.1
| Analogously, is
|
| | > do { a <- getChar
| | > ; rec { b <- f c
| | >; c <- g b }
| | > ; putChar c
| | > ; return b }
|
| equivalent to
|
| | > do { a <- getChar
| | > ; rec { b <- f c
| | >; c <- g b } in do
| | > { putChar c
| | > ; return b }
No, there is no
rec { ss } in e
form; nor should there be since rec { ss } is monadic.
| Is
|
| | > do { rec { b <- f c
| | >; c <- g b }
| | > ; putChar c
| | > ; return b }
|
| equivalent to
|
| | > rec { b <- f c
| | > ; c <- g b } in do
| | > { putChar c
| | > ; return b }
No. Same answer.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Simon Peyton Jones answered me:
> | > do { a <- getChar
> | > ; rec { b <- f c
> | >; c <- g b }
> | > ; putChar c
> | > ; return b }
>
>
> | This last point notwithstanding,
> | I find the scoping rules very unintuitive!
> | (b and c appear to escape their apparently nested scope.)
>
> well you are happy with
^
(Let's say: I got used to it...)
>
> do { z <- getChar
> ; let { b = f c
> ; c = g b }
> ; putChar c
> ; return b }
>
> It's just the same!
Indeed; I had not noticed that.
(I am spoilt by layout, and had never ``seen'' those braces before.)
However, if you write those braces, there is no reason anymore to omit the
``in do'' at the end! This variant of let is only motivated by layout...
Analogously, is
| > do { a <- getChar
| > ; rec { b <- f c
| >; c <- g b }
| > ; putChar c
| > ; return b }
equivalent to
| > do { a <- getChar
| > ; rec { b <- f c
| >; c <- g b } in do
| > { putChar c
| > ; return b }
?
Is
| > do { rec { b <- f c
| >; c <- g b }
| > ; putChar c
| > ; return b }
equivalent to
| > rec { b <- f c
| > ; c <- g b } in do
| > { putChar c
| > ; return b }
?
Would ``dorec'', in analogy with ``letrec'', perhaps be a better name?
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
On Wed, 2009-10-28 at 22:55 +, Simon Peyton-Jones wrote: > SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are > about to produce RC2. However, before releasing 6.12 we'd like to > compile all of Hackage, in case doing so reveals bugs in GHC's APIs > (which are not supposed to change). But we can't do that until an > update to cabal-install is ready. (We don't expect this dependency to > happen all the time, but it does hold for 6.12.) > > Duncan has been working on the cabal-install update, and expects > to release by end November. So the timetable looks like this: > > - Very soon: GHC 6.12.1 release candidate 2 > - End Nov: cabal-install release > - ...test GHC against Hackage... An update on this: People can now grab the current darcs version of cabal-install and build and test it with ghc-6.12 (or indeed earlier ghc versions). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Update on GHC 6.12.1
| Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) Oh cruel, cruel, cruel! And unjustified to boot. My proposal (perhaps unclear) was exactly as Bulat suggests. However I'm sure we'll find some other way of breaking existing programs :-) Simon | -Original Message- | From: Lennart Augustsson [mailto:lennart.augusts...@gmail.com] | Sent: 29 October 2009 10:25 | To: Bulat Ziganshin | Cc: Simon Peyton-Jones; GHC users | Subject: Re: Update on GHC 6.12.1 | | Bulat, that would not be in the ghc tradition of breaking existing | programs in every release. ;) | | -- Lennart (iPhone) | | On 29 Oct 2009, at 03:33, Bulat Ziganshin | wrote: | | > Hello Simon, | > | > Thursday, October 29, 2009, 1:55:00 AM, you wrote: | > | >> Currently 'mdo' is enabled by -XRecursiveDo. So we propose to | >> deprecate this flag, with another flag -XDoRec to enable the 'rec' | >> keyword. | > | > i think the best way is to support both in 6.12, marking mdo usage as | > deprecated, and remove it in one of next versions | > | > -- | > Best regards, | > Bulatmailto:bulat.zigans...@gmail.com | > | > ___ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Update on GHC 6.12.1
| > do { a <- getChar
| > ; rec { b <- f c
| >; c <- g b }
| > ; putChar c
| > ; return b }
| This last point notwithstanding,
| I find the scoping rules very unintuitive!
| (b and c appear to escape their apparently nested scope.)
well you are happy with
do { z <- getChar
; let { b = f c
; c = g b }
; putChar c
; return b }
It's just the same! Perhaps I should mention this in the user manual.
(In haskell 'let' means 'letrec' of course.)
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Hello Simon, Thursday, October 29, 2009, 1:55:00 AM, you wrote: > Currently 'mdo' is enabled by -XRecursiveDo. So we propose to > deprecate this flag, with another flag -XDoRec to enable the 'rec' > keyword. i think the best way is to support both in 6.12, marking mdo usage as deprecated, and remove it in one of next versions -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Simon Peyton Jones wrote:
>
> Recursive do-notation.
> ~~
> The change is this. 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 }
>
> That is,
> * 'mdo' is eliminated
> * 'rec' is added, which groups a bunch of statements
> into a single recursive statement
> See http://hackage.haskell.org/trac/ghc/ticket/2798
>
> This 'rec' thing is already present for the arrow notation, so it
> makes the two more uniform. Moreover, 'rec' lets you say more
> precisely where the recursion is (if you want to), whereas 'mdo' just
> says "there's recursion here somewhere". Lastly, all this works with
> rebindable syntax (which mdo does not).
>
> The main question is not whether to make this change, but when.
This last point notwithstanding,
I find the scoping rules very unintuitive!
(b and c appear to escape their apparently nested scope.)
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
