Re: Re: issue with implicit conversion

Seth Tisue wrote:
>>>>>> "Raphael" == Raphael Jolly writes:
>
> Raphael> Then how comes this simpler example is working: [...]
>
> Maybe the recursive nature of the Poly[Poly] type is what is confusing
> the compiler.
>
> I think it's a compiler bug and you should file a report.

done:

Issue with implicit conversion
http://lampsvn.epfl.ch/trac/scala/ticket/1756

Raphael

>>>>> "Raphael" == Raphael Jolly writes:

Raphael> So it seems that the compiler is only looking for an implicit
Raphael> conversion when there is no method at all, not when there is
Raphael> one with the wrong arguments.

That's not right. If you write x + y, the compiler is perfectly willing
to insert an implicit conversion like this:

x + implicit(y)

In general, if you write x + y, and it doesn't compile as written, the
compiler will try implicits as follows:

implicit(x) + y
x + implicit(y)

but it won't try

implicit(x) + implicit(y)
implicit1(implicit2(x)) + y
x + implicit1(implicit2(y))

and this is by design. Your "1 + a" doesn't compile because the compiler
would have to add implicits on both sides: "int2b(1) + a2b(a)".

Seth Tisue wrote:
>
> Raphael> So it seems that the compiler is only looking for an implicit
> Raphael> conversion when there is no method at all, not when there is
> Raphael> one with the wrong arguments.
>
> That's not right. If you write x + y, the compiler is perfectly willing
> to insert an implicit conversion like this:
>
> x + implicit(y)
>
> In general, if you write x + y, and it doesn't compile as written, the
> compiler will try implicits as follows:
>
> implicit(x) + y
> x + implicit(y)
>
> but it won't try
>
> implicit(x) + implicit(y)
> implicit1(implicit2(x)) + y
> x + implicit1(implicit2(y))
>
> and this is by design. Your "1 + a" doesn't compile because the compiler
> would have to add implicits on both sides: "int2b(1) + a2b(a)".

If you read carefully my former example, you will see that the compiler
is perfectly willing to accept:

implicit(a)+implicit(a)

Raphael

>>>>> "Raphael" == Raphael Jolly writes:

Raphael> If you read carefully my former example, you will see that the
Raphael> compiler is perfectly willing to accept:

Raphael> implicit(a)+implicit(a)

You're right. Thanks, I just learned something.

>>>>> "Alex" == Alex Boisvert writes:

Raphael> So it seems that the compiler is only looking for an implicit
Raphael> conversion when there is no method at all, not when there is
Raphael> one with the wrong arguments. I would be surprised this one is
Raphael> not on purpose. This is sometimes annoying, but not as bad as
Raphael> my original problem as far as my project is
Raphael> concerned. Although these two problems may be related, of
Raphael> course, in which case perhaps x+x*y is bound to fail. This
Raphael> would be too bad really.

Alex> Not quite. The issue here is conflicting implicits because Scala
Alex> defines the "+" operator in Predef.anyToString.
Alex> Your example works if you use a different operator (e.g. ++)

Hmm... but it doesn't work with *, as shown below, so I think that shows
Predef.anyToString is irrelevant here.

scala> class A
defined class A

scala> class B { def *(that: B) = new B }
defined class B

scala> implicit def a2b(a: A) = new B
a2b: (A)B

scala> implicit def int2b(n: Int) = new B
int2b: (Int)B

scala> val a = new A
a: A = A@1cc01a

scala> a * 1
res0: B = B@da7c9a

scala> 1 * a
:10: error: overloaded method value * with alternatives (Double)Double (Float)Float (Long)Long (Int)Int (Char)Int (Short)Int (Byte)Int cannot be applied to (A)
1 * a
^

 Alex> Not quite.  The issue here is conflicting implicits because Scala
 Alex> defines the "+" operator in Predef.anyToString.
 Alex> Your example works if you use a different operator (e.g. ++)

Hmm... but it doesn't work with *, as shown below, so I think that shows
Predef.anyToString is irrelevant here.