Ink Syntax Specs

[micabytes]

As mentioned, I'm tinkering with an Ink implementation in Java, and it sounds like someone else might do something in Javascript (though perhaps it might make sense to join forces for that - depending on the implementation, a JS client could use the Java code).

Anyway, if it's OK, it might be useful to have a thread for questions/clarifications about the script intents. I've already run into a few things which are not covered in the docs.

[micabytes]

1. Keywords/IDs are all case-sensitive, correct? I don't see this mentioned anywhere in the docs (which maybe it should be), but I can see that inklecate seems to enforce this. Just want to be sure this is intentional.
2. Multiline comments '/* ... /' should actually not allow any text after the end of the final '/'. I think I saw this mentioned somewhere, but just wanted to be sure since inklecate allows this (but sometimes gives a warning about the "dangling text").

[micabytes]

Also an interesting wrinkle I've noted.

Your conditional choice syntax, is basically:

*   { variable } Some text 

This seems to have the side-effect that one can't insert variables or functions into the front of a choice. The following is invalid:

* { print_num(price) } dollars? Think of my seven children...

As is the following

+ { gavel_hit < 3} {&Going once|Going twice|Gone} -> gavel_hit

Since the second is assumed to be a conditional as well.

Working as designed, I expect, though at least the second case could conceivably be handled by the parser. Assuming you've encountered this issue in your writings, how do you typically work around them?

Also, I'm a bit surprised that this is legal:

* { true }
  { true }
  three

[joethephish]

Okaaaay, tackling each in order...

1. Yup, keywords are case sensitive
2. Actually, we do allow text after the trailing */. The reason being, to allow you to comment something out in the middle of the line. You may have noticed that the way we handle this is via two passes: first a separate whitespace-elimination parser is run, and then the main one is run.

3. Yeah, we hit that wrinkle too, and there's a couple of ways round it.:

   1. Simple repetition (if convenient). i.e. put the same content within square brackets as well as after them:

      * {condition} [{logic} Hello] {logic} Hello world

   2. Escape a space. Hacky, but not awful (and kinda looks like a separator right? :) ...

      * {condition} \ {logic} Hello []world

   Neither of these is beautiful, but it's a fairly unusual edge case, so we're pretty happy overall with it.

4. The multiple conditions thing is a feature. It's a way for the writer to write a set of preconditions over multiple lines. They simply boil down to one big "AND". We found the syntax really convenient in certain circumstances.

[micabytes]

Hadn't noticed that point about the comments. But makes sense. Must have misunderstood that earlier comment.

I thought about the repetition solution as well as the "obvious", if inelegant, solution. I'd assume you're right about it being a rare edge-case, though - it's just something I fell across as I was working through implementing examples as tests.

The multiple conditions thing is fine. The multi-line thing is annoying from a parsing POV, because it is inconsistent with how things work in every other aspect of the Ink syntax.