[Haskell-cafe] Why shouldn't variable names be capitalized?
haskell-cafe at martinpercossi.com
Fri Aug 4 14:49:38 EDT 2006
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
> 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! ;-)
More information about the Haskell-Cafe