Kebab-case identifiers and the `@` sign in mlog identifiers

[cardillan]

Mindcode currently supports kebab-case identifiers. Primary motivation for kebab-case identifiers is that some mlog content identifiers contains them naturally (@blast-compound). The current syntax allows using the mlog content identifiers without the @ sign in some contexts, e.g. vault1.blast-compound. As mlog content identifiers can appear in various contexts, Mindcode has to support the kebab-case identifiers in general.

This causes two problems:

• Mindcode syntax currently doesn't support postdecrement operators. E.g. a-- is an identifier, not an identifier a followed by operator --. This is easily solvable by allowing dashes only on the inside of the identifier, not at the beginning/end, so surge-alloy would parse as an identifier, but foo-- wouldn't.
• a-b is different from a - b. The first one is an identifier, the other is an expression. I can't figure out a good solution for this, but I want to fix it.

Kebab-case identifiers are not a problem for contents identifiers, as long as they are prepended with the @ character: it is possible to parse @blast-compound as a single token, even when blast-compound would parse as blast - compound. It is, however, possible to declare all kebab-case identifiers for items and liquids (blast-compound, spore-pod etc.) as keywords. Then they would be correctly parsed with the dash inside in all contexts, but only those explicitly included in the grammar.

At this point, I'm considering two alternatives:

1. Declare keywords for the kebab-case content identifiers at the grammar level. The current syntax would remain the same, but if Mindustry, or some Mindustry mod, added a new content (say, dark-matter), it couldn't be used as a property name (vault1.dark-matter) without updating the syntax. It would still be usable as a content identifier, so vault1.sensor(@dark-matter) would compile correctly.
   • Pros: existing syntax works just fine, no need to update existing code.
   • Cons: users would naturally try the first form (vault1.dark-matter) and when it wouldn't work, they might not remember to try the seconds one.
2. Make the @ character compulsory at all places the content identifier might appear. This would mean it would be necessary to write vault1.@coal, or even vault1.@totalItems. To make thing consistent, we'd probably also require switch1.@enabled = true (note the @in @enabled).
   • Pros:
     • New content, even from mods, would blend in seamlessly.
     • The new syntax would be actually closer to mlog, where today's vault1.totalItems corresponds to sensor result vault1 @totalItems (note the @ in front of @totalItems in mlog)
     • The syntax would be more consistent (@coal would always appear as @coal, never just as coal only). Might even help with syntax highlighting.
   • Cons:
     • I don't really like vault1.@totalItems or vault1.@coal - but that is probably just a matter of habit.
     • Existing code would have to be updated a lot.

If we decide to go with the second solution (which does seem to have a bunch of advantages), there would be a transitional period in which both cases would be supported.

It would be great to hear what you think about this.

[cardillan]

I'm currently leaning towards the second option, for the consistency in provides. If someone can voice any arguments in support of the first solution, please do so.

[cardillan]

Setting a property in mlog is done without the @ sign:

control enabled block1 0 0 0 0

So, we'll do block1.enabled = true without the @ sign too.

It's going to be inconsistent in some aspect either way. There is control shootp, for example, but no @shootp property. We'll stick strictly to how things are done in mlog.

Using the built-in identifiers without the @ sign will generate a warning. I found it more user friendly than making it available in the relaxed syntax only.