NetBeans support for proposed small language extensions

John Rose John.Rose at Sun.COM
Wed Jan 21 15:04:48 PST 2009


On Jan 21, 2009, at 2:00 PM, Charles Oliver Nutter wrote:

> I'm not sure there's a way to reconcile multiple proposed Java  
> languages
> changes that all want to use #.

The exotic identifiers proposal does not conflict with any use of  
hash '#' (that I am aware of) as a separator or operator.  That's  
because an exotic identifier is introduced by the two character  
sequence hash-quote '#"'.  It interferes with other uses of hash '#'  
as much as it interferes with other uses of quote '"':  That is, not  
at all.

On Jan 21, 2009, at 12:01 PM, Rémi Forax wrote:
> I am not a big fan of the exotic identifier proposal mostly because
> i doesn't understand the need

As Charlie pointed out, along with the Dynamic.foo() syntax, exotic  
identifiers allow Java to make direct calls to other languages.   
E.g., Dynamic.#"setcar!"(aCons, aValue) as well as Dynamic.list(aValue).

A second point:  I know that annotations are the current state of the  
art for assigning non-Java names to definitions.  But I think exotic  
identifiers will provide, in many new cases, a smoother way to allow  
Java to define names which are directly usable from non-Java languages.

> and because using '#' creates conflicts
> with several closure proposal (BGGA and CICE) and my modest
> property proposal.

See above.  For example, a proposed expression Author#name could be  
harmlessly requoted as #"Author"##"name".  The example is  
intentionally bad style, but there is no ambiguity.  At worst, an  
operator "##" (is anybody suggesting one?) would be lexically  
ambiguous if immediately followed by a string literal; the solution  
(as with all such ambiguities) is to introduce a space to separate  
the intended tokens.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090121/64801b46/attachment.html 


More information about the mlvm-dev mailing list