[PATCH] A compromise on case

[Michal Wallace (sabren)]

On 23 May 2000, Jeff Senn wrote:

> nickm at mit.edu (Nick Mathewson) writes:
...
> > So I tried to make a quick-and-dirty patch the Python interpreter to
> > do something more reasonable.  Here's a sample interaction:
> ...
> >     >>> print MAP(square, [1,2,3])
> >     NameError: No such name as 'MAP'.  Perhaps you meant 'map'?
> 
> Merits of the patch aside (I like the idea!), it still doesn't get to
> the core of *why* Guido suspects there are benefits to making the
> language case-insensitive.
> 
> Just consider how to handle the more complex case of code like:
> 
>   CountOfLumberJacksAvailable = 12
>   if something.or.other():
>      CountOfLumberjacksAvailable = CountOfLumberJacksAvailable + 1
>   print CountOfLumberJacksAvailable
> 
> Code, which you will notice, generates no "errors"...


But this is a seperate kind of problem, and not necessarily confined
to case issues.

Perl (and many other languages) handle this by forcing you to declare
all variables. (It's optional in Perl.. "use strict". In VB, it's
"Option Explicit")


> Guido's assertion (which I believe) is that we humans are not used to
> reading case as being significant to the meaning of a word -- in
> addition our ability to even perceive the case of a word is pretty
> poor.  I'm sure that there are studies in the cog-sci reading-
> comprehension area that support this result and demonstrate that memory
> for case is pretty pathetic.

But that's because you don't know by looking at a token like
"onceUponatime" what the capitalization means...  But, if you use a
set of conventions, eg... AClass, aFunction(), anInstance.aMethod(),
anAttribute... then capitalization gives you extra information.


BTW -> Nick: great idea!

Cheers,

- Michal
-------------------------------------------------------------------------
http://www.manifestation.com/         http://www.linkwatcher.com/metalog/
-------------------------------------------------------------------------