3 ms·

Being semantically equivalent is not sufficient, because performance matters - concat(a,b) is just "{a}{b}" if and only if a compiler is sufficiently smart to r

Being semantically equivalent is not sufficient, because performance matters - concat(a,b) is just "{a}{b}" if and only if a compiler is sufficiently smart to reduce it to the minimum of operations needed, avoiding having to parse the format string every time that line is invoked, avoiding having apply runtime introspection to find out mapping between variable name "a" and the location of that string, etc, etc - without that, it makes all sense for there to be an explicit concatenation and programmers choosing to use that instead of a more general format string.

Olreich 3y ago
Semantically, these say the same thing, so all of those concerns exist for “concat(a, b)” too. Avoiding having to parse the concat every time the line is invoked, avoiding having to apply runtime introspection to find out mapping between the variables and their locations, etc.
josefx 3y ago
> because performance matters - concat(a,b) is just "{a}{b}" if and only if a compiler is sufficiently smart to reduce it to the minimum of operations needed If I remember correctly these kinds of format strings have to be resolved by the compiler since they refer to variables in the source by name, which is information most languages do not keep around at runtime and a security nightmare if done dynamically. Also performance sensitive language like C aren't exactly known for a fast strcat, it is usually left as an exercise to the user to avoid catastrophic runtime behavior caused by the eternal search for nul.
- matheusmoreira 3y ago
  I suppose format strings can be transformed into a series of concatenation function calls. Or a single n-arity call. (format "{a} {b} cde {f}") Could be a macro that returns: (concat a " " b " cde " f) The non-trivial part seems to be replacing the original format call site with the compiled version in the code. When I try to think it through, I conclude that everything should be a macro that outputs a compiled program. Just seems wrong in a dynamic language but it seems people do it all the time: https://news.ycombinator.com/item?id=39240528 https://news.ycombinator.com/item?id=39240528 Partially evaluated programs.
int_19h 3y ago
It is really not a problem for even a very simple compiler to rewrite "{a}{b}" into a simple function call. I'm not sure what you mean by "runtime introspection" in this context, because literals with embedded expressions don't require any runtime parsing or lookup - such a literal is parsed completely at compile-time, and in languages with lexical scoping, all variables etc are resolved then. It really is just syntactic sugar for concatenating; it's not at all like runtime templates.
lolinder 3y ago
String interpolation is not the same as C-style format strings. Format strings live in userland as part of the standard library and have the many drawbacks you note. Proper string interpolation is part of the language grammar itself, and the bits between the braces are usually full-fledged expressions that resolve variable names the same way that every other expression does. Since it's a language construct, it's trivial for it to just compile down to a series of concat(a, b) operations. It sounds like Python had a half-complete string interpolation mechanism until this PEP, so I can understand why there'd be confusion on this point, but that is a problem with Python's implementation, not something that is an inherent risk with string interpolation. In a new language it is easier to implement string interpolation properly than to introduce a half measure like Python's.

Olreich 3y ago

Semantically, these say the same thing, so all of those concerns exist for “concat(a, b)” too. Avoiding having to parse the concat every time the line is invoked, avoiding having to apply runtime introspection to find out mapping between the variables and their locations, etc.

josefx 3y ago

> because performance matters - concat(a,b) is just "{a}{b}" if and only if a compiler is sufficiently smart to reduce it to the minimum of operations needed If I remember correctly these kinds of format strings have to be resolved by the compiler since they refer to variables in the source by name, which is information most languages do not keep around at runtime and a security nightmare if done dynamically. Also performance sensitive language like C aren't exactly known for a fast strcat, it is usually left as an exercise to the user to avoid catastrophic runtime behavior caused by the eternal search for nul.

matheusmoreira 3y ago
I suppose format strings can be transformed into a series of concatenation function calls. Or a single n-arity call. (format "{a} {b} cde {f}") Could be a macro that returns: (concat a " " b " cde " f) The non-trivial part seems to be replacing the original format call site with the compiled version in the code. When I try to think it through, I conclude that everything should be a macro that outputs a compiled program. Just seems wrong in a dynamic language but it seems people do it all the time: https://news.ycombinator.com/item?id=39240528 https://news.ycombinator.com/item?id=39240528 Partially evaluated programs.

int_19h 3y ago

It is really not a problem for even a very simple compiler to rewrite "{a}{b}" into a simple function call. I'm not sure what you mean by "runtime introspection" in this context, because literals with embedded expressions don't require any runtime parsing or lookup - such a literal is parsed completely at compile-time, and in languages with lexical scoping, all variables etc are resolved then. It really is just syntactic sugar for concatenating; it's not at all like runtime templates.

lolinder 3y ago

String interpolation is not the same as C-style format strings. Format strings live in userland as part of the standard library and have the many drawbacks you note. Proper string interpolation is part of the language grammar itself, and the bits between the braces are usually full-fledged expressions that resolve variable names the same way that every other expression does. Since it's a language construct, it's trivial for it to just compile down to a series of concat(a, b) operations. It sounds like Python had a half-complete string interpolation mechanism until this PEP, so I can understand why there'd be confusion on this point, but that is a problem with Python's implementation, not something that is an inherent risk with string interpolation. In a new language it is easier to implement string interpolation properly than to introduce a half measure like Python's.