New implicit parameter & argument syntax

[odersky]

Motivation

The current syntax for implicit parameters has several shortcomings.

1. There can be only one implicit parameter section and it has to come at the end. Therefore
   normal and implicit parameter types cannot depend on other implicit parameters except
   by nesting in an inner object with an apply method.

2. The syntax (implicit x: T, y: U) is a bit strange in that implicit conceptually scopes over
   x and y but looks like a modifier for just x.

3. Passing explicit arguments to implicit parameters is written like normal application. This
   clashes with elision of apply methods. For instance, if you have

     def f(implicit x: C): A => B
   

   then f(a) would pass the argument a to the implicit parameter and one has to write
   f.apply(a) to apply f to a regular argument.

Proposal

• Introduce a new symbolic delimiter, ?(. This is one token, no spaces allowed between the ? and the (.

• Write implicit parameter definitions with ?( instead of (implicit. E.g.

    def f(x: Int)?(ctx: Context) = ...
  

  instead of

    def f(x: Int)(implicit ctx: Context) = ...
  

• Explicit arguments to implicit parameters have to be enclosed in ?(...). E.g.

  f(3)?(ctx)
  

• There can be several implicit parameter sections and they can be mixed with normal parameter sections. E.g.

  def f ?(ctx: Context)(tree: ctx.Expr) = ...
  

Problems

• ? can be already used as an infix operator. So the meaning of (a)?(b) would change but
  only if no space is written after the ?, which should be rare.
• ? can be part of a symbolic operator. In this case the longest match rule applies. So
  def #?(x: T) defines an operator #? with a regular parameter list. To define # with
  an implicit parameter list an additional space is needed: def # ?(x: T).

[smarter]

Explicit arguments to implicit parameters have to be enclosed in ?(...)

I like this because it would prevent sneaky and hard to diagnose bugs like 5225f00

But I worry that newcomers will think that ??? and ? are related, even though one is very unsafe and the other completely safe, I don't have a better suggestion except maybe renaming ??? to !!! :).

[retronym]

This would still lack the expressive power to skip an implicit parameter section that is immediately followed by another implicit param section.

The workaround would be the same for as the way we selectively provide implicit params within a single section, by using implicitly.

def foo ?(a: Int) ?(b: Int) = 0
foo ?(1)?(2) // explicitly providing a and b
foo ?(implicitly)?(2) // explicitly providing b

[odersky]

@retronym Good point. I think the workaround is fine.

[Blaisorblade]

Hi! I like that you address this problem :-)

Should you want to bikeshed syntax, I'd consider using characters that are reserved — my proposal happened to use [[...]] (inspired by [...] for type arguments, which also create optional parameter lists) and should avoid the above problems with ?.
http://blaisorbladeprog.blogspot.de/2013/01/flexible-implicits-from-agda-for-scala.html

This would still lack the expressive power to skip an implicit parameter section that is immediately followed by another implicit param section.

The workaround would be the same for as the way we selectively provide implicit params within a single section, by using implicitly.

Slight issue with this workaround: you might need many implicitly to skip many arguments, and adding implicit parameters would break more source code.

What about using allowing to use named parameters to skip implicit sections? That's the solution in Agda, and it easily scales to longer lists of arguments.
While having 10 implicit arguments might (should) be less common in Scala than Agda, a more SCALAble language doesn't hurt, and I trust shapeless to run into arbitrary limits to scaling.

def foo ?(a: Int) ?(b: Int)?(c: Int)?(d: Int) = 0
foo?(d = 2) //explicitly providing `d`

[odersky]

@Blaisorblade The named argument trick looks neat. I'd like to check how hard it would be to add it.

[ctongfei]

So it would be "xs sorted ?(order)"? A little bit ugly I think.

I prefer using an additional keyword for introducing implicit parameters such as by or under but probably that'll not be backward-compatible.

Declaration:
def sorted under (T: Order[T]) = ???
def map[B](f: A => B) under (sc: SparkContext) = ???
Usage:
xs sorted under order
xs map f under sparkContext

[ctongfei]

This ? syntax also cannot express the following currently expressed by implicit:
{ implicit r => ... }

[propensive]

As an alternative, how about reusing the period (.) instead of ?? There would be no risk of it meaning anything else.

implicit val str: String = "x = "
def foo(x: Int).(y: String) = y+x
foo(0) // "x = 0"
foo(1).("Value: ") // "Value: 1"

Also, to which implicit block would context bounds be appended? Could we say, an entirely new block appended immediately after the type parameters, or would that be more confusing than a new block at the end?

Perhaps, given this new lightweight syntax, the type parameter block is the wrong place to be defining context bounds. Much as I like the context-bound syntax, assuming an anonymous parameter syntax, there's not that much difference between,

def foo[T: Typeclass](t: T) = ...

and,

def foo[T](t: T).(_: Typeclass[T]) = ...

versus the original,

def foo[T](t: T)(implicit ev: Typeclass[T]) = ...

and I think the argument could quite easily be made that the additional clarity at the definition site (especially given potential confusion about which implicit block contains the context bounds) would be a net benefit.

Generally, I'm very supportive of the original proposal, though. 👍

[mdedetrich]

Like the proposal, I disagree with the ? syntax though. ? implies optional, or maybe unknown, it just seems kinda random in the context of implicits.

In fact, I don't really see the problem with having stuff like

def f(x: Int) implicit (ctx: Context) = ...

and

f(3) implicit(ctx) 

or maybe

f(3) implicitly(ctx)

Note that I have just replaced ? with implicit/implicitly and just added whitespace to make it look cleaner.

p.s. I am kinda a fan of the implicit keyword because its easier to spot with your eye and its not confused with anything else. If we really want a symbol, than I think something like % would be better, since I don't think its used anywhere else and its also visually easy to spot. Not really a fan of @propensive idea of using a period (.), since its really hard to spot and easy to visually confuse with method invocation.

# could also work, I mean its already used for type projections but in context of implicit its somewhere else (you could also argue that they are somewhat related)

[smarter]

? implies optional, or maybe unknown, it just seems kinda random in the context of implicits.

Well, implicits are sort-of-optional arguments, the ? is also used in Haskell for implicit parameters: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#implicit-parameters

[mdedetrich]

Well, implicits are sort-of-optional arguments, the ? is also used in Haskell for implicit parameters: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#implicit-parameters

Most other mainstream languages tend to use ? to refer to an optional value, or as a safe way to deal with null. I can sought of see the connection in logic, however I would prefer to prefix the ? infront of the type, rather than using it inplace of the keyword, i.e. (? a: A, ? b: B) instead of ?(a: A,b: B).

I guess my biggest grip is more how it visually/syntactically looks

[DarkDimius]

I like the proposal, but I'm not sure about the syntax, as ? is also a potential shortcut for OR type with null.
I don't like the look of signature:

def f[A, B]?(a: ?A, b: ?B)

[sirinath]

Add an optional :- separator for implicit. E.g. (implicit:- x: T, y: U). :- means applies to all. If it is optional then omitting it will give the old syntax. Similarly you can have (x, y -: U) if you want.

Another option is to make implicitness part of the typesystem when you add effects. E.g. (x: T @ {implicit}, y: U @{implicit}) or (x: T, y: U -: @{implicit}). Assuming @{} how you specify effects and tag types (as called in Nim Language) / type extensions / annotated type (as called in X10 language).

[sirinath]

Also implicits can simply become annotations than a baked in language feature.