Contextualizing keywords

Oliver Hoog kingboscop at gmail.com
Sun Aug 2 09:37:31 PDT 2009


Oliver Hoog schrieb:
> Robert Fraser schrieb:
>> Hi, hope you're all enjoying the properties debate.
>>
>> I've been seeing the "too many keywords" argument a lot lately, and I 
>> think it's definitely a valid argument. "shared" and "body" in 
>> particular are rather annoying keywords since I frequently use them in 
>> code. And if users are deciding not to use D because of the number of 
>> keywords, that's even worse.
>>
>> The idea of "kewyord" as a parser construct is antiquated thinking. 
>> Look at C#: "get", "set", "value", "event", "var", etc. are only 
>> keywords in a particular context. C++/CLI takes it a step further 
>> (from http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). 
>> There are three new reserved words ("gcnew", "generic", "nullptr") and 
>> a few multi-word keywords ("for each", "enum/interface/ref/value 
>> class/struct") as well as some contextual keywords that can only 
>> appear in certain positions.
>>
>> In D, without a significant change to the lexer/parser, any keywords 
>> that cannot appear in the same place as an identifier could be made 
>> legal identifiers easily. Off the top of my head, "in", "out", "body", 
>> "module", "unittest", "import", "throw" and probably a few others 
>> could be freed up.
>>
>> With some parser lookahead, you could add modifiers and storage 
>> classes to the list and probably dozens of others. If braces were 
>> required in try/catch statements, "try", "catch", and "finally" could 
>> be added.
>>
>> Further, this might be pretty easy to implement (i.e. Walter, if 
>> you're interested, I'm willing to make a patch). It's all 
>> backwards-compatible and would even work in D1.
>>
>> Thoughts?
> 
> Of the keywords mentioned, I only needed "body" in the past. And (maybe 
> except for "in" and "out") I don't think I would ever need the others. 
> Freeing them is generally good though. But if it slows down compilation 
> time, I would rather have it as it is. And requiring try/catch to have 
> braces introduces inconsistency.

Besides, I find it easier to read source code when keywords are only 
used as keywords. Not only because of possible syntax-highlighting errors.



More information about the Digitalmars-d mailing list