Skip to content

Conversation

@retronym
Copy link
Member

@retronym retronym commented Apr 5, 2014

Namely: scala/scala#3656

I can't find a way to express a QQ that matches an constructor
invocation and lets me bind a reference to the New tree.
So I've dropped down to a borrowed version of TreeInfo#Applied.

/cc @xeno-by @densh

retronym added 2 commits April 5, 2014 23:03
Namely: scala/scala#3656

I can't find a way to express a QQ that matches an constructor
invocation *and* lets me bind a reference to the `New` tree.
So I've dropped down to a borrowed version of `TreeInfo#Applied`.
  - simpler means to calculate `applyDepth`
  - remove unused binder
retronym added a commit that referenced this pull request Apr 6, 2014
Update to Scala 2.11.0-RC4, adapting to change in quasiquotes
@retronym retronym merged commit dc5ee63 into scala:master Apr 6, 2014
@xeno-by
Copy link
Contributor

xeno-by commented Apr 6, 2014

So from what I can see, syntactic disjointness is actually undesireable here, right? Also seems related to https://roslyn.codeplex.com/discussions/541303 (to my best understanding of what they are discussing there)

@densh
Copy link

densh commented Apr 7, 2014

Why not add one extra q"new $f[..$targs](...$argss)" case?

@densh
Copy link

densh commented Apr 7, 2014

@xeno-by experts can get away without disjointness because they know inner representations of trees, new users – not as much.

@retronym
Copy link
Member Author

retronym commented Apr 7, 2014

@densh I can't bind to the New tree in that case, and I need to propagate that, type and all, to the transformed tree.

@retronym
Copy link
Member Author

retronym commented Apr 7, 2014

Note that this doesn't work, as the new is not in the same QQ as the [..](...)

case q"${n @ q"new ${_}"}[..$targs](...$argss)"

@retronym
Copy link
Member Author

retronym commented Apr 7, 2014

From a transformation point of view, anytime you want to match a method application, you probably also want to match a constructor invocation. The uniformity helps here, IMO.

@densh
Copy link

densh commented Apr 7, 2014

I guess we can discuss this on one of the upcoming meetings. Forced disjointness here might have been premature. We can document this case and revert to previous behavior back in 2.11.1.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants