To align, or not to align?
brian.goetz at oracle.com
Thu Apr 18 16:39:44 UTC 2019
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
- 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
- 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
Now accepting arguments one way or the other. (Not yet accepting
comments on syntax.)
More information about the amber-spec-observers