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.

Hi. Any update / progress there ?
cheers

For a long time I could not think of a syntax for the extended MATCH that I would be happy with. But I think I finally got something (not implemented yet).

Similarly to specifying pairs of bracket characters, a third argument of CALM's MATCH could choose a special character to modify wildcard names with additional options, something like: Here "name/." would define the wildcard, with "." being the modifier (likely meaning that the wildcard must cut complete symbol identifiers). The special character would be chosen freely, so that it would not interfere with symbols required for the pattern: Such syntax would be extendable, as it opens up possibility of introducing more modifiers for the wildcards.

Note about the syntax of the third argument: currently it must consist of two characters, defining brackets. A single-character third argument is currently invalid syntax and can therefore be adapted to mean something else. And a three-character variant would allow to specify both options at once.

Hi Tomasz !
thx for feedback .. was kinda thinkin this topic was in limbo... happy to see i was wrong !
this sounds promising

quick questions :
1/ i would assume this 'new syntax' would then entail multiple such 'modifiers', typ to
allow matching vs various cases - or do u see it differently now ? :
* valid identifier of a symbol
* valid identifier of a symbol with symbolic value
* valid identifier of a symbol with symbolic value defined earlier in the source
+
same for identifier of struc / macro instruction
+
potentially also for maximum well-formed expression


2/ for potential modifier relating to 'symbol with symbolic value defined earlier in the source', how would that work vs fwd-referencing / asm passes ?
I mean would that exhibit same 'side effects' as previously discussed (typ. inducing potential multiple passes even if no fwd ref, due to case sensitity - similar to irpv, as u mentionned in some other thread)

Yes, potentially all of my previous protype operators like "__nameofpriormacro" could be re-implemented as wildcard modifiers, and greedy expression wildcard could also be possible. As for the multi-pass process, they would likely have the same side effects as their counterparts in the previous prototype.

Adding custom wildcards is tricky, though. Because making them too flexible would break some of the assumptions that allowed me to optimize MATCH, I have to put well-defined constraints on them. I need to proceed very carefully, thus the progress is slow.