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 wrote:

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