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

Restrict macro API #445

Open
adriaanm opened this Issue Nov 21, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@adriaanm
Member

adriaanm commented Nov 21, 2017

Only the simplest blackbox macros. Other applications should be subsumed by direct language support, if sufficiently proven:

  • deriving
  • hlists (use case: type safe mappings)

Develop good tooling support for codegen to subsume more complicated examples.

@adriaanm adriaanm added this to the 2.14 milestone Nov 21, 2017

@SethTisue

This comment has been minimized.

Member

SethTisue commented Nov 21, 2017

note that compiler plugins still exist, for people who realllllly want to do something arbitrary

@ritschwumm

This comment has been minimized.

ritschwumm commented Nov 21, 2017

how about lenses, prisms, and coproducts?

@Ichoran

This comment has been minimized.

Ichoran commented Nov 21, 2017

Can a whitebox macro compiler plugin exist and work properly? If not, can the hooks be altered so a compiler plugin could provide whitebox macro capability?

@SethTisue

This comment has been minimized.

Member

SethTisue commented Nov 21, 2017

@ritschwumm what about them? (offhand, it sounds like this might be covered under “deriving”?)

@jvican

This comment has been minimized.

Member

jvican commented Nov 21, 2017

Can a whitebox macro compiler plugin exist and work properly? If not, can the hooks be altered so a compiler plugin could provide whitebox macro capability?

You can already do this with the current scala reflect. The whole macro infrastructure is pluggable and can be modified by any compiler plugin. But you need to know your fair amount of magic to be able to pull it off.

The only problem is that if another plugin does it, they're not composable.

@ritschwumm

This comment has been minimized.

ritschwumm commented Nov 21, 2017

@SethTisue if they are covered, i'm fine with it. these (and source location) are the only things i use macros for in lots of places so it would be sad if i couldn't have them any more.

@nafg

This comment has been minimized.

nafg commented Nov 22, 2017

Speaking of which (source location, and making macro usages language features), it would be great if source location would be in the standard library, that way e.g. Future could use them to give better "stack traces"

@nafg

This comment has been minimized.

nafg commented Nov 22, 2017

Another suggestion that someone made that can help reduce the need for whitebox macros, is to have an API for macros to add metadata to trees that another macro can later consume

@adriaanm

This comment has been minimized.

@DavidDudson

This comment has been minimized.

DavidDudson commented Dec 9, 2017

Please see scalameta/scalameta#1182

I will be prototyping a scalameta based implementation of a code generator, to replace blackbox macro annotations and possibly some whitebox annotations.

The first implementation will be extremely basic, only allowing "extensions" to existing objects/traits/classes. This first implementation will also allow companion objects to be populated. The push to do this is mostly based around deriving typeclasses for AST nodes.

@ghik

This comment has been minimized.

ghik commented Dec 21, 2017

What exactly would be covered by "deriving"?
Obviously, it would include ADT-based deriving (case classes and sealed hierarchies). But IMHO it's also important give macros ability to materialize implementations of traits, which now requires introspection of trait methods and usually implicit searches for some typeclass instances on parameter types and return types.

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