Re: Preliminary Haskell 1.3 report now available

[Lennart Augustsson]

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

-- Lennart

Re: Preliminary Haskell 1.3 report now available

[Thomas Hallgren]

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

[Philip Wadler]

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

[Lennart Augustsson]

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

-- Lennart

Re: Preliminary Haskell 1.3 report now available

[alms]

 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