Any reason template string with empty interpolation placeholder (`${}`) throws?
Doesn't necessarily seem like a bad idea. I could be on board with that.
It is an unnecessary special case. The empty string is a valid statement (aside from the semicolon) but not a valid expression. The syntax of what appears between the curlies is expression.
Having it default to the empty string makes no sense. Why not 0, false, null, or undefined? Remember that template strings can be used to make arbitrary objects using any DSL that your tag knows how to parse. There's nothing about template strings that is about strings in either the substitution values or the result values.
If you want the equivalent of ${''}, just say ${''}.
Cute, but nobody is realistically going to do that.
Possible valid uses for the empty placeholder:
- Contents of expression commented out, maybe debugging if it causes side effects which may be harmful
- Expression is a placeholder, with contents soon to come (mentioned by OP)
The DSL thing is a non-issue, because the empty expression didn't need to be included in the list of expressions, and if it is included, DSLs can be smart enough to deal with it, and should probably be implemented as a recursive descent parser on top of the interpolated text anyways
Ease of use, ease of debugging, ease of editing. Users of JS don't make the distinction between a Statement and Expression or ExpressionStatement, and interpolated strings are very much about strings.
If there were to be a value for ${}, undefined makes more sense to me than the empty string as a default “nothing” value.
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Caitlin Potter Sent: Thursday, October 22, 2015 19:20 To: Mark S. Miller <erights at google.com>
Cc: es-discuss at mozilla.org
Subject: Re: Any reason template string with empty interpolation placeholder (${}) throws?
Cute, but nobody is realistically going to do that.
Possible valid uses for the empty placeholder:
- Contents of expression commented out, maybe debugging if it causes side effects which may be harmful
- Expression is a placeholder, with contents soon to come (mentioned by OP)
The DSL thing is a non-issue, because the empty expression didn't need to be included in the list of expressions, and if it is included, DSLs can be smart enough to deal with it, and should probably be implemented as a recursive descent parser on top of the interpolated text anyways
Ease of use, ease of debugging, ease of editing. Users of JS don't make the distinction between a Statement and Expression or ExpressionStatement, and interpolated strings are very much about strings.
On Oct 22, 2015, at 7:05 PM, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
It is an unnecessary special case. The empty string is a valid statement (aside from the semicolon) but not a valid expression. The syntax of what appears between the curlies is expression.
Having it default to the empty string makes no sense. Why not 0, false, null, or undefined? Remember that template strings can be used to make arbitrary objects using any DSL that your tag knows how to parse. There's nothing about template strings that is about strings in either the substitution values or the result values.
If you want the equivalent of ${''}, just say ${''}.
On Thu, Oct 22, 2015 at 6:31 PM, Caitlin Potter <caitpotter88 at gmail.com<mailto:caitpotter88 at gmail.com>> wrote:
Doesn't necessarily seem like a bad idea. I could be on board with that.
On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter <caitpotter88 at gmail.com>
wrote:
Cute, but nobody is realistically going to do that.
Since ${} is a static error, what do you realistically think people will
do? Especially if they meant ${''}, how do you expect them to react to
the static error?
Possible valid uses for the empty placeholder:
- Contents of expression commented out, maybe debugging if it causes side effects which may be harmful
- Expression is a placeholder, with contents soon to come (mentioned by OP)
The DSL thing is a non-issue, because the empty expression didn't need to be included in the list of expressions, and if it is included, DSLs can be smart enough to deal with it, and should probably be implemented as a recursive descent parser on top of the interpolated text anyways
Ease of use, ease of debugging, ease of editing. Users of JS don't make the distinction between a Statement and Expression or ExpressionStatement, and interpolated strings are very much about strings.
A surprising static error is better than a dynamic error that silently
violates programmer expectations. If I saw ${} and did not know what it
means, I would sooner guess undefined than ''.
Code that matters is read more often than it is written. By making ${} a
static error, we spare readers the hazard of trying to guess what this rare
edge case would do.
Okay, but usability wise, this kind of sucks. There's a reason it's not what people expect, and why other languages with string interpolation behave differently.
JavaScript does not have string interpolation. It has arbitrary value interpolation.
(oops, sent from wrong account)
On Oct 22, 2015, at 4:55 PM, Mark Miller <erights at gmail.com <mailto:erights at gmail.com>> wrote:
On Thu, Oct 22, 2015 at 7:20 PM, Caitlin Potter <caitpotter88 at gmail.com <mailto:caitpotter88 at gmail.com>> wrote: Cute, but nobody is realistically going to do that.
Since
${}is a static error, what do you realistically think people will do? Especially if they meant${''}, how do you expect them to react to the static error?
Just like they do if they have a line of code that reads:
str = ;
when they meant
str = ‘’;
It’s just a syntax error. I probably have syntax errors in 50% of the lines that I initially type. I parse, and then fix.
JavaScript does not have string interpolation. It has arbitrary value interpolation.
Disagree. foo ${bar} baz is string interpolation. ${bar} becomes ToString(bar). Tagged templates were an addition that weren’t really needed. Since they exist, great, people can come up with some clever uses for them. But they’re hardly the common use case, which is definitely string interpolation
On Thu, Oct 22, 2015 at 8:54 PM, Caitlin Potter <caitpotter88 at gmail.com>
wrote:
JavaScript does not have string interpolation. It has arbitrary value interpolation.
Disagree.
foo ${bar} bazis string interpolation.${bar}becomesToString(bar). Tagged templates were an addition
That is not the history.
that weren’t really needed.
Disagree. They were and are the main motivation. The fact that the unmarked case does string interpolation is just icing on the cake.
The history does not matter. It doesn’t make a difference what someone presented or argued for to a room full of people. What matters is how they’re actually used in practice.
There are some libraries which do some clever things with them. They are not common, there are not a lot of them, and they don’t necessarily perform their tasks easier than a simple recursive descent parser would.
The main use is absolutely string interpolation.
I’m not making a claim about history, I wasn’t in the room when they were presented. It’s a claim about creating something that was never really needed by the vast majority of users. It’s nice to have, but it’s not the most useful aspect of template literals/quasi literals. It makes the spec more complicated, and makes changing it more difficult (particularly in this case, where it could change the # of expressions passed to a tag, depending on how it were spec’d, if it were ever added to the specification).
It’s clearly something that most programmers have no use for in their own projects. While it is certainly nice to have, I don’t think it can be considered the main point. It does little to make anyones work simpler, whereas multiline strings and ${…} expressions are easir to read and understand, compared to how they were done previously.
On Thu, Oct 22, 2015 at 7:34 PM, Caitlin Potter <caitpotter88 at gmail.com> wrote:
Okay, but usability wise, this kind of sucks. There's a reason it's not what people expect, and why other languages with string interpolation behave differently.
Perl and bash both treat "${}" as a syntax error. So does Python's string.Template().
I think it would be a mistake to sweep this kind of situation under the rug. Pointing out a place where the programmer started to type something but then never finished it seems like a good thing.
Pardon my lack of use of proper terminology.
This is kind of annoying working with large template strings. When I leave an interpolation placeholder(what's the right name?) empty it blows up all my code.
Can it be forgiving like Ruby and CoffeScript and just replace it with empty string?