为了在派生某个类型类的实例时减少最终用户的样板(让我们以 Showable
为例),我的目标是编写一个宏,它将自动生成实例名称。例如。:
// calling this:
Showable.derive[Int]
Showable.derive[String]
// should expand to this:
// implicit val derivedShowableInstance0 = new Showable[Int] { ... }
// implicit val derivedShowableInstance1 = new Showable[String] { ... }
我尝试通过以下方式解决问题,但编译器提示该表达式应返回
< no type >
而不是 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
)
)
}
}
}
我得到一个
val
声明不完全是表达式,因此 Unit
可能不合适,但是如何使它正确呢?这是可能吗?如果没有,那么为什么会这样,是否有任何解决方法?
最佳答案
恩,那就对了。声明/定义不是表达式,因此需要将它们包装到返回单元的块中才能成为单元。通常 Scala 会自动执行此操作,但在这种特殊情况下,您需要自己执行此操作。
但是,如果您将定义包装在块中,则它从外部变得不可见。这就是当前严格遵循“宏应用程序非常类似于类型化函数调用”的比喻的宏系统的局限性。函数调用不会将新成员带入作用域,因此 def 宏也不会 - 无论是出于技术原因还是哲学原因。如我最近的“宏有什么用?”的示例 #3 所示。谈谈,通过使用结构类型 def 宏可以解决这个限制,但这看起来与你的问题没有特别的关系,所以我会省略细节。
另一方面,有一些想法如何用新的宏风格来克服这个限制。宏注释表明宏引擎 Hook 新成员创建在技术上是可行的,但我们希望在将宏注释引入主干之前获得更多的宏注释经验。关于这方面的一些细节可以在我的“Scala 宏哲学”演讲中找到。这在您的情况下可能很有用,但我仍然不会详细介绍,因为我认为对于这种特殊情况有更好的解决方案(尽管可以在评论中要求详细说明!)。
我想建议您使用在 http://docs.scala-lang.org/overviews/macros/implicits.html 中描述的物化。 .通过物化宏,您可以自动为用户生成类型类实例,而无需用户编写任何代码。这适合您的用例吗?
关于scala - 编写生成语句的宏,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20767806/