[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Haskell 1.3



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                                Ian.Holyer@uk.ac.bristol,   Tel: 0272 303334