--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I think that's the best that can be done right now. The API to reflect against enclosing trees and nearby compilation units is something that definitely needs improvement, as there are a lot of non-obvious interactions with the order of how things get typechecked, with the style of typechecking (in-place / functional), which varies on a per-node basis and such.
Post-typer macros are definitely appealing, because they allow for more predictable typechecking (e.g. no more macros, which refine their declared return type and no more macros which slow down the typer), which provides multiple benefits to the tools (compiler has easier time reasoning about types in the program, IDE doesn't have to expand macros to provide useful info to the user, humans can understand macro-using programs better).
Nevertheless post-typer macros have at least one (but big) problem: implicits. First of all, due to technical restrictions post-typer implicit lookup is inaccurate, which means that if a macro expands into a call to a method which requires an implicit argument (e.g. something as commonplace as a map), it will most likely run into problems. Secondly, macros can be used to conjure implicit arguments, and by doing that (or by refusing to do that) they can steer type inference, overload resolution, etc. These kinds of things can only be done during typechecking.
Speaking of post-typer macros and macro paradise, well, anything can happen :)
As for retypechecking, as mentioned above that's currently impossible because of implementation restrictions. But even if those restrictions are lifted, retypechecking won't help with implicit macros, which have to be expanded in typer to behave correctly.
It seems each macro-project could in fact use a dedicated macro type ;). Just shows that there's a lot of possibilities to do meta-programming … and intersected with not-so-few Scala features, well, you get problems sometime.
Implicit macros are implicit defs declared as macros. They can be used to generate type class instances on-the-fly, as, for example, described in section 4.3 of my recent paper: http://scalamacros.org/news/2013/04/22/let-our-powers-combine.html.