dotty-feature-requests
dotty-feature-requests copied to clipboard
lampepfl
Enhance Signature in Quotes
https://github.com/lampepfl/dotty/blob/master/library/src/scala/quoted/Quotes.scala#L3359
The Signature in Quotes only exposes def paramSigs: List[String | Int] and def resultSig: String without any information of type. I think Quotes needs a well typed Signature for better reflection.
The thing with this is that creating dotty internal representation of signature is actually a lossy operation, it's not cleanly reversible without a lot of exploratory branching, which is perhaps concerning to me, if we make it unambiguously reversible this would be possible.
@bishabosha Thanks for the explanation. Is "reversible" meaning the conversion between the Signature in quotes and compiler?
@changvvb So what I mean is that the Signature in Quotes is a view on the Signature in the compiler, but where semantic names, (which have a tree structure) have been replaced by flattened strings. The problem is that the compilers internal Signature data structure is generated by converting the compiler representation of Types to semantic names, and the semantic name representation is then stored in TASTy to convert back to a Signature. These names are structured like a path separated by ., e.g. [scala . Int] may be such a path.
To convert a semantic name back to a type you have to reverse engineer the path by looking up members from left to right. The paths have enough information to tell you when selecting a member of an object, but it is ambiguous if something is a member of a class or package, so there has to be exploration to find that. Maybe in practise it is unambiguous but the structure of the name itself doesn't seem to tell you that
so it does seem illegal to have a class and package with the same name, so then perhaps a package acts like a class in this situation and so no exploration is required
@bishabosha Great explanation! It sounds feasible to convert semantic names to a typed Signature .
@bishabosha Do you know what's the point of Signature in Quotes, and why doesn't it expose proper type representations instead of stringly-typed ones?
Signature is an internal implementation detail of the compiler and the tasty format, we shouldn't expose any method on it.
@smarter should it be exposed at all in Quotes, even without methods? What's its purpose there?
No idea, internally we use it to select an overload, it might be useful for that in the reflection layer too.