Hello, I never liked the decision to rename 'map' to 'fmap', because it introduces two different names for the same thing (and I find the name `fmap' awkward). As far as I understand, this was done to make it easier to learn Haskell, by turning errors like "Cannot discharge constraint 'Functor X'" into "X =/= List". I am not convinced that this motivation is justified, although I admit that I have very limited experience with teaching functional programming to complete beginners. Still, students probably run into similar problems with overloaded literals, and I think, that a better approach to problems like these would be to have a simplified "learning Prelude" for the beginners class, rather than changing the standard libraries of the language (writing type signatures probably also helps...) Renaming 'fmap' to 'map' directly would probably break quite a bit of code, as all instances would have to change (although it worked when it was done the other way around, but there probably were fewer Haskell programs then?). We could work around this by slowly phasing out 'fmap': for some time we could have both 'map' and 'fmap' to the 'Functor' class, with default definitions in terms of each other. A comment in the documentation would say that 'fmap' is deprecated. At some point, we could move 'fmap' out of the functor class, and even later we could completely remove it. This is not a big deal, but I thought I'd mention it, if we are considering small changes to the standard libraries. -Iavor
On 2006-08-14 at 12:00PDT "Iavor Diatchki" wrote:
Hello, I never liked the decision to rename 'map' to 'fmap', because it introduces two different names for the same thing (and I find the name `fmap' awkward).
I strongly concur. There are far too many maps even without that, and having two names for the same thing adds to the confusion.
As far as I understand, this was done to make it easier to learn Haskell, by turning errors like "Cannot discharge constraint 'Functor X'" into "X =/= List". I am not convinced that this motivation is justified, although I admit that I have very limited experience with teaching functional programming to complete beginners. Still, students probably run into similar problems with overloaded literals, and I think, that a better approach to problems like these would be to have a simplified "learning Prelude"
Agreed. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
On Mon, 2006-08-14 at 20:55 +0100, Jon Fairbairn wrote:
On 2006-08-14 at 12:00PDT "Iavor Diatchki" wrote:
Hello, I never liked the decision to rename 'map' to 'fmap', because it introduces two different names for the same thing (and I find the name `fmap' awkward).
I strongly concur. There are far too many maps even without that, and having two names for the same thing adds to the confusion.
If it goes in that direction it'd be nice to consider the issue of structures which cannot support a polymorphic map. Of course such specialised containers (eg unboxed arrays or strings) are not functors but they are still useful containers with a sensible notion of map. The proposals to allow this involve MPTCs where the element type is a parameter. That allows instances which are polymorphic in the element type or instances which constrain it. Duncan
Hello Duncan, Tuesday, August 15, 2006, 2:37:50 AM, you wrote:
If it goes in that direction it'd be nice to consider the issue of structures which cannot support a polymorphic map. Of course such specialised containers (eg unboxed arrays or strings) are not functors but they are still useful containers with a sensible notion of map.
unboxed arrays - not if you using implementation from ArrayRef lib ByteStrings - can be also parameterized by its type elements, as i always suggested. of course, these elements should be unboxable and belong to the Storable class in order to allow peek/poke them there is also faking solution: type ByteStr a = ByteString instance Functor ByteStr (although i never tested it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Aug 14, 2006, at 3:00 PM, Iavor Diatchki wrote:
Hello, I never liked the decision to rename 'map' to 'fmap', because it introduces two different names for the same thing (and I find the name `fmap' awkward).
As far as I understand, this was done to make it easier to learn Haskell, by turning errors like "Cannot discharge constraint 'Functor X'" into "X =/= List". I am not convinced that this motivation is justified, although I admit that I have very limited experience with teaching functional programming to complete beginners. Still, students probably run into similar problems with overloaded literals, and I think, that a better approach to problems like these would be to have a simplified "learning Prelude" for the beginners class, rather than changing the standard libraries of the language (writing type signatures probably also helps...)
This idea has been kicked around a few times, but, AFAIK, it's never really been fleshed out. Has anyone ever put anything concrete on the table? It seems to me that most complaints are about hard-to- understand error messages, and these almost always arise from typeclasses. They are especially confusing when they arise from syntax sugar. I suppose a prelude with no typeclasses and compiler options to make all syntax non-overloaded would be one way to start. On a related note, I've seen a number of Haskell design decisions justified by the "beginners find it difficult" argument. Is this argument really valid? Is there any reason not to just tell beginners to use Helium? Is there a case for something between Helium and full H98 (or H')?
Renaming 'fmap' to 'map' directly would probably break quite a bit of code, as all instances would have to change (although it worked when it was done the other way around, but there probably were fewer Haskell programs then?). We could work around this by slowly phasing out 'fmap': for some time we could have both 'map' and 'fmap' to the 'Functor' class, with default definitions in terms of each other. A comment in the documentation would say that 'fmap' is deprecated. At some point, we could move 'fmap' out of the functor class, and even later we could completely remove it.
This is not a big deal, but I thought I'd mention it, if we are considering small changes to the standard libraries.
-Iavor
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
On Mon, Aug 14, 2006 at 12:00:25PM -0700, Iavor Diatchki wrote:
As far as I understand, this was done to make it easier to learn Haskell, by turning errors like "Cannot discharge constraint 'Functor X'" into "X =/= List". I am not convinced that this motivation is justified, although I admit that I have very limited experience with teaching functional programming to complete beginners.
I think it is more because if you make too many things overloadable, you get ambiguity problems. Having to annotate a bunch of terms with type signatures is really anoying. Still,
students probably run into similar problems with overloaded literals, and I think, that a better approach to problems like these would be to have a simplified "learning Prelude" for the beginners class, rather than changing the standard libraries of the language (writing type signatures probably also helps...)
I don't like the idea of a learning prelude. people should teach the language outright otherwise students will end up confused. Better error messages for compilers is the correct solution, not a watered down version of the language. Once at caltech, they tried this experiment where they took the beginning programming course taught in C, and changed it to use 'java junior' a version of java for teaching, it was an absolute disaster. the students ended up not being able to program in java and not learning the basics of computer architecture that learning C gives you (as well as the ability to program in C) and generally being quite upset. IMHO everyone should know both C and Haskell fluently. there is no point dawdling in between the extremes. :) John -- John Meacham - ⑆repetae.net⑆john⑈
participants (6)
-
Bulat Ziganshin -
Duncan Coutts -
Iavor Diatchki -
John Meacham -
Jon Fairbairn -
Robert Dockins