confusing points about token types
A couplefew things:
- If users are expected to use the TT_* names everywhere else, it makes sense for them to use the TT_* names when calling H_MAKE. Currently, the H_MAKE macro adds the TT_ prefix on its own. I expect this is because the implementation of the underlying h_make function expects itself to be used only for user-defined token types, thus shielding the user. Given the nascent token-type registry, however, I believe this is destined to (and should) be changed.
- I understand that folding the TT_ prefix into the macro body is intended to make the H_MAKE_SEQ, etc macros look more or less the same, but I still think it's confusing to use the TT_ some places but not others.
- Also given the nascent token-type registry, I think it makes sense to provide an another wrapper for h_make that interacts with it. Perhaps an "H_MAKE_USER" macro would do the trick, taking a string and doing the registry lookup within. Though perhaps a full-on function might be better.
- That said, were I allowed to be super-greedy, I'd love to see exactly one token-creation entry point that expects an int, and exactly one wrapper that expects a string and converts it to an int via a registry lookup. That said, I totally see how it's more efficient to do it this way (though I think it might be worth at least investigating how much prettier the code is vs. how much slower it performs). What I wouldn't give for pattern matching in C!
I'm happy to write code for any/all of this, but I don't want to start digging in without some discussion/approval from the powers-that-be. =)