[Haskell-cafe] Why shouldn't variable names be capitalized?

[Martin Percossi]

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