On 2/9/2023 7:28 AM, Gavin Bierman wrote:
https://cr.openjdk.java.net/~gbierman/jep430/latest
Specifying the lexical and syntactic monster that we call a template
expression is no mean feat, so congratulations on 15.8.6. The
rejiggering of 15.8.6 that follows is mostly stylistic.
There's a lot going on in the first paragraph; compare with the first
paragraphs of 15.9 and 15.12 and 15.27, where less is more. The detail
about a template (e.g., n+1, n>0) is perhaps excessive, and unusually we
end up introducing "template" twice -- once as a "specification"
(brilliant word BTW) and later as something that "resembles either a
string literal ...". I would like to spotlight the novel fact that a
template expression delegates to a template processor to do work. I
would also like to dial down the grammatical device of "template
argument" and the string literal/text block possibilities -- people can
realize all that stuff from the grammar -- our job is to introduce
"template".
[Best to introduce a construct using the singular form, per the
style of 15.9, 15.10, etc.]
A _template expression_ provides a general means of combining
literal text with the values of expressions. The text and
expressions are specified by a _template_. The task of combining
the text with the expressions' values is delegated to a
_template processor_.
[Note] Simple interpolation of text and values into a `String`
is available from a predefined template processor, `STR` (7.3).
Other template processors may combine text and values in
arbitrary ways to produce a result of a more sophisticated
type than `String`.
[Grammar follows. A copy-paste error has crept in for the
recap of StringTemplateEnd and TextBlockTemplateEnd.]
A template is either a _string template_ or a _text block template_.
[The JLS needs to get those terms on the record.] A string template
(respectively, a text block template) resembles a string literal (a
text block) but contains ... If nothing appears ... [See 4.8 for
another use of this "respectively" idiom.]
A string template with _n_ embedded expressions (n>0) consists of the
alternate interleaving of _n+1_ fragments with the n embedded
expressions. The first fragment is a StringTemplateBegin token;
the next n-1 fragments are StringTemplateMid tokens; the last
fragment is a StringTemplateEnd token. [Here, with a syntactic-
grammar-derived StringTemplate in our hand, is where we finally
get to describe fragments in positional terms: first, next, last.]
A text block template with _n_ embedded expressions ...
[Four example interleavings follow. Please avoid the term "simple
string template". Can say: "Here is the breakdown of some string
templates:".]
[We have now fully described the form of a template. Time to
motivate and derive an artifact. I'm going to avoid switching
between "fragment" (which is a kind of token per 3.13) and
"fragment token". Bear in mind that 3.13 defined "the content
of a fragment".]
The _fragment strings_ of a template represent the literal text
that surrounds the embedded expressions. Fragment strings are
determined as follows:
- A string template with _n_ embedded expressions and _n+1_
fragments has _n+1_ fragment strings, where each fragment string
is the content of the corresponding fragment.
- A text block template with _n_ embedded expressions and
_n+1_ fragments has _n+1_ fragment strings, determined as follows:
1. The _string content_ of the text block template is ...
2. The string content of the text block template is further ...
3. The fragment strings s_1 .. s_n+1 are based on the string content
as follows: ...
[Continues from the fragment strings example.]
After the "At run time ..." evaluation procedure, please add a note:
That is, the meaning of the template expression
e . "_x_"
is equivalent to the meaning of the method invocation expression
e.process(y)
where y refers to an instance of java.lang.template.StringTemplate
that encapsulates both the literal text in x and the values of the
embedded expressions in x.
Alex
