Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
SIP 16: Self-cleaning macros #57
added a commit
this pull request
Mar 9, 2012
During the SIP meeting on 10 Aug 2016, I presented this proposal to the committee as part of the "Formal evaluation" phase of the current SIP process (http://docs.scala-lang.org/sips/sip-submission.html). At this phase, the committee iterates on the design of a SIP and eventually decides whether it will be accepted or rejected.
Initial discussion of SIP-16 took place almost three and a half years ago.
The committee has arrived at the conclusion that the idea is worthwhile, but a practical experiment is required to fully evaluate the consequences of including macros in the language. We delivered the implementation as an experimental part of the 2.10.0 release and started observing.
Now, I can confidently say that the experiment is over. We have gathered enough practical evidence and user feedback to make a decision about SIP-16. Below you can find our thoughts on this matter.
Def macros introduced by this proposal and macro annotations spun off about 1.5 years later have become an integral part of the Scala ecosystem. They marry metaprogramming with types and work in synergy with other language features, enabling practically important use cases. A significant number of popular libraries use macros.
However, in addition to having the reputation of an indispensable tool, macros have also gained notoriety as an arcane and brittle technology. It is not uncommon to encounter macros that produce obscure error messages / compiler crashes or work incorrectly in IDEs. While there are ways to write robust and portable macros, they require intimate familiarity with the internals of the Scala compiler and cannot be considered acceptable for an official language feature.
While trying to fix these problems via evolutionary changes to the current macro system, we have realized that most of them are caused by the decision to use scala.reflect as the underlying metaprogramming API. Modelled after compiler internals, scala.reflect inherits many of its peculiar design choices. Extensive use of desugarings and existence of multiple independent program representations may have worked well for compiler development, but they turned out to be inadequate for a public API.
The realization that we cannot make meaningful progress while staying within the confines of scala.reflect means that the proposed macro system needs a redesign. Therefore, the SIP committee has unanimously voted to reject SIP-16.
This rejection means that we don't have plans to include macros from SIP-16 into Scala. However, it doesn't mean that macros are going away. We are already working on a new SIP that will provide similar functionality in a slightly different linguistic package.
Concretely, before the end of this month, I will officially kick off the process for a new macro SIP by posting our new design for public discussion at scala-sips, as mandated by the current process (http://docs.scala-lang.org/sips/sip-submission.html). I will also provide a link to that discussion in this thread for the ease of reference.
I have just published a follow-up proposal at https://gist.github.com/xeno-by/9d7a709b1ba7c2ee64cfedcc5d264bd5. In order to centralize the discussion, post your questions, feedback and ideas to http://gitter.im/scalameta/sips.