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 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

...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 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 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

and the alluded extension / pragma idea would be for equi typed names,not for anyting fancy about type subsumption On Mon, Feb 11, 2019 at 1:14 PM Carter Schonwald wrote:

no, map should have the more general type :)

On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich wrote:

...

...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 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 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

Even with a tool to automate it I know many authors would be very disturbed by such a huge diff in their code. On larger teams with many active branches this kind of sweeping change is quite difficult to maneuver. On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson

On 08/02/2019 19.45, Edward Kmett wrote:

...

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.

+1 for "the way"

Most of these 'migrations' which are mostly syntactic should be automatable and really should be *automated* via some sort of tool support. I still haven't experienced a language where this sort of thing "just works", but IMO gofix and scalafix have sort of the right idea.

(In Haskell we have the luxury of 'only' having to guarantee source compatibility.)

If people are worried about having to add CPP sections, then I would submit it's very possible to convert diffs (between pre-fix to post-fix) to CPP. That, or one can usually create a *-compat library which contains the CPP and just use that as a dependency. Ugly, yes, but in practical terms it seems to be quite simple.

Regards,

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 2019-02-08 1:45 p.m., Edward Kmett wrote:

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.

A similar sort of magic could be used for MonadOfNoReturn: we want to end up with a `return = pure` definition, not a method of any class, while all the existing code still compiles. Or is that migration plan already fully covered by existing magic tricks?