Nikita Volkov | 21 Jun 11:51 2013
Picon

Make Prelude's map = fmap

Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to
start a poll on a subject.

I know that "map" is limited to lists for the beginners, but then we're already making a lot of unbeginnerish
changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person learn Haskell
without understanding what a Functor is?
Andrew Butterfield | 21 Jun 11:59 2013
Picon
Picon

Re: Make Prelude's map = fmap


On 21 Jun 2013, at 10:51, Nikita Volkov wrote:

> Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to
start a poll on a subject.
> 
> I know that "map" is limited to lists for the beginners, but then we're already making a lot of
unbeginnerish changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person
learn Haskell without understanding what a Functor is?

!!!! No one needs to know what a functor is in order to learn Haskell.
No one needs to know any category theory ideas to learn Haskell.

Haskell is a very good vehicle to introduce such category-theoretic concepts,
and as someone learns Haskell, learning about Haskell classes(*) such as Functor,
etc, is very important and useful. 

My main reason for this sudden and abrupt response is that I would be worried if
any Prelude re-design was predicated on the idea that Haskell beginners need to understand Functors
 - they don't, but hopefully they will learn...

(*) as distinct from learning about the category theoretic notion of functor.

> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
(Continue reading)

Daniel Díaz Casanueva | 21 Jun 21:00 2013
Picon

Re: Make Prelude's map = fmap

Hello!

To be honest, I always write "fmap" instead of "map" in all my code. Sometimes I change the container I am using, and if I write "map", then I would have to change that "map" to "Something.map" or just "fmap". I know for sure that fmap is going to work in any Functor instance, so I don't have to deal with these things. In some situations (using functions from other classes as well), I only change the type signature of my functions, and the program keeps working as expected, which is awesome.

Therefore, I support the proposal.

By the way, how strong is the reason "it would be harder to learn"? Is it really that hard to use type classes? I don't think you need any deep math to understand how to work with type classes in Haskell. Even if they are called "Functor" or "Monad", you don't need to know about categories to use them. In fact, any Haskell student faces type classes in some point.

In the other hand, I remember that at the beginning somebody showed me that "+" sums integers. And eventually, it worked with floats too. He called this "overloading" and, presented in that way, type classes appeared like something natural in my mind. Can't the same thing been done in this case?

Best regards,
Daniel Díaz.


On Fri, Jun 21, 2013 at 11:59 AM, Andrew Butterfield <Andrew.Butterfield <at> scss.tcd.ie> wrote:

On 21 Jun 2013, at 10:51, Nikita Volkov wrote:

> Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to start a poll on a subject.
>
> I know that "map" is limited to lists for the beginners, but then we're already making a lot of unbeginnerish changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person learn Haskell without understanding what a Functor is?


!!!! No one needs to know what a functor is in order to learn Haskell.
No one needs to know any category theory ideas to learn Haskell.

Haskell is a very good vehicle to introduce such category-theoretic concepts,
and as someone learns Haskell, learning about Haskell classes(*) such as Functor,
etc, is very important and useful.

My main reason for this sudden and abrupt response is that I would be worried if
any Prelude re-design was predicated on the idea that Haskell beginners need to understand Functors
 - they don't, but hopefully they will learn...


(*) as distinct from learning about the category theoretic notion of functor.

>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero <at> TCD, Head of Foundations & Methods Research Group
Director of Teaching and Learning - Undergraduate,
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
                          http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Carter Schonwald | 21 Jun 22:53 2013
Picon

Re: Make Prelude's map = fmap

I'd support the map=fmap thing, 


On Fri, Jun 21, 2013 at 3:00 PM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
Hello!

To be honest, I always write "fmap" instead of "map" in all my code. Sometimes I change the container I am using, and if I write "map", then I would have to change that "map" to "Something.map" or just "fmap". I know for sure that fmap is going to work in any Functor instance, so I don't have to deal with these things. In some situations (using functions from other classes as well), I only change the type signature of my functions, and the program keeps working as expected, which is awesome.

Therefore, I support the proposal.

By the way, how strong is the reason "it would be harder to learn"? Is it really that hard to use type classes? I don't think you need any deep math to understand how to work with type classes in Haskell. Even if they are called "Functor" or "Monad", you don't need to know about categories to use them. In fact, any Haskell student faces type classes in some point.

In the other hand, I remember that at the beginning somebody showed me that "+" sums integers. And eventually, it worked with floats too. He called this "overloading" and, presented in that way, type classes appeared like something natural in my mind. Can't the same thing been done in this case?

Best regards,
Daniel Díaz.


