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 <saurabhnanda@gmail.com> wrote:

Intresting. Wont using "void" or "_ <- forM blah" have the same effect? Why not?

On 20-Sep-2017 9:37 PM, "Nick Smallbone" <nick@smallbone.se> wrote:

Hi Stanislav,

Станислав Черничкин <schernichkin@gmail.com> 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