[OT] Teaching Haskell in High School
Hi all, Before getting in to this, let me preface my question(s) with a note that I have checked through the Haskell in Education web page and have found various links off there of interest (and I've googled, etc. In short: I've done my homework). That said, I've been in rather close correspondence with my math/computer science teacher from high school. When I first took CS there, they taught Pascal (a year early they had been teaching Scheme). They switched over to VB (alas) recently and have been teaching that for a few years now. The teacher really wants to get away from VB, but is having a somewhat difficult time deciding what to go to. The two most promising options are Haskell and Java. Aside from hype, etc., the primary advantage to Java is that the Advanced Placement (AP) tests are in Java. For those of you unfamiliar with these, high school students can take AP tests and then (typically) skip out of first semester college courses. They're essentially proficiency exams. The way the computer science curriculum is set up at my old school is essentially as either (a) an elective or (b) a replacement for senior year math. The students in the course are usually about 2/3 juniors (16 year olds) taking it as an elective and 1/3 seniors who want to get our of senior year math :). Either way, they've both taken differential calculus, algebra, etc. Note, however, that high school math in the states is very rudimentary when it comes to things like "induction" and "proofs" and things of this sort. Due to the fact that CS is essentially an alternative math course, I think it would be interesting to teach Haskell. It would enable the instruction of things the students wouldn't have come across in their ordinary math studies, etc. However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Given that this would in large part be a first language for them and that they won't have a college-level math background, do you think it would be too much to attempt to teach Haskell at this level, and stick with Java? I'm really interested in any comments/experience/etc. that people have that might assist the teacher (and, to some extent, me) make this decision. Thanks in advance! - Hal
On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote:
[...]
However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach).
Hi, I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell. Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: "No."
[...]
Wolfgang
I had the good fortune to teach Haskell to some thousand freshmen a few years ago, and noticed that some who did especially well had no previous programming experience. This supports Wolfgang Jeltsch's claim that Haskell is not inherently difficult to learn. I've taught similar numbers of students C++, and I find Haskell considerably easier to teach (and much easier on the conscience!). Freshmen innocent of programming experience are increasingly rare, however, so we have to deal mainly with students who've been trained to think not only imperatively but operationally. Their weak program-design skills, and their meager understanding of the excessively complicated languages they're using (C++, Java, ...), result in marathon debugging sessions, which they're been trained to accept as a normal part of software development. How such students respond to Haskell depends heavily on their attitude. Some feel lost without a debugger, and resist any nudge away from their operational thinking. The more open-minded students, on the other hand, recognize in Haskell a means of expressing computational ideas with far more economy than they are used to, and report that learning Haskell has improved their thinking about programming even if they never use Haskell again. Whether Haskell would be a good language for a high-school programming class (this thread's original question) depends on the class's goals. If it's intended as vocational training, i.e., direct preparation for employment, then some language more fashionable in industry would probably be appropriate. On the other hand, if it's intended as training in precise thinking, then Haskell can't be beat. Best, --Ham At 3:03 AM +0100 2/4/03, Wolfgang Jeltsch wrote:
On Tuesday, 2003-02-04, 01:01, CET, Hal Daume wrote:
[...]
However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach).
Hi,
I wouldn't claim that Haskell is very difficult to learn. I think, people often have problems with learning Haskell because they know imperative programming and try to apply their imperative thinking to programming in Haskell.
Some months ago, a first year student told me that she liked Haskell very much and that she didn't find it very difficult. I asked her if she had had experiences with other programming languages before learning Haskell. She answered: "No."
[...]
Wolfgang
-- ------------------------------------------------------------------ Hamilton Richards Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu hrichrds@swbell.net ------------------------------------------------------------------
I've also been working high school students a bit and functional programming is a great way to teach the principals of computation. The best results come when FP is applied to domains that get kids excited. I've had very good luck with Haskore as an excellent way to bring computation to a general audience. I'm also working on a student friendly version of Pan that should be releasable in a few more weeks. The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems. But even so with a little supervision everything works quite well. I think fundamentals of computing as found in Haskell are good for a general mathematics class as opposed to a "computer" class where you have to deal with curriculum defined by the AP test or intertwined with some specific software environment. John
John Peterson wrote:
The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems.
For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect. I've found myself look at a program with a comparable problem as the one below for fifteen minutes until I saw what was happening (please look at the program with a non-proportional font like Courier for optimal confusion): filterr :: (a -> Bool) -> [a] -> [a] filterr p [] = [] fi1terr p (x:xs) = if p x then x : filterr p xs else filterr p xs Hugs, which we used for teaching, doesn't say a word. GHC does if you helpful warnings if you pass the -Wall flag. Helium says: (2,9): Variable "p" is not used (3,1): Missing type signature: fi1terr :: (a -> Bool) -> [a] -> [a] (3,1): Suspicious adjacent functions "fi1terr" and "filterr" I'm curious what the other "gotcha's" are that John refers to because it might give us inspiration for more warnings/language design decisions. Arjan http://www.cs.uu.nl/~afie/helium/
For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect.
I'm curious what the other "gotcha's" are that John refers to because it might give us inspiration for more warnings/language design decisions.
I've been negligent in not playing with Helium yet - I'm sure that this sort of system is going to be a significant improvement for this sort of audience. I'm also hoping that Helium can be adapted into other problem domains which use typed functional languages. As far as language gotchas, the issue is much more in the way the programming environment responds to a problem than in the language design. If a system can generate a sensible response / suggestion when a student makes an error then I don't think there's any particular problem. Another issue is in how the material is presented - I think this makes a big difference in what errors a student is likely to encounter. When you teach in a slow, constructive manner I think you're less likely to encounter problems than in my case, where I was teaching from a mathematics perspective and asking students to transcribe their mathematical ideas directly into Haskell and hope that they work. Notationally, there were three problems that hit students hard and generated error messages that had nothing to do with their mistake. The numeric syntax requires digits on both sides of a decimal. Mistakes like a = .2 were extremely common. Unary minus was also a big problem - I "solved" this by requiring all negative number to be wrapped in parens. The varid / conid stuff also was a problem - it was hard to explain why a = 1 is OK and A = 1 isn't. This definitely was a problem with going straight into programming from math. There were a lot of problems with type errors. The numeric type classes pop up unexpectedly in error messages, rendering them cryptic. Monomorphism also caused some problems but as I recall it was the old Hugs that didn't handle monomorphism quite right anyway. Debugging was a serious problem - we basicly gave up on that. Since the programs were fairly short I could usually spot bugs fairly easily but I couldn't get students to do this on their own. Sorry if this isn't very precise - it's been a while. John
John Peterson wrote:
The downside of Haskell is that none of the regular implementations (ghc, hugs) are really right for this level of student. Type inference is an especially nasty problem. There also a number of gotcha's lurking in the language that cause problems.
For exactly these reasons we have implemented Helium; not for replacing Haskell (we're very happy with Haskell), but for *learning* Haskell. There is no overloading, so types and type errors are easier to understand. The Helium compiler produces warnings for situations that are probably incorrect. I've found myself look at a program with a comparable problem as the one below for fifteen minutes until I saw what was happening (please look at the program with a non-proportional font like Courier for optimal confusion): filterr :: (a -> Bool) -> [a] -> [a] filterr p [] = [] fi1terr p (x:xs) = if p x then x : filterr p xs else filterr p xs Hugs, which we used for teaching, doesn't say a word. GHC does give helpful warnings if you pass the -Wall flag. Helium says: (2,9): Variable "p" is not used (3,1): Missing type signature: fi1terr :: (a -> Bool) -> [a] -> [a] (3,1): Suspicious adjacent functions "fi1terr" and "filterr" I'm curious what the other "gotcha's" are that John refers to because it might give us inspiration for more warnings/language design decisions. Arjan http://www.cs.uu.nl/~afie/helium/
"Hal" == Hal Daume, <Hal> writes:
Hal> Hi all, Hal> Before getting in to this, let me preface my question(s) with a note that Hal> I have checked through the Haskell in Education web page and have found Hal> various links off there of interest (and I've googled, etc. In Hal> short: I've done my homework). Hal> That said, I've been in rather close correspondence with my math/computer Hal> science teacher from high school. When I first took CS there, they taught Hal> Pascal (a year early they had been teaching Scheme). They switched over Hal> to VB (alas) recently and have been teaching that for a few years now. Hal> The teacher really wants to get away from VB, but is having a somewhat Hal> difficult time deciding what to go to. The two most promising options are Hal> Haskell and Java. I really recommend looking at the TeachScheme! curriculum and the How to Design Programs curriculum. Here are two URLs: http://www.teach-scheme.org/ http://www.htdp.org/ This works exceptionally well at the High School level (I know that earlier attempts to do this with Scheme failed---this one is very different), and has been extensively applied with great success---also and especially in conjunction with the AP curriculum and/or a course on Java based on the same methodology. There's a wealth of software and material, and the TeachScheme! program offers (mostly free) workshops on this. Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla
I can't resist jumping in on this one:
Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme.
I have spent many years teaching both Scheme and Haskell to beginners, and I would have to say that Haskell syntax has never been a serious problem, certainly no more than Scheme's parentheses. It is true that there is a lack of good programming environments, although Hugs is pretty easy to use, and things like Helium should be even better. (I won't say much about textbooks since I wrote one that I think is pretty good for beginners :-) Finally, aside from extraneous type error messages (which Helium should do much better at), I claim that Haskell's type system is BETTER for beginners compared to having no type system at all. As for the last point above, I could just as easily say that Scheme is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Haskell. Now, having said all this, I will add that I have the greatest respect for the TeachScheme project, and I wish that we had something as well developed for Haskell! -Paul
"Paul" == Paul Hudak <paul.hudak@yale.edu> writes:
Paul> I can't resist jumping in on this one: Sure :-)
Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme.
Paul> I have spent many years teaching both Scheme and Haskell to beginners, Paul> and I would have to say that Haskell syntax has never been a serious Paul> problem, certainly no more than Scheme's parentheses. It is true that Paul> there is a lack of good programming environments, although Hugs is Paul> pretty easy to use, and things like Helium should be even better. (I Paul> won't say much about textbooks since I wrote one that I think is pretty Paul> good for beginners :-) Finally, aside from extraneous type error Paul> messages (which Helium should do much better at), I claim that Haskell's Paul> type system is BETTER for beginners compared to having no type system at Paul> all. As for the last point above, I could just as easily say that Paul> Scheme is very easy to learn (and an excellent choice for a 2nd or 3rd Paul> language) when you know Haskell. Here are some observations I've made when teaching Haskell for the first time which are relevant when you're trying them out on beginners: - With the programming environment, it isn't just a question of being "easier to use": in my experience, environments like Hugs (or any Scheme environment other than DrScheme) work for some, but frustrate many beginners because they don't enable them to fix trivial mistakes which they're bound to make in the first couple of weeks. These are *crucial* to the overall success of an intro course. The TeachScheme! folks had to work a long time on getting DrScheme to provide the feedback needed to alleviate this problem. Haskell systems just don't have this kind of investment. (I'm glad Helium showed up, and I'm sure to try it out soon.) - In theory, static typing is good because it helps spot bugs in your program early. However, the current state of the art is such that the type error messages in Haskell systems are not sufficiently helpful (in fact, often misleading) when it comes to finding the actual source of the problem. You're saying "aside from extraneous type error messages"---but these are *exactly* the problem. Certainly, the messages from Hugs and GHC often frustrate beginners (and not just beginners in programming---I've seen quite a few students who were learning Haskell as a 3rd or 4th language give up because of this). Again, Helium may be an improvement, but I suspect that the underlying problem is deeply rooted. - I've written between 10000 and 100000 lines of code in Haskell, and I still do things like: - look up syntax in a book - getting the alignment wrong - using a name twice in a recursive let, leading to infinite recursion Scheme syntax is just *way* smaller than Haskell syntax, and, while it may not constitute a serious problem in any given course, it certainly eats up less space when you explain it. Here are some other aspects of Haskell syntax which---in my experience---are confusing for beginners: - The syntax for ordinary variables and type variables are the same. In fact, many examples by Great Haskell Programmers use a variable "s" (for instance) to denote a value of type "s". Beginners often have trouble understanding and distinguishing the concepts of variables and type variables, and this makes it worse. - The same holds generally for the type syntax which is analogous to the value syntax. - I don't know what kind of beginners you're talking about exactly. The original poster was asking about high school. With *CS* beginners (or beginners in some related field) different rules apply than for the average population. If these kids have problems early on, they're just bound to leave programming and never come back (or much later). I'm sure some of you have didactic concepts to get around these problems---but, as you mention, they sure aren't published anywhere, much less in a comprehensive form as HtDP, and the tools don't exist with the same quality as DrScheme. There's much more to say---about things like motivating examples with GUIs and web servers---which DrScheme has in a form accessible to beginners, but you can all read up on that in the TeachScheme! material. Haskell has great potential to be a wonderful and useful language for software development and research. It often pains me to see the efforts of the functional programming community (which is small enough as it is) fragmented by the "My language is the best for *everything*" attitude. For intro teaching, the TeachScheme! have *done* so much work on teaching functional programming not available for Haskell, and I wish the Haskell (and ML and ...) community would just reap the benefits rather than doing the usual NIH thing. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla
Hello all, Michael Sperber wrote:
- With the programming environment, it isn't just a question of being "easier to use": in my experience, environments like Hugs (or any Scheme environment other than DrScheme) work for some, but frustrate many beginners because they don't enable them to fix trivial mistakes which they're bound to make in the first couple of weeks.
I completely agree. I've downloaded and installed DrScheme and I must say the environment is really nice: it looks good, helps you to layout your program, matches parentheses and so on. The quality of the messages, however, is not as good as I would have expected. I am a beginning Scheme programmer and here's something I encountered:
(define (length2 xs) (cond [(empty? xs) 0] [else (+1 (length2 (rest xs)))])) (length2 (cons 3 (cons 7 empty))) procedure application: expected procedure, given: 1; arguments were: 1
The definition is accepted but when use it I get an error I don't understand. I should note that the environment neatly indicates that (+1 (length2 (rest xs))) is the problem. I've browsed the documentation, found a definition of length and saw that the only difference was a space character between + and 1. That couldn't be it, could it? But it was. Apparently Scheme supports a unary plus, but still the message was wrong and should have read: procedure application: expected procedure, given: +1; arguments were: 1 I think it is important that error messages show exactly what was entered by the user (+1 and not 1) and that's why in Helium we remember each little detail in the abstract syntax tree. I still don't know what "arguments were: 1" means. Does it refer to the number of arguments?
The TeachScheme! folks had to work a long time on getting DrScheme to provide the feedback needed to alleviate this problem.
That's a really good point. We should look at the errors students actually make and not at the errors we make or just make an educated guess. For that reason, Helium has a logging facility built in which sends a server the programs containing errors. This wealth of information can now be used to give hints for type errors that occur often and to improve other kinds of errors. [Don't worry, the version distributed via the web does not contain the logging facility; only the version in our labs has that piece of code compiled in].
- In theory, static typing is good because it helps spot bugs in your program early. However, the current state of the art is such that the type error messages in Haskell systems are not sufficiently helpful (in fact, often misleading) when it comes to finding the actual source of the problem.
True. I've also seen people being disappointed in the language Haskell because of the message of the compiler/interpreter. But then I wondered: how can dynamic typing improve on this? So I made a type error in my length2 example:
(define (length2 xs) (cond [(empty? xs) 0] [else (+ 1 (rest xs))])) (length2 (cons 2 empty)) +: expects type <number> as 2nd argument, given: empty; other arguments were: 1
Perfect. I know immediately what the problem is and I can fix it. [The fact that a type error only shows up when you actually reach to code is a pity, because you may submit a lab assignment that still somewhere tries to add a number to a list.] But how is this different from the Helium message: (2,20): Type error in infix application *** Expression : 1 + xs *** Term : xs *** Type : [a] *** Does not match : Int It contains exactly the same information; invisible to the user for now is that we also now where the expresion ends so that we can do highlighting in the future. Maybe Michael is referring to what Hugs says about this program: ERROR "C:\docs\Bla.hs":1 - Illegal Haskell 98 class constraint in inferred type *** Expression : mylength2 *** Type : Num [a] => [a] -> [a] Wrong line number and a very confusing message. We must keep in mind though that no Haskell compiler so far was designed primarily with helpful messages in mind.
Again, Helium may be an improvement, but I suspect that the underlying problem is deeply rooted.
The underlying problem may be the inference algorithm used in most compilers. We use a radically different approach which allows us to determine much more information and point at different origins of the error when compared to Hindley Milner based inferencing. If there are three uses of a variable as a Bool and one as an Int we can say that probably the Int usage is wrong.
- The syntax for ordinary variables and type variables are the same.
That's just how you teach it. You can 'raise' hords of students believing that type variables are always called a, b and c and normal variables use longer, more informative names. As Larry Wall put it: "you can write assembly in any language".
- The same holds generally for the type syntax which is analogous to the value syntax.
I use different colours in my lectures and a really cool, parsing programming environment could do that, too.
I wish the Haskell (and ML and ...) community would just reap the benefits rather than doing the usual NIH thing.
Good point, but there are fundamental differences between Scheme and Haskell and our whole teaching here in Utrecht is heavily geared towards Haskell: we really need laziness to write our parsers and our attribute grammars, we believe that static typing is the way to go for more robust software, we think that algebraic data types are a great way to model data and so on. The whole curriculum is based on those needs and beliefs and switching to DrScheme because there is a wonderful environment out there is no option. The Scheme people cannot convince me to use Scheme and I can't convince the Scheme people to use Haskell. And I honestly think that that is *no problem*. I let myself be inspired by DrScheme and maybe DrScheme can learn some tricks from Helium in the future. And maybe by doing that we can make this world a little better :-) Cheers, Arjan
Hello again, Kevin suggested:
Then you should have set the language to "Beginning Student" or "Beginning Student with List Abbreviations".
You're right. That makes the messages much better. I switched to 'Advanced' level because I thought that something was possibly not accepted because it was too difficult. My fault. Wolfgang asked:
[...logging facility in Helium...] Do you tell your students about the existence of this facility?
We certainly do. They don't seem to mind; I even feel that they think it's nice to help research.
I just have had a look at Helium and think that at least a deriving mechanism is absolutely needed.
There is 'show' function for each data type you write down. Eq and Ord are not generated but we will do that; we will need it anyway for our simple class system.
Furthermore, I think, the need to state equality functions explicitely as paramters of certain functions makes learning harder and not easier.
I don't know. Could be. We'll probably provide two different Preludes, one with and one without overloading. This would compare to the language levels in DrScheme. A lot is possible in this area.
But it's an interesting project. Keep going on it.
Don't worry. We just started... Cheers, Arjan
"Arjan" == Arjan van IJzendoorn <afie@cs.uu.nl> writes:
Arjan> Good point, but there are fundamental differences between Arjan> Scheme and Haskell and our whole teaching here in Utrecht is Arjan> heavily geared towards Haskell: we really need laziness to Arjan> write our parsers and our attribute grammars, This seems like a backwards way of approaching teaching the intro course. (Besides, is this really suitable material for beginners, let alone high school students?) It's the common method to specify "We must do this, that, and this in the intro course" and work backwards towards the didactics. I once was a strong proponent of the same method, but I came to realize that it's necessary to abandon stuff that I don't know how to teach well to beginners. I now have a poster in my apartment saying "Kill your darlings." (A Faulkner quote, for those who must know.) This is what differentiates HtDP from all other intro curriculi I've seen: it *really* isn't about Scheme, and *nothing* is "heavily geared" towards Scheme. It's about programming and problem solving, and it prepares you for learning the language you need to know to produce software. (In fact, even if you want to produce actual software in Scheme, you'd be expected to take another course after HtDP.) Arjan> we believe that static typing is the way to go for more robust Arjan> software, we think that algebraic data types are a great way to Arjan> model data and so on. Sure. But you'll notice that HtDP *does* use a completely type-centric approach to teaching, along with algebraic data types. And the fact that you would like to apply Haskell to professional software engineering and believe static types are "the way to go" there says nothing about the suitability of Haskell for intro teaching. Teach them Haskell, by all means. Helium seems to be a great effort directed at that, and I'm glad *someone* in the community finally caught on to the problems you're solving. But if you want Haskell to be as broadly applicable to intro teaching for non-CS majors as HtDP/TeachScheme!, you have a long way to go. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla
Michael Sperber writes:
This seems like a backwards way of approaching teaching the intro course.
I like to look at it as a a track.
(Besides, is this really suitable material for beginners, let alone high school students?)
Ah, there's the catch. They are not beginners; they are CS students who already learned about Java. When it comes to other disciplines and high school students you're right that TeachScheme is ahead of us and we know we have a long way to go. Cheers, Arjan
Hello all, Michael Sperber wrote:
I really recommend looking at the TeachScheme! curriculum and the How to Design Programs curriculum. Here are two URLs:
I believe that the environment students work in is very important and can help them learn languages quicker. And so the TeachScheme programming environment is something I'm jealous of and my compliments to the people who made it. Here in Utrecht we will try to do the same for Haskell with Helium: a cool programming environment and the best compiler messages ever (we still have some tricks up our sleeve for the near future).
I've looked at the PPT presentation and it looks like a fine commercial for functional programming. It could easily be adapted to Haskell and the syntax would be even closer to their mathematical definitions. But I don't want to argue about syntax, because that will not get us anywhere. Let the people who love Haskell try and make an environment (and by that I also include books, presentations and what not) that will make functional programming nice to learn, maybe even in high school. We will do our bit here with Helium so that the Haskell textbooks can be used with Helium. Yes, that does mean adding type classes, but not the whole machinery. If we support Eq, Ord, Show and Num with a limited number of instances, chapters 1 to 11 of Hudak's book can be used without modification. And importantly, the type errors can still be clear! No "Cannot find Num instance of Char" for the expression "1+'a'" but "The character 'a' is not a number and + expects one" (or something along that line). Oh yes, we'll need SOEGraphics, too, but who knows... If we think Haskell is good for high schools and for using in other courses (like logic and so on), let's try and prove it! Kind regards, Arjan van IJzendoorn PS: What does [OT] stand for? Off topic? I don't think this is off topic.
On Friday, 2003-02-07, 12:31, CET, Arjan van IJzendoorn wrote:
[...] Yes, that does mean adding type classes, but not the whole machinery. If we support Eq, Ord, Show and Num with a limited number of instances, chapters 1 to 11 of Hudak's book can be used without modification.
I just have had a look at Helium and think that at least a deriving mechanism is absolutely needed. The need to write down obvious implementations for equality is very disturbing, IMHO. Furthermore, I think, the need to state equality functions explicitely as paramters of certain functions makes learning harder and not easier. But it's an interesting project. Keep going on it.
[...]
Wolfgang
participants (7)
-
Arjan van IJzendoorn -
Hal Daume III -
Hamilton Richards -
John Peterson -
Paul Hudak -
sperber＠informatik.uni-tuebingen.de -
Wolfgang Jeltsch