On Monday, 9 April 2018 at 15:30:33 UTC, Stefan Koch wrote:
On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote:

I think Walter's reason was that such macros would hide too many idiosyncrasies in how they were programmed, such that a lot of code which seems simple on the surface will actually obfuscate complicated and arbitrary macro-programming patterns. Thus, code that uses them will become much less maintainable, because it is liable to do so many different and hidden things. Also, the tasks for which AST-macros would typically be used are already largely accommodated by templates and other features. Thus, the real need for them isn't that high.

I think it's time to revisit this.

The reason being that templates are only well suited to very specific types of meta-programs which have a low degree of parameterization and a low degree of abstraction.

Using templates to introspect and manipulate types is like using a hammmer's flat back to remove a nail.
It _can_ be done but with an absurd amount of work.
You just have to remove all of the wall around the nail by pounding it until the wall has around the nail is disintegrated :)

This is not an exaggeration.

Templates used for introspection (or anything else really that's modestly complex) are equally hard to reason about for compilers and for programmers. I guess programmers have an advantage when it comes to _efficient_ pattern recognition.

Wouldn't AST macros require either to standardize (and freeze) AST representation within the compiler or to maintain an equally frozen alternate representation to be exposed? I can't see how that wouldn't make the compiler's development slower since all of a sudden changing the internal representation would impact user code, especially given the low number of breaking changes that are accepted today.

I have little experience with AST macros outside Lisp where its homoiconicity avoids the issue almost completely so pardon the naive question.

Reply via email to