On Fri, Jun 21, 2013 at 11:59 AM, Andrew Butterfield <Andrew.Butterfield <at> scss.tcd.ie> wrote:

On 21 Jun 2013, at 10:51, Nikita Volkov wrote:

> Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to start a poll on a subject.
>
> I know that "map" is limited to lists for the beginners, but then we're already making a lot of unbeginnerish changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person learn Haskell without understanding what a Functor is?


!!!! No one needs to know what a functor is in order to learn Haskell.
No one needs to know any category theory ideas to learn Haskell.

Haskell is a very good vehicle to introduce such category-theoretic concepts,
and as someone learns Haskell, learning about Haskell classes(*) such as Functor,
etc, is very important and useful.

My main reason for this sudden and abrupt response is that I would be worried if
any Prelude re-design was predicated on the idea that Haskell beginners need to understand Functors
 - they don't, but hopefully they will learn...


(*) as distinct from learning about the category theoretic notion of functor.

>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--------------------------------------------------------------------
Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
Lero <at> TCD, Head of Foundations & Methods Research Group
Director of Teaching and Learning - Undergraduate,
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
                          http://www.scss.tcd.ie/Andrew.Butterfield/
--------------------------------------------------------------------


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Matthias Kilian | 21 Jun 23:12 2013
Picon

Re: Make Prelude's map = fmap

On Fri, Jun 21, 2013 at 04:53:49PM -0400, Carter Schonwald wrote:
> I'd support the map=fmap thing,

Does it cause any consequences for existing libraries and programs?
Does it break any existing Haskell98 (or Haskell2010) code?

If not: fine. But if yes: please don't do it.

Ciao,
	Kili
Henning Thielemann | 23 Jun 19:46 2013
Picon

Re: Make Prelude's map = fmap


On Fri, 21 Jun 2013, Matthias Kilian wrote:

> On Fri, Jun 21, 2013 at 04:53:49PM -0400, Carter Schonwald wrote:
>> I'd support the map=fmap thing,
>
> Does it cause any consequences for existing libraries and programs?
> Does it break any existing Haskell98 (or Haskell2010) code?
>
> If not: fine. But if yes: please don't do it.

My main concern is that we reduce type-safety. If you have a lot of nested 
Functors, and you apply a nested fmap like in (fmap (fmap (fmap f))) with 
a polymorphic f, then after adding or removing a functor level the code 
can probably still be compiled, but is wrong. It is also more difficult to 
read, since in order to understand (fmap (fmap (fmap f))) you have to 
infer types mentally, in order to find out that, say, the second fmap is a 
List.map. These are my general concern with always using the most general 
function available.

Thus a -1 for this proposal, from me.
Nikita Volkov | 23 Jun 20:04 2013
Picon

Re: Make Prelude's map = fmap

Henning, don't forget that noone suggests to remove Data.List.map, which you will still be perfectly able
to use qualified when you feel the need to. 

To me having the most general functions imported unqualified from Prelude and specific ones qualified
seems most natural. After all, why list should have this "data structure by default" status, why not
vector, seq or set or whatever? 

On Jun 23, 2013, at 9:46 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

> My main concern is that we reduce type-safety. If you have a lot of nested Functors, and you apply a nested
fmap like in (fmap (fmap (fmap f))) with a polymorphic f, then after adding or removing a functor level the
code can probably still be compiled, but is wrong. It is also more difficult to read, since in order to
understand (fmap (fmap (fmap f))) you have to infer types mentally, in order to find out that, say, the
second fmap is a List.map. These are my general concern with always using the most general function available.
> 
> Thus a -1 for this proposal, from me.
Henning Thielemann | 23 Jun 20:11 2013
Picon

Re: Make Prelude's map = fmap


On Sun, 23 Jun 2013, Nikita Volkov wrote:

> Henning, don't forget that noone suggests to remove Data.List.map, which 
> you will still be perfectly able to use qualified when you feel the need 
> to.

If in future Prelude moves more and more to one most general function that 
does everything given the right type, then I am really concerning to use 
NoImplicitPrelude in all my modules and use a custom Prelude or none at 
all.

> To me having the most general functions imported unqualified from 
> Prelude

... are you sure, "fmap" is the most general function?

> and specific ones qualified seems most natural.
Nikita Volkov | 23 Jun 20:20 2013
Picon

Re: Make Prelude's map = fmap


On Jun 23, 2013, at 10:11 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

> If in future Prelude moves more and more to one most general function that does everything given the right
type, then I am really concerning to use NoImplicitPrelude in all my modules and use a custom Prelude or
none at all.

