If your metaprogramming is happening at compile time, and your AST savvy tools are savvy enough to work on the final (all macros evaluated) form of the code, then I don't see why they should fail?

If you wait until the final form of the code, it would seem very difficult to trace back from function symbol to its generating/binding macro. That is, how do you know which macro bound a specific function? Hope for no ambiguities, I suppose. Maybe it's not a problem, but I'd think the main point of such a grep tool is to point back to the originating code, right? Merely detecting that a specific function symbol is bound is not quite the same.

Smuglispweeny? Unfortunately, a lot of metaprogramming is done in languages that don't even have a "compile time" never mind providing a hook to metaprogram in it.

compile-time metaprogramming is far more tractable, yes.

No, actually, dynamic languages can, theoretically, handle this. At least, I can introspect in a running Lisp instance quite well. By all reports Smalltalk does it quite well too.

The fact that most dynamic languages were hacked together doesn't imply that the better systems also fail.

No, actually, dynamic languages cannot handle this even theoretically. See halting problem: No realistic amount of introspection is going to automatically tell you where negative_position is defined in the second example from TFA, because method_missing can do literally anything to decide what method names it does and does not handle. And Smalltalk's #doesNotUnderstand: works exactly like that.

You are confusing dynamic typing vs static typing with run-time execution vs compile-time execution.

A statically typed language can do arbitrary stuff at run-time too that will not be amenable to static analysis. This has nothing to do with the type system.

Furthermore, a dynamic language can be perfectly amenable to static analysis. For instance, in lisp+slime, slime-who-calls can identify callers of a particular function, even when grep would not, e.g. if the function was invoked via a turing-complete macro. The key thing here is that the AST to be analyzed does exist at compile-time; it just happens to be generated rather than hand-coded.

In practice, you can add a sprinkle of static to your dynamic language, adding a preprocessor that requires declaration of method_missing patterns that are acceptable to the application.

Theoretically, for constrained cases yes.

On the other hand, the typical Ruby ORM defines methods that corresponds to the current columns of tables in the database it is told to connect to. That fancy AST parsing tool won't be able to do anything in that case without being able to connect to your database and issue queries...

You might consider this "hacked together" but those kinds of api's is a major part of the draw of Ruby for a lot of people.

> clever AST savvy tools will fail in the presence of metaprogramming, unless you restrict it to patterns the tool knows. And then you're halfway towards static typing with inference.

Common Lisp has plenty of well-defined macros with simple patterns any tool could learn, but it's definitely dynamically typed. (defstruct foo ..) generates foo-p, make-foo, copy-foo; what parser couldn't understand that? All it takes is a few good macros to really make the DRY work. Either give up like the author and repeat yourself or move past the problem with a macro.

Patterns mean "I have run out of language." — Rich Hickey

> Common Lisp has plenty of well-defined macros with simple patterns any tool could learn

If the tool has to learn (i.e. be written to know about, yes?) these patterns, then it will not know about those you wrote.

However, as someone else has pointed out, the compile-time execution of macros actually does make them accessible to a sufficiently sophisticated "grep", the kind of tool shurcooL asked for.