one little implicit

On Sun, Feb 20, 2011 at 9:21 PM, Paul Phillips wrote:
> I feel like there must be some reason I haven't done this before, but since
> I can't remember it, it sure looks appealing right about now.  Add one
> little tiny implicit to Predef...
>
>  implicit def compareComparables[T](x: T)(implicit ord: Ordering[T]):
> Ordering[T]#Ops = new ord.Ops(x)

At the risk of stating the obvious, Numeric would benefit from the
same treatment.

scala> implicit def numericOps[T](lhs: T)(implicit n: Numeric[T]):
Numeric[T]#Ops = n.mkNumericOps(lhs)
numericOps: [T](lhs: T)(implicit n: Numeric[T])scala.math.Numeric[T]#Ops

scala> def foo[T: Numeric](t: T) = t - t
foo: [T](t: T)(implicit evidence$1: Numeric[T])T

-jason

Looks cool. If it does present problems on Predef, it could be provided on Ordering, at least.

On Sun, Feb 20, 2011 at 17:21, Paul Phillips <paulp@improving.org> wrote:

I feel like there must be some reason I haven't done this before, but since I can't remember it, it sure looks appealing right about now.  Add one little tiny implicit to Predef...

 implicit def compareComparables[T](x: T)(implicit ord: Ordering[T]): Ordering[T]#Ops = new ord.Ops(x)

And suddenly your methods involving Ordering look like this:

 scala> def bippy[T: Ordering](x: T, y: T) = x < y

rather than your current options (assuming you like using the nice operators.)

 scala> def bippy[T: Ordering](x: T, y: T) = { val ord = implicitly[Ordering[T]] ; import ord._ ; x < y }

 scala> def bippy[T](x: T, y: T)(implicit ord: Ordering[T]) = { import ord._ ; x < y }

What is that old saying? Implicit conversions which take implicit parameters are the happiest implicits in the world? Something like that.

--
Daniel C. Sobral

I travel to the future all the time.

I really like this implicit.

Any chance we could try to put it on the companion for any or Function1?  Should achieve the same result.

I've become very anti predef in my old age.

On Feb 20, 2011 5:50 PM, "Daniel Sobral" <dcsobral@gmail.com> wrote:

Looks cool. If it does present problems on Predef, it could be provided on Ordering, at least.

On Sun, Feb 20, 2011 at 17:21, Paul Phillips <paulp@improving.org> wrote:
>
> I feel like there mu...

--
Daniel C. Sobral

I travel to the future all the time.

On 2/20/11 12:45 PM, Jason Zaugg wrote:
> At the risk of stating the obvious, Numeric would benefit from the
> same treatment.

You are a daring risk taker!

Continuing with the obvious, I started fiddling around with something
along the lines of:

trait HasImplicitOps[T, +M[X]] {
abstract class AbstractOps(lhs: T) { }
type Ops <: AbstractOps
def implicitOps(lhs: T): Ops
}

implicit def agnosticImplicitOps[T, TC[X] <: HasImplicitOps[T, TC]](x:
T)(implicit tc: TC[T]): TC[T]#Ops = ...

But it's not really a detour I have time for right now. You seem like a
likely person to know whether it has any chance of making it to working.
I feel like if it did, someone would have done it already, but I've
been surprised before. It looks like everything would work easily
enough except the type inference, which is one of those "other than that
mrs. lincoln, how was the play" caveats, consigning it to hypothetical
land for another time around the maypole.

On 2/20/11 3:35 PM, Josh Suereth wrote:
> I really like this implicit.
>
> Any chance we could try to put it on the companion for any or
> Function1? Should achieve the same result.

I would be kind of surprised if either of those "just worked".
Especially the non-existent Any companion object. I had to agree to mow
the devil's lawn for the next 144 months to bootstrap the AnyVal
sources, and I don't want to know what the price is for Any.

> I've become very anti predef in my old age.

I'm with you about predef from day one, but I don't think spreading
things around addresses the problem.