Eliminate forward declarations for recursive macros.

[gilch]

Recursive macros currently require an explicit forward declaration. The template quote has to know at read time if an unqualified symbol should be qualified as a global or as a macro. In principle, defmacro shouldn't need this, because the macro name is provided. But by the time defmacro knows the symbol for the new macro, read time has passed and the template is already qualified.

[gilch]

I should mention that the forward declaration is only required if the recursive macro invocation isn't qualified. But remembering to qualify it yourself is no easier than a forward declaration. The defmacro machinery should be able to do it for you somehow.

Making defmacro a reader macro wouldn't help, because inner reader macros evaluate first when composed, and unlike compiler macros, are not recursive.

Making defmacro expand to the forward declaration and then the definition in a progn doesn't work either, because read time has already passed at that point.

Some possible solutions:

Option 1: Make template symbol in the function position expand to something like (hissp.._macro_.qualify foo) to postpone the decision about how to qualify it until compile time. When the qualify macro expands, it can check the current macro namespace. No changes are required for the compiler. But this will complicate the output of templates even more, making them harder to read and manipulate programmatically. And it changes the compile time type from a string to a tuple (which is arguably no worse than quote, but still). And I think defmacro would still have to expand into a forward declaration in a progn. If someone wants to implement their own more capable defmacro, this is a requirement they might miss.

Option 2: Make the templates always qualify symbols in the invocation place as a macro, and then make the compiler itself fall back to evaluating it like a global if there's no macro with that name. This is already similar to how the compiler handles unqualified symbols: assume macro first, and then fall back to global. It would make sense to assume an unqualified symbol in a template would act the same way. I like this better, however, it is confusing to see an explicit _macro_ qualification in a template when you intended a global, or to see an explicit _macro_ identifier evaluate as a global. Seems like it could cause or hide bugs in user code, which is not nice. And it would add yet another logic path to the compiler and reader, when I'm trying to avoid any bloat.

Option 3: Make the templates qualify symbols in the invocation place in some third way, like xINVOKE_ or xAUTO_ or something, and make the compiler use the "macro first, then global"-fallback logic for those. This helps with most of the problems from option 2. It's a little extra magic, but it's more consistent magic.

[gilch]

duplicate of #55