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

expose much needed methods in public reflection/macro API #8063

Closed
scabug opened this Issue Dec 10, 2013 · 21 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented Dec 10, 2013

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

This comment has been minimized.

Copy link

scabug commented Dec 10, 2013

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 10, 2013

@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

This comment has been minimized.

Copy link

scabug commented Dec 10, 2013

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

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 11, 2013

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

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 12, 2013

@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

This comment has been minimized.

Copy link

scabug commented Dec 19, 2013

@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

This comment has been minimized.

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 30, 2013

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

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 4, 2014

@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

This comment has been minimized.

Copy link

scabug commented Jan 4, 2014

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

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 5, 2014

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

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 11, 2014

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

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 11, 2014

@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

This comment has been minimized.

Copy link

scabug commented Jan 31, 2014

@retronym said:
One more requests: Symbol#alternatives

@scabug

This comment has been minimized.

Copy link

scabug commented Feb 1, 2014

@scabug scabug closed this Feb 19, 2014

@scabug

This comment has been minimized.

Copy link

scabug commented Mar 1, 2014

@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

This comment has been minimized.

Copy link

scabug commented Mar 1, 2014

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

@scabug

This comment has been minimized.

Copy link

scabug commented Mar 1, 2014

@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

This comment has been minimized.

Copy link

scabug commented Mar 4, 2014

@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.

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