An alternative to "restricted keywords"

[Peter Levart]

On 05/12/2017 06:08 PM, Peter Levart wrote:
>> For me, a restricted keyword is a keyword which is activated if you 
>> are at a position in the grammar where it can be recognized and 
>> because it's a keyword, it tooks over an identifier.
>> by example for
>>    module m {
>> if the next token is 'requires', it should be recognized as a keyword 
>> because you can parse a directive 'required ...' so there is a 
>> production that will starts with the 'required' keyword.
>>
>> so
>>    module m { requires transitive; }
>> should be rejected because transitive should be recognized as a 
>> keyword after requires and the compiler should report a missing 
>> module name.
>>   and
>>    module m { requires transitive transitive; }
>> should be rejected because the grammar that parse the modifiers is 
>> defined as "a loop" so from the grammar point of view it's like
>>    module m { requires Modifier Modifier; }
>> so the the front end of the compiler should report a missing module 
>> name and a later phase should report that there is twice the same 
>> modifier 'transitive'.
>>
>> I believe that with this definition of 'restricted keyword', compiler 
>> can recover error more easily and offers meaningful error message and 
>> the module-info part of the grammar is LR(1).
>
> This will make "requires", "uses", "provides", "with", "to", "static", 
> "transitive", "exports", etc .... all illegal module names. Ok, no big 
> deal, because there are no module names yet (apart from JDK modules 
> and those are named differently). But...
>
> What about:
>
> module m { exports transitive; } 

...ok, I realized there's no problem in exports or opens as there are no 
exports/opens modifiers in the current syntax, so what follows 'exports' 
or 'opens' can always be interpreted as package name only. But what if 
some future extension of the language wants to define an exports or 
opens modifier? Or some new yet unexistent requires modifier?

Peter