Crystal: The policy on availability of ASTNode methods in macros

Created on 7 Sep 2016  路  2Comments  路  Source: crystal-lang/crystal

It seems that the set of methods available on type nodes in macros is inconsistent.

  • and and or can be split to their subexpressions, but with unary ! you can't get the expression it wraps.
  • .as is readable but .is_a? isn't.
  • There are random omissions, like block and splat arguments not being available on def.
  • And what's so special about case? Why is it available when many smaller and more frequently used nodes aren't?

I think it is important to define a policy on what is available and what isn't, and then proceed to fill the gaps (I can help with that).
I don't see a reason to have arbitrary limits in exploring the structure of expressions passed to macros. Sure, not everything is applicable, at least it's clear that not being able to modify the nodes is part of the current policy, but not much else seems to be well-defined.

So, what is the policy on the availability of these methods?

feature compiler

Most helpful comment

The policy is: all nodes should be able to be traversed. Currently they are not but only because we didn't have time to implement them all. I added the methods that I thought would be most convenient, or that I needed at that moment for some stuff, but all of them should be available.

Adding these methods and tests for them should be relatively easy.

All 2 comments

The policy is: all nodes should be able to be traversed. Currently they are not but only because we didn't have time to implement them all. I added the methods that I thought would be most convenient, or that I needed at that moment for some stuff, but all of them should be available.

Adding these methods and tests for them should be relatively easy.

How is the status now four years later? Anybody wants to reevaluate?

Was this page helpful?
0 / 5 - 0 ratings