Paul Hudak wrote:
Ok, you asked for it, so here's my worst :-)
You're too gentle! I was expecting some serious community flagellation
for my heretical remarks!
1) Here's what the "History of Haskell" has to say about this:
Namespaces were a point of considerable discussion in the Haskell
Committee. We wanted the user to have as much freedom as possible,
while avoiding any form of ambiguity. So we carefully defined
a set of lexemes for each namespace that were orthogonal
when they needed to be, and overlapped when context was sufficient
to distinguish their meaning. As an example of overlap, capitalised
names such as Foo can, in the same lexical scope, refer to a
type constructor, a data constructor, and a module, since whenever
the name Foo appears, it is clear from context to which entity it
is referring. As an example of orthogonality, we designed normal
variables, infix operators, normal data constructors, and infix data
constructors to be mutually exclusive.
We adopted from Miranda the convention that data constructors are
capitalised while variables are not; and added a similar convention
for infix constructors, which in Haskell must start with a colon. ...
The key point here is that we wanted data constructors to be
orthogonal to formal parameters. For example, in:
foo x y = ...
We know that x and y are formal parameters, whereas if they were
capitalized we'd know that they were constructors. Some of us had had
experience with ML where this distinction is not made, and we didn't
like that. There are surely other ways to achieve this, but
captilization was one of the least painful, as we saw it.
I agree that naming can be abused. But I think it should be *me*, the
programmer, or in the limit ghc, the glorious compiler (but only because
of unresolvable ambiguities), who decides it -- not *you*, the language
implementor!!! ;-)
2) Note that this is not a compiler issue -- the compiler won't have
much problem either way -- but it is a readability issue.
Ok - that's what I suspected - contrary to some of the other replies
which seem to imply that it would cause big problems in the compiler.
While I have never written a compiler of anything near the complexity of
haskell (I just about managed an awk-like language! ;-), you still feel
that it shouldn't be that difficult to handle these cases.
3) I suspect that you are mostly kidding, but Haskell doesn't require
you to know any category theory to write imperative code!
True again - but I think you understood the general gist.
I hope this helps, -Paul
It does, thanks for your time. And now I will stop complaining! ;-)
Martin
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
