August 2006 - Haskell-prime

All Monads are Functors
by Jon Fairbairn 02 Oct '06

02 Oct '06

I find myself dismayed that the mathematical relationship between Monads and Functors isn't available in Haskell98; if I use fmap in a Monad m=>... typed function, I get an extra Functor m required in the context, but not only are all mathematical monads functors, any instance of Monad has fmap in the form (>>= return . f), so it's annoying. There has been discussion in the past about whether Monad should be defined as > class Functor m => Monad m where ... (or some other means of making all Monads instances of Functor) I think the general consensus on the libraries mailing list in this thread http://thread.gmane.org/gmane.comp.lang.haskell.libraries/2815/focus=2815 which refers to this: http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=444 was that it would be a good thing, but it breaks Haskell98 programmes. Surely Haskell' can get this right? On haskell prime I can find http://thread.gmane.org/gmane.comp.lang.haskell.prime/1328/focus=1427 which agrees with me, but I don't see a definite decision either there or in the Trac. I'd favour the above method as most conservative in terms of the language, but I'm not too fussed how it happens. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

11 17

Exceptions
by John Goerzen 06 Sep '06

06 Sep '06

Hello, One thing that bugs me about Haskell is that exceptions are not extensible. I don't know how to craft a good solution, but perhaps if I explain the problem well, someone would come up with one. In a language such as Python or Java, and exception is an object. Let's consider Python for a quick example. Python has an IOError exception. So if I want to write a handler that deals with IOErrors, that's easy enough. Now maybe I want to do something like report socket errors specially. I could define a SocketError class that subclasses IOError. I could take this further, and define a URLError that subclasses SocketError. Now the beauty of it is that I can: * Have a handler that catches URLErrors only and does nothing special with SocketErrors or IOErrors. * Have a handler -- perhaps not even mine -- that catches and works with IOErrors. Since SocketError and URLError are descendants of IOError, that handler will *automatically* work if I raise a SocketError or a URLError. I can see no such mechanism in Haskell. Haskell's I/O exceptions have a certain defined set of errors that they can report, and I can't subclass them and make them more specific for my purposes if I want. Ditto for all the others. The Dynamic exception support is necessary and good to have, but it also under-documented and can be complex. And of course, they still suffer from the same lack of extensibility Are there any suggestions on how we might improve this situation in Haskell? -- John

6 12

Small note regarding the mailing list
by Christophe Poucet 03 Sep '06

03 Sep '06

Hello, Just a small request. Would it be feasible to tag the Haskell-prime list in a similar manner as Haskell-cafe? With regards, Christophe Poucet / vincenz

6 9

Re: map and fmap
by John Hughes 30 Aug '06

30 Aug '06

> > On 8/22/06, John Meacham <john(a)repetae.net> wrote: >> I am not talking about type signatures, I am talking about having to >> annotate in the middle of a term. >> >> f x y | x `member` map g freeVars y = .... >> >> having to become >> >> f x y | x `member` map g (freeVars y :: [Id]) = .... > > There is no need to write such types... In this particular case the > type of 'elem' indicates that the argument is a list. I don't think > that a polymorphic 'map' function requires any more signatures than, > say, '>>='. This certainly is not my experience when I use 'fmap'... > >> So, I am not saying renaming fmap to map is bad outright, I am just >> saying that the question is trickier than just the error message problem >> it was previously stated in terms of. > > Do you have an example illustrating what is tricky about 'fmap'? As > far as I understand 'map' used to be polymorphic, and later the > distinction between 'map' and 'fmap' was specifically introduced to > avoid the error messages that may confuse beginners. > > -Iavor No, map was never overloaded--it was list comprehensions that were overloaded as monad comprehensions in Haskell 1.4. That certainly did lead to problems of exactly the sort John M is describing. As for an example of fmap causing trouble, recall the code I posted last week sometime: class Foldable f where fold :: (a -> a -> a) -> a -> f a -> a instance Foldable [] where fold = foldr example = fold (+) 0 (fmap (+1) (return 2)) Here nothing fixes the type to be lists. When I posted this, someone called it contrived because I wrote return 2 rather than [2], which would have fixed the type of fmap to work over lists. But I don't think this is contrived, except perhaps that I reused return from the Monad class, rather than defining a new collection class with overloaded methods for both creating a singleton collection and folding an operator over a collection. This is a natural thing to do, in my opinion, and it leads directly to this example. John

7 9

Re[6]: All Monads are Functors
by Bulat Ziganshin 28 Aug '06

28 Aug '06

Hello Taral, Tuesday, August 15, 2006, 3:11:37 AM, you wrote: >> > Do we complain about a duplicate instance declarations? >> >> yes. after all, this is just syntax sugar of giving both declarations: > Not necessarily. If A doesn't have any Functor declarations, it could > be considered just a Monad without a Functor. in this case we lose "class Functor a => Monad a" base class declaration. so what will be the meaning of this: class Monad m where instance Functor m return :: ... .... and this: class Monad m where instance Functor m where fmap = return ... return :: ... .... ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

6 9

Re: map and fmap
by John Hughes 23 Aug '06

23 Aug '06

