First, as quick feedback on those operators, I do find those pretty nice and useful indeed ! tx !

Some further questions / remarks :
1/ one thing that I feel is still missing is a was to check "computability" of expression in CALM:
i mean, pretty often, when doing sthg like : compute var, val,
I wish there could be and option to have flags set to track and process or log malformed expression in val
i/o fasmg simply failing with 'invalid expression' msg (which could be anywhere in the middle of calm code...)
... maybe sthg like : compute ? var, val
-> if successful, then valid computation numerical result readily available in var
-> computation success / failure testable via jyes / jno
-> "traditional"compute behavior preserved
.. this is also a way to check if val is of numerical type
... happy to get comments


2/ back to above operators, are they going to make it to "official" distribution ?
what do you have in mind there ?
do you think they could somehow be "factorized" ? talking bout 8 new operators....
i mean esp the 3 pairs __nameofequ / __nameofpriorequ, __nameofmacro / __nameofpriormacro, __nameofstruc / __nameofpriorstruc ...
... cud somehow be "fused" with defined / definite ?
... sthg like defined _name xxx / definite __name xxx, defined __nameofmacro xxx / definite __nameofmacro xxx, ...

Yes, I have been hesitating to integrate it into the main line, because I'm not fully satisfied with the execution. While it nicely utilizes the perks of compiled expressions, it is only fun if one understands how all the underlying mechanisms work. It would not be easy to explain this in the manual in a non-tiring way, and CALM already has enough rules that require careful description. And I don't consider it a crucial feature - keep in mind that I made the entirety of fasm2 package without ever needed anything like this. Therefore, I felt I can comfortably wait until I come up with something better.

In particular, a family of condition-checking operators cannot provide all the capabilities I would want from such addition to the language. Instead of checking whether something is a valid name or a complete expression, I would prefer to have the ability to cut such name or expression off a longer sequence of tokens. Because of that I'm now considering switching to actual ALM commands - with an added value of not cluttering the global namespace, allowing to choose cleaner names. Such commands would provide more abilities than just simple checks, while allowing to be used to purpose of said checks when needed.

The experimental branch is therefore still just that, and I'm going to be testing other solutions, without any hurry.

A side note about COMPUTE: the main purpose and strength of this command lies in its ability to evaluate precompiled expressions (everything that follows the comma at the time when CALM instruction is defined). While it can also parse and evaluate expressions embedded in variables as a tokenized text, it is a secondary function, and not especially advantageous, because the text goes through the same processing as normally for classic fasmg's commands. That's why from my point of view COMPUTE is not a good place for language additions related to parsing tokenized text of an expressions - in fact, even MATCH might be a better home. For example, the third argument of ALM MATCH could be extended so that it could state that matched segment needs to consume a complete identifier or a maximum well-formed expression. It is in fact one of the variants I've been considering, and quite promising.