Question

With intention of reducing the boilerplate for the end-user when deriving instances of a certain typeclass (let's take Showable for example), I aim to write a macro, which will autogenerate the instance names. E.g.:

// calling this:
Showable.derive[Int]
Showable.derive[String]
// should expand to this:
// implicit val derivedShowableInstance0 = new Showable[Int] { ... }
// implicit val derivedShowableInstance1 = new Showable[String] { ... }

I tried to approach the problem the following way, but the compiler complained that the expression should return a < no type > instead of Unit:

object Showable {

  def derive[a] = macro Macros.derive[a]

  object Macros {
    private var instanceNameIndex = 0

    def derive[ a : c.WeakTypeTag ]( c : Context ) = {

      import c.universe._
      import Flag._

      val newInstanceDeclaration = ...

      c.Expr[Unit](
        ValDef(
          Modifiers(IMPLICIT), 
          newTermName("derivedShowableInstance" + nameIndex), 
          TypeTree(), 
          newInstanceDeclaration
        )
      )

    }
  }
}

I get that a val declaration is not exactly an expression and hence Unit might not be appropriate, but then how to make it right? Is this at all possible? If not then why, will it ever be, and are there any workarounds?

Was it helpful?

Solution

Yes, that's right. Declarations/definitions aren't expressions, so they need to be wrapped into Unit-returning blocks to become ones. Typically Scala does this automatically, but in this particular case you need to do it yourself.

However if you wrap a definition in a block, then it becomes invisible from the outside. That's the limitation of the current macro system that strictly follows the metaphor of "macro application is very much similar to a typed function call". Function calls don't bring new members into scope, so neither do def macros - both for technical and philosophical reasons. As shown in the example #3 of my recent "What Are Macros Good For?" talk, by using structural types def macros can work around this limitation, but this doesn't look particularly related to your question, so I'll omit the details.

On the other hand, there are some ideas how to overcome this limitation with new macro flavors. Macro annotations show that it's technically feasible for the macro engine to hook into new member creation, but we'd like to get more experience with macro annotations before bringing them into trunk. Some details about this can be found in my "Philosophy of Scala Macros" presentation. This can be useful in your situation, but I still won't go into details, because I think there's a much better solution for this particular case (feel free to ask for elaboration in comments, though!).

What I'd like to recommend you is to use materialization as described in http://docs.scala-lang.org/overviews/macros/implicits.html. With materializing macros you can automatically generate type class instances for the user without having the user write any code at all. Would that fit your use case?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top