If the calm language can provide isofunctionality to the really important classic macro language features (at the price of writting more code) then, for the sake of "ultimate" consistency (since the calm language is a "macro" assembly-like language), why not eat the bullet: port fasmg "std lib" to calm and drop the classic macro language.

The "price" seems to be that for a calm instruction, it is not that straight forward to understand what assembly code is generated compared to its equivalent classic macro instruction.

I wonder if there are constructions which are more intuitive in the standard macro language without much benefit in calm implementation? Or maybe it is desirable to have both a brief scripting language like the classic macro language as well as a more verbose, fine grain language like calm?

This is probably just my classic macro bias talking though.

"Removing" the classic macro language could bring serious cleanup and simplification to fasmg code structure and "specs". And as you said, since we already write assembly, our eye will be already trained to read calm macros.
But, I presume calm can do most if not all of 'classic macro'... and I may be very wrong for obvious reasons I am not seeing right now.

I would calm down with any language that is not assembly because creating new languages is a hobby and it's something fun from the author's point of view, unless you are ready to switch to a new language in a year and a half, you should stay calm and wait.

The author has not planned for calm, it came instinctively. And it's this instinct that you should be cautious with because it will force you to switch to a new language in about a year and a half from now.

If calm came about from an old plan that was written down in a rusty old document, I would try calm, but because it came out of the toilet on a random sunday, I suggest you will wait.

You know, it's not very wise to learn a new language every year and a half. He is an innovator at heart and he loves what he do, if you love something, you don't want to say "This is good enough". He will of course continue and create something even better the next time and the question remains whether or not calm will be compatible with that, time will tell.

What I DO know for sure is that I think he is moving forward too fast, I think he should seriously sit down a saturday night or choose which day you want, and really try to come up with something that can make assembly more peaceful and interesting. We need more non-macro keywords.

Forget the "Every idea must come out RIGHT NOW so everybody can read it" scenario.

People have unique opportunities to make assembly something, but time is short, one should not waste time in doing it the wrong way. This requires INTENSE focus and every nerve cell in the body must be on alert on this quest.

Intense focus is not enough, imho. Some things can only be learned in the process - race a few laps around the track to get some data. This is especially true with complexity - so many interdependent parts - language features that work with other language features, etc. Using the language intentionally leads one to an understanding that it was not so carelessly thrown together as you suggest.

The whole "forcing to switch" attitude doesn't seem valid. Tomasz has even demonstrated ways to migrate between different forms of assembly - both from a language specific perspective and systems perspective. It would be an understatement to say he's a very talented programmer.

It's not unusual for assembly programmers to want different language features - that's why macros exist. What non-macro keyword do you need?

I'm for innovations that remove things and reduces complexity.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery

Hardcoded keywords in the assembler takes away a ten word macro and in return it gives you a one word keyword.

Keywords are the luxury of assembly, don't forget them. Don't be ruled by them, but neither should you forget about them.

If you build your house on sand, you risk the whole house collapsing. Instead, build it on a mountain, unless you have a digger and (modern) sement.

Every idea must be processed intensely before it makes it to the panel of judges, or else it ends up being discouraged with criticism and everything rots.

I still don't know enough about CALM to "see" if it provides iso functionality to classic macros.
I have not tried to rewrite the classic macros from my current project using CALM, but I don't think it will be pertinent in giving me more perspective since those macros are really simple.
If you are building experience on CALM coding, it would be very valuable to have feedback here.
Like I was lurking on ELF TLS support (and got scared away by its broken design), I am lurking on ELF dynamic executable support (PIE), that without the usage of an external linker... and such support would have to be written using CALM, I guess.

---- edit

There is also the 'going full case sensitive', that would remove as a whole the case sensitive/insensitive logic from fasmg 'specs', which could lighten to some extend fasmg implementation.