Re: scalac does not infer super types when implicit for super type exists.

Hi Stephen,

Thanks for your reply.

On Saturday, 21 March 2015 06:09:20 UTC+2, Stephen Compall wrote:

It undermines it, but not seriously. In most cases in non-test code, you 
> don't statically know which data constructor of the ADT you have in hand 
> anyway.


I disagree here. The following situations are common:

   1. Creating object literals (as demonstrated) is not specific to test 
   code (although it's more prevalent there). Besides, test code is just as 
   important to me as non-test code (around 50% of my code is test code).
   2. It seems you assume that working with ADTs always means you only know 
   you have something whose type is the base of the hierarchy (perhaps because 
   the hierarchy is shallow). But some hierarchies are deep, and methods might 
   return a more specific type than the root. Think about the spire 
   example, It is perfectly valid to have a method returning a B
   
   def foo(i): B = B(i)
   
   def bar(a: A): Unit = println(a.i)
   
   bar(foo(1)) //Compiles
   
   foo(1) + foo(2) //Does not compile
   
   Of course I could define foo this way:
   
   def foo(i): A = B(i)
   
   but then I have information loss. 

Any solution to the problem you describe must satisfactorily address the 
> various concerns raised in this very argumentative thread about this issue 
> <https://groups.google.com/d/msg/scala-language/ZE83TvSWpT4/el3-hNgzwv8J>
> . 
>

I've been looking at that thread  - I'm not sure this is exactly the same 
problem. The thread deals specifically with contravariant typeclasses - my 
case is the one of an invariant typeclass. while playing with my own 
example and the one in https://issues.scala-lang.org/browse/SI-2509 I've 
found that scalac is very (too) sensitive to a lot of detail, such as 
whether I write 

implicit object RA extends R[A]

or  


object RA extends R[A]

implicit val ra = A

or

object RA extends R[A]

implicit val ra: R[A] = A


Now couple this with the placement of the implicit definition (both 
evidences in the same scope vs in each companion object) and with an 
invariant vs. contravariant typeclass and you get every possible outcome (A 
inferred, B inferred, implicit not found, ambigious implicits).

My point being - although that issue also deals with implicit search, I'm 
not convinced this is actually the same issue.

Specifically regarding your proposal, you must also deal with the fact that 
> there may be no unambiguous or finite linearization of supertypes of a 
> given type to try.


Well implicit search has a notion of a finite linearization of supertypes - 
why not use it for this case as well? 


Jon

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.