"as" keyword woes

[MRAB]

Patrick Mullen wrote:
> 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.
>> 
> 
> 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.