Allow implicit precedence to be controlled by an `@implicitWeight` annotation

[paulp]

...or any way of controlling implicit precedence which doesn't require creating ridiculous inheritance hierarchies. scala@c01e44786d

[propensive]

I tested this out this patch in old fork a few months ago. @paulp's not lying when he implies it works.

[puffnfresh]

👍

[tixxit]

👍!!

[non]

👍 this would be incredibly useful

[gabro]

+1, the LowPriority trait dance is madness!

[puffnfresh]

Reminds me of the CSS z-index mess, though. Can't wait to see @implicitWeight(9999).

[paulp]

@puffnfresh Your reservations are warranted. My enthusiasm for a better mechanism exceeds my enthusiasm for this mechanism. But at the moment I don't have a better idea.

[paulp]

As an aside, it's funny how many of our problems come down to composition.

[Blaisorblade]

👍

As an aside, it's funny how many of our problems come down to composition.

Composition is a major PL problem, and Scala's goal is to have progress on this.

Can you spell out requirements on the order structure of weights?
In short, if I'm guessing requirements correctly, floating point weights might be an improvement, though not perfect.

Floating point would satisfy the requirement that :

1. between any two weights there's always another weight.

Another advantage is that we have two infinities, so that we can write @implicitWeight(Double.PositiveInfinity). Requirement:

there's a least weight and a biggest weight (like in a complete lattice).

However, I'm talking about the mathematical set of rationals extended with both infinities — also because I believe that's the level the discussion should happen at.
Doubles have extra stuff we don't care for — two different zeros, and NaN. We would rule NaNs out and declare zeros equal.

Also, do we want a total ordering? I don't really buy that; I think you want some complete lattice.
(Though I can't think of an interesting complete lattice which is dense and not a total order).

1. If the ordering of weights is partial, we have the possibility to express ambiguity.
2. Choosing sensible weights globally can't be modular. In fact, what's modular is to order weights within a single library. But if you have conflicting implicits from two libraries, it doesn't make sense that one or the other libraries prevails because e.g. the first libraries uses weights 1 and 2 and the second chooses weights 1000 and 2000: you really want them to conflict. So you need weights to form a partial order; in this scenario, only weights from the same library should be comparable.
   One should be able to resolve the ambiguity by writing some glue code, by reexporting the implicits with different priorities. (Should the need arise, one might design support for this glue code). Sth. like:

@implicitWeight(100) implicit val reexportFoo = lib1.foo _;
@implicitWeight(120) implicit val reexportFoz = lib1.foz _;
@implicitWeight(200) implicit val reexportBar = lib2.bar _;
@implicitWeight(300) implicit val reexportBaz = lib2.baz _;

A problem is that I know no sensible definition of "module" or "library" for use here.

[Blaisorblade]

As a counterpoint to what I wrote: we should be careful with letting perfect be the enemy of good; in particular, we should try to satisfy requirements we actually have, not just stuff we imagine is important.

[paulp]

@Blaisorblade that's definitely the spirit of the actually written patch. You can see the immediate payoff in nearby commits, and I have no doubt everyone here has a project which would also see immediate benefits.

[non]

I agree with @paulp -- weights would be a huge payoff.

If the cost of specifying weight as a Double is small, it might be worth changing to make it harder to create two weights with no weight in between them. (Note: harder, not impossible.) But I don't want to bike shed this to death (despite my previous statements about how attractive a turquoise shed would be).

[milessabin]

I share @Blaisorblade's concerns here. I'm also not convinced that the benefits are that great once we've dealt with the headline cases. Does anyone have an estimate of the LoC reduction this would win for Scalaz?

[propensive]

So, my instinct is to agree with @Blaisorblade and @milessabin about the lack of modularity, though I think the benefits of the "simple" solution would be significant. But let's not rush into this.

Here's an alternative suggestion I just came up with. In the event of finding ambiguous implicits, could we have some sort of adjudicator (disambiguator?) -- itself defined as an implicit, and resolved by the same rules, but only in the event of a tie -- determine the winner?

Open questions:

• How do you define such an adjudicator?
• In particular, if you have a tie between 2 (or n) implicits, possibly from different libraries, how do we specify in the adjudicator definition how we match which implicits we're disambiguating between? We could have the adjudicator describe an order (partial or total?) on which implicits it should use first, but how would we refer to those implicits?
• If we find an adjudicator which doesn't reference one or more of the ambiguous implicits, do we ignore it because we consider that it doesn't know enough?
• Adjudicators would probably need to compose
• What happens if we have ambiguous adjudicators? (I actually don't think this matters; we solve it the same way.)
• If we introduced such a new concept, what other (unintended, possibly evil) possibilities could it introduce?

This all sounds quite complicated. I suspect it has to be, because we're working in the realm of implicit search, but (as you can see) my ideas are vague at best right now. Hopefully some sense can be made out of all this...

[paulp]

@propensive Please see this thread in particular this message about inference guidance.

trait Guidance {
  def inferrable(tpe: Universe#Type): Boolean
}
object NoGuidance extends Guidance {
  def inferrable(tpe: Universe#Type) = true
}
object NoAnyGuidance extends Guidance {
  def inferrable(tpe: Universe#Type): Boolean = !(tpe exists (tp => tp.typeSymbol.fullName.toString == "scala.Any"))
}

Anything like this is so much more complicated than the implicitWeight annotation it's not even in the same sphere of discussion. You guys will have to decide between some of your taller ambitions and maintaining compatibility, because you won't do both.