3 ms·

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics

by kothar 4y ago

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

aardvark179 4y ago
Bingo!
layer8 4y ago
More specifically: https://news.ycombinator.com/item?id=35016204 https://news.ycombinator.com/item?id=35016204
dmitriid 4y ago
This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.
- zelphirkalt 4y ago
  PHP never stood out as a language with very clean syntax. It is very PHPesque to put the burden on the user of the language instead of going the extra mile and implement something that might be harder to parse, but would be more consistent. Inonsistency in general is one of PHP's issues.
- sirsinsalot 4y ago
  if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding. Then being walled in by backwards compatibility
  - colejohnson66 4y ago
    Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?
    - sirsinsalot 4y ago
      I do not, it'll be in whatever version control php is in though I'm sure. Another absolute horror parser was the wikipedia wikitext parser. An ambiguous hand written mess of epic disgust.
kevincox 4y ago
But you need the `FOO.` prefix anyways. So there was never any ambiguity. It seems that it would be good to either make the prefix optional (presumably something equivalent to the `STR.` processor would be default) or keep the interpolation syntax clean. (IMHO just `STR."Hello {name}!"` would have been ideal). But instead they require both the prefix and the ugly interpretation syntax.

by kothar 4y ago

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

aardvark179 4y ago

Bingo!

layer8 4y ago

More specifically: https://news.ycombinator.com/item?id=35016204 https://news.ycombinator.com/item?id=35016204

dmitriid 4y ago

This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.

zelphirkalt 4y ago
PHP never stood out as a language with very clean syntax. It is very PHPesque to put the burden on the user of the language instead of going the extra mile and implement something that might be harder to parse, but would be more consistent. Inonsistency in general is one of PHP's issues.
sirsinsalot 4y ago
if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding. Then being walled in by backwards compatibility
- colejohnson66 4y ago
  Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?
  - sirsinsalot 4y ago
    I do not, it'll be in whatever version control php is in though I'm sure. Another absolute horror parser was the wikipedia wikitext parser. An ambiguous hand written mess of epic disgust.

kevincox 4y ago

But you need the `FOO.` prefix anyways. So there was never any ambiguity. It seems that it would be good to either make the prefix optional (presumably something equivalent to the `STR.` processor would be default) or keep the interpolation syntax clean. (IMHO just `STR."Hello {name}!"` would have been ideal). But instead they require both the prefix and the ugly interpretation syntax.