To align, or not to align?

[Guy Steele]

Sorry to make trouble, Brian, but I am going to argue that the question posed may be a false dichotomy, because it makes an unstated prior assumption that I think needs examining one more time: it seems to make an assumption that the syntax of a multiline string begins with a delimiter, that the syntax ends with a delimiter, that ** the _content_ of the multiline string consists of the _entire_ sequence of characters between the delimiters **, and that ** the job of align-by-default is to adjust that content (according to some rules) **.

There is an alternate approach that views the _syntax_ of a multiline string (whatever it may be) as having a somewhat richer structure that includes both “content” and possibly also explicit indications of the user’s intent as to alignment.  (In such a design “align-by-default” is not necessary.)

I worry that framing the question as “align-by-default” versus “no align-by-default” implicitly discards consideration of this alternate approach.

Are we in fact already firmly committed to the idea that that the syntax of a multiline string, at least as initially implemented, necessarily consists of an unbroken sequence of characters, all of which constitute string content, sandwiched between exactly two delimiters?  If the answer is “yes”, then my concern is addressed and I will withdraw my objection.  I just want to be reassured that the question has been considered and that the answer is “yes”.

—Guy


> On Apr 18, 2019, at 12:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I think we're at a point where we're ready to make the next big decision.
> 
> So far, we seem to be converging on a reasonable definition of "alignment" for multi-line strings, modulo a few small choices (e.g., what to do about single-line strings, etc.)  Jim has posted a prototype.  This could be exposed as either a language feature, or a library feature, or both.
> 
> The question we're now ready to confront is: how should a user indicate that they do, or do not, want alignment?  Options include:
> 
>  - Align by default, with some sort of opt-out
>  - Do not align by default, with some sort of opt-in
>    - Opt in could just be a library invocation, such as `String::align`
>    - Opt in could be a linguistic marker
> 
> (Note: we are not ready to discuss syntax yet, we're still discussing how the language works.)
> 
> Arguments for align-by-default:
> 
>  - General feeling (hopefully to be bolstered by data soon) that _most_ embedded ML strings are "programs" in languages like HTML, XML, JSON, YAML, SQL, etc, which naturally use indentation and users will generally want to strip off the incidental indentation caused by embedding in Java source.
> 
>  - Incidental indentation is a natural, but accidental, consequence of embedding ML strings in a program.
> 
>  - Early feedback included plenty of complaints about "why do I have to say `.align()` all the time?"
> 
>  - We don't want to leave users with a perceived bad choice: either say `.align()` explicitly, or mangle your source code to not have incidental indentation (making it look bad), or live with extra indentation.
> 
> Arguments against align-by-default:
> 
>  - The language should provide a _simple_ facility for string literals; the complexity of alignment does not belong in the language.
> 
>  - Alignment is not always what the user is going to want; even if it is, the built-in alignment algorithm may not be exactly what the user is going to want.
> 
>  - It is not an orthogonal decomposition; we're tying ML-ness to alignment.  The language should expose primitives that the user can combine compositionally.
> 
>  - It interacts badly with string concatenation.
> 
> 
> Note that the "for" arguments are mostly pragmatic, and the "against" arguments are mostly principled.  (That is not to say we shouldn't decide for "for"; this feature is, after all, purely about user convenience, since these strings can be expressed already in the existing language.)
> 
> Now accepting arguments one way or the other.  (Not yet accepting comments on syntax.)
> 
>