Patrick Mullen wrote:
On Wed, Dec 10, 2008 at 6:57 AM, MRAB <[EMAIL PROTECTED]>
wrote:
Aaron Brady wrote:
On Dec 9, 12:40 pm, MRAB <[EMAIL PROTECTED]> wrote:
Aaron Brady wrote:
On Dec 9, 8:28 am, MRAB <[EMAIL PROTECTED]> wrote:
snip
In some languages (I think Delphi is one of them - it's
been a while!) some words which would normally be
identifiers have a special meaning in certain contexts, but
the syntax precludes any ambiguity, and not in a difficult
way. "as" in Python was one of those. I certainly wouldn't
want something like PL/I, where "IF", "THEN" and "ELSE"
could be identifiers, so you could have code like: IF IF =
THEN THEN THEN = ELSE; ELSE ELSE = IF;
Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language).
snip That is, 'certainly' doesn't change the meaning of your
statement any. You wouldn't want it, but King George III
didn't want the American Revolution.
It's called emphasis.
I just take you to have meant, then, +1 on excluding keywords
from identifiers. You said it the long way though, so I thought
I missed something deeper, that didn't come across.
IIRC, most computer languages have an LL(1) grammar, which means
that when they are parsed you need to look at only the next word.
If you're about to parse a statement and the next word is "IF" then
you know it's an IF-statement, if it's an identifier then it's
either a call or an assignment statement (OK, you don't know
exactly what kind of statement it is at that point, but it works
out just fine!).
In the example from PL/I, "IF" could be the start of an
IF-statement "IF <condition> THEN" or an assignment statement "IF =
<expression>". It's a bit more tricky for the parser as well as the
programmer.
Life is easier if words having special meanings are reserved.
However, that doesn't mean that all special words /must/ be
reserved (pragmatism beats purity). Sometimes the syntax makes it
clear and unambiguous, so you can get away with not making it a
reserved word. The word "as" in Python doesn't need to be reserved
because the syntax precludes ambiguity, but it's the only such word
in the language, so it's just tidier to make it reserved too.
I don't have a huge stake in this, but I wouldn't mind a change to
allow anything proceeding a "." or preceeding a "(" to not be
identified as a keyword.
Don't you mean 'following a "."'? IMHO if you forbid "bar = True" then
you should also forbid "foo.bar = True".
As for preceding a "(", what about the call "if(True)"? It looks like an
if-statement!
It is obvious to me a s a human reader that something.if is quite a
bit different than just a bare if. And as far as parsing technology
goes, isn't it supposed to go for the biggest match first? I would
not be for allowing bare keywords to be used in the situations
described above, but since we are so used to being able to being able
to have say, myclass.dir() or myclass.len() without them overwriting
the builtin functions, it makes sense to me to be able to define a
myclass.as() or myclass.with() without overwriting the keywords.
Though I know the semantics behind these two things are very
different, the rules I go through when reading the code are very
similar. The parser change might be a hassle, and it might not be
worth it at all of course, but from a conceptual point of view it is
simple. I mean, even now you can do class.__dict__["as"].
I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword
usage.
Parsing isn't about the biggest match. Ideally you want something that's
simple without being simplistic. Python is a good example.
--
http://mail.python.org/mailman/listinfo/python-list
