A better type signature for `forM_`

[Bryan Richter]

On Fri, Apr 01, 2016 at 10:23:24AM -0400, davean wrote:
> On Fri, Apr 1, 2016 at 1:13 AM, Erik de Castro Lopo wrote:
> 
> > Which is the exact problem. I suspect that most people use `forM_`
> > as "assume the action returns unit" rather than "assume the return
> > value of the action is ignored".
> >
> 
> A review of my code shows I mostly use it as "assume the return value of
> the action is ignored".
> 
> Many things return data that is sometimes useful, but not always. Rarely do
> they have an '_' variant or the like to allow you to be more specific.

(emphasis added:)

> I wouldn't find it to be overly onerous to throw "void" in in those
> cases though.

The first email in this thread hinted at another possible solution,
with "unexpected behavior from... code that... has zero warning (even
with -Wall)."

Even if forM_ gets a new type, I don't think people will be much
assisted with the new message:

    Expected: IO ()
    Actual: IO (IO Int)

That message actually mixes two different problems. If the wisdom
becomes "throw a void on it", which I've already seen suggested a few
times, you easily get back to the original problem. Change the body of
the lambda to

    void $ maybe (HT.insert ht k v) (const $ abort k) <$> HT.lookup ht k
    ^^^^^^^

...and now it *still* typechecks without warnings, but the original
problem remains.

Better, if possible, would be

    Warning: Discarded monadic value [in forM_]

Even that wouldn't catch my 'void $' above, but it also wouldn't
be indirectly *suggesting* it as a solution.

However, the thing Snoyberg raised about performance seems important.
Busting the stack while trying to throw away variables seems
unfortunate. Is Free the best counterexample to the "performance" of
`t a -> (a -> m ()) -> m ()`? Does Free really matter? It's not
exactly known for being a performant option.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160401/34166962/attachment.sig>