Add TwineScript version of `<<script>>`?

[tmedwards]

Currently, the only way to simply execute TwineScript‍† code is to use the <<run>> or <<set>> macros. This works well for single-line code snippets, but is less than ideal for multi-line snippets.

Ideally, there should be a better way to handle multi-line TwineScript code snippets. For example, either:

• A way to use TwineScript with the <<script>> macro. E.g., <<script type twinescript>>…<</script>>.
• <<script>> macro aliases specifically for JavaScript and TwineScript. E.g., <<javascript>>…<</javascript>> and <<twinescript>>…<</twinescript>>.

Thoughts?

-- † In SugarCube, TwineScript is simply sugared JavaScript. E.g., The TwineScript snippet $foo to true desugars to the JavaScript snippet State.variables.foo = true.

[SjoerdHekking]

I vote for option 2: it's faster to read/write, especially if you also allow for javascript, js and twinescript, tw, plus a lot less confusing for newer authors that might not understand arguments that well, e.g. script type javascript

[greyelf]

Why can't the current <<script>> macro just be altered to include support for TwineScript?

eg. what use-case(s) are there that require that the existing macro doesn't support TwineScript?

[tmedwards]

There is a non-zero chance that TwineScript may not desugar into JavaScript perfectly.

I'd prefer that end users who need/want JavaScript not have to worry about possible desugaring issues.

[ChapelR]

You could also do a flag/keyword on the existing script macro to make it execute TwineScript, instead of having two names, which might be better if you wanted to keep the <<script>> name for parity (such as it is) with HTML. Something like <<script twine>>...<</script>> maybe. Idk.

It's a good idea, though, I think.

In my dream SugarCube, it'd be cool to be able to do like <<run expression>>, or <<run>>expression<</run>>.

[tmedwards]

That was one of the options—well, not exactly that but the gist is the same.

 

In my dream SugarCube, it'd be cool to be able to do like <<run expression>>, or <<run>>expression<</run>>.

That's unlikely to work for expression type macros—edit: without more ambiguity than I'd like—but it's on my radar in v3 for argument types. Though the syntax would probably be a bit different. E.g.,

<<textbox $value />>

<<textbox $value>>
    /* Field was changed. */
<</textbox>>

This is one of those things that would work better, or more broadly, with a core syntax change—i.e., moving away from the <<…>> syntax.

[ChapelR]

That was one of the options—well, not exactly that but the gist is the same.

I guess I somehow blacked out for like 10% of reading the original issue, lol. That's my preference though.

Yeah, something like that would be cool in SC3!