Kodi Arfer

Kek, yeah, I've had that experience of convincing myself the other way in the middle of trying to sort out this kind of issue. I would be open to special-casing...

Since regular macros and reader macros get separate namespaces as well as seperate syntax for defining them, `require`ing them, etc., there shouldn't be issues with having both a regular macro...

Aw geez, we already have both regular macros and reader macros. I think adding a third type of macro solely to ease a perceived whitespace issue is going too far....

After all, it is Lisp; syntactic regularity over readability is a choice we should be used to making.

@scauligi This issue is fulfilled, right? Since `HyReader.__init__` sets up the `reader_for` methods as reader macros.

As I understand, the current setup should work just fine if we later add some ability to introspect or override core reader macros. Whether they're written in Hy or Python...

This is probably outside the scope of Hy itself.

I'm working on a game for this, but I haven't put it on GitHub yet because so little is implemented.

It's up at https://github.com/hylang/simalq. I'll close this issue when it's more mature and I've added links to it from hylang.org or the documentation.

Better support for introspection of the macro system could replace `hy.reserved` and perhaps also `delmacro`.