Multiple Parameter Lists Treated as Second-Class Citizens in Reflection

[Chris Hodapp]

So, currently, methods that take multiple argument lists are treated like second-class citizens in a lot of places. For example, value argument/parameter lists other than the first one are not considered when resolving an overloaded reference. Personally, I find this to be totally wrong (which is why I currently have on the back-burner a proposal to change how overload resolution works. I can post my in-progress specification proposal if anyone cares to see or comment, I guess... ), but that's not directly the reason for this post.

Rather, I'm writing it because, currently, the reflection API also treats value parameter lists other than the primary list as second-class citizens in a lot of places. For example, MethodType.params returns a List[Symbol] containing only Symbols representing the parameters in the initial value parameter list, rather than List[List[Symbol]] that I believe it should return. Also, TermSymbol.resolveOverloaded takes a single Seq[Type] to represent the types of the arguments in the first value parameter list, rather than taking a List[List[Type]] and only using the head like I would advocate. I'm sure that there are other examples, these are just the ones that come to mind immediately.

I think that this is a mistake. I think it compromises Martin's stated goal of doing the reflection API right the first time.

Yes, I am partially motivated by a self-serving desire to get the reflection API into a state where the language changes that I want to propose are closer to being drop-in method logic replacements (rather than needing signature changes), but I am also motivated by my earnest beliefs that

1) Multiple parameter list methods are part of the language. A reflection API is supposed to reify the language. Therefore, therefore, reflection should fully acknowlege them.

2) More generally, if Scala is going to have have multiple parameter list methods as a feature, it should own that feature. It should be well-supported and well-integrated into the language.

Agree? Disagree? Creeped out by the fact that I am so impassioned about this?

[Lukas Rytz]

On Fri, Jul 6, 2012 at 1:57 PM, Chris Hodapp <clho...@gmail.com> wrote:

So, currently, methods that take multiple argument lists are treated like second-class citizens in a lot of places. For example, value argument/parameter lists other than the first one are not considered when resolving an overloaded reference.

Note that also for type parameter inference, only the first argument list is considered.

 

Personally, I find this to be totally wrong (which is why I currently have on the back-burner a proposal to change how overload resolution works. I can post my in-progress specification proposal if anyone cares to see or comment, I guess... ), but that's not directly the reason for this post.

Rather, I'm writing it because, currently, the reflection API also treats value parameter lists other than the primary list as second-class citizens in a lot of places. For example, MethodType.params

There should be "paramss" (at least in the compiler internals, it's there)

 

returns a List[Symbol] containing only Symbols representing the parameters in the initial value parameter list, rather than List[List[Symbol]] that I believe it should return. Also, TermSymbol.resolveOverloaded takes a single Seq[Type] to represent the types of the arguments in the first value parameter list, rather than taking a List[List[Type]] and only using the head like I would advocate.

Well, as you say, that's according to the current spec

 

I'm sure that there are other examples, these are just the ones that come to mind immediately.

I think that this is a mistake. I think it compromises Martin's stated goal of doing the reflection API right the first time.

It's a decision that makes Scala easier to spec and implement, I wouldn't call it a "mistake".

Yes, I am partially motivated by a self-serving desire to get the reflection API into a state where the language changes that I want to propose are closer to being drop-in method logic replacements (rather than needing signature changes), but I am also motivated by my earnest beliefs that

1) Multiple parameter list methods are part of the language. A reflection API is supposed to reify the language. Therefore, therefore, reflection should fully acknowlege them.

I think the API reflects the spec

 

2) More generally, if Scala is going to have have multiple parameter list methods as a feature, it should own that feature. It should be well-supported and well-integrated into the language.

That's a valid opinion. Maybe Martin knows about some problems of that idea that are not obvious?

Lukas

[Chris Hodapp]

In general, "it is implementing the spec" is a well-measured and strong critique of what I am saying.

This does raise a more general question, though:

 

A) Spec => Reflection

