Skip to content
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

quasiquotes sometimes require specific static types of splicees #6842

Closed
scabug opened this issue Dec 19, 2012 · 9 comments
Closed

quasiquotes sometimes require specific static types of splicees #6842

scabug opened this issue Dec 19, 2012 · 9 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Dec 19, 2012

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.

@scabug
Copy link
Author

scabug commented Dec 19, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6842?orig=1
Reporter: @xeno-by
Affected Versions: 2.11.0-M4

@scabug
Copy link
Author

scabug commented Dec 22, 2012

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

@scabug
Copy link
Author

scabug commented Nov 29, 2013

@densh said:
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.

@scabug
Copy link
Author

scabug commented Nov 29, 2013

@xeno-by said:
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.

@scabug
Copy link
Author

scabug commented Nov 29, 2013

@densh said:
densh/scala@59ee22c

@scabug
Copy link
Author

scabug commented Dec 13, 2013

@densh said:
Fixed in scala/scala#3255

@scabug
Copy link
Author

scabug commented Jan 20, 2014

@Blaisorblade said (edited on Jan 20, 2014 5:29:21 AM UTC):
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.

@scabug
Copy link
Author

scabug commented Jan 20, 2014

@densh said:
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.

@scabug
Copy link
Author

scabug commented Jan 21, 2014

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

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

No branches or pull requests

2 participants