Scala Programming Language
  1. Scala Programming Language
  2. SI-6842

quasiquotes sometimes require specific static types of splicees

    Details

      Description

      scala> val v = q"val x: Int"
      v: reflect.runtime.universe.ValDef = val x: Int
      
      scala> q"def foo($v)"
      res3: reflect.runtime.universe.DefDef = def foo(x: Int): scala.Unit
      
      scala> val v: Tree = q"val x: Int"
      v: reflect.runtime.universe.Tree = val x: Int
      
      scala> q"def foo($v)"
      <console>:31: error: type mismatch;
       found   : List[List[reflect.runtime.universe.Tree]]
       required: List[List[$u.ValDef]]
                    q"def foo($v)"
                    ^
      

      The same goes for TypeDefs and CaseDefs.

        Activity

        Hide
        Eugene Burmako added a comment -

        When closing this bug, update the docs at http://docs.scala-lang.org/overviews/macros/quasiquotes.html

        Show
        Eugene Burmako added a comment - When closing this bug, update the docs at http://docs.scala-lang.org/overviews/macros/quasiquotes.html
        Hide
        Denys Shabalin added a comment -

        We've discussed this point a few times. IMO type errors here make sense. I would personally love to have more of them, not less.

        Show
        Denys Shabalin added a comment - We've discussed this point a few times. IMO type errors here make sense. I would personally love to have more of them, not less.
        Hide
        Eugene Burmako added a comment -

        I agree that it'd be nice to have more static guarantees when assembling trees. However, this particular initiative seems premature to me, because a lot of our tree-related APIs work with raw Tree's, which means that return values of such APIs would require casting just to satisfy the quasiquoting engine.

        This seems somewhat related to the situation with methods like Symbol.typeParams in the reflection API. The idea to move typeParams to TypeSymbol was, in principle, a good one. However, the fact that most of our symbol-related APIs return raw Symbol, which resulted in necessity to do mechanical casting.

        Here's another angle to view the situation. When we start using quasiquotes inside the compiler, we'll have to live with the fact that most of tree manipulation functions in the compiler return Tree, not specific subclasses of Tree. If quasiquotes are going to be too picky, we're going to have a lot of casting to do in the interim period.

        Show
        Eugene Burmako added a comment - I agree that it'd be nice to have more static guarantees when assembling trees. However, this particular initiative seems premature to me, because a lot of our tree-related APIs work with raw Tree's, which means that return values of such APIs would require casting just to satisfy the quasiquoting engine. This seems somewhat related to the situation with methods like Symbol.typeParams in the reflection API. The idea to move typeParams to TypeSymbol was, in principle, a good one. However, the fact that most of our symbol-related APIs return raw Symbol, which resulted in necessity to do mechanical casting. Here's another angle to view the situation. When we start using quasiquotes inside the compiler, we'll have to live with the fact that most of tree manipulation functions in the compiler return Tree, not specific subclasses of Tree. If quasiquotes are going to be too picky, we're going to have a lot of casting to do in the interim period.
        Show
        Denys Shabalin added a comment - https://github.com/densh/scala/commit/59ee22c1b242bea3af29c1bb784a09e6f77c6494
        Hide
        Denys Shabalin added a comment -
        Show
        Denys Shabalin added a comment - Fixed in https://github.com/scala/scala/pull/3255
        Hide
        Paolo G. Giarrusso added a comment - - edited

        Docs (http://docs.scala-lang.org/overviews/macros/quasiquotes.html) haven't been updated yet, and the example in http://docs.scala-lang.org/overviews/macros/quasiquotes.html still has two type errors:
        1. the code must use name.toString.capitalize instead of name.capitalize. I guess that's an actual bug in the example code.
        2. q"class $name extends AnyRef { ..${body ++ newdefs} }" is still missing a toList call, which might be an instance of this bug.

        Hence, this should be reopened.

        Show
        Paolo G. Giarrusso added a comment - - edited Docs ( http://docs.scala-lang.org/overviews/macros/quasiquotes.html ) haven't been updated yet, and the example in http://docs.scala-lang.org/overviews/macros/quasiquotes.html still has two type errors: 1. the code must use name.toString.capitalize instead of name.capitalize. I guess that's an actual bug in the example code. 2. q"class $name extends AnyRef { ..${body ++ newdefs} }" is still missing a toList call, which might be an instance of this bug. Hence, this should be reopened.
        Hide
        Denys Shabalin added a comment -

        This bug has been fixed and works properly in 2.11-M8. It wasn't backported to macro paradise yet.

        Documentation revamp is on my short list of things to be done before 2.11-RC1.

        Show
        Denys Shabalin added a comment - This bug has been fixed and works properly in 2.11-M8. It wasn't backported to macro paradise yet. Documentation revamp is on my short list of things to be done before 2.11-RC1.
        Hide
        Adriaan Moors added a comment -

        Sounds like this can be closed then? Releasing M8, so I'd like everything with fix-by M8 to be closed

        Show
        Adriaan Moors added a comment - Sounds like this can be closed then? Releasing M8, so I'd like everything with fix-by M8 to be closed

          People

          • Assignee:
            Denys Shabalin
            Reporter:
            Eugene Burmako
          • Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development