Re: whenJust / forM_ (was Re: Proposal: Add isLeft/isRight to Data.Either)

10 Dec 2012

      On 10.12.12 4:42 AM, Conrad Parker wrote:
...
On 8 December 2012 02:38, Erik Hesselink  wrote:
...
On Friday, December 7, 2012, Thomas Schilling wrote:
...
On 7 December 2012 09:25, Erik Hesselink  wrote:
...
There is no need to define whenJust, since it is just a specialization
of forM_ from Data.Foldable.
I don't know if that's such a good argument.  I prefer my code
readable -- too much abstraction can have a seriously bad effect on
that.  As a simple rule, if the user has to do type inference in their
head, readability suffers.
In this case, "forM_" implies we're iterating over something container
like, "whenJust" means "I want to do something if this thing yielded a
result". It depends on the context whether a "Maybe" is behaving more
container-like or is indicating the presence of a result where there
may not have been one.
I don't have this problem, but I guess that's just personal. But in general
I'm not in favor of adding specialized versions of generalized functions.
At least in my mind, there is a conceptual distinction between a 
conditional execution such as whenJust and an iteration such as forM_. 
But I guess I am not alone in favoring, say,

   if (debugLevel >= 1) then print ("Bla")

over

   while (debugLevel >= 1) do print ("Bla")

So for purposes of program readability, whenJust has clearly a right of 
existence, even if it is just an alias for forM_.
...
indeed, and likewise we should get rid of
Control.Monad.forM_ :: Monad m => [a] -> (a -> m b) -> m ()
which is just the same specialization to lists (and likely the reason
that forM_ doesn't come to mind for other container types, as much as
I generally like Data.Foldable).
This is a another issue, these special instances of mapM for lists are 
indeed annoying...
...
btw:
$ git grep whenJust|wc -l
40
Cheers,
Andreas

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/