That's exactly what I am doing now and the very existence of a dozen of "prelude" projects on hackage
suggests that I'm hardly alone in that.
Brandon Allbery | 23 Jun 20:25 2013
Picon

Re: Make Prelude's map = fmap

On Sun, Jun 23, 2013 at 2:20 PM, Nikita Volkov <nikita.y.volkov <at> gmail.com> wrote:
On Jun 23, 2013, at 10:11 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:
> If in future Prelude moves more and more to one most general function that does everything given the right type, then I am really concerning to use NoImplicitPrelude in all my modules and use a custom Prelude or none at all.

That's exactly what I am doing now and the very existence of a dozen of "prelude" projects on hackage suggests that I'm hardly alone in that.

Except that most of them are making things *more* general, whereas Henning believes polymorphism is evil and confusing.

Is there anything else we need to remove from Haskell to make it "appropriate"? Within the past 24 hours I have heard impassioned arguments for jettisoning polymorphism, monads, and arrows. Maybe strong typing should be removed next? Currying?

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 24 Jun 09:20 2013
Picon

Re: Make Prelude's map = fmap


On Sun, 23 Jun 2013, Brandon Allbery wrote:

> On Sun, Jun 23, 2013 at 2:20 PM, Nikita Volkov <nikita.y.volkov <at> gmail.com> wrote:
>       On Jun 23, 2013, at 10:11 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:
>       > If in future Prelude moves more and more to one most general function that does everything
>       given the right type, then I am really concerning to use NoImplicitPrelude in all my modules and
>       use a custom Prelude or none at all.
> 
> That's exactly what I am doing now and the very existence of a dozen of "prelude" projects on hackage
> suggests that I'm hardly alone in that.
> 
> 
> Except that most of them are making things *more* general, whereas Henning believes polymorphism is evil and
> confusing.

I use 'fmap' a lot myself. I only do not see why to alter Prelude, because 
you can import everything you need from Data.List, Data.Functor and 
friends.
Andreas Abel | 21 Jun 22:57 2013
Picon

Re: Make Prelude's map = fmap

Frankly, the proposal text does not make clear what exactly you want to do.

I would guess the name 'fmap' was chosen for 'Functor' because 'map' was 
already taken for lists.  So it would make sense to

1. remove Prelude.map
2. make map an alias for fmap

Then, in 50 years from now we can deprecate fmap and remove it in 100 
years from now. ;-)

Cheers,
Andreas

On 21.06.2013 21:00, Daniel Díaz Casanueva wrote:
> Hello!
>
> To be honest, I always write "fmap" instead of "map" in all my code.
> Sometimes I change the container I am using, and if I write "map", then
> I would have to change that "map" to "Something.map" or just "fmap". I
> know for sure that fmap is going to work in any Functor instance, so I
> don't have to deal with these things. In some situations (using
> functions from other classes as well), I only change the type signature
> of my functions, and the program keeps working as expected, which is
> awesome.
>
> Therefore, I support the proposal.
>
> By the way, how strong is the reason "it would be harder to learn"? Is
> it really that hard to use type classes? I don't think you need any deep
> math to understand how to work with type classes in Haskell. Even if
> they are called "Functor" or "Monad", you don't need to know about
> categories to use them. In fact, any Haskell student faces type classes
> in some point.
>
> In the other hand, I remember that at the beginning somebody showed me
> that "+" sums integers. And eventually, it worked with floats too. He
> called this "overloading" and, presented in that way, type classes
> appeared like something natural in my mind. Can't the same thing been
> done in this case?
>
> Best regards,
> Daniel Díaz.
>
>
> On Fri, Jun 21, 2013 at 11:59 AM, Andrew Butterfield
> <Andrew.Butterfield <at> scss.tcd.ie <mailto:Andrew.Butterfield <at> scss.tcd.ie>>
> wrote:
>
>
>     On 21 Jun 2013, at 10:51, Nikita Volkov wrote:
>
>      > Since there's been so many suggestions concerning radically
>     changing the Prelude recently, I'd like to start a poll on a subject.
>      >
>      > I know that "map" is limited to lists for the beginners, but then
>     we're already making a lot of unbeginnerish changes to Prelude. Also
>     it's not a monad transformer, but just a functor - how can a person
>     learn Haskell without understanding what a Functor is?
>
>
>     !!!! No one needs to know what a functor is in order to learn Haskell.
>     No one needs to know any category theory ideas to learn Haskell.
>
>     Haskell is a very good vehicle to introduce such category-theoretic
>     concepts,
>     and as someone learns Haskell, learning about Haskell classes(*)
>     such as Functor,
>     etc, is very important and useful.
>
>     My main reason for this sudden and abrupt response is that I would
>     be worried if
>     any Prelude re-design was predicated on the idea that Haskell
>     beginners need to understand Functors
>       - they don't, but hopefully they will learn...
>
>
>     (*) as distinct from learning about the category theoretic notion of
>     functor.
>
>      >
>      >
>      >
>      > _______________________________________________
>      > Libraries mailing list
>      > Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
>      > http://www.haskell.org/mailman/listinfo/libraries
>
>     --------------------------------------------------------------------
>     Andrew Butterfield     Tel: +353-1-896-2517     Fax: +353-1-677-2204
>     Lero <at> TCD, Head of Foundations & Methods Research Group
>     Director of Teaching and Learning - Undergraduate,
>     School of Computer Science and Statistics,
>     Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>     http://www.scss.tcd.ie/Andrew.Butterfield/
>     --------------------------------------------------------------------
>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries <at> haskell.org <mailto:Libraries <at> haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
David Luposchainsky | 21 Jun 23:19 2013

