add map back to Functor
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
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
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
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
...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
no, map should have the more general type :) On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich <ryan.reich@gmail.com> 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 <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
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 <carter.schonwald@gmail.com> wrote:
no, map should have the more general type :)
On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich <ryan.reich@gmail.com> 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 <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
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,
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 <spam@scientician.net wrote:
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
No... the point of such an extension would be that no code that already works would need to change. Except to the extent If I’m not understanding your misapprehension, Could you lay out a specific micro example ? On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron <eacameron@gmail.com> wrote:
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 <spam@scientician.net wrote:
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
_______________________________________________ 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?
El 8 feb 2019, a las 12:06 PM, Carter Schonwald <carter.schonwald@gmail.com> escribió:
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
I'm personally -1 on this even if we had a nice migration plan. (Even though I'm not someone who uses an alternative prelude!). "map" is a simple, helpful function. "fmap" is a nice generalized version. It's not costly in readability or typing to keep them separate. Also, nearly every module I've written in Haskell has used "map," under the assumption it meant one thing, and changing it to mean something else (even if only generalized) will have more implications than I can go through and inspect. This is similar to how generalizing "length" in the BBP indirectly caused hard-to-track-down bugs. Lastly, I don't think "pedagogy" can be entirely relegated to "use an alternative prelude". If when I was first evaluating _whether_ to use Haskell I had been told to use "-fno-implicit-prelude" and "import FakePrelude", I'd chafe at essentially being told "pay no attention to the man behind the curtain." If I'd been told that if I wanted to (+1) every element of a list I had to learn a small bit of category theory, I'd have thought "wow, it really is just a language for mathematicians" and likely thought the language wasn't for me. In my view this proposal will make Haskell more intimidating, when we should be trying as much as we can to make it less! Tom
participants (7)
-
amindfv＠gmail.com -
Bardur Arantsson -
Carter Schonwald -
Edward Kmett -
Elliot Cameron -
Mario Blažević -
Ryan Reich