B) Reflection is stable

C) Spec is stable ???

[Eugene Burmako]

Multiparamlist methods have returnType of type MethodType. Inspecting that one will uncover subsequent parameter list(s).

[Chris Hodapp]

On Friday, July 6, 2012 7:35:46 AM UTC-5, Eugene Burmako wrote:

Multiparamlist methods have returnType of type MethodType. Inspecting that one will uncover subsequent parameter list(s).

So they do. I have to do a better job of looking before I leap if I want to retain credibility ;).

[Paul Phillips]

On Fri, Jul 6, 2012 at 5:11 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

There should be "paramss" (at least in the compiler internals, it's there)

Indeed, and looking at the implementation would also have led us to where the others the others were hiding:

    override def paramss: List[List[Symbol]] = params :: resultType.paramss

[martin odersky]

On Fri, Jul 6, 2012 at 4:12 PM, Paul Phillips <pa...@improving.org> wrote:

On Fri, Jul 6, 2012 at 5:11 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

There should be "paramss" (at least in the compiler internals, it's there)

Yes, we left it out, because we want to err on the side of minimalism for the first release. Besides, the name is too cryptic for a public API.

Cheers

 - Martin

 

Indeed, and looking at the implementation would also have led us to where the others the others were hiding:

    override def paramss: List[List[Symbol]] = params :: resultType.paramss

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Daniel Sobral]

I, for one, think it's reasonable to keep them out for 2.10, even
though I felt the lack of resultType, and have been wondering what
would I do about methods with multiple parameter lists.

At the same time, I suspect these two will top the list of requests for 2.10.1.

--
Daniel C. Sobral

I travel to the future all the time.

[Tomer Gabel]

One glaring inconsistency is that MethodMirror.apply only works on methods with multiple parameter lists by invoking it with a flattened parameter array. Took me a bit of experimentation to figure that one out.

This is definitely a wishlist item for Scala 2.10.next, however I couldn't make heads or tails of the JIRA issues; the closest two I could find are:

• https://issues.scala-lang.org/browse/SI-6006 - closed as a REPL bug
  
• https://issues.scala-lang.org/browse/SI-6182 - specifically around multiple varargs lists
  

Is this a "know issue on the backlog" or should I add this as a new issue?

[Eugene Burmako]

Does it only bring problems in case of multiple vararg lists or there are other issues?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tomer Gabel]

The API itself just doesn't reflect reality. MethodMirror.apply should reflect the fact that any method can have multiple parameter lists, and consequently take List[List[Any]]; the existing parameter (varargs of Any*) captures the wrong behavior.

[Eugene Burmako]

Then it would be quite inconvenient for the most frequent use case of a single parameter list. Though I agree that we should look into this again. Please file an issue.

[Paul Phillips]

The answer to this should be obvious. We do what I said up front and make parameter lists  first class. Now you can tell one thing from another, and there is an easy option to create implicits for the single parameter list case. You obviously can't create implicits from List[] to List[List[], but you can from paramlist to paramlists. 

[Jan Vanek]

On 17.03.2013 16:53, Paul Phillips wrote:

The answer to this should be obvious. We do what I said up front and make parameter lists  first class. Now you can tell one thing from another, and there is an easy option to create implicits for the single parameter list case. You obviously can't create implicits from List[] to List[List[], but you can from paramlist to paramlists.

Perhaps paramlist can be plain List[] and you only need class(es) for paramlists (custom list of List[])?

[Paul Phillips]

On Sun, Mar 17, 2013 at 2:00 PM, Jan Vanek <j3v...@gmail.com> wrote:

Perhaps paramlist can be plain List[] and you only need class(es) for paramlists (custom list of List[])?

Yes, I wrote that on a phone so it lacked nuance. It's the first which is important, not the second - there are advantages to the second, but it's not cut-and-dried like IMO the first is.

[Eugene Burmako]

Submitted an issue https://issues.scala-lang.org/browse/SI-8317