Re: Make Prelude's map = fmap

I'm not sure what to think about this. The proposal pretty much boils
down to removing the "f" from "fmap", which is a *very* minor issue.

- Renaming fmap to map will break every single Functor instance so far.

- Defining map = fmap will create two functions with the same name and
functionality. Taken habit away, people will just define fmaps and use
maps. Sounds odd to me, we shouldn't add more DRY than we already have.

- <$> is already a pretty useful alias for fmap. Contrary to the "map"
synonym, it's canonical use is infix, which I would argue is as much
diversity as we could possibly add or need.

Therefore, -1 from my side.

What I'd be willing to go with is deprecating "map" in favour of using
"fmap" everywhere, but my gut tells me others will not like that idea.

David
Dan Doel | 21 Jun 23:26 2013
Picon

Re: Make Prelude's map = fmap

On Fri, Jun 21, 2013 at 4:57 PM, Andreas Abel <andreas.abel <at> ifi.lmu.de> wrote:
Frankly, the proposal text does not make clear what exactly you want to do.

I would guess the name 'fmap' was chosen for 'Functor' because 'map' was already taken for lists.

About 15 years ago (in Haskell 1.4), 'map' was the name of the method of the Functor class. Then it was changed to 'fmap' and the monomorphic 'map' was added.

(Hint: go read the Haskell 1.4 report if you want to see a version of Haskell that is better than the one we have today in a dozen or so ways. :))
 
 So it would make sense to

1. remove Prelude.map
2. make map an alias for fmap

Then, in 50 years from now we can deprecate fmap and remove it in 100 years from now. ;-)

I suspect that is the proposal, although it probably entails getting rid of Data.List.map (and re-exporting the Functor version) as well to not be a significant pain.

It is possible to break some things by doing this, but the corner cases involved ought to be pretty rare.

-- Dan
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Clifford Beshers | 21 Jun 23:28 2013
Picon

Re: Make Prelude's map = fmap

This proposal is always loudly shouted down by teachers and textbook authors who want to keep things simple and consistent.  While I'm sympathetic, I think they've been going about it the wrong way.

I don't care deeply about fmap=map, but I am opposed to preserving the prelude in amber for teaching purposes.

Instead, I believe the teachers need to create their own requirements for a beginner's mode, and that we add long-term support for that with a few widely-published features.

