map and fmap

[Iavor Diatchki]

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.

In any case, it seems to me that it is good to encourage beginners to
write type signatures, because
(i) it clears their thinking about what they are trying to do,
(ii) it leads to more accurate type errors, because the system can
detect if it is the definition of a function that is wrong or its use.
In fact, I write type signatures for the same reasons.


> I think
> everyone has tried to write
>
> class Cast a b where
>         cast :: a -> b
>
> at some point but found it not very useful as whenever it was fed or
> used as an argument to another overloaded function, you ended up with
> ambiguity errors.
>
> with all the added generality being added all over the place, you need
> collections of functions that work on concrete data types to 'fix'
> things every now and again. lists are common enough that I think they
> deserve such 'fixing' functions. And it has nothing to do with newbies.
>
> having to write type annotations when not even doing anything tricky is
> not an acceptable solution for a type infered language.

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! :-)

-Iavor