A sigil to access properties of the setup object

[ezsh]

Could you, please, add a third sigil to the TwineScript that maps identifiers to the properties of the setup object? And make it read-only. Or even a way to add user-defined sigil to map to a user-provided object?

[tmedwards]

I'd really rather not for a few reasons. I'd rather keep the set of sigil-/sugar-ed variables to those that are special in some way, which the setup object is not. I'd also rather keep the set of sigils to symbols that valid as part of an identifier, and both of those are already in use.

I can only assume that you find typing setup.[…] onerous. If so, couldn't something like the following work just as well?

/* Place in Story JavaScript or the equivalent. */
Object.defineProperty(window, 's', {
    get : function () {
        return setup;
    }
});

Usage:

s.foo = () => console.log('bar');

s.foo();
setup.foo();

Yes, it has to be a legal identifier—but I'd require that anyway—and, yes, you have to use an access notation—dot or square bracket—but it's close to what you want and entirely under your control.

[ezsh]

I'm asking about a new sigil because my intention is to use it in the naked variable markup. Something like:

Engine.registerObject('^', myObj);

So then I could simply use in the passage text (<<print ^todayWeather>>).

[ezsh]

Right now I use a hack creating a property on State.temporary, but that has an obvious bad implication.

[tmedwards]

Given your stated intention, would the template markup not work?

E.g., template definition:

Template.add('todayWeather', function () { … });

Usage:

It's ?todayWeather outside.

That wouldn't work for non-markup usages, but I'm unsure if you really need those or not.

[ezsh]

Templates can only return strings, right? I would like to access the object equally easy in the passage text as wells as in conditions and assignments (<<set>>). Of course, that can be done now with templates plus regular objects, but then macro arguments will be written differently as comparing to the transparent objects (templates) in strings. That would make non-obvious the fact that they point to the same data bits / functions.

It would be nice to use the same consistent notation for all the cases. That's why I proposed to add just one more sigil to address the setup object. Maybe a general case with registering user provided objects provide a better flexibility for authoring text, but at the same time it would make a lexer significantly more complex, or the set of allowed sigils has to be fixed. All in all, the simplest implementation with the setup would solve the problem, I don't know whether the general solution worth the efforts to implement in the SugarCube and in SugarCube syntax analysers for editors.

[tmedwards]

My primary concern with adding new TwineScript sigils, for any purpose, is that any sigil-bearing identifier sugar must be distinguishable from valid JavaScript—e.g., your example sigil from above (^) is unsuitable because it cannot be cleanly disambiguated from the bitwise XOR operator (^).

While there are certainly readily accessible symbol characters that could be suitable—e.g., @—I would prefer to ensure that future additions to JavaScript's own syntax do not compromise the integrity of SugarCube's TwineScript sugar. This is why both of the current sigils ($, _) are valid identifier characters, specifically part of IdentifierStart—it's unlikely that they could be made ambiguous wrt. TwineScript sugar without also being ambiguous within JavaScript's own syntax. To my knowledge, no other readily accessible symbols have that basic safeguard.

My fear, which is possibly overblown, is that a syntax addition that breaks TwineScript sugar will make it through the (ECMAScript TC39) committee's approval processes if I don't remain within the relatively safe identifier space—I mean, they haven't been shy in adding new syntax lately.

[ezsh]

They already adopted #, maybe it is safe to use it now?

[tmedwards]

Are you referring to the hashbang grammar? If so, then that's not a bare hash (#) symbol, but, and as the name implies, a hash (#) immediately followed by a bang (!). While that does probably limit how likely they are to use the # symbol for other purposes within valid JavaScript in the future, it's no guarantee. Still, I suppose that does alleviate some of my concerns on the matter wrt. that symbol.

There is an additional issue, however. In the currently TiddlyWiki-flavored style markup, the # symbol is the ordered list markup. Beyond that, for SugarCube v3, I'm seriously considering switching to Markdown-flavored style markup, which uses # for ATX heading markup. The issue there is that if the naked variable markup were to made to support such sigil'd variables it would create ambiguity with those markups.

One possible solution to that issue would be to simply not have the naked variable markup support it, which would require the use of <<print>>, but I'm unsure how I feel about that.

[ezsh]

I meant the private fields. But anyway, when thy symbol is already taken by the list markup, it does not matter.

[tmedwards]

Ah. So they finally made up their minds as to what they are probably doing with private fields, eh. Well, that's good.

I couldn't parse that second sentence.

[ezsh]

No matter how well the # suits the sigil requirements, it cannot be used as a sigil because it is used in another markup element.

[ezsh]

On a second though, for the lists in the SugarCube and Markdonw, the # symbol has to be followed by a whitespace, while for the sigil use case there may be no whitespace.