### Re: Preliminary Haskell 1.3 report now available

I always favoured `=' over `-', but I don't care much. -- Lennart

### Re: Preliminary Haskell 1.3 report now available

First, I am happy to see that Haskell 1.3, with its many valuable improvements over Haskell 1.2, is finally getting ready, but I also have a comment: In the syntax for labeled fields (records) the symbol - is chosen as the operator used to associate a label with a value in constructions and patterns: data Date = Date {day, month, year :: Int} today = Date{day - 11, month - 10, year - 1995} According to a committee member, there were no convincing reasons why - was chosen. Other symbols, like = and := were also considered. Here are some (in my opinion) good reasons for using = instead of - : 1. In ordinary declarations, :: is used to specify the type of a name and = is used to specify its value: day, month, year :: Int day = 11; month = 10; year = 1995 so for consistency I think the same notations should be used inside record values: data Date = Date {day, month, year :: Int} date :: Date date = Date {day = 11, month = 10, year = 1995} 2. The - symbol is used also in list comprehensions and the new monad syntax ('do'): [ 2*x | x - [1..10] ] do c - getChar; putChar c In these uses of - the name on the lhs does not have the same type as the expression on the rhs (above, x::Int, but [1..10]::[Int] and c::Char but getChar::IO Char). The value that the lhs name (or, indeed, pattern) is bound to is "extracted" from the value of the rhs expression. This is very different from what happens with field labels, so a difference in syntax is motivated. Sadly, I suspect it would be difficult to convince the committee to change their minds about this at this late stage, but I am sure it would be even more difficult to change it for a later version of Haskell... Regards, Thomas Hallgren

### Haskell 1.3

Congratulations to all involved on Haskell 1.3! I especially like the introduction of qualified names and the attendant simplifications. Here are some small suggestions for further improvement. Interfaces ~~ Suggestion: the introduction should draw attention to the fact that interface files are no longer part of the language. Such a wondrous improvement should not go unremarked! ISO Character Set ~ Suggestion: Add a one-page appendix, giving the mapping between characters and character codes. Fields and records ~~ Suggestion: Use = to bind fields in a record, rather than -. I concur with Thomas Hallgren's argument that - should be reserved for comprehensions and for `do'. SML has already popularised the = syntax. Suggestion: Use the SML syntax, `#field' to denote the function that extracts a field. Then there is no possibility of accidentally shadowing a field name with a local variable. Just as it is a great aid to the readability of Haskell for constructors to be lexically distinguished from functions, I predict it will also a great aid for field extractors to be lexically distinguished from functions. (Alternative suggestion: Make field names lexically like constructor names rather than like variable names. This again makes shadowing impossible, and still distinguished fields from functions, though now field extractors and constructors would look alike.) The empty type ~~ Suggestion: Include among the basic types of Haskell a type `Empty' that contains no value except bottom. It was a dreadful oversight to omit the empty type from Haskell, though it took me a long time to recognise this. One day, I bumped into the following example. I needed the familiar type data Tree a = Null | Leaf !a | Branch (Tree a) (Tree a) instantiated to the unfamiliar case `Tree Empty', which has `Null' and `Branch' as the only possible constructors. One can simulate the empty type by declaring data Empty = Impossible and then vowing never to use the constructor `Impossible'. But by including `Empty' in the language, we support a useful idiom and (perhaps more importantly) educate our users about the possibility of an algebraic type with no constructors. It would be folly to allow only non-empty lists. So why do we allow only non-empty algebraic types? The infamous (n+1) patterns ~~~ Suggestion: Retain (n+1) patterns. If Haskell was a language for seasoned programmers only, I would concede that the disadvantages of (n+1) patterns outweigh the advantages. But Haskell is also intended to be a language for teaching. The idea of primitive recursion is powerful but subtle. I believe that the notation of (n+1) patterns is a great aid in helping students to grasp this paradigm. The paradigm is obscured when recursion over naturals appears profoundly different than recursion over any other structure. For instance, I believe student benefit greatly by first seeing power x 0 = 1 power x (n+1) = x * power x n and shortly thereafter seeing product [] = 1 product (x:xs) = x * product xs which has an identical structure. By comparison, the definition power x 0 = 1 power x n | n 0 = x * power x (n-1) completely obscures the similarity between `power' and `product'. As a case in point, I cannot see a way to rewrite the Bird and Wadler text without (n+1) patterns. This is profoundly disappointing, because now that Haskell 1.3 is coming out, it seems like a perfect time to do a new edition aimed at Haskell. The best trick I know is to define data Natural = Zero | Succ Natural but that doesn't work because one must teach recursion on naturals and lists before one introduces algebraic data types. Bird and Wadler introduces recursion and induction at the same time, and that is one of its most praised features; but to try to introduce recursion, induction, and algebraic data types all three at the same time would be fatal. Now, perhaps (n+1) patterns introduce a horrible hole in the language that has escaped me; if so, please point it out. Or perhaps no one else believes that teaching primitive recursion is important; if so, please say. Or perhaps you know a trick that will solve the problem of how to rewrite Bird and Wadler without (n+1) patterns; if so, please reveal it immediately! Otherwise, I plead, reinstate (n+1) patterns. Yours, -- P --- Professor Philip Wadler[EMAIL PROTECTED] Department of Computing Sciencehttp://www.dcs.glasgow.ac.uk/~wadler University of Glasgow office: +44 141 330 4966 Glasgow G12 8QQ fax: +44 141 330 4913 SCOTLAND home: +44 141 357 0782

### Re: Preliminary Haskell 1.3 report now available

I always favoured `=' over `-', but I don't care much. -- Lennart

### Re: Preliminary Haskell 1.3 report now available

Thomas Hallgren [EMAIL PROTECTED] writes: In the syntax for labeled fields (records) the symbol - is chosen as the operator used to associate a label with a value in constructions and patterns: [...] According to a committee member, there were no convincing reasons why - was chosen. Other symbols, like = and := were also considered. I support Thomas Hallgen's suggestion that `=' be used instead. Another reason, in addition to the two he mentioned, is that the `-' symbol is very unintuitive when used for pattern matching, because the arrow is in the *opposite* direction to the data-flow. I find this very confusing. Indeed, a couple of reasons I find convincing myself: 1 - SML uses '=' too, therefore it is one less problem for people moving to/from SML/Haskell. 2 - The '-' notation always reminds me of list comprehensions, e.g. at first sight if I see an expression like R{v - [1..10]} I could think v is an integer (taken from [1..10]) when it is actually a list. the following expression is also confusing: [R{v - [1..x]} | x - [1..10]] (defines a list of records) An expression using records on the rhs of the '|' should be even more interesting (and useful for obfuscated Haskell competitions). The same applies for records with fields defined with list comprehensions. Andre. Andre SantosDepartamento de Informatica e-mail: [EMAIL PROTECTED] Universidade Federal de Pernambuco http://www.di.ufpe.br/~alms CP 7851, CEP 50732-970, Recife PE Brazil