Case sensitivity

Alex Martelli aleax at aleax.it
Sat Feb 22 04:37:32 EST 2003


Dave Kuhlman wrote:
   ...
> As long as we have Alex wound up, it's a shame to let him sit down so
> soon.

Hmmm, for a moment there I thought I was on s.s.spanking...;-).

> Let me carry this a bit further.  If there is no real value in
> distinguishing between 'add_century' and 'Add_century', then perhaps there

Are you claiming there IS?  Would you give me a use case where
you would WANT in the same scope to have add_century and
Add_century as distinct identifiers, please?

> is no need to distinguish between 'add_century' and 'addcentury'.  And, if

That's roughly what Fortran does, except with spaces instead of
underscores allowed and ignored inside identifiers &c.  And I think I
recall that Ada allows and ignores underscores somewhere, though
I vaguely remember it was in literals, to let you write 1_000_000
which may be more readable than 1000000 (in Fortran you could
write 1 000 000 to similar effect), but it's too long since I looked at
Ada and never used it in a production environment, so I'm unsure.

Having used and taught Fortran for long, I do have an opinion about
the "spaces everywhere" idea, and it's a negative one (I don't even
know if modern Fortrans still support that quirk).  I think the concept
of "token" IS useful, and allowing and ignoring spaces inside tokens
doesn't ease either learning or use, because it weakens the "token"
concept.  On the other hand, allowing and ignoring optional extra
spaces BETWEEN tokens is just fine with me (I've used languages
that _required_ whitespace for tokenization -- that might be fine in
the abstract but conflicts with the punctuation-vs-letters divide that
people have learned and internalized, so I think it's suboptimal).

Would you please apply your exact same arguments to "allowing and
ignoring extra whitespace between tokens" as you do to capitalization?
Why DOESN'T allowing optional whitespace encourage laziness,
luxury and the decay of western moral values, pray?  Aren't you
perchance letting the HABIT of whitespace-allowing languages blind
you to the close similarity between the two issues?

Allowing and ignoring underscores everywhere inside a token, i.e.
generalizing my vague memories of Ada, might be an interesting
idea for a greenfield language design -- leaving the token concept
sound and solid, and letting underscores play a similar ornamental
role to that of optional whitespace _between_ tokens.  But then I
guess you'd claim that Ada isn't disciplined enough for your tastes,
right?-)  However, I have no experience with putting such a
concept in practice, so I'll pass.

> there is no other variable that begins with 'addcen', then the
> compiler/interpreter should let me use 'addcen' as a replacement for

Whoa there!  What an unwarranted generalization.  The concept
of "unambiguous abbreviations" (present e.g. in Dec's command
language for VMS) is a proven disaster: the abbreviations ARE in
fact ambiguous to human readers even when they aren't to
computers.  Rather, this should be dealt with in a smart editor,
where it's called "word completion" and is indeed quite popular.

I don't want the compiler to "guess what I _mean_" (if I did, maybe
I'd be using Perl) and in practice the u.a. concept leads to that
(because even the _writer_ of the code may not be fully aware
of all names in scope).  Even worse, this seems to require adding
declarations (ERGH) or having different rules for how you're allowed
to spell a variable name on the left vs the right of an = sign (DOUBLE
ERGH).

In other words, this absurd generalization qualifies as a typical
"strawman argument".


> A language that is case-insensitive encourages a similar type of laziness.

No more than a language that allows optional whitespace between
tokens.  So why not force everybody to use exactly determined
whitespace?  Isn't it just SLOPPY to allow
   a+b
   a + b
and a zillion other variations as all equivalent?!

Uh, I assume your employees all must wear starched collars if male
and corsets if female, right?

So much for Python not being a "bondage and discipline" language, I
guess... now we're down to imposing arbitrary discipline because doing
otherwise would "encourage laziness".  What a hoot...!


Alex





More information about the Python-list mailing list