Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The left-hand (doTypedApply) doesn't know what the right hand (isApplicable) is doing #8427

Open
scabug opened this issue Mar 18, 2014 · 2 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Mar 18, 2014

The in scope view, ApplicativeIdV in Scalaz seems to lead to curious results:

object Test {
  import scalaz.Scalaz._

  val y2: List[(String, Int)] = ???
  
  // erroneous or inaccessible type in 210dbc7~1
  // after 210dbc7~1, we get unexpected inferred types for `apply`.
  // I think this stems from an in-scope implicit making the application
  // viable (via `isCoercible`), even though no view is applied to `x$1`!
  val y3 = y2.map(((x$1: (String, Int)) => scalaz.WriterT.apply(x$1)))

  scalaz.WriterT.apply/* !!! [Any, Nothing, Nothing]*/(("", 0))
}

object TestNoImport {
  val y2: List[(String, Int)] = ???
  
  // both of these give the expected type errors before and after 210dbc7.
  //val y3 = y2.map(((x$1: (String, Int)) => scalaz.WriterT.apply(x$1)))
  //scalaz.WriterT.apply(("", 0))
}

object TestSpecificImports {
  import scalaz.Scalaz.ApplicativeIdV
  scalaz.WriterT.apply(("", 0)) 
}

We expect a type error for all of those apply calls (as we don't have higher order unification to infer the identity type constructor, Tuple2[A, B] ought not to be applicable.

But, isCompatible also checks if arguments can be coerced to the formal parameter type with a view.

If you're unlucky enough to have exactly one view in scope that fits the bill, the application is deemed compatible. Views are sought in two phases based on their evaluation strategy: firstly strict and secondly by-name. The view ApplicativeIdV is in the second category, and is probably the lone _ -> _[_] view in the grab-bag of Scalaz._. For reasons that aren't clear to me, it also needs to return a refinement type to trip this bug.

The icing on the cake is the fact that the view actually doesn't get applied, we reinfer the type parameters in doTypedApply, and end up with F[(A, B)] instantiated as Any[(Nothing, Nothing)], which is just Any. The argument (0, 0) conforms to this.

Here's a standalone look at this:

object Standalone {
  trait M[A]
  def writerT[F[_], A, B](fab: F[(A, B)]) = ???
  
  writerT((0, 0)) // type error, as we exped

  {
    implicit def View[A](v: => A): M[A] {} = ???
    writerT/* !!!  [Any, Nothing, Nothing]*/((0, 0)) // no type error
  }
}
@scabug
Copy link
Author

scabug commented Mar 18, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8427?orig=1
Reporter: @retronym
Affected Versions: 2.10.4, 2.11.0-RC1

@scabug
Copy link
Author

scabug commented Mar 18, 2014

@retronym said:
/cc [~larsrh] @puffnfresh

@scabug scabug added the infer label Apr 7, 2017
@scabug scabug added this to the Backlog milestone Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants