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
