Suggestion regarding (.) and map

Cale Gibbard cgibbard at gmail.com
Thu Apr 24 18:25:39 EDT 2008


2008/4/24 Twan van Laarhoven <twanvl at gmail.com>:
> Cale Gibbard wrote:
>
>
> > Hello,
> >
> > In keeping with my small but seemingly extremely controversial
> > suggestions for changes to the Prelude, here's a suggestion which I
> > think is elegant and worth considering for the Haskell' Prelude:
> >
> > Rename fmap to map (like it was in Haskell 1.4), and define (.) as a
> > synonym for it.
> >
>
>  One thing I fear (though that fear may be irrational) is that you get code
> that looks like "(.) . ((.) . (.) .)". To me, and I expect to many people,
> map and composition are different things, and used in different ways. If
> both are written as a dot it will take extra mental effort to decipher the
> meaning of a program. The potential for writing code that resembles the
> worst outputs of the @pl lambdabot plugin also becomes larger.

This is why I recommend having (.) only be a synonym for map (which
would be the method of Functor).

>  Cale: do you have some real world examples of code you wrote using (.) =
> fmap?

I haven't used the convention in anything too large, but I've found it
rather convenient and natural in the case of, for instance, IO, to be
able to write things like  map read . lines . getContents. I've played
around with it in a lot of small cases and not found ambiguity to be
much of a problem. It turns out that the functor is basically always
determined by the last thing in the chain of (.) applications, so it
remains sensible.

>  Secondly, I am really fond of the Applicative notation <$>, which goes
> great together with <*>. A lighter notation would be nice, but I see no good
> way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?)

Yeah, that's something to think about. I agree that the appearance of
<$> mixes well with the other Applicative operators, and should likely
remain a part of that library. Adding special syntactic support for
Applicative could be very nice though.

 - Cale


More information about the Haskell-prime mailing list