Hello everyone, I teach Haskell to our first-year students and I find that Haskell's syntax is confusing to many. Some examples: (1) You define data types with vertical bars (|) but in the world of expressions vertical bars (i.e. guards) are exactly what you can not use to discriminate between constructors. (2) Pattern-matching and guards are very often mixed up. Both are used for making choices and they overlap somewhat but not completely in expression power. For learning a language it would be nice if one construct did it all, guards including pattern guards maybe. (3) Types and expressions look very much alike. Say we have: data Tree a = Bin (Tree a) a (Tree a) | Nil. Around half (!) of the students now write (on a written test): size (Bin (Tree left) x (Tree right)) = ... mixing up the two worlds completely. Do other teachers have the same experience? Regards, Arjan
(3) Types and expressions look very much alike. Say we have: data Tree a = Bin (Tree a) a (Tree a) | Nil.
I encourage my students to always use named record notation data Tree a = Bin { left :: Tree a, ... }
Around half (!) of the students now write (on a written test): size (Bin (Tree left) x (Tree right)) = ...
sure they had this in their mind: size (Bin ( left :: Tree a ) ( x :: a ) ( right :: Tree a )) = ... (i. e. they wanted to specify the types of formal parameters at the most natural place - at their first appearance in the text) I think the following is conceptually cleaner size ( t @ Bin { } ) = let l = left t r = right t in size l + 1 + size r (it separates matching and binding) altough the first line looks rather cryptic. NB: I wouldn't mind the language enforcing the students ( and me ) to write size ( t @ Bin { } :: Tree a ) = let l :: Tree a = left t r :: Tree a = right t in size l + 1 + size r Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
Of these I think that (3) is most serious. What I do is tell students that a data type declaration such as: data Tree a = Bin (Tree a) a (Tree a) | Nil is really a kind of shorthand for: data Tree a where Bin :: Tree a -> a -> Tree a -> Tree a Nil :: Tree a which better separates the worlds of types and terms (and happens to look like a type class declaration). Hope this helps, -Paul Arjan van IJzendoorn wrote:
Hello everyone,
I teach Haskell to our first-year students and I find that Haskell's syntax is confusing to many. Some examples:
(1) You define data types with vertical bars (|) but in the world of expressions vertical bars (i.e. guards) are exactly what you can not use to discriminate between constructors.
(2) Pattern-matching and guards are very often mixed up. Both are used for making choices and they overlap somewhat but not completely in expression power. For learning a language it would be nice if one construct did it all, guards including pattern guards maybe.
(3) Types and expressions look very much alike. Say we have: data Tree a = Bin (Tree a) a (Tree a) | Nil. Around half (!) of the students now write (on a written test): size (Bin (Tree left) x (Tree right)) = ... mixing up the two worlds completely.
Do other teachers have the same experience?
Regards, Arjan
Hello Paul,
Of these I think that (3) is most serious. What I do is tell students that a data type declaration such as:
data Tree a = Bin (Tree a) a (Tree a) | Nil
is really a kind of shorthand for:
data Tree a where Bin :: Tree a -> a -> Tree a -> Tree a Nil :: Tree a
I like this. And it solves both (3) and (1) (because the bars are gone). Thanks, Arjan
Hi all, I'd like to have a better way for "showing" a list of things, e.g. show (f1 t) ++ show (f2 t) ++ show (f3 t) ++ .... I would love to just write: (f1 # f2 # f3) t but I do not see how to define an operator like # in Haskell without applying show over again on the first arguments (i.e. f1 and f2). Because polymorphic lists are not possible, I can not define # as to write [f1,f2,f3] # t either. Any idea? Regards, Bernd
Bernd Holzmüller <holzmueller@ics-ag.de> writes:
I'd like to have a better way for "showing" a list of things, e.g.
show (f1 t) ++ show (f2 t) ++ show (f3 t) ++ ....
I would love to just write: (f1 # f2 # f3) t but I do not see how to define an operator like # in Haskell without applying show over again on the first arguments (i.e. f1 and f2). Because polymorphic lists are not possible, I can not define # as to write [f1,f2,f3] # t either.
How about the following? infixr # (#) :: (Show b) => (a->b) -> (a->String) -> (a->String) f # g = \t-> show (f t) ++ g t newline, empty :: a -> String newline _ = "\n" empty _ = "" which you could use like (f1 # f2 # f3 # newline) t Regards, Malcolm
On Tue, Apr 22, 2003 at 04:35:25PM +0100, Malcolm Wallace wrote:
infixr # (#) :: (Show b) => (a->b) -> (a->String) -> (a->String) f # g = \t-> show (f t) ++ g t
Or, to avoid unnecessary overhead: (f # g) t = shows (f t) (g t) Lauri Alanko la@iki.fi
I understand that clarity is vital, but I kind of hoped that Haskell would grow up to be a combination of a professional language and a communicative and cognitive tool for testing computer-scientific ideas in (much) higher education. It is not necessarily the case that clarity from a well-educated computer scientist's or a professional software developer's point of view is the same as clarity for beginners. It is kind of sad that we are stuck with beginners' languages, such as Java and VB. What works for beginners might not always be the best choice for us highly experienced engineers and scientists. The problem is that if you want to make a language popular in actual use, you have to infiltritate the educative system, since the beginners of today are the professionals behind systems built in two years. This crazy IT world makes doctors out of nurses... The clean and formal touch of Haskell (as well as of Oz and other declarative languages) makes it highly attractive to (1) highly educated professionals and (2) computer-science students (via their teachers.) But beside that "aura," the two groups have different needs. Maybe we have to invent Haskell++, to obfuscate things just enough to keep students out of the way, enable the insertion of features viable for use amongst professionals and in (much) higher education. Or, perhaps, to go the other way, HaskellScript, as a gift to students :-) I hope this mail did not sound too negative (re-reading it, it does...), but I just wonder if anyone else has experienced the conflicting requirements on this (and other) languages? PS Paul, sorry for getting this as a private mail the first time, I hit the "reply" button -- just shows how professional I am ;-) DS /David
participants (7)
-
Arjan van IJzendoorn -
Bernd Holzmüller -
David Bergman -
Johannes Waldmann -
Lauri Alanko -
Malcolm Wallace -
Paul Hudak