To align, or not to align?

[Kevin Bourrillion]

On Thu, Apr 18, 2019 at 9:42 AM 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.
>

I wouldn't have used this particular argument, as these parsers usually
ignore extra indentation anyway.



>   - Incidental indentation is a natural, but accidental, consequence of
> embedding ML strings in a program.
>

It is exactly that. That rectangular zone of incidental indentation
"belongs" to the high-level structuring of the file. It shouldn't be viewed
as belonging to the specific string literal being defined in that location.


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

To drill in on "making it look bad", what's happening is that a local
choice to use one kind of string or another is doing damage to the
perceived *high-level* organization of the file.



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

This argument lacks meaning unless we delve into what is really meant by
"simple". We all know that simple to use, simple to read, simple to
explain, simple to write up in a language spec, etc., all mean very
different things.


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

This simply says there should be a way to opt out, which I don't think is
controversial. So in other words it doesn't seem to say anything.


  - It is not an orthogonal decomposition; we're tying ML-ness to
> alignment.  The language should expose primitives that the user can
> combine compositionally.
>

Interesting!  I think this is exactly opposite to what's really going on.

Here's how people think of their program indentation. When I open a block,
I increase it by N. When I close a block, I decrease it by N. Continuation
line, maybe +2N. I move in and out based on what's happening locally.
However, I have no care at all for what the current absolute value of that
indentation is.  Maybe it's 10, maybe it's 14, whatever; that value is
irrelevant to me, it simply emerges from how nested I happen to be.

Indentation stripping is precisely what *preserves* that independence.

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