Clarify the documentation for 'evaluate'

Authored by Feuerbach on Jan 11 2015, 8:18 AM.




Diff Detail

rGHC Glasgow Haskell Compiler
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
Feuerbach updated this revision to Diff 2103.Jan 11 2015, 8:18 AM
Feuerbach retitled this revision from to Clarify the documentation for 'evaluate'.
Feuerbach updated this object.
Feuerbach edited the test plan for this revision. (Show Details)

From a user pov, a good improvement. Especially the last paragraph (the rule of thumb) is useful 👍

ezyang added a subscriber: ezyang.Jan 11 2015, 11:19 AM
ezyang added inline comments.

I don't think this advice is quite right: say you do

(return $! some_big_thunk) >> throw e

GHC is within its rights to skip evaluating some_big_thunk, but maybe you wanted to force the thunk, and THEN throw an error. Of course, you'll do fine if you have:

(return $! some_big_thunk) >> throwIO e

So it might still be a useful rule of thumb.

Feuerbach added inline comments.Jan 11 2015, 1:00 PM

Good point, I hadn't thought of that.

On the other hand, in your example it may actually be beneficial to discard the thunk, as that particular reference to it will be lost immediately. So, when there's no other reference to it (which is likely, although not necessary), we'll win time and lose nothing.

Another thing to consider is that the scenario you describe may happen in any monad, while we only have the luxury of 'evaluate' in IO. If this concern is real, should we recommend using pseq instead of seq?

ezyang added inline comments.Jan 11 2015, 1:08 PM

It's more a matter of predictability. For example, would you rather a library function say, "When this function is evaluated, its argument is evaluated to WHNF" or "When this function is evaluated, AND there is no existing entry in the map for k, its argument is evaluated." This is important for parallel computation, because I care a lot about whether or not a thunk is evaluated or not. (Unsurprisingly, parallel computation is when one tends to recommend use of pseq.)

It's an interesting question whether or not pseq is a suitable replacement for evaluate. It might be.

Mikolaj accepted this revision.Jan 12 2015, 1:06 AM
Mikolaj edited edge metadata.

I see the discussion now spans ghc-devs, the ticket *and* here. Perhaps it makes sense to move it back to ghc-devs so that others can more easily follow? Anyway, the new docs are a significant improvement already, so I'm accepting the revision.

This revision is now accepted and ready to land.Jan 12 2015, 1:06 AM
austin accepted this revision.Jan 19 2015, 4:20 PM
austin edited edge metadata.

I think the way this revision currently looks is fine to me; we can keep this in 7.12 and revise it later.

This revision was automatically updated to reflect the committed changes.