(removed)

[dfabulich (Dan Fabulich)]

@tayruh

I wanted the story text to be your focus, not the script. The entire reason I chose to use a bazillion tokens was because languages like SugarCube and ChoiceScript become difficult to read for me when you’re forced to parse out the reserved words when reading your story. The code and the dialogue all blend together and it becomes messy. This is not an issue in normal programming where the reserved words intentionally stand out because the rest of the code is all tokens and numbers. Writing interactive fiction requires a different kind of syntax priority, IMO.

This is a really crucial point. ChoiceScript started with the theory that there would be a sigil at the start of a line to indicate “this is a line of code.” In ChoiceScript, all code lines begin with a command, each of which starts with a *, so if a line starts with *, it’s code, and otherwise, it’s text.

Only later did I decide to add ${} inline variable replacements, which allow some code to intermingle with text on the same line, and then, reluctantly, I added @{} multireplace, which absolutely does have the problem you describe of intermingling code and text.

What convinced me to go with ${} was that the syntax was pretty distinctive, and that it’s straightforward to write a syntax highlighter for it, and typically only a single token (a variable name) would appear in the braces, so it would be fairly legible regardless. (I think @{} might have been a bad idea, but it was highly demanded.)

I wonder whether the moral of this story, especially apropos the accessibility thread from the other day, is that hypertext source (text containing inline links) is inherently hard to read.

I think hypertext is particularly hard to read when the “link” is really acting as a button that runs a few short lines of code. In React JSX, you can write:

You can click <button class="link" onclick={(e)=>e.preventDefault(); const foo = getFoo(); setBar(foo + 1);}>here</button>
to make the thing happen.

But this totally blows up the flow of the sentence. Generally speaking, people recommend that you define a quicky function elsewhere:

const clickHandler = (e) => {
  e.preventDefault();
  const foo = getFoo();
  setBar(foo + 1);
}

return <div>You can click <button class="link" onclick={clickHandler}>here</button>
  to make the thing happen.</div>

That’s somewhat better, but it’s still pretty hard to read the sentence. Your approach of cramming the code into a few short (but not-yet-taken) bits of punctuation represents a totally different approach. It seems to me that it would be much harder to learn, but it might be easier to use if you can mentally recall what the punctuation does.

But if you don’t use inline hypertext, if you just don’t embed buttons in the middle of your story text, the problems mostly just go away, including some of the more serious accessibility issues.