Long names are doom ?

Alex Martelli aleaxit at yahoo.com
Sun May 27 02:50:03 EDT 2001


"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in message
news:mailman.990935541.21263.python-list at python.org...
    ...
> This points toward one of my few complaints against Python:
> the absolute restriction against using a reserved word as a
> variable name *even if it is unambiguous*.  In particular,

That's the definition of *reserved*, of course.  One language
that tried to use keywords that were not reserved was PL/I,
IBM's ambitious attempt in the '60s to make one language
that would have all good points of Cobol, Fortran AND Algol
plus more, and thereby become the only programming lang
in the world.  It never really overtook either Cobol or
Fortran in popularity, despite a few admirers, and remains a
good object lesson in complicated languages and their
failure-mechanisms.

Part of the problem was that, instead of focusing on real
issues, its compiler writers had to sweat out in the lexer
and parser the problem of what constructs were in fact
"unambiguous".  They made it, but that useless effort was
a sheer waste of energy that would have been better spent
elsewhere -- a "opportunity cost".  A later language designer
who was among PL/I's admirers, and copied this feature,
was Mike Cowlishaw, the designer of REX (later REXX) -- I
think that still today, in REXX (another language that has
become pretty hard to find), you can "use any unambiguous
constructs" -- no words are reserved.  If I remember well
the time I was studying REX's 370-assembly sources, the
parser was a typical piece of Cowlishawian genius -- but was
still substantially slower than it would have been with a
simple keywords-are-reserved language.  A scripting language,
like Rexx or Python, really needs a *FAST* parser -- slowing
it down can only be justified for stuff that's really CRUCIAL.

And it turns out that people don't make much use of the
feature.  I hand-recoded a hundred thousand lines of PL/I
to C back in the early '80s, and only remember a couple of
cases out of that huge program where I had to rename some
variable to avoid a reserved-word (C, like Pascal, Python,
and most other modern languages, reserves its keywords;
it turns out to be the simplest, most effective approach).

Sure, in PL/I you could (and in Rexx, I think, you still can)
code beauties such as:
    IF IF=THEN THEN THEN=ELSE ELSE ELSE=IF
which also uses double-meaning '=', either comparison
or assignment; Visual Basic still has that particular PL/I
legacy -- it's very much part of the same parser-design
mindset: abandon the simplicity of context-free langs in
favour of using context to disambiguate, so that the same,
identical token has very different syntactic roles depending
on what context surrounds it.


> but IMHO Python would be better if it were allowed for
> attribute access as here:
>
>     myobj.class = 10

In my view, Python's greatest single strength is its focus
on simplicity.  Having a token's lexical category be totally
independent of the surrounding context is simplest for
both the parser AND the human beings reading any given
program.  Abandoning this simplicity, so prevalent in
just about all of today's programming languages, for a
return to the complications of PL/I, would, I believe, be
a heinous language design error, going against the grain
of Python itself.


Just about the only advantage would need keywords to
be usable in ALL "non-ambiguous" contexts (having them
just as attribute names would not suffice), including
'class=10' and 'def class(x):' etc -- that advantage would
be the possibility to introduce new keywords (and thus
potentially clearer syntax for new constructs) without the
reserved-word issue of breaking previously working code.

This is the advantage on which Rexx focused (and also
part of the reason to 'strop' variable names in Perl -- by
almost-never allowing barewords as user-definable
identifiers, new keywords can also be added anytime).
But it's a dubious advantage, too, as it can lead to a
more complicated language in itself, and the complication
price of context-dependent parsing is large for both the
Python parse and human readers.


Alex






More information about the Python-list mailing list