Re: [Haskell-cafe] Better names for
fmap f. If I could re-define Haskell from scratch, I'd probably name the Functor type class function 'map'
As it was in Haskell 1.4
That's interesting, I did not know this. Thanks for sharing. Are there any public records as to why the decision was made to re-name 'map' to 'fmap'? I can not find any mention in the Haskell98 report(s). There is a stackoverflow thread (#6824255) which mentions paedagogical reasons, simplifying error messages. I sometimes use the current naming 'map' to specialize a polymorphic function to work exclusively on lists where any functor could have been used. Other than that, I can not quite see the use in keeping 'map' around when it is equivalent to fmap. What reasons are there apart from backwards compatibility? Are there re-write rules that make 'map's (operational) semantics different to 'fmap'? Olaf
Olaf Klinke
fmap f. If I could re-define Haskell from scratch, I'd probably name the Functor type class function 'map'
As it was in Haskell 1.4
That's interesting, I did not know this. Thanks for sharing. Are there any public records as to why the decision was made to re-name 'map' to 'fmap'? I can not find any mention in the Haskell98 report(s).
Sorry, I don’t know.
There is a stackoverflow thread (#6824255) which mentions paedagogical reasons, simplifying error messages.
That is the reason that I remember, the problem being that it makes sense to teach map on lists before teaching type classes, so error messages mentioning classes were considered confusing. I was against this, preferring that teaching should use a specialised prelude, but this was rejected on the grounds that teachers wanted to teach “the real language”. I still think this was a mistake. — Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
Jon Fairbairn
fmap f. If I could re-define Haskell from scratch, I'd probably name the Functor type class function 'map'
As it was in Haskell 1.4
There is a stackoverflow thread (#6824255) which mentions paedagogical reasons, simplifying error messages.
That is the reason that I remember, the problem being that it makes sense to teach map on lists before teaching type classes, so error messages mentioning classes were considered confusing.
I was against this, preferring that teaching should use a specialised prelude, but this was rejected on the grounds that teachers wanted to teach “the real language”. I still think this was a mistake.
I wasn't there for that discussion, but the evolution of Haskell as an industrial tool makes this justification look worse in hindsight, now that we have things like the Foldable/Traversable typeclasses. Both of which are fantastic improvements for industrial use, but mean that you see classy signatures even on straightforward list functions. Even numeric literals induce classy type signatures if you're not careful. I think the case for a solid teaching prelude separate from the industrial prelude has become more compelling over time, especially now that GHC can emit custom type error messages. -- Jack
participants (3)
-
Jack Kelly -
Jon Fairbairn -
Olaf Klinke