PROPOSAL: Language Escape Operator

[Bruce Chapman]

Reinier Zwitserloot wrote:
> The problem then is: When does the special magic end?
Yes I wrestled with that issue, but in the end I decided it was not up 
to java to specify where the magic ends, and the java restarts. It is up 
to whatever starts to specify that. If you were to attempt to specify 
the end, you must be certain that the end was not actually valid content 
for any possible use of the escape operator. I believe that to be 
impossible, unless the java tools are to interpret the content and pass 
it to the other tool. That is a restriction on how the tools work 
together which I do not want to make - and doesn't fit the example use case.

 The Java compiler has pretty good heuristics for determining where to 
attempt a restart of parsing once a error is detected. At this stage I 
would not want to specify any more than that.
>
> If there is no end, then this is no different from a 'language' 
> indicator at the top.
There is a difference if it doesn't start at the top. If it always 
starts at the top (by which I presume you mean the beginning of the 
source file - but you seem to be labouring this point so maybe I am 
misunderstanding you) then its not java source code.
>
> I am very much in favour of editing a vanilla java AST that involves 
> lots of sugaring, but I don't think such an operator is neccessary or 
> even useful for it; all those backticks would become mighty ugly fast. 
> Also, because you're doing AST editing, those backticks aren't 
> anywhere on disk, so they become a keystroke to indicate: The next few 
> things I'm going to type are definitely intended as non-java sugar 
> that you should java-ize for me.
>
> Two things come to mind:
>
> 1) That's what cmd/ctrl/alt is for. Typing a backtick on most keyboard 
> is very difficult; I'd rewire a cmd+something to generate it instead, 
> easier on the fingers.
On my standard US ascii keyboard its just a single keypress, no shift, 
no ctrl, just `

For the example use the intention is make make it feel almost as good as 
if the syntax sugar was in the language. yes you could use a magic key 
combination in this particular case, but that would skip your brain out 
of the "laying down code" mode, and into the editing and driving the IDE 
mode, that context switch takes quite a lot of effort. Writing experts 
suggest that if you are writing, just write, if you are editing, just 
edit, to swap back and forth frequently, even pressing backspace to fix 
a typo is really really inefficient.

For other possible uses of the language escape I cannot comment but I 
suspect some at least will work with files that are a mix of content.
>
> 2) *any* IDE that is going to do this correctly also needs to know all 
> about java. Therefore, if an IDE can only handle up to java6 
> (+AST-based sugaring), and you want to type something java7, which so 
> happens to also be legal sugaring, then - that's only a minor pain. 
> You can't use java7 in this IDE, it doesn't know the syntax. It's 
> unfortunate that this AST sugar now needs to find another syntax, but 
> isn't that part of the point of AST sugaring? Ease of switching 
> around? I really doubt any kind of AST sugaring system is going to 
> make 'start with a backtick' a prerequisite.
I presume you are talking about the specific sugaring example and not 
the use of language escape operator in general. The way I envisage the 
sugaring  working is that the tool will load a regular java source file 
and for any code constructs that happen to match the desugared form of a 
particular loaded syntactic sugar, and if that sugar was defined in such 
a way as to always collapse to the sugared form when a file is loaded, 
then (and only then) would it be shown in sugared form. If someone else 
opened the file without the sugar definition loaded, they'd just see the 
long form. IF they edited that so that it no longer matched the sugar 
definition, and the original user reloaded the file, it wouldn't be 
shown in sugared form because it wouldn't match. The sugared form is 
JUST A VIEW, an EDITABLE VIEW, but still JUST A VIEW.

There is no prerequisite for any tool to use the backtick. By making it 
a compiler error, we reserve the opportunity for tools to use that if 
that is deemed the best strategy for the particular tool. There is 
nothing prescriptive about this other than the compiler error which is 
already the case, I just want to make sure it remains the case in the 
future.


Bruce
>
>
>  --Reinier Zwitserloot
>
>
>
> On Mar 27, 2009, at 04:13, brucechapman at paradise.net.nz wrote:
>
>> Quoting Reinier Zwitserloot <reinier at zwitserloot.com>:
>>
>>> 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:
- SNIP -