[RSL] RSL update

[Kevin Bourrillion]

Sorry for the delay.

I do agree that this is in a reasonable place (and will save my quibbling
over the name "align" for later :-)).

Here are two more arguments in favor of language-level stripping:

1. Strings inside annotations aren't left out. Whenever an annotation
attribute feels like something users may want to use an RSL for, the best
we can hope for (if we don't have automatic unindenting) is for the
specification of that attribute to say "consumers of this data *really
should* call .align() on this" - quite unsatisfying, and we can be sure
most annotation specs won't bother.

2. When a parse method throws an exception identifying either character
position or line/column number of a parsing error, we would like our IDE to
correlate that back to the correct position in the source file where that
happened. This is necessarily going to be heuristic in nature no matter
what, but any post-processing of the RSL by libraries will make that
heuristic that much more dodgy. (aside: we may want to consider an
interface that such exceptions can implement, and retrofit
java.text.ParseException to implement it.) I don't think I'm being fanciful
here; I am definitely seeing that a majority of use cases in our codebase
for RSLs are embedding a language which will get parsed and can have
parsing errors, and I think shortening the debugging cycle for such errors
is virtuous.

I am still slow to convince myself that language-based unindenting is
absolutely definitely better; however, I do feel like the cited advantages
for library-based unindenting are just a bit questionable:

On Mon, Jun 18, 2018 at 8:52 AM Brian Goetz <brian.goetz at oracle.com> wrote:

Arguments in favor of the library approach:
>   - Many embedded languages don't care about indentation anyway (HTML,
> SQL, JSON);
>

This doesn't actually constitute an advantage; it is just saying that one
of the advantages on the *other* side can be weighted a little less.



>   - The string mangling algorithm is somewhat complicated (though less
> than it used to be) and subjective, both strikes against pushing it into
> the language;
>

I think that whether it is subjective is subjective. :-)  I think it is
actually quite simple, straightforward, and defensible. It's a minimal
bounding box of the visible text; it is reasonable to assume that what's
outside the box was probably never meant to be actual program data.



>   - If auto-alignment doesn't do what the user wants, it may be hard to
> get back to what the user does want.
>

I'm not sure why this is so. The only "mistake" it can make is removing
more space than you meant, but we're saying now that you should restore
that space explicitly/programmatically, so.....?

Do we have stronger arguments in this column than these?


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180625/ef9c36c6/attachment.html>