We've had numerous suggestions to add things to Haskell.   However in my opinion
many more computer languages (and programs) are ruined by too many features, than
by too few.   So here is my own list of things to remove.  I realise there is
no chance whatever of it making it into the Haskell standard, as too much 
code would be broken, but maybe it might have some influence if they ever
get around to designing a successor to Haskell.  I hope other people will
contribute their pet hates.

(1) The Prelude.  If you want a program to print out "2+2", you should have
    to import "IO" and a numeric library, say "Integers".  The current approach
    has several disadvantages:
    (a) compilers such as GHC have to have an extra option saying "Please don't
        load the prelude", so that the prelude libraries can be written.
    (b) the documentation for IO functions (for example) is scattered in two places.
        The code tends to be as well.
    (c) if as a user I want my own definition of "+" (say I want an Int +
        that (doesn't) signal overflow), I am stuck.  (Other potential use -
        experiment with how floating point rounding is affecting the stability
        of my code by importing a version of the arithmetic functions that
        rounds differently.)
    Of course teensy student programs of the nature of fib will get two lines
    longer.  I haven't noticed many people in the C community complaining about
    having to do "#include <stdio.h>" all the time though.  And why conceal from
    students that these functions have to come from somewhere?
(2) Get rid of the do { ; ; ; } notation and force people to use indentation. 
    Or vice-versa.  Two ways of doing the same thing just make maintenance harder.
    To make indentation less dangerous, any leading blank characters apart from
    plain old simple " " (that means you, TAB) should cause the program to be
    rejected.
(3) $.  I would rather people wore out their ( and ) keys a little more,
    and tried a little less to impress me with the brevity of their code.
(4) If a datatype is declared as having field labels it should not also
    allow access by providing the field entries in the same order as the datatype.
    Two primitive ways of access to the same type don't go.

Reply via email to