可以避免这种自由项变量错误(在宏扩展中产生)吗? [英] Can this free-term-variable error (produced at macro expansion) be avoided?

问题描述

我正在开发DSL，并且在扩展宏时遇到免费术语"故障.我想知道是否可以避免.我已将问题简化为以下情况.

I am developing a DSL and I am getting a "free term" failure while expanding a macro. I would like to know if it can be avoided. I have simplified the problem to the following situation.

假设我们有这个表达式:

Suppose we have this expression:

val list = join {
  0
  1
  2
  3
}
println(list)

其中join是一个宏，其实现是:

where join is a macro whose implementation is:

def join(c: Ctx)(a: c.Expr[Int]): c.Expr[List[Int]] = {
  import c.mirror._
  a.tree match {
    case Block(list, ret) =>
      // c.reify(List(new c.Expr(list(0)).eval, 
      //              new c.Expr(list(1)).eval,
      //              new c.Expr(list(2)).eval) :+ new c.Expr(ret).eval)
      c.reify((for (expr <- list) yield new c.Expr(expr).eval) :+ new c.Expr(ret).eval)
  }
}

宏的目的是将参数块中的所有元素联接起来，并在单个列表中返回它们.由于该块的内容可能是可变的，所以我不能使用带注释的reify(效果很好).未注释的-具有for理解功能，可生成免费条款-会抛出以下消息:

The aim of the macro is to join all the elements in the argument block and return them in a single list. Since the contents of the block could be variable, I cannot use the commented reify (which works nice). The uncommented one -with a for comprehension, which generates free terms- throws the message:

宏扩展包含由Macros.scala:48:18中的join定义的免费术语变量列表.在将该变量拼接成reifee时，您是否忘记使用eval?如果您在跟踪免费术语变量时遇到麻烦，请考虑使用-Xlog-free-terms"

有没有办法引入理解(或迭代器之类的东西)而不会出现此错误?顺便说一句，我正在使用2.10-M3.

Is there any way to introduce the for-comprehension (or an iterator or whatever) without getting this error? By the way, I am using 2.10-M3.

推荐答案

问题是您的代码混合了编译时和运行时概念.

The problem is that your code mixes compile-time and runtime concepts.

您使用的列表"变量是一个编译时值(即应该在编译时进行迭代)，并且您要求reify将其保留到运行时(通过拼接派生值) ).这种跨阶段的难题导致创建了一个所谓的免费术语.

The "list" variable you're using is a compile-time value (i.e. it is supposed to be iterated during the compile-time), and you're asking reify to retain it till the runtime (by splicing derived values). This cross-stage conundrum leads to creation of a so called free term.

简而言之，自由术语是指早期阶段的值的存根.例如，以下代码段:

In short, free terms are stubs that refer to the values from earlier stages. For example, the following snippet:

val x = 2
reify(x)

将如下编译:

val free$x1 = newFreeTerm("x", staticClass("scala.Int").asTypeConstructor, x);
Ident(free$x1)

聪明吧?结果保留了以下事实:x是一个Ident，保留其类型(编译时特性)，但是仍然引用其值(运行时特性).通过词汇作用域可以做到这一点.

Clever, huh? The result retains the fact that x is an Ident, preserves its type (compile-time characteristics), but, nevertheless, refers to its value as well (a run-time characteristic). This is made possible by lexical scoping.

但是，如果您尝试从宏扩展(内联到宏的调用站点)中返回此树，则事情将会崩溃.宏的调用站点很可能在其词法范围内不包含x，因此它将无法引用x的值.

But if you try to return this tree from a macro expansion (that is inlined into the call site of a macro), things will blow up. Call site of the macro will most likely not have x in its lexical scope, so it wouldn't be able to refer to the value of x.

更糟的是.如果上面的代码段是在宏中编写的，则x仅在编译时存在，即在运行编译器的JVM中存在.但是，当编译器终止时，它就消失了.

What's even worse. If the snippet above is written inside a macro, then x only exists during compile-time, i.e. in the JVM that runs the compiler. But when the compiler terminates, it's gone.

但是，包含对x的引用的宏扩展结果应该在运行时运行(很可能在其他JVM中运行).为了理解这一点，您将需要跨阶段的持久性，即能够以某种方式序列化任意编译时值并在运行时反序列化它们的功能.我不知道如何使用Scala这样的编译语言来做到这一点.

However, the results of macro expansion that contain a reference to x are supposed to be run at runtime (most likely, in a different JVM). To make sense of this, you would need cross-stage persistence, i.e. a capability to somehow serialize arbitrary compile-time values and deserialize them during runtime. I don't know how to do this in a compiled language like Scala.

请注意，在某些情况下，跨阶段持久性是可能的.例如，如果x是静态对象的字段:

Note that in some cases cross-stage persistence is possible. For example, if x was a field of a static object:

object Foo { val x = 2 }
import Foo._
reify(x)

那么它就不会成为一个免费术语，而是会以一种简单的方式加以修正:

Then it wouldn't end up as a free term, but would be reified in a straightforward fashion:

Select(Ident(staticModule("Foo")), newTermName("x"))

这是一个有趣的概念，在SPJ的Scala Days 2012上的演讲中也进行了讨论: http://skillsmatter.com/podcast/scala/haskell-cloud .

This is an interesting concept that was also discussed in SPJ's talk at Scala Days 2012: http://skillsmatter.com/podcast/scala/haskell-cloud.

为验证某些表达式不包含自由术语，他们在Haskell中向编译器(Static类型构造函数)添加了一个新的内置原语.使用宏，我们可以自然地通过使用reify(它本身只是一个宏)来做到这一点.请参阅此处的讨论: https://groups.google.com/forum/#!topic/scala-internals/-42PWNkQJNA .

To verify that some expression doesn't contain free terms, in Haskell they add a new built-in primitive to the compiler, the Static type constructor. With macros, we can do this naturally by using reify (which itself is just a macro). See the discussion here: https://groups.google.com/forum/#!topic/scala-internals/-42PWNkQJNA.

好的，现在我们已经看到了原始代码到底有什么问题，那么我们如何使其工作呢?

Okay now we've seen what exactly is the problem with the original code, so how do we make it work?

不幸的是，我们不得不依靠手工AST构造，因为reify很难表达动态树.在宏观上进行验证的理想用例是具有一个静态模板，该模板具有在宏编译时已知的孔的类型.退一步-您将不得不手工建造树木.

Unfortunately we'll have to fall back to manual AST construction, because reify has tough time expressing dynamic trees. The ideal use case for reify in macrology is having a static template with the types of the holes known at macro compilation time. Take a step aside - and you'll have to resort to building trees by hand.

最重要的是，您必须遵循以下内容(适用于最新发布的2.10.0-M4，请参阅scala语言的迁移指南，以了解究竟发生了什么变化:

Bottom line is that you have to go with the following (works with recently released 2.10.0-M4, see the migration guide at scala-language to see what exactly has changed: http://groups.google.com/group/scala-language/browse_thread/thread/bf079865ad42249c):

import scala.reflect.makro.Context

object Macros {
  def join_impl(c: Context)(a: c.Expr[Int]): c.Expr[List[Int]] = {
    import c.universe._
    import definitions._
    a.tree match {
      case Block(list, ret) =>
        c.Expr((list :+ ret).foldRight(Ident(NilModule): Tree)((el, acc) => 
          Apply(Select(acc, newTermName("$colon$colon")), List(el))))
    }
  }

  def join(a: Int): List[Int] = macro join_impl
}

这篇关于可以避免这种自由项变量错误(在宏扩展中产生)吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！