Syntax snags for new users

[aiverson]

While getting some new people to learn terra and expanding projects in terra, I'm finding bits of syntax that are difficult and confusing to read and write, especially for new users.

One example of this is a splice in an array index. This introduces a syntax collision and produces a confusing error message. Because arr[[expr]] parses as a string call, it gives an error message that is nonobvious and doesn't help fix it. However, in a common case for implementing __entrymising with self[ [ fieldmap[entryname] ] ]the nesting of square brackets inside them selves is even more difficult.

Changing the brackets for a splice to |expr| would make this less confusing, and was suggested to me by one new user.

I'm opening this issue to collect a list of similar syntax snags and to discuss mitigating them by some combination of improving documentation, improving error messages, and changing syntax.

[ErikMcClure]

An alternative syntax might be {{expr}}, which is similar to the action syntax in Go templates, which is basically the same thing as an escape in Terra.

[aiverson]

That conflicts with constructing a tuple or anonymous struct.

[elliottslaughter]

We should have (in a separate issue, not this one) a discussion on what our backwards compatibility story is going to be. I'm torn on issues like these because they are paper cuts, but they also require backwards compatible changes (unless you propose to maintain two syntaxes, which is not without cost either).

[DarkWiiPlayer]

Since [exp] clashes with indexing and {exp} with tuple creation, my next idea would have been $(exp), which is a familiar syntax to (ba|z|.*)sh users, where it's already used for a sort of "multi stage" scripting (The output of one command becomes part of another command) and it wouldn't clash with any other Lua or Terra syntax.

Since $ isn't used anywhere else, a shorter version $exp could even be added for certain simple expressions.

Another option that should be mentioned, though I personally find it extremely ugly is `exp` as in Bash or Ruby.

[elliottslaughter]

I believe $exp is always unambiguous because exp must always be an expression (i.e. $exp $exp can be parsed unambiguously as $exp; $exp). Someone please correct me if I'm wrong about this. Of course $(exp) will be valid because (exp) is just a parenthesized expression.

The other option `exp` doesn't work because `exp is already the expression quote operator in Terra.

There is still the issue of having two syntaxes for the same thing though.

[DarkWiiPlayer]

what about $a + b though? is that $(a + b) or ($a) + b? I'd say it should be the second one (so the rule would be use to stop as soon as there's a valid expression), and if you wanted the first you should have to write the braces explicitly.

[elliottslaughter]

You'd have to pick the precedence, just like unary - and the ` operator. Probably I'd look at the latter to see what has been done so far. (I don't remember off the top of my head what the precedence of ` is.)

[OvermindDL1]

In every other language I can think of, the precedence would be ($a) + b.

[aiverson]

This also has a natural extension to basic string splicing, making a parallelism between splicing in a tree quote and splicing in a string quote. PHP made this syntax look terrible to me, but it does make sense.

And as for precedence and implementation. I'd just make it a prefix expression just like # which I believe accomplishes the desired goal.

[Vorlent]

I am perplexed that this hasn't been solved yet. Is a simple $[exp] too much to ask?

[elliottslaughter]

@Vorlent the way this project works is that interested parties push forward the efforts they care about. No one works on this project full-time; it is purely volunteer driven.

In this case, no one in this comment thread felt strongly enough to push through all the design and implementation issues.