Valid characters in a module name

Peter Levart peter.levart at
Sun Jan 8 09:18:29 UTC 2017

Hi Ess,

On 01/08/2017 02:33 AM, Ess Kay wrote:
>> Why wouldn't Peter's syntax proposal suffice
> For any syntax to work (in ANY context) you need to be able to distinguish
> between the use of that syntax and the specification of an identifier (e.g.
> a module, package, class, field or method name) which happens to match that
> syntax.  Let's take Peter's string #"\\u0022\\\"" as an example.  How is
> that string to be interpreted? Is it an example of the proposed syntax that
> should be interpreted as the 11 character identifier \\u0022\\\" or is it a
> 14 character identifier starting with # and ending with to double quotes?

If this sequence of characters appear in source at position where 
identifier is expected:


then they are interpreted as an identifier with following characters:


This is unambiguous because otherwise the syntax of "plain" identifier 
(as opposed to "exotic" identifier) doesn't allow it to start with 
character #.

If parser encounters character # followed by double quote, it knows it 
is a start of exotic identifier.

> Module, package, class, field and method names can legally start with the 2
> characters #" and end in a double quote.  That is why Peter's syntax would
> not work.

Why? If the name of identifier starts with #"... then such identifier 
can only be expressed in the syntax of exotic identifiers, therefore you 
have to write it in the source as:


> This is the difficulty when you specify that almost any
> character and character combination is a valid in an identifier.

I see no difficulty here.

Regards, Peter

>> I thought your problem was that users needed a way to express
>> "crazy identifiers" in _your_ (or other Java-like) script languages.
> My discussion of  the problem of crazy identifiers in JAR manifests was
> more of "parting shot". It is very easy to be ultra flexible in a
> specification. It is very concise and even aesthetically pleasing.
> However, it can be much, much harder to actually support that ultra
> flexibility in the practice.  Problems can occur in unexpected places. Such
> is life.

More information about the jigsaw-dev mailing list