PROPOSAL: Language Escape Operator

[Reinier Zwitserloot]

Isn't it easier to do this with a keyword?

Right at the top of your java file (after all, a non-java language  
would work at least on CompileUnits, if not entire Modules/Packages/ 
directories), put something like:

language groovy;

some sort of guarantee by java, in the vein of your proposal, that  
java will never make:

language (anything-but-"java", literally);

legal. That's not to say that "language java;" at the top WOULD be  
legal, just that "language foo;" at the top would NEVER be legal.

  --Reinier Zwitserloot



On Mar 27, 2009, at 00:35, brucechapman at paradise.net.nz wrote:

> Title Language Escape Operator
>
> latest html version at http://docs.google.com/Doc?docid=dcvp3mkv_9gdg3jfhg
>
> AUTHOR(S): Bruce Chapman
>
> OVERVIEW
>
>
> FEATURE SUMMARY:
>
> There is great potential for syntactic sugars to be implemented in  
> tools rather
> than the Java language. One requirement of such a mechanism is that  
> the sugared
> form is NOT valid java source code (otherwise the meaning is  
> ambiguous - is a
> piece of code intended as is, or intended to be desugared). In order  
> to future
> proof such mechanisms it is also desirable that such a syntactic  
> sugar form will
> never become a valid java form due to some unanticipated future  
> language change.
>
>
> A simple way to ensure this is to reserve a character as a language  
> escape,
> effectively it indicates that source code is at that point escaping  
> from the
> java language.
>
>
> Such a character should be a printable ascii character to enable it  
> to be typed
> and read, and it should have no existing defined meaning in the java  
> language
> within the contexts in which it is to be used.
>
>
> Inside commments, String literals and character literals all  
> printable ascii
> characters have meaning and therefore there is no way we can escape  
> from these.
> This is not thought to be an overly burdensome restriction.
>
>
> The candidate characters for the escape operator are therefore #  
> (hash), \
> (backslash) and ` (back quote). Neither # or ` have any currently  
> defined
> meaning in the Java language specification. \  does have defined  
> meanings but
> only as a unicode escape and inside String and character literals  
> and so is also
> suitable.
>
>
> The intention of this proposal is to reserve one of these three  
> characters for a
> range of uses that are outside the language. Although the syntactic  
> sugar
> example is mentioned above it is but one example. A crystal ball  
> would be
> advantageous here - alas we are limited to our ability to dream.
>
>
> Several proposals and ideas are circulating which suggest uses for  
> each of these
> few remaining characters which are becoming a precious resource for  
> language
> developers due to their scarcity. It is the author's belief that use  
> of any one
> of these characters as a language escape operator offers far more  
> long term
> value than use for a single new syntactic form. Let us reserve one  
> of the three
> characters as a language escape and let all other language proposals  
> squabble
> over the remaining two.
>
>
> For the rest of this proposal it is assumed the back-quote character  
> is the
> language escape operator. Either of the three characteres could be  
> used equally
> from a technical point of view however aesthetic considerations  
> would probably
> place # as least desirable.
>
>
> MAJOR ADVANTAGE:
> Shuts the gate before the horse has bolted. Once all these  
> characters are
> assigned meaning by the language, then there is no single character  
> that can be
> used as a language escape.
>
>
> MAJOR DISADVANTAGE:
>
> Prevents the back-quote (GRAVE-ACCENT) character from being used in  
> other
> language features.
>
> ALTERNATIVES:
>
> Alternative characters have been discussed above. Another  
> alternative is to do
> nothing and let language tools develop further (using any of the  
> three available
> characters) in order to get a slightly better idea of where this  
> might be
> heading before committing to a language change. The risk with this  
> approach is
> that all three characters might get defined uses by other language  
> changes
> before one can be reserved as a language escape. At that point it  
> would be too
> late and would restrict language tools.
>
> EXAMPLES
> SIMPLE EXAMPLE:
> `Property String name;
>
> is not valid Java source code, and can be automatically desugared by  
> an IDE. See
> references section.
>
>
> ADVANCED EXAMPLE:
>
>
> N/A
>
>
>
> DETAILS
> SPECIFICATION:
>
>
> Add new section 3.13 after 3.12 operators.
>
>
> 3.12 Language Escape
>
> The Ascii back quote ` character (unicode GRAVE ACCENT) is reserved  
> for use by
> tools that process mixed language content to indicate to their  
> parsers while
> parsing java source code, the start of something that is not Java  
> source code.
> It is the responsibility of such tools to pass only java source to  
> the java
> compiler.
>
>
> It is a compile time error for a ` character to appear in other than  
> a comment,
> a String literal or a Character literal.
>
> COMPILATION:
> Generate the error if the ` character is encountered in other than a  
> comment,
> String or Character literal.
>
> While the protoype does this, a more specific error message might be  
> useful.
>
> TESTING:
>
> Test for the compiler error.
>
> LIBRARY SUPPORT:
>
> No library support required.
>
> REFLECTIVE APIS:
>
> N/A
>
> OTHER CHANGES:
>
> N/A
>
> MIGRATION:
>
> N/A
>
> COMPATIBILITY
> BREAKING CHANGES:
>
> N/A
>
> EXISTING PROGRAMS:
>
> N/A
>
> REFERENCES
>
>
> http://docs.google.com/Doc?docid=dcvp3mkv_8sn3ccbkk describes a  
> working proof of
> concept tool which uses ` as a language escape.
>
>
> EXISTING BUGS:
>
> ?
>
> URL FOR PROTOTYPE (optional):
>
>
> JDK6's javac is the protoype implementation for this language change.
>
> http://java.sun.com/javase/downloads
>
>