For example:
{-# LANGUAGE BeginnerMode #-}
import BeginnerPrelude

plus a web page at haskell.org that every author could point to that would detail any changes.

Any book could remain relevant simply by updating a page linked to this site with relevant updates.  These might include changes to the BeginnerPrelude as well as current help on transitioning from Beginner to the current full prelude.





On Fri, Jun 21, 2013 at 2:51 AM, Nikita Volkov <nikita.y.volkov <at> gmail.com> wrote:
Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to start a poll on a subject.

I know that "map" is limited to lists for the beginners, but then we're already making a lot of unbeginnerish changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person learn Haskell without understanding what a Functor is?



_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
wren ng thornton | 22 Jun 00:11 2013

Re: Make Prelude's map = fmap

On 6/21/13 5:12 PM, Matthias Kilian wrote:
> On Fri, Jun 21, 2013 at 04:53:49PM -0400, Carter Schonwald wrote:
>> I'd support the map=fmap thing,
>
> Does it cause any consequences for existing libraries and programs?
> Does it break any existing Haskell98 (or Haskell2010) code?
>
> If not: fine. But if yes: please don't do it.

As with the Foldable/Traversable stuff, there's the impediment of ensuring
that list fusion still works right.

This is hopefully a minor issue and can be easily resolved by
inlining/monomorphizing at the appropriate stage; however, it is a
technical issue that needs to be addressed by the time we actually
implement the change.

--

-- 
Live well,
~wren
Edward A Kmett | 22 Jun 01:28 2013
Picon

Re: Make Prelude's map = fmap

Wren gave what I think is the principal potential blocker: if we are to proceed with generalizing map, we
really need to know the practical impact on foldr/build fusion. 

NB: This is also a lingering concern for the Foldable/Traversable generalization.

That said, I do not believe these would be a problem as the RULES involved impact only a single instance, and
these have worked well for me in the past.

Even so, having data would definitely go a long way towards assuaging fears of this sort!

-Edward

On Jun 21, 2013, at 6:11 PM, "wren ng thornton" <wren <at> freegeek.org> wrote:

> On 6/21/13 5:12 PM, Matthias Kilian wrote:
>> On Fri, Jun 21, 2013 at 04:53:49PM -0400, Carter Schonwald wrote:
>>> I'd support the map=fmap thing,
>> 
>> Does it cause any consequences for existing libraries and programs?
>> Does it break any existing Haskell98 (or Haskell2010) code?
>> 
>> If not: fine. But if yes: please don't do it.
> 
> As with the Foldable/Traversable stuff, there's the impediment of ensuring
> that list fusion still works right.
> 
> This is hopefully a minor issue and can be easily resolved by
> inlining/monomorphizing at the appropriate stage; however, it is a
> technical issue that needs to be addressed by the time we actually
> implement the change.
> 
> -- 
> Live well,
> ~wren
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 22 Jun 00:36 2013
Picon

Re: Make Prelude's map = fmap (Nikita Volkov)

+1

I'm in favor of generalizing `map`.  At first I was wary of less monomorphic types, but now I've found that it's not that hard to just lie and pretend the type is more specialized when teaching.  Plus, `map` is a much nicer name than `fmap`.

Since there's been so many suggestions concerning radically changing the Prelude recently, I'd like to start a poll on a subject.
I know that "map" is limited to lists for the beginners, but then we're already making a lot of unbeginnerish changes to Prelude. Also it's not a monad transformer, but just a functor - how can a person learn Haskell without understanding what a Functor is?
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 23 Jun 07:39 2013

Re: Make Prelude's map = fmap (Nikita Volkov)

>>>>> Gabriel Gonzalez <gabriel439 <at> gmail.com> writes:

> I'm in favor of generalizing `map`.  At first I was wary of less monomorphic
> types, but now I've found that it's not that hard to just lie and pretend the
> type is more specialized when teaching.  Plus, `map` is a much nicer name than
> `fmap`.

+1, pending results on how it affects foldr/build fusion.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 23 Jun 19:49 2013
Picon

Re: Make Prelude's map = fmap (Nikita Volkov)


On Fri, 21 Jun 2013, Gabriel Gonzalez wrote:

> +1
> 
> I'm in favor of generalizing `map`.  At first I was wary of less monomorphic types, but now I've found that
> it's not that hard to just lie and pretend the type is more specialized when teaching.  Plus, `map` is a
> much nicer name than `fmap`.

We could also have Functor.map, if people would get familiar with 
qualified imports.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Isaac Dupree | 24 Jun 09:56 2013

Re: Make Prelude's map = fmap

I'm indifferent; I either use List.map, Map.map etc. for explicitness,
or fmap for generality.  I'll keep doing this regardless of what
Prelude.map is.  By the way, not all mappable types can be in Functor,
e.g. Set and ByteString.

-Isaac
Alec | 24 Jun 17:12 2013
Picon

Re: Make Prelude's map = fmap

On Sun, Jun 23, 2013 at 2:20 PM, Nikita Volkov <nikita.y.volkov <at> gmail.com>wrote:
> That's exactly what I am doing now and the very existence of a dozen of
> "prelude" projects on hackage suggests that I'm hardly alone in that.

As the author of one of those projects wherein I rather joyously
pollute the namespace, I still elected not to do the "map = fmap"
thing.  I had two main reasons:

1. fmap (or (<$>)) isn't a terribly onerous thing to type.  (I did end
up exporting (<>), because typing "mappend" is clearly an intolerable
burden.)

2. Code that works with fmap in my prelude will work with fmap without
my prelude.  Changing map means a type error (rather than, at worst,
an unbound identifier) should someone elect not to use my prelude one
day.

While generalizing map doesn't break old code, it makes it somewhat
more annoying to backport new code.

-A

Gmane