expose much needed methods in public reflection/macro API

[scabug]

Ideally we should be able to write scala-async / sbt macros without resorting to down casting.

• expose the current owner of the call site typer
• conveniences like paramss, typeArgs, resultType, finalResultType
• more to come

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8063?orig=1
Reporter: @retronym
Affected Versions: 2.10.3
See #6732, #6441, #8118, #6379, #6565, #6733, #6814, #7044, #8086, #6931, #6785, #7993, #7533

[scabug]

@xeno-by said:
http://stackoverflow.com/questions/20417654/consructing-or-modifying-scala-reflect-api-position

[scabug]

@soc said:
Can we get a better name for paramss at least in the public API? If people want to have their maximally cryptic abbreviations in the compiler, I don't care, but we shouldn't start exposing them to users.

[scabug]

@densh said:
equalsStructure vs structureEquals on trees. I don't care which one stays but it's really crazy that we have both

[scabug]

@xeno-by said:
I will add a couple related issues while I go through the list triaging bugs.

[scabug]

@densh said:
Another point is change of api on FunctionClass, TupleClass and ProductClass. Currently they are exposed as a Int => Symbol. Currently it's hard to find if symbol is a Function, Tuple or Product. We either need to expose seq extra field or provide additional helper methods.

[scabug]

@xeno-by said (edited on Dec 19, 2013 10:17:01 PM UTC):
We should also go through the APIs and apply deprecation to things that seemed to be useful, but ended up unused (deSkolemize, I'm looking at you!).

[scabug]

@xeno-by said:
https://groups.google.com/forum/#!topic/scala-internals/CfmPHXrHliw

[scabug]

@xeno-by said:
How about we also tackle the NoSymbol <: XXXSymbol problem, so that we can formulate convenient methods called method, methods, etc?

[scabug]

@xeno-by said:
http://stackoverflow.com/questions/20908036/how-do-i-splice-symbols-of-various-types-in-a-quasiquote

[scabug]

@xeno-by said (edited on Jan 4, 2014 7:01:50 AM UTC):
Also, if we don't manage to fix the NoSymbol problem, at least there are some places in the API where we can improve the types of returned values (e.g. MethodSymbol.typeParams, MethodSymbol.paramss, etc).

[scabug]

@xeno-by said:
Also, it looks like TermSymbol doesn't refine name to be TermName, same for TypeSymbol. Not good.

[scabug]

@clhodapp said:
To Simon's point, how about 'paramLists' instead of 'paramss'?

[scabug]

@xeno-by said:
Would also be nice to add ClassSymbol.primaryConstructor.

[scabug]

@xeno-by said:
@chris Hodapp. Not sure about the names yet. First I'd like to figure out the list of methods to add/remove.

[scabug]

@retronym said:
One more requests: Symbol#alternatives

[scabug]

@xeno-by said:
scala/scala#3452

[scabug]

@Blaisorblade said:
What about moving TypeMap into scala.reflect.api? Or is one supposed to use it from .internal for now?

  // todo. move these into scala.reflect.api

(from https://github.com/scala/scala/blob/fabc9f1424824975943241b9bb2c9b7669f805bd/src/reflect/scala/reflect/internal/tpe/TypeMaps.scala#L94, on current master).

[scabug]

@xeno-by said:
What would be the use case for that? Could you provide some more detail?

[scabug]

@Blaisorblade said:
I agreed with the TODO because, given how hard type substitution is, if you ever need it you should reuse TypeMap.
I suppose a use case would require a transformation on terms and types for some DSL implementation — a standard example in metaprogramming literature would be CPS conversion. (I also happen to have another such transformation in my last paper, at PLDI '14, but it's not a paradigmatic example, just some specific transformation).

But I don't have a specific example I'm working on right now.

[scabug]

@xeno-by said:
On a related note, it would also be nice to have a convenient way to traverse trees, because Transformer can hardly be called convenient :)

Speaking of tree transformers, I also have a hypothesis that with modest changes to compiler internals, we'll be able to downgrade from attributed trees to unattributed trees, so type mapping might actually be equivalent to tree mapping, which should be much easier to get right.