"as" keyword woes

[Patrick Mullen]

On Wed, Dec 10, 2008 at 6:57 AM, MRAB <google at mrabarnett.plus.com> wrote:
> Aaron Brady wrote:
>>
>> On Dec 9, 12:40 pm, MRAB <goo... at mrabarnett.plus.com> wrote:
>>>
>>> Aaron Brady wrote:
>>>>
>>>> On Dec 9, 8:28 am, MRAB <goo... at mrabarnett.plus.com> 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.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

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.  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.