New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIP 16: Self-cleaning macros #57

Merged
merged 1 commit into from Mar 9, 2012

Conversation

Projects
None yet
2 participants
@xeno-by
Member

xeno-by commented Mar 9, 2012

No description provided.

heathermiller added a commit that referenced this pull request Mar 9, 2012

Merge pull request #57 from xeno-by/gh-pages
SIP 16: Self-cleaning macros

@heathermiller heathermiller merged commit 2912f3d into scala:gh-pages Mar 9, 2012

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Aug 11, 2016

Member

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.

Background

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.

Evaluation

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.

Verdict

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.

Member

xeno-by commented Aug 11, 2016

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.

Background

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.

Evaluation

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.

Verdict

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.

@xeno-by

This comment has been minimized.

Show comment
Hide comment
@xeno-by

xeno-by Aug 22, 2016

Member

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.

Member

xeno-by commented Aug 22, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment