Burning bridges

Ben Gamari bgamari.foss at gmail.com
Wed May 22 18:41:31 CEST 2013


Ian Lynagh <ian at well-typed.com> writes:

> On Wed, May 22, 2013 at 11:16:04AM -0400, Ben Gamari wrote:
>> I'm another from the crowd of silence observers. It seems to me that
>> we still don't have a fully specified proposal. In particular which
>> functions are we discussing? Only those from Traversable and Foldable?
>> map? It would be nice to make this clear with a concrete proposal.
>
> Yes, my intention was to describe what I think a proposal should look
> like, not to make one. I think a proposal ought not be under a subject
> of "Burning bridges" too  :-)
>
A fair point :)

>> Concerning removing mapM without replacement: I'd be concerned that
>> moving such a frequently used function out of the Prelude might be a bit
>> confusing for beginners.
>
> The Prelude is a bizarre snapshot of what was common (or perhaps even
> what existed?) more than a decade ago. For example, it includes 'mapM'
> and 'sequence', but not 'when'. Here are the usage counts for the ghc
> package:
>
>     mapM        562
>     mapM_       175
>     sequence    41
>     sequence_   8   
>     when        205
>     unless      84
>
> and while this is only one package, I would be surprised if 'sequence'
> isn't generally less used than 'when'. I would also expect that most
> mapM users would also use when, so would need to import Control.Monad
> anyway, at which point there's no point having mapM in Prelude (although
> that argument is diminished if the generalised mapM is exported
> instead).
>
I agree that the subset of functions exposed by the Prelude is a bit
strange. Perhaps when should be added; perhaps sequence should be
dropped. Either way, both of these discussions are I think mostly
orthogonal to the decision of making what is currently in the Prelude
polymorphic.

> The Prelude is also bizarre due to being very broad, which also causes
> headaches with where to put it when splitting base up (the IO functions
> in particular are problematic).
>
>> Given the prominence of Monads in Haskell, 
>> it might be perplexing to find (f)map exported by the Prelude yet not
>> mapM.
>
> Well, why should map be exported by Prelude?
>
> If you want to do other things with lists, like 'sort' them, then you
> need to import Data.List, which makes a lot of sense. But if you want to
> 'scanl1' a list (when's the last time you did that?), then for
> historical reasons the function is magically imported through the
> Prelude.
>
> So why shouldn't you need to tell the compiler (i.e. "import Data.List")
> if you want to do /anything/ with a list, including 'scanl1' or 'map'?
>
In the case of these monomorphic functions on lists you may have a
point. That being said, I believe that fmap has a place in the Prelude
and my original point holds in this case as well.

I would argue that mapping over functors with pure functions
and monadic actions are both needed often enough that requiring an
import for either would be unduly onerous. I would be interested to hear
if others disagree with this premise.

Cheers,

- Ben




More information about the Libraries mailing list