[patch] 6746458 support for exotic identifiers (identifier superquote)

Stephen Colebourne scolebourne at btopenworld.com
Tue Sep 9 15:11:13 PDT 2008


Given that # is the symbol that has been most frequently used for the 
method/field reference concept I'm not convinced that using a # here is 
wise.

FCM and recently BGGA closures have used the following syntax to 
reference a method (aka eta expansion):

ClassName#methodName(ParamTypes)

or a field:

ClassName#fieldName

In addition, the class name (at least in FCM) can be implied based on 
context:

#methodName(ParamTypes)
#fieldName

This syntax has now become pretty widely used in the context of the 
closures debate and, in general, I have found references to be very 
popular and not as controversial as closures.

While the #" syntax does distinguish this proposal from the above 
technically, it is far less clear in terms of readability or to a 
typical developer (two similar syntaxes with widely differing meanings).

Is there no alternative syntax?

Stephen


John Rose wrote:
> Each language has its own rules for forming identifiers of functions, 
> variables, and types.  The JVM allows almost total freedom, at the 
> bytecode level, for forming names of methods, fields, and classes.  So 
> far so good.  If a language (say, Lisp, Smalltalk, Ruby, or Scala) wants 
> to encode its names directly in the JVM, it runs into two problems.  The 
> first is the small number of remaining restrictions on JVM bytecode 
> names; this can easily be overcome by lightweight mangling as outlined 
> in this blog post:
>   http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm
> 
> The second problem is the fact that the language runtime is probably 
> written largely in Java, which means that the "exotic" names in the 
> language cannot be directly implemented by Java classes, methods, and 
> fields.  In practice, this difficulty forces language implementors to 
> mangle their names not for the JVM (which is permissive) but for Java 
> (which is restrictive).
> 
> The solution to the second problem is to provide an "escape" syntax 
> (similar to that of Lisp and other languages) which allows an arbitrary 
> string to pass through the language scanner as a simple identifier token 
> instead of some other token (or an unscannable mess).
> 
> We propose the syntax #"foo".  See example implementation here and 
> enclosed in this message:
>   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/quid.patch
> 
> The javac frontend should accept any quoted string immediately following 
> '#' (with no intervening space), interpreting normal string escape 
> sequences, and taking the resulting string exactly as the spelling of a 
> normal identifier.  Keywords like 'int' should not be recognized.  
> Strings which risk being illegal at the JVM level must be rejectedi 
> immediately; this simply means rejecting the empty string and strings 
> which contain any of the characters "/.;<>[".
> 
> This design is neutral toward mangling schemes but supports the one 
> described in the blog entry mentioned above.
> 
> (Thanks for Alex Buckley and Jon Gibbons for helping me figure this out, 
> and especially for suggesting a reasonable syntax.)
> 
> -- John
> 



More information about the compiler-dev mailing list