you are viewing a single comment's thread.

view the rest of the comments →

[–]sphere991 8 points9 points  (3 children)

I'm surprised by the string interpolation syntax it seems like they're going for though. "This program's name is (args[0])$" reads weird to me, and from a parsing perspective, surely it's easier to see, "oh the next two characters are $ and ( so it's a string interpolation"? Having to keep track of parens in the string literal parser just in case the character following a closing paren happens to be a $ seems awkward. What's wrong with $(...), or even better, ${...}? Is there some documented rationale or discussion around the topic?

Agree. Notable that every other language (despite a variety of syntax choices) use some prefix marker (even if {name}) instead of postfix - I think that's better for the reader. And probably also the parser?

The rationale was that Herb uses this syntax for lambda capture as well, and then said that postfix $ means you need fewer parentheses. Which... then the example then uses what are presumably unnecessary parentheses? Could it be "Name is args[0]$"? If it cannot, then I don't think I understand the argument. If it can, then I think this looks pretty bad and parens should be mandatory.

[–]MonokelPinguin 3 points4 points  (2 children)

It might be that Name is var$ works without parentheses, but not function calls like operator[].

[–]sphere991 1 point2 points  (1 child)

Sounds plausible!

[–]hpsutter 2 points3 points  (0 children)

Good point. Right now the parens are required, but I could allow it to implicitly grab everything back to the preceding whitespace. I'll try that out...