"do" notation and ">>"
David Feuer
dfeuer@cs.brown.edu
Mon, 15 Apr 2002 00:49:25 -0400
On Sun, Apr 14, 2002, Koen Claessen wrote:
>
> | do {e ; stmts} = e >> do {stmts}
>
> With the risk of being late at this, and with the risk of
> repeating something that has already been said (because I
> have been away), I will give my two euro-cents.
>
> I remember a discussion at the Haskell mailing list about
> the possibility of creating a nasty space leak with this
> translation. After all, there is a difference between:
>
> <e1> >> <e2>
>
> which, for the default definition of >> expands to an
> expression which is operationally equivalent to:
>
> <e1> >>= let x = <e2> in \_ -> x,
>
> and:
>
> <e1> >>= \_ -> <e2>.
>
> In the first case, x is shared between successive
> invocations, but in the second case, e2 is recomputed.
>
> I remember that the example involved a definition like:
>
> f = do ...; print [1..]
>
> In the translation in the report, the list [1..] is shared
> between all invocations of f, whereas the current GHC
> translation does not.
If I understand this correctly, this only comes up when full laziness is
used. Since full laziness turns space-efficiency upside-down, it does
not seem to make much sense to try to tweak the Report to make things
work better with full laziness.
Note: I think it could be pretty cool to have something like full
laziness that depended on programmer annotations:
f p = let x = e1 in e2
would not save the value of x across calls to f, but
f p = letfl x = e1 in e2
would save it.
Something like this could be used for those cases where full laziness
makes programs easier to read/write/understand without bothering people
in cases where it is a bad idea.
>
> So, changing the translation in GHC might actually introduce
> a very nasty space leak in existing programs!
--
Night. An owl flies o'er rooftops. The moon sheds its soft light upon
the trees.
David Feuer