On 3/13/2024 10:48 AM, Archie Cobbs wrote:
I was intrigued by this comment (Maurizio):
> Another, simpler, option we considered was to use some kind of
prefix to mark a string template literal (e.g. make that explicit,
instead of resorting to language wizardry). That works, but has the
disadvantage of breaking the spell that there is only “one string
literal”, which is something we have worked quite hard to achieve.
What exactly is the advantage, in terms of the mental model of the
programmer, of having "one string literal"?
When we started doing text blocks, we did a survey of string
literal-like features in other languages, and were a little concerned
that a lot of languages had a proliferation of different kinds of
strings with different rules. (An example of "different rules for
different kinds of strings" would be that $ is a regular character in a
string literal, but an escape character in an interpolated string.)
Before we figured out the design center of text blocks (think
"two-dimensional string literals"), there were a number of envisioned
extension directions for string literals -- multi-line, raw, embedded
expressions, etc. And because these extension directions are
orthogonal, there could easily be 2^n kinds of string literal. We
didn't want to put users in a position of having to choose between e.g.,
"raw" and "multi-line", nor did we want to risk there being interactions
between the rules for these different sub-kinds.
One technique we use to tie together these various forms is by having a
common sub-language within the quotes; each of the forms uses the same
set of escape sequences (though this set is extended with
context-specific options, such as \{ for templates.) Another is the
delimiters; they are all "double-quote flavored", again to provide a
sense that these are all projections of the same core literal feature.
The more we wander from this center, the more we risk ending up with
locally-sane but globally-inconsistent sub-features.
Maybe I'm just not seeing it.
I can understand the advantage of having String <: StringTemplate -
that gives me more flexibility when passing around objects - great!
But do I need that same flexibility with /literals/?
Consider how we handle float vs. double literals. They overlap for
32-bit values, which is very convenient, but you can also "force" a
narrower interpretation by adding an "f" suffix. That seems like
pretty much the best of both worlds to me.
So is this an analogous situation? Then we'd allow a StringTemplate
literal to have an /optional/ "$" prefix:
obj.takingString("abcd"); // ok - string
obj.takingTemplate("abcd"); // ok - template
obj.takingStringOrTemplate($"abcd"); // ok - template
obj.takingStringOrTemplate("abcd"); // ok - string or template
(personally I don't care)
obj.takingString($"abcd"); // fail
obj.takingTemplate($"abcd"); // ok - template
obj.takingString("x = \{var}"); // fail
obj.takingTemplate("x = \{var}"); // ok - template
Thanks,
-Archie
--
Archie L. Cobbs
