> (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".
Agreed in principle, but I don't think we should go so far as eliminating
the entire prelude. I'd be in favour of removing (to libraries) everything
that wasn't required by virtue of being built-in to the Haskell syntax.
That means class names and types that can result from overloaded literals,
deriving, do syntax, (n+k) patterns, emumeration syntax etc.
Also, it would be nice if "import qualified M" was implied, for all M (the
only argument I can see against this is that it makes automatic
dependency-generation harder, but not significantly).
> 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.
import Prelude ()
> (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.
Disagree. The layout rule sucks, but I don't think we should get rid of it,
rather we should try really hard to find a simpler (to specify and
implement) definition. See previous discussion on this subject...
> (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.
and here's my pet hates:
(5) '~' patterns
(6) (n+k) patterns
(7) the monomorphism restriction
*duck*
Simon
