I hope that Haskell 1.3 will clean up the report, and maybe even the language,
and not just add features. Recent work at Bristol has raised the following
points; I apologise for any which are well known already.
o The layout rule that says that an implicit block can be terminated by the
surrounding construct (ie whenever an `illegal' token is found) is painful.
It forces layout processing to be intertwined with parsing, which (eg)
rules out the design of a language-sensitive editor based on matching
tokens rather than full parsing. It can also make it difficult to report
syntax errors precisely. There is little problem when the surrounding
construct is a multi-token one, as in:
pair = (case n of 1->42, 43)
but pathological cases such as the following (all legal!) cause problems:
a = n where n = 42 ; ; b = 43 -- terminated by second `;'
c = case x of 1->y where {y=44} where {x=1} -- ditto by second `where'
d = case 1 of 1->44 :: Int + 1 -- ditto by `+'
Is it not possible to find some better convention which rules these out
and allows layout processing to be carried out separately from parsing?
o The expression 4/2/1 is illegal according to section 5.7 of the report
(division operators are not associative), but legal according to the fixity
declarations in appendix A.2 (infixl). Existing compilers differ.
Also :% is missing from the table in 5.7.
o Section 2.4 doesn't make it clear that decimal points are (presumably) the
one and only exception to the longest lexeme rule of section 2.3, which
explicitly says that no lookahead is required. This exception is needed to
make expressions such as [1..n] legal. Presumably, the rest of the
numeric literal syntax follows the longest lexeme rule, so that (f 1.2e)
is reported as an incomplete literal rather than accepted as (f 1.2 e).
o Definitions such as (f x) = ... or (x # y) = ... are illegal (although
existing compilers allow them). This prevents, for example, the
following natural definition of the composition (dot) operator:
(f . g) x = f (g x)
Is this restriction intentional?
o The situation with unary minus is still confused. Expressions such as
(2 + -3) are technically illegal, although accepted by current compilers.
Also, it is not entirely clear from sections 3.3 and 3.4 whether (2-) is
legal (presumably meaning (\n->2-n)). Also, the definition -42 = 42 is
legal (patdefs do not exclude minus patterns), and accepted by current
compilers, although it is meaningless.
o The form (`div`) is illegal, even though it looks very natural in
definitions such as
ops = [(+),(-),(`div`),(`mod`)]
This seems to be against the general policy of allowing any meaningful
expression in any suitable context.
o There is a general inconsistency of language in the report. A notable case
is that the functions associated with a class are variously called
methods, operations, or operators. The last of these is surely wrong.
o A number of other minor matters are raised by the tests available by
anonymous ftp from ftp.cs.bris.ac.uk, directory /pub/functional/brisk.
Ian [EMAIL PROTECTED], Tel: 0272 303334
