-
Notifications
You must be signed in to change notification settings - Fork 233
Semantic API #604
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
Comments
Interesting! This seems similar to the kind of things IDEs do to handle features like type-at-point/symbol-at-point (which incidentally should soon be very easy to do in dotty :)) |
@smarter Sounds very nice! Can you provide more details? Upd. Here are some links from our hangout call with @smarter:
|
This functionality is no longer necessary according to the new approach described in scalameta#604. Therefore, I’m gladly removing it from scala.meta. Both the codegen part and the whole withAttrs/setTypechecked business were terribly complicated for the value they offered.
This functionality is no longer necessary according to the new approach described in scalameta#604. Therefore, I’m gladly removing it from scala.meta. Both the codegen part and the whole withAttrs/setTypechecked business were terribly complicated for the value they offered.
This functionality is no longer necessary according to the new approach described in scalameta#604. Therefore, I’m gladly removing it from scala.meta. Both the codegen part and the whole withAttrs/setTypechecked business were terribly complicated for the value they offered.
Recently, we decided to limit the surface of our work to actionable items only - either bugs in existing code or feature requests that are warranted by the roadmap. While semantic API is definitely on our roadmap, we're going to figure out desired APIs from use cases, not from reflecting on scala.reflect and pondering what functionality from there we should add to Scalameta. That's why I'll be closing this issue and letting feature requests be submitted naturally by our users. |
Uh oh!
There was an error while loading. Please reload this page.
Scala.meta 1.5 supports inspections of the structure of Scala code (syntax and tokens), but it doesn't provide any facilities to inspect semantics (what's the type of this fragment of code? what does this name point to? etc). We had this in scala.reflect, and we need to have this in scala.meta, too, because that's one of the most basic features one expects in a metaprogramming framework.
In the past, we've made two unsuccessful attempts at implementing the semantic API for the Scala compiler (first and second). Both of them were based on the concept of a scala.reflect -> scala.meta tree converter, i.e. a module that would convert attributed compiler trees into equivalent scala.meta trees with semantic information encoded in a platform-independent way. Long story short, eventually we realized that it is prohibitively hard to implement a useful converter, so we had to start looking for other ways to build a semantic API (see #148 for a detailed explanation).
Around Scala eXchange 2016, we had an idea to give up on converters altogether and obtain semantic information about scala.meta trees using positions. Instead of eagerly converting attributed scala.reflect trees into attributed scala.meta trees, we handle semantic requests dynamically. For every request to a scala.meta tree, we use its position to identify a corresponding attributed scala.reflect tree and then use that tree's attributes to complete the request. After several hacking sessions in December and January, I'm now convinced that this approach is solid enough to become the basis of the semantic API.
After some consideration, we have also decided to cut the scope of the initial vision of the semantic API as designed ca. 2013. Concretely, in the first iteration of the API (
scala.meta.semantic.v1
), we're going to temporarily introduce the notion of symbols, and we're going to only support fully attributed and fully unattributed ASTs. We are still planning to eventually implement the initial vision (scala.meta.semantic.v2
, see #623 for more information), but we'd like to ship something partially useful as soon as possible.(April 2017). After more deliberation, we have further cut the scope of the semantic API. For the time being, we're going to give up on supporting unattributed trees and on the unification of symbols and trees. Therefore,
scala.meta.semantic.v2
bites the dust andscala.meta.semantic.v1
becomesscala.meta.semantic
.Implementation plan:
Ref.symbol
(Online mirror with support for Ref.symbol #606)Ref.symbol
for unattributed trees (Ref.symbol for unattributed trees #608)Ref.symbol
(Offline mirror with support for Ref.symbol #607)Term.tpe
(Term.tpe #611)Term.desugaring
and other issues labelled withSemantic
(list)The text was updated successfully, but these errors were encountered: