On named type arguments and partial type argument specification SIP draft

[Ahmad Salim Al-Sibahi]

Hi,

I had promised to talk with the dotty team about my SIP draft* on named type parameters and partial specification (https://github.com/scala/scala.github.com/pull/456) after the SIP discussion meeting in January.

First of all, thank you for taking the time to look at my SIP draft at the meeting; I appreciate the feedback and fully understand the points raised during discussion. 

I have read the proposal in the documentation of Dotty in the GitHub repository on higher-kinded types (https://github.com/lampepfl/dotty/blob/master/docs/HigherKinded-v2.md) and adding named type parameters. Here, as far as I understand, the main purpose of named type parameters is for partial type application where a type like `Map[K=Int]` should return a new type of kind `(V :: *) -> *` (I am unsure how to write this correctly in Scala) and the parameter K is fixed to be Int.

My proposal was about partial type argument specification in method calls (as you also kindly suggested in the meeting), where one could provide only some of the type arguments in a method call and letting the scala typing mechanism infer the rest. I believe that in my original scala-debate discussion (https://groups.google.com/d/topic/scala-debate/tGMUQzSCsKc/discussion) I initially also argued for a positional approach, where one could provide a wild-card character in the positions to be inferred; however, because of disagreement on whether there is a good wildcard character to be used, I ended up with just the named type parameter suggestion (similarly to named value parameters in methods) in the SIP draft. 

I believe that in that discussion thread, Jason Zaugg provided a quick prototype (https://github.com/scala/scala/compare/scala:2.12.x...retronym:topic/sip-infer-me) showing that such positional partial type argument specification could be done, at least for the cases supported in the prototype. Of course, covering all cases might require more work thinking how to handle features like overloading and other corner cases.

Now, taking both partial type argument specification and partial type application into account, I can see some obvious challenges:

• Would it be possible to use named type parameters for both?
• My initial hypothesis would be no, or rather that it require some more thought. For example, `map[F=Tuple[T2=String]](f)` may lead to confusion on which concept is used where, especially for non-expert users.
• Alternatively one could differentiate the uses by using different constraint symbols, e.g. `==` or `=?=` for partial type argument specification, but that seems to overly complicate things and be somewhat verbose.
• Another alternative, is to find a suitable wildcard for position partial argument specification for example `!`. The main disadvantage of this, along with requirement to treat a new symbol as a special wild card, is that combined with positional partial type application (e.g. `?` used in kind projector, or `_` in the proposal) one almost gets a small language for specifying type parameters.
• It requires non-trivial changes to various parts of the compiler
• For partial type argument specification, I believe that this is mostly around the front-end, specifically the parser (for the new syntax) and typing system (to add the additional constraints in the inference process). For the latter, this might not be straightforward, for example if the scala/dotty type system already has an inference strategy that depends on some ordering of type arguments, which the user now can change.
• For partial type application, I think the document on higher-kinded types already covers many of the challenges. 

Of course, you might also see more challenges that should be added to that list, and I look forward to have a discussion with you.

Thanks again,

Ahmad Salim

* I think that the meeting determined that the proposed PR did not have enough depth in technical details to be called a complete SIP.