Proposal: Embedded Expressions for String Statements

Jeremy Manson jeremy.manson at gmail.com
Sun Mar 15 14:06:17 PDT 2009


Fair enough.  I guess I'm too used to that; I just put parentheses everywhere.

On the flip side, I'm not a big fan of \{ as a delimiter.  It seems to
me that there should be a way to unify the general desire for better
String handling (escaped Strings, multi-line Strings, embedded
expressions).  Can we colonize the ` (back-tick) character and start
Strings over again from scratch?

Jeremy

On Sun, Mar 15, 2009 at 1:23 PM, Neal Gafter <neal at gafter.com> wrote:
> By properly nesting the embedded expressions, it helps address
> precedence puzzlers such as this
>
> System.out.println("2 + 2 is " +
>        2+2);
>
> Which declares that 2+2 is 22.
>
> On Sun, Mar 15, 2009 at 12:57 PM, Jeremy Manson <jeremy.manson at gmail.com> wrote:
>> Hi Stefan,
>>
>> I'm sure this is obvious to everyone who isn't me, but I'm not sure
>> what the big win is here.  Basically, it looks to me as if you save a
>> very small number of keystrokes:
>>
>>  String name = "Dave";
>> Old:
>>  System.out.println("Hello, " + name + "!");
>> New:
>>  System.out.println("Hello, \{name}!");
>>
>> ADVANCED EXAMPLE:
>>  Object product = produce();
>> Old:
>>  log("We " + (product == null ? "failed" : "produced " + product) + "!");
>> New:
>>  log("We \{product == null ? "failed" : "produced \{product}"}!");
>>
>> Again, I'm sure there is a motivation here, but I'm not exactly sure what it is?
>>
>> Jeremy
>>
>> On Sun, Mar 15, 2009 at 12:15 PM, Stefan Schulz <schulz at e-spirit.de> wrote:
>>> Howard mentioned it before, embedding expressions might be a nice thing
>>> to have in Java. The simplest thing is to embed variables to print their
>>> value.
>>> The proposal is not at the same level as Multi-line Strings, as it does
>>> not result in a construction of a String Literal but rather offers a
>>> "short cut" for building complex Strings.
>>> To at least have a basis for discussion, I set up a proposal that IMO
>>> could fit in the scope of COIN.
>>>
>>> Stefan
>>>
>>>
>>> Proposal: Embedded Expressions for String Statements
>>>
>>> AUTHOR(S):
>>>
>>> Stefan Schulz
>>>
>>> VERSION:
>>>
>>> 1.0    Initial version.
>>>
>>> Formatted version:
>>> http://docs.google.com/Doc?id=ddhp95vd_11dv7rmrcp
>>>
>>>
>>> OVERVIEW
>>>
>>> FEATURE SUMMARY:
>>>
>>> Often, textual output is constructed of a mix of plain text and values
>>> resolving from expressions. An escape sequence allows embedding such
>>> expressions into a string. If the result of the expression is no String,
>>> it will be converted to one.
>>>
>>> MAJOR ADVANTAGE:
>>>
>>> Improves readability and eases String construction.
>>>
>>> MAJOR BENEFIT:
>>>
>>> Reduces the cluttering in writing textual output.
>>>
>>> MAJOR DISADVANTAGE:
>>>
>>> May encourage to write one-liners with many expressions inside a String
>>> construction.
>>>
>>> ALTERNATIVES:
>>>
>>> Write strings the old way by using concatenations or using builders.
>>>
>>>
>>> EXAMPLES
>>>
>>> SIMPLE EXAMPLE:
>>>   String name = "Dave";
>>>   System.out.println("Hello, \{name}!");
>>>
>>> ADVANCED EXAMPLE:
>>>   Object product = produce();
>>>   log("We \{product == null ? "failed" : "produced \{product}"}!");
>>>
>>>
>>> DETAILS
>>>
>>> SPECIFICATION:
>>>
>>> The new escape sequence \{ will be handled at compile time by
>>> transforming the string statement into a concatenation of Strings.
>>> Neither can the statement be understood as a String literal nor is it an
>>> escape sequence in the sense of representing a single character literal.
>>> Therefore, the transformation has to be done prior to any other escape
>>> sequence handling.
>>>
>>> Changes are required in the JLS §3.10.5 "String Literals" and 3.10.6
>>> "Escape Sequences for Character and String Literals". Although the new
>>> escape sequence does not form a part of a String literal, it must be
>>> stated that it's a legit escape sequence with the consequence of making
>>> the string sequence become a statement rather than a literal.
>>>
>>> A new chapter is to be introduced on embedding expressions in string
>>> sequences, which closely relates to §15.18.1 "String Concatenation
>>> Operator +". The syntax would be as follows:
>>>
>>> EmbeddedExpressionStatement:
>>>   " StringCharactersAndExpression StringCharactersOpt "
>>>
>>> StringCharactersAndExpression
>>>   StringCharactersOpt EmbeddedExpression StringCharactersAndExpressionOpt
>>>
>>> EmbeddedExpression
>>>   \ { Expression }
>>>
>>> Note: The sequence "\{exp}" is deliberately chosen as it resembles the
>>> way other languages provide a similar ability, e.g., JavaFX ("{exp}"),
>>> PHP, Python and Groovy ("${exp}").
>>>
>>> COMPILATION:
>>>
>>> In general, the statement will be transformed into a concatenation of
>>> literals and expressions. In the following, the String Concatenation
>>> Operator is being used, but maybe replaced by a StringBuilder solution.
>>> The latter might be easy to do, as the transformation happens before
>>> literal processing.
>>>
>>> Transformed simple example:
>>>   String name = "Dave";
>>>   System.out.println("Hello, " + name + "!");
>>>
>>> Transformed complex example:
>>>   Object product = produceSomething();
>>>   log("We " + (product == null ? "failed" : "produced " + product) + "!");
>>>
>>> TESTING:
>>>
>>> The transformation has to be tested to resolve to the expected old style
>>> way of concatenating Strings. The cases should cover simple variable
>>> references (null, primitive, String, and Object) as well as simple and
>>> nested expressions (including nested expressions with Strings having
>>> embedded expressions).
>>>
>>> LIBRARY SUPPORT:
>>>
>>> None.
>>>
>>> REFLECTIVE APIS:
>>>
>>> None.
>>>
>>> OTHER CHANGES:
>>>
>>> None.
>>>
>>> MIGRATION:
>>>
>>> Replace existing old style concatenation by applying the new escape
>>> sequence.
>>>
>>>
>>> COMPATIBILITY
>>>
>>> BREAKING CHANGES:
>>>
>>> None. The escape sequence \{ would prior have caused a compiler error.
>>>
>>> EXISTING PROGRAMS:
>>>
>>> No changes.
>>>
>>>
>>> REFERENCES
>>>
>>> EXISTING BUGS:
>>>
>>> (Although it is to be assumed there are existing bugs/rfes, the search
>>> did not pop up results for the keywords used. So this remains to be done.)
>>>
>>> URL FOR PROTOTYPE (optional):
>>>
>>> None of yet.
>>>
>>>
>>>
>>
>>
>



More information about the coin-dev mailing list