"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