[I'm replying to both Fergus and Alastair in this message.]
>This is a reply to Fergus Henderson's comments on my proposal.
>
>My answer to all his comments is that consistent languages are
>easier to learn than languages littered with exceptions, special cases
>and random default behaviour.
On the one hand, Haskell has so much syntactic sugar that I am skeptical as
to whether it is really possible to eliminate all of these kinds of
problems. On the other hand, maybe we can keep the syntactical redundancies
while eliminating exceptional behavior.
>> > 1) Fixity declarations usually look like this:
>> > infixl 6 +, -
>> > but you can omit the precedence digit and write this instead:
>> > infixl +, -
>> >
>> > [which is bad...]
>>
>> I don't think it's harder. Even if the number is specified explicitly,
>> I would *still* have to look up the precedence table in the report,
>> or at least grep the source for the standard prelude, because
>> I don't know what the precedence of the other operators is.
I was surprised to learn that this kind of declaration is possible. It's a
safe bet that most other people would be too. Standard Haskell is supposed
to be Haskell 1.4, but streamlined. If you can eliminate a rarely used
feature, I think you should. If you can reduce the size of the grammar, I
think you should.
BTW, if I had seen this first in somebody else's source code rather than
here on the list, and it compiled, my first impulse would have been that
there must be a bug in the compiler that accepted it. Then, after a few
seconds, I would maybe calm down, check the report... and send a message to
this list about it.
>> > 3) Empty contexts are not allowed.
>
>> Who would ever write them?
>>
>> Even for programs that generate Haskell code, it's trivial to handle
>> the empty context case differently.
>
>Probably not many people - but it's still a pointless exception
>and you have to remember to handle that empty case differently.
See below.
>> > 3) Contexts come in two flavours:
>> > f :: Ord a => a -> a -> Bool
>> > and
>> > f :: (Ord a, Bounded a) => a -> a -> Bool
>> > [and that's bad]
>>
>> I could live with that, but it might break a lot of existing code.
If I understand this correctly, you want to require the parentheses. I
believe HBC's grammar needs (or needed---maybe it's fixed now) them, and I
remember when I was writing code for HBC that the extra two keystrokes were
not such a great burden. If you are going to require this, I think you
should definitely allow #2 above also.
>> > 4) Module headers can be omitted.
>> > If the module leaves out the module header, the header
>> > module Main(main) where
>> > is assumed.
>> > [and that's a mistake]
>>
>> Fix the compilers. If there's no module header, the compiler should
>> not include the module name (Main) in the error messages.
What do you propose they should use in its stead? "Type error in the module
formerly known as Main"? ;)
>That's be nice AS WELL but why not simplify the report by removing
> pointless defaults.
>
>There's an argument going around that it must be possible teach Haskell
>without having to mention the word "module" in the first month.
>This argument is used to justify reexporting all kinds of rubbish
>from the Prelude (and is something I have argued against in the Standard
>Haskell discussion).
Larry Paulson has been lauded for introducing and using modules much earlier
in the second edition of his book "ML for the Working Programmer", and that
book is often used as an introduction to FP by beginners (despite the
title). I agree that it is "cleaner" from the teacher's standpoint to avoid
mention of modules in the beginning, but so what?
Haskell is supposed to be a language suitable both for education and
programming in the large (PITL). Fine. But nobody said it had to be a
scripting language and, although I think functional languages are great for
that purpose, Haskell should not be both a scripting language and a language
for PITL at the same time.
Furthermore: a language suitable for scripting is not necessarily suitable
for education, nor vice versa. Certainly no one would start off a bunch of
freshmen on Perl! It seems to me that many of the syntactic oddities above
might be viewed as symptoms of conflating one with the other. For example,
in a scripting language, it is desirable to have lots of defaults, etc. so
that there is as little time as possible between the time you start to write
a program and the time you get it running. That's possible because
scripting languages are often targeted at one specific domain, and so you
can choose your defaults accordingly. But Haskell is supposed to be a
general-purpose language, so default behavior is not much of a benefit.
If you want a functional scripting language with H-M type inference and type
classes and monads, that's great, but maybe it should be something separate
from Haskell.
--FC
