PROPOSAL: Language Escape Operator

[rssh at gradsoft.com.ua]

1.  But feature without 'semantic' of use is quite useless. I. e. until
processing of 'escaped part' in java program is not standardized, I will
be able redistribute and show such code only with knowledge about extra
tools and how they are applied.
  I.e. to be practical, at least process of defining and applying such
extra tools must be described somewhere. (something like call of
annotation processing interface from compiler)

2. Yet one linked 'bug' in JLS: Behaviour of java compiler is not defined
at all. (Annotation processing is described in man page, not in JLS
itself, so, strictly it's not part of Java language)

//(Hmm, submit issue about this ?)


> 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
>
>
>