
Briefly, because the 'spine' of IO (and indeed most monads) imposes a
boundary on laziness, so when the IO action happens, the list *will* be
built. It can only be bypassed by laziness if the IO action itself is.
Hypothetically one could have RULES that rewrite to the non-list-building
variants (trailing _) if the result is seen to be discarded --- but it
would probably be unreliable, much as stream fusion can only happen if
things go just right.
On Wed, Sep 20, 2017 at 12:12 PM, Saurabh Nanda
Intresting. Wont using "void" or "_ <- forM blah" have the same effect? Why not?
On 20-Sep-2017 9:37 PM, "Nick Smallbone"
wrote: Hi Stanislav,
Станислав Черничкин
writes: I've wrote simple Haskell benchmark program, which populated primitive vector from vector package:
... void $ for [0..1000000 - 1] $ flip (P.unsafeWrite v) (1 :: Int)
'for' is a variant of 'map' - it returns a list of results (in this case a list of a million () values). Instead you should use 'forM_' (note the underscore) from Control.Monad, which discards the result - that cuts the runtime by a huge amount when I try it. (And make sure to compile with -O too.)
Nick
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net