map and fmap

[John Meacham]

On Tue, Aug 22, 2006 at 01:52:45PM -0700, Iavor Diatchki wrote:
> Hello,
> I agree that this is a small change, and I don't expect that it will happen.
> 
> On 8/21/06, John Meacham <john at repetae.net> wrote:
> >Yeah, the change doesn't seem worth it to me. And I still have concerns
> >about ambiguity errors, if a beginner ever has to use an explicit type
> >signature it sort of ruins the whole "type inference" benefit.
> 
> There is a big difference between having to declare all types vs.
> writing type signatures only in some places.

I am not talking about type signatures, I am talking about having to
annotate in the middle of a term.

f x y | x `member` map g freeVars y  = ....

having to become

f x y | x `member` map g (freeVars y :: [Id])  = ....

types in the middle of terms are badbad. (and having to break up your
logical structure is worse)

> The problem you are describing above is entirely different...
> I agree that we should not overload everything, after all there must
> be some concrete types in the program.
> 
> However, having a 'map' function that is specialized to lists in the
> standard library seems quite ad-hoc to me, in a way it is comparable
> to saying that 'return' should be specialized to IO, and we should
> have 'mreturn' in the Monad class (I am not suggesting this! :-)

Well there will always be a tension between generality and ambiguity,
finding the nice optimal spot is something we are going to need to do. I
am just saying that talking about beginners is something of a red
herring, and the real issue we should be concerned about is this
tension. Concessions are made in both directions all the time, we don't
have a returnM, returnP  like you say (but there used to be, before type
classes and such) but at the same time, fundeps were added to the mtl to
avoid having to annotate everything with type signatures.

So, I am not saying renaming fmap to map is bad outright, I am just
saying that the question is trickier than just the error message problem
it was previously stated in terms of.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