Directives and expression syntax

[lexikos]

I don't understand why directives do not use expression syntax. Maybe it has been discussed somewhere.

That would require something like:

• parsing and evaluation of expressions before the script starts executing, perhaps even before the script's structure is actually valid;
• parsing and "evaluation" of a very limited subset of expression syntax; or
• some other fundamental change to how directives work.

Consider what directives exists:

• #MaxThreadsBuffer, #SingleInstance, #UseHook and #Warn take one or more keywords, and there seems no reason to allow built-in variables (non-built-in variables would be empty). "Expression syntax" would be just adding quote marks.
• Likewise for #MenuMaskKey, except that it takes a key name (including vk/sc syntax, so not really one from a list of keywords).
• #If accepts an expression, but the expression isn't evaluated until later, such as whenever a hotkey is pressed.
• #Hotstring accepts keywords and possibly a list of symbols. Using expression syntax here complicates that.
• #Include/Again accepts a library name or path, with optional variables. It would probably be better to interpret a subset of expression syntax, although an explanation of this subset may be more complicated than the current documentation. "Enclose variables in percent signs" is very straight-forward, and fairly familiar, both because of v1 and because of environment variables used in paths. (But maybe that also implies some risk of confusion, since it doesn't accept environment variables.)
• #SuspendExempt (which was added for v2) accepts a subset of expression syntax (literal True, False, 0 or 1).
• All other directives have no parameters or accept literal numbers; again, a subset of expression syntax.

Directives are fundamentally different to statements/expressions. They are much more limited, and are generally validated more effectively (at load time), so even if you get the syntax wrong (writing unnecessary quote marks or attempting to use a function call, operator or variable), it's not much of an issue.

Basically, the cost (in terms of development time and increase in code size) versus practical benefit does not seem favorable, especially while there are more important and interesting things to work on. However, I will probably change them before the v2.0 release.

[just me]

• #Include/Again accepts a library name or path, with optional variables. It would probably be better to interpret a subset of expression syntax, although an explanation of this subset may be more complicated than the current documentation. "Enclose variables in percent signs" is very straight-forward, and fairly familiar, both because of v1 and because of environment variables used in paths. (But maybe that also implies some risk of confusion, since it doesn't accept environment variables.)

I think that #Include/Again is the only directive which might need a 'special handling'. The "risk of confusion" is not "... since it doesn't accept environment variables". It's just that "enclose variables in percent signs" is a double-ref in all other cases in v 2.

[guest3456]

unnecessary imo

[lexikos]

It's just that "enclose variables in percent signs" is a double-ref in all other cases in v 2.

%var%() isn't a double-deref.

[just me]

%var%() isn't a double-deref.

It's another exception and source of confusion.

Edit: It's using the value stored in var as a name, just like result := %var%.