> From: "Iavor Diatchki" <iavor.diatchki(a)gmail.com> > > I know this is not exactly accurate, but for beginners' purposes one > could explain 'Functor' as a container type such as a list or a tree. > Only to students who already know what a (parameterised) list and tree ARE. Introducing both those concepts, and generalising them first over arbitrary element types, and then over the kind of container, is something that will take some time. It's on the way to that point that one needs to be able to talk about and use lists, without encountering Functor even in error messages. > In any case, if one wanted to avoid the issue, it seems entirely > reasonable to define a function 'mapList' that has the list specific > type. Most classes probably do this anyway. That would be the alternative, but I doubt whether any classes do that right now. What's the point, when map already does the job? > From: Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> > > A reasonable choice (forestalling the objection that using > List.map, listMap or mapList would be too distracting for > students) would be > > lmap:: (t -> t') -> [t] -> [t'] > map:: Functor f => (t -> t') -> f t -> f t' > I'd prefer mapList to lmap, to be honest--at least the connection between the name and the type is clear. But remember, this would at a stroke make Haskell' incompatible with all existing Haskell textbooks. Even if publishers brought out new editions, even if we told students to buy them, there are many, many second hand books in circulation, and it would be years before one could rely on students having Haskell' books. All that time, students would write map instead of mapList because that's what the book says, and get stuck with incomprehensible error messages. Is it really worth an incompatible change in the library functions used by all beginners, just to rename fmap to map? It seems to me that the gain from a change is very small, and the cost considerable. John

6 13

Re: map and fmap
by John Hughes 18 Aug '06

18 Aug '06

From: Robert Dockins <robdockins(a)fastmail.fm> 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')? I have a lot of experience of teaching beginners--I've been doing it for years, and have seen the effects of introducing functional programming at various stages in the curriculum, and in various ways. That's given me a strong desire to ensure there is an easy learning path into Haskell. One thing I've observed repeatedly is that many students in later years, who learned functional programming early, have a strong impression that functional languages are only suitable for toy programs. Of course, that's because in their first courses they only SAW toy programs. But perhaps, they also moved on to Java as soon as they started to build GUIs, and as a result have the impression that you CAN'T build a GUI in the functional language they learned first. This is a very negative impression for students to have, and one that is hard to combat because beginning undergraduates are sceptical to functional languages from the word go: they "know" they really want to learn C++ or Java, and wonder initially what we're playing at. I combat that--successfully--by showing them early on that Haskell *is* a "real" programming language, in which one can build real applications. I tell them about darcs, or whatever new application is hot at the time. I show them how to build a GUI in wxHaskell--in the fifth week of their university studies. I want them to be frustrated at how difficult GUI programming is when they do it in Java (:-)! It works--some find it very hard, but many of the good students go much further than my lectures and exercises, and reappear in the third and fourth years as very expert and enthusiastic Haskell programmers. Now, this approach couldn't work if the language I taught really WAS only suitable for toy programs! Even a "beginner's prelude" would introduce a discontinuity for students, making it harder to take the step from course exercises to real programs, and that would mean that fewer of my students would end up as Haskell enthusiasts. I'd be very sad about that. On the specific point of map vs. fmap, it's true that similar difficulties DO arise for numeric literals, and a partial solution is to tell students to write type signatures at the beginning. However, this isn't a complete solution, because students still see plenty of class constraints in error messages, and they need to understand them sufficiently well to fix their errors. It's not too hard to explain that "Num a" means that a should be a numeric type--Integer, Double, i.e. a type they are familiar with. It's much harder to explain what "Functor f" means to a student who's still struggling to keep in mind the difference not just between a type and a class, but between a type and a value. The fact that f is a type constructor, and not a familiar type, is an additional obstacle. That makes overloading list operations much more of an obstacle for beginners, than overloading numeric operations is. The other thing to remember is that, even when students write type signatures, overloading ambiguities may still arise within their definitions. This is not usually much a problem for numeric types, because they are defaulted to Integer or Double. Making overloaded list operations easy to use for beginners would, I suspect, require defaulting rules for other classes--defaulting Functor and Monad to lists, for example. This is a whole new can of worms. John

3 4

map and fmap
by Iavor Diatchki 17 Aug '06

17 Aug '06

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

6 5

do and if then else (Ticket 23)
by Jon Fairbairn 16 Aug '06

16 Aug '06

This seems like a good idea, but if it's adopted, I'd argue that the same thing should be done to case, for consistency. I like to lay out case like this: case whatever of blah -> bluh blah' -> bluh' and that also breaks under do. case exp1 [;] of ... would solve this. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

1 0

[pupeno@pupeno.com: Binary IO]
by dons＠cse.unsw.edu.au 15 Aug '06

15 Aug '06

While we're thinking a little about the libraries, I received the following: ----- Forwarded message from Pupeno <pupeno(a)pupeno.com> ----- Date: Tue, 8 Aug 2006 07:44:04 +0000 Subject: Binary IO Hello, I've seen that you have been assigned the task of evaluating binary IO for inclusion in Haskell: http://hackage.haskell.org/trac/haskell-prime/ticket/15 I just want to express that I really would like to see this. I was coding a DNS server in Haskell and the main reason I stopped was because binary IO was very, very painful (so many different library, or half libraries, whenever I was using one it seemed to be the wrong one). Thank you. Pupeno <pupeno(a)pupeno.com> (http://pupeno.com) ----- End forwarded message -----

2 1