Valid characters in a module name
Peter Levart
peter.levart at gmail.com
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:
#"\\u0022\\\""
then they are interpreted as an identifier with following characters:
\u0022\"
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