#177 Don't want implicit mmac parameter expansion
Attached is a simple test case that shows how the consequent introduction of the macro indirection operator %[...] affected existing code. Note that really expanding list1 and list4 here (such as in the db, or for %warning) ends with an "interminable macro recursion" error, which makes macro indirection necessary for such lists. (Anything involving %assign still works without it, because it always expands.) To produce the expected result (a list consisting of "0,1,2,3,4") you additionally have to use list3 (not list2), i.e. put a macro indirection around the smac to be appended too. Otherwise, the smac's name is appended, not the smac's value.
That's all well (besides breaking existing macros), but unfortunately mmacro parameters still are implicitly expanded. I have some mmacros that would ordinarily require their parameters unexpanded and thus currently only work with an ugly workaround. Thus, I request that either mmacro parameters should require explicit macro indirection as all the smacros do now, or there should be an alternative way to access macro parameters without implicit expansion.
I'll also attach a file which shows the basic reason why my mmacros need mmacro parameters without implicit expansion, and how they fail currently with the implicit expansion. My current workaround is shown too.
List creation with the preprocessor: Shows how macro indirection is required.
Implicit parameter expansion does not allow parameters to be used as smacro names for %define verbatim.