String reboot - (1a) incidental whitespace

[Elias N Vasylenko]

If we design with our preferred IDE support in mind then Guy's box-of-
quotes proposal appears to be functionally equivalent to Jim's IDE-
highlighted-box suggestion.

Given two equivalent proposals I'd go with the one that delegates to
the IDE rather than complicating the language spec.

And if we do care about fallback behaviour without IDE support, even
just a little, it becomes a choice between:

- Box-of-quotes: Easy to read, horrible to edit.

- IDE-highlighted-box: Possibly tricky to read, easy to edit.

One more very minor point against the box-of-quotes: believe it or not
there is a small-but-non-empty set of people who prefer programming
with proportional fonts, no matter how perverse that may seem to the
rest of us. They wouldn't appreciate this feature!

On Wed, 2019-04-17 at 11:41 -0400, Guy Steele wrote:
> > On Apr 17, 2019, at 8:55 AM, Jim Laskey <james.laskey at oracle.com>
> > wrote:
> > 
> > To paraphrase McLuhan, I think that we need to keep the focus on
> > the rider and not the horse they rode in on.  This was the main
> > reason I pushed for backtick over triple double quote; making it
> > about the content and not the syntax around it.
> > 
> > In the Raw String Literal round, I suggested that
> > 
> > String query = ```````````````````````````````````````````````
> >                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
> >                WHERE `CITY` = ‘INDIANAPOLIS'
> >                ORDER BY `EMP_ID`, `LAST_NAME`;
> >                ```````````````````````````````````````````````;
> > 
> > might freak out some developers.
> > 
> > If you break this example down, the multiple quotes are not really
> > for the language, but instead for the eye of the beholder.
> 
> Exactly.  Which is why I think it’s an advantage that it can be
> supported as an optional and orthogonal extension.  When the
> programmer reaches the point where he cares more about readability of
> a reasonably final result than the ability to make changes easily,
> then a potentially easier-for-the-eye-of-the-beholder notation can be
> available.  I envision a programmer debugging code using Swift-stye
> multiline strings, and then later asking the IDE to turn it into a
> pretty box.  (If we do it right, this transformation is reversible so
> that the string content can easily be edited or replaced.)
> 
> > Alignment wise, all the language cares about is the first character
> > of each of the delimiters. The last character can be derived from
> > the longest line based on end of line.  So this reduces down to 
> > 
> > String query = ``
> >                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
> >                WHERE `CITY` = ‘INDIANAPOLIS'
> >                ORDER BY `EMP_ID`, `LAST_NAME`;
> >                ``; // need `` because of the enclosed backticks
> > 
> > or in the fat delimiter world 
> > 
> > String query = """
> >                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
> >                WHERE `CITY` = ‘INDIANAPOLIS'
> >                ORDER BY `EMP_ID`, `LAST_NAME`;
> >                """;
> > 
> > In the incidental whitespace discussion, this aligns with closing
> > delimiter influencing indentation.  Brian and I have been of four
> > minds on this, where I tend to favour closing delimiter influence
> > and Brian tends otherwise. My strongest argument thus far has been,
> > "Swift does it."
> > 
> > As you point out, management of literal boxing is nightmarish and
> > heavily reliant on IDE support, and I feel strongly that is a
> > problem.  I'm in and out of BBEdit , VSC, Atom, and Coda as much as
> > I am in Intellij.  The IDE answer doesn't work for me, and may not
> > for (many?) others.  What I do see is an IDE putting a light gray
> > box or a different background colour to highlight the "auto
> > aligned" string content.
> > 
> > Bottom line, closing delimiter influencing indentation provides the
> > same information as boxing with less hassle.
> 
> I am sympathetic to the hassle caused by lack of support from
> IDEs.  On the other hand, it’s a pity if sticking purely to current
> IDE capabilities causes us to be stuck in a lowest-common-denominator 
> situation forever.
> 
> I well remember when no IDE supported automatic indentation.  (In
> fact, I helped write one of the earliest automatic-indentation
> routines, for Lisp in Emacs).  Early programming languages such as
> Fortran 66 and BASIC did not have block structure and did not use
> indentation as part of their customary programming style.  Even when
> a kind of block structure was adopted in Fortran 77, programmers did
> not always use indentation to highlight it.
> 
> Languages such as Lisp and Algol and Pascal and C did have block
> structure (or parenthetical structure), and a lot of programmers wore
> out a lot of space bars on their keyboards doing their indentation
> manually.  It was a pain, but well worth the resulting
> readability.  It took many years before IDEs caught up, but
> eventually they all did, and now we take automatic indentation for
> granted; we would laugh at any program editor that did not provide
> it.
> 
> With that history, I bet if we added rectangle-strings to Java, it
> would be a pain for about a year, maybe less, but by then all IDEs
> would support it.
> 
> On the other hand, if the only thing that the rectangle-string
> proposal accomplishes is to get everyone to agree that trailing-
> delimiter conventions are acceptable, then it will have served a good
> purpose.  :-)
> 
> —Guy
> 
> 
> 
>