Core macro expansion order switch from outside-in to inside-out by default

[azazel75]

Hello,

I'm using macropy and I stumbled on an unexpected problem last week when using a moderately complex patterns macro like this:

    with switch(cls_or_seq):
        if (ast.Tuple(elts=classes) | ast.List(elts=classes) |  # noqa: F821
            ast.Set(elts=classes)):  # noqa: E129,F821
            args = tuple((tgt, c) for c in classes)  # noqa: F821
            return JSMultipleArgsOp(JSOpInstanceof(), JSOpOr(), *args)
        elif q[str]:
            return q[typeof(ast_literal[tgt]) == 'string' or  # noqa: F821
                     isinstance(ast_literal[tgt], String)]  # noqa: F821
        elif q[int] | q[float]:
            return q[typeof(ast_literal[tgt]) == 'number' or  # noqa: F821
                     isinstance(ast_literal[tgt], Number)]  # noqa: F821
        else:
            return JSBinOp(tgt, JSOpInstanceof(), cls_or_seq)

strangely, I thougth that this would work but the switch macro is expanded before the others and complained about all the (unexpanded) q macros in its body. So I looked up the docs and found out about the default expansion order and the possible work-around of using expand_macros() inside to top macro and i was thinking if/how best use it. Here are a few thoughts that came up:

• I don't want to reimplement every macro that I use that may contain other macros just for the sake of calling expand_macros() on the sub-tree;
• For the general use, I find more natural if inner macros were expanded first, am I wrong?
• Even the way of wrapping that switch macro inside another that "jumps over" the outer one and expands its body seemed a little fragile to me

So I've reimplemented the core logic of the expansion process to be inside-out by default, with an option for interested macros (like those in tracing.py) to reverse this process. Unfortunately I had to rewrite almost all of it, the previous implementation didn't fit in my brain sorry.

To anyone still interested in this project and using it in Python3 (3.3+) can you please have a look at my fork here and tell me what you think? @lihaoyi are you still interested? I hope so

I haven't created a pull request for this because my fork has diverged a little too much, while being still a target for a fast-forward.

P.S. I still have to update the docs

[lihaoyi]

@azazel75 I'm not interested, but if you are I can give you admin to this repo so you can continue the work with the existing mindshare MacroPy already has.

[azazel75]

Yes, I'm interested! I think that the best thing though would be to for you to create a new organization (MacroPy?), move this repo to it and add me to the organization. What do you think?

[lihaoyi]

Passed you contributor access for now; feel free to go wild with the repo

We can figure out how to set up an org later