Another update follows closely, as I found a way to add another experimental ability to CALM's MATCH. I realized that in context of CALM modifying a wildcard with "?" is not really needed (because the identifiers in CALM are seen as uses, not definitions - only declarations of parameters and LOCAL statements are definition-like) and I had just a perfect feature that could use this syntax space - a wildcard marked this way can be matched with an empty text. This widens the gap between regular directive and more-capable command available to CALM, but the regular directive has only so little syntax design space available. And places where these features are most useful, should be better off using CALM anyway: Please keep in mind that any features that I add to MATCH need to respect the original design (which was first made for fasm 1). It based on an assumption that it should be possible to implement it in a way that would not allow for a potentially catastrophic backtracking. This is why every wildcard is said to match as little text as possible (so an optional wildcard is going to try to match empty text whenever possible), why literals cannot be optional, and why bracket checking option disallowed presence of the same brackets characters in the pattern. Such design allows matching to be performed with no real backtracking. The limitations require sometimes multiple MATCH commands to be used, but I believe this is still better than to have MATCH that might catastrophically backtrack.

One more little feature added: TRANSFORM can now take a second argument to identify and replace symbols from a specific namespace. This simplifies a trick I've been using to recognize size operators in x86 instructions (although performance gain there is negligible), but I believe it can be even more useful in other places, while it required almost no effort to implement (because it uses an option that fasmg engine had anyway). Note that the namespace base is resolved at compilation time.

I think the language of CALM is mostly complete, though. One thing that I considered but did not make it into language is a way to call another CALM instruction directly (without having to pass through ASSEMBLE). I may revisit the idea further in the future, but so far I did not see enough advantage in having it.

Hello. After some time, I've just encounter a problem in my project.
It's just a little question . In this code:

A it's expanded to $00. So everything work fine but with the initsym in place of arrange the result is different.

I don't understand why the symbolic variable "A" is defined in the scope of "nested" CALM and not in the "test" CALM.
I really sorry if this was answered somewhere.
PS: I don't known if it's a normal behavior but you can define stuff like that:

space can be replaced by dot?
Thx in advance.

It is related to something I have written a few posts backs: The ARRANGE command does not add context information to the symbols it copies literally from pattern, and then it see no defined value associated with symbol, it just treats it as literal. So "A" in the "buffer" has no context associated with it when you prepared it with ARRANGE, and so the current context is used at the point when what command is executed. It would be safer to write "arrange buffer, initsym =A, $00" there instead, as then it does not depend whether there is some "A" symbol defined that ARRANGE could use for value replacement. The way you used it there without "=" is actually a fallback mechanism, that could even be made to show an error message.

When you instead use INITSYM, it gets called like a macro, so the values of arguments carry their original context - in this case the context of "nested" instruction, because that's where the INITSYM has been called. This text of argument is then assigned as-is to the variable, and the command you get in "buffer" ends up having a different context for "A".

Also, in both cases the command you execute from buffer is another INITSYM, which then again adds context to the text that did not have one already. So in the first case, when "A" in "buffer" had no context associated yet, in becomes equipped with the context of "test", while in the second case it already had the context of "nested" and packing it into another one changes nothing.

In practice, in many cases this carrying of recognition context works so naturally that you don't really notice it. But with ARRANGE you should remember that the context is stripped from the symbols in the pattern. Although I could make it so that when name is not preceded by "=" but no value is found for that symbol, it could be copied as a name with additional context, but this would not be reliable. I'm still considering adding an error message, though.

These are all valid modifiers, each with specific function, as defined in section 2 of the manual. A final "." appended to the identifier ("place?.") and a starting "?" character ("?.holder?") are two different modifiers. The appended dot allows to re-define a symbol visible in current scope (which may be a symbol from some external namespace) instead of defining a new local one. The question mark at the start of identifier can enforce it being a label-like symbol, for example when the name is numeric. And the ":" that separates the two identifiers is a modifier for macro/instruction definitions that means defining a recursive instruction.

Ok thx you Thomasz.

Yes, I'm sorry. At the time of reading, I didn't understand the original "meaning".

In fact, I said this because with macro in place calminstruction, this not work. I didn't know that a dot can follow a question mark.

In case of macros, the arguments need to be preprocessed parameters, so they cannot use sub-namespaces, etc. Here the arguments are just symbolic variables, and you can use dot operator in their identifiers. The same goes for LOCAL (as opposed to macro's LOCAL, which has to use simple parameter names).

BTW, if I add an error message for ARRANGE when it does not find a defined symbol, would it break much for you? I tried it and I see that it helps to catch bugs in instructions. In fact, it showed me several mistakes in x86 headers, and now I'm convinced I should make it more strict this way.

Yes, why not. This might be more "user-friendly", I guess .

Initially I thought it could be nice to release CALM officially once the version string reaches "it...", to have a clear-cut boundary. Then I changed my mind and released it early (encouraged by all of you that started using it immediately!). But perhaps a final, stable release is going to be "it..." after all.