...which is a problem, because you can't distinguish code that was written (either before or after the pragma is introduced) with the assumption of a list in mind from code (written after the pragma is introduced) that intends to use the generalized type signature.  This is different from the situation created by `instance Functor [] where {fmap = map}`, which introduces a specialization of `fmap` rather than a generalization of `map`.

On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich <ryan.reich@gmail.com> wrote:
This pragma needs to have a type inference guarantee that the old signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be approximately one zillion ad-hoc functions out there written without type signatures that implicitly depend on inferring a list.

On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <carter.schonwald@gmail.com> wrote:
You make a good point, we should cook up this desired magic pragma!

Could you sketch out 1-2 examples of what you’d want this pragma to do?

Something like 
{-# method_synonym_of fmap map #-} 
?
This would sort of be like a sort of duplicate record field for how names are mapped to definitions? 
This example would be “fmap is an alias of map”


On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <ekmett@gmail.com> wrote:
The real problem with this sketch of a proposal is the lack of a nice migration plan.

If it is top level and just calls fmap, then the distinction requires random rote memorization of which one you can define.

On the other hand, say you put it in Functor today as an extra member. Currently everybody has definitions in terms of `fmap`, so you'd need to make the two definitions mutual. This would mean enlarging the dictionaries for one of the most common structures in Haskell for a rather far flung removal that breaks everyone.

If we had a way (say a pragma or other syntactic form) to say that fmap and map were somehow the 'same name' or something and so that defining one was the same as defining the other, so that this tax didn't exist, I could see how we might get there.

That sort of "magic" might be useful for making migration plans to get sequenceA to be sequence and mapM and traverse without requiring folks to memorize which one is in the class and which is a top level definition.

Without something like that, I'd remain somewhat inclined against concocting a complicated migration plan to save one letter.

-Edward

On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <carter.schonwald@gmail.com> wrote:
harkening back to the old Haskell 1.5 days, Lets have map back in functor. it "F"-  strange to not have our lovely maps be functorial by default.

I think it would be a genuine boon for old and new haskellers alike, and those who disagree with this change already use alt-preludes for pedagogy reasons anyways
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries