You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The in scope view, ApplicativeIdV in Scalaz seems to lead to curious results:
objectTest {
importscalaz.Scalaz._valy2: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`!valy3= y2.map(((x$1: (String, Int)) => scalaz.WriterT.apply(x$1)))
scalaz.WriterT.apply/* !!! [Any, Nothing, Nothing]*/(("", 0))
}
objectTestNoImport {
valy2: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))
}
objectTestSpecificImports {
importscalaz.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:
objectStandalone {
traitM[A]
defwriterT[F[_], A, B](fab: F[(A, B)]) =???
writerT((0, 0)) // type error, as we exped
{
implicitdefView[A](v: =>A):M[A] {} =???
writerT/* !!! [Any, Nothing, Nothing]*/((0, 0)) // no type error
}
}
The text was updated successfully, but these errors were encountered:
The in scope view,
ApplicativeIdV
in Scalaz seems to lead to curious results: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 ofScalaz._
. 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 withF[(A, B)]
instantiated asAny[(Nothing, Nothing)]
, which is justAny
. The argument(0, 0)
conforms to this.Here's a standalone look at this:
The text was updated successfully, but these errors were encountered: