When there is an equality assertion in scalatest that fails. It generally shows only the different part, e.g.:
"...error;
!I e: F[Arg]
[g invalid because
nonconformant bounds;
[Arg, Nothing]
[A <: __wrapper$1$47213a912399466a973eddce7b3420f4.__wrapper$1$47213a912399466a973eddce7b3420f4.]Bounds.Base, B]
im..." did not equal "...error;
!I e: F[Arg]
[Bounds.g invalid because
nonconformant bounds;
[Arg, Nothing]
[A <: ]Bounds.Base, B]
im..."
org.scalatest.exceptions.TestFailedException: "...error;
!I e: F[Arg]
[g invalid because
nonconformant bounds;
[Arg, Nothing]
[A <: __wrapper$1$47213a912399466a973eddce7b3420f4.__wrapper$1$47213a912399466a973eddce7b3420f4.]Bounds.Base, B]
im..." did not equal "...error;
!I e: F[Arg]
[Bounds.g invalid because
nonconformant bounds;
[Arg, Nothing]
[A <: ]Bounds.Base, B]
im..."
A lot of information are lost in this report. In addition, When the IDE is armed with a diff parser, it will show the comparison result incorrectly. Is there way to disable this feature in scalatest, so there won't be any ellipsis in the report?
You can add the flag -- -Dtest.show_diff=true. The full command will look like: test-only *TestFileName* -- -Dtest.show_diff=true
Unfortunately this is impossible at the moment starting with ScalaTest 3.x.x without writing your own custom assertion code. See this issue.
You can change the prettifier to Prettifier.basic like this for example:
import scalatest.org.Assertions._
import org.scalactic.Prettifier
assert(foo == bar)(Prettifier.basic, org.scalactic.source.Position.here)
But even then I it will use the StringDiffer with a hard coded MaxContext of 20 characters.
Related
I'm attempting to use the #usecase scaladoc annotation to simplify a complicated type which has been uglified in the process of kind-projector constructing a type lambda for me. Here is the function in question:
def oneOf[P[_], I](alts: List[Alt[Schema[Unit, P, ?], I, B] forSome {type B}]): Schema[Unit, P, I]
By the time it gets to scaladoc, however, it's gotten pretty mangled:
def oneOf[P[_], I](alts: List[Alt[[γ$13$]HCofree[[β$0$[_$1], γ$1$]SchemaF[P, β$0$, γ$1$], Unit, γ$13$], I, _]]): Schema[Unit, P, I]
I'd love it if I could just have the original function definition in the scaladocs, so I attempted to use the #usecase annotation to give it my own definition:
/** Builds an un-annotated schema for the sum type `I` from a list of alternatives.
*
* Each alternative value in the list describes a single constructor of `I`.
* For example, to construct the schema for [[scala.util.Either]] one would provide
* two alternatives, one for the `Left` constructor and one for `Right`.
*
* #usecase def oneOf[P[_], I](alts: List[Alt[Schema[Unit, P, ?], I, _]]): Schema[Unit, P, I]
*/
def oneOf[P[_], I](alts: List[Alt[Schema[Unit, P, ?], I, B] forSome {type B}]): Schema[Unit, P, I] =
However, it looks like the #usecase value is actually being processed somehow by the Scala compiler, and nothing I do can convince it to allow me to use this string directly. Here's a sample error:
> doc
[info] Main Scala API documentation to /home/nuttycom/schematic/target/scala-2.12/api...
[error] /home/nuttycom/schematic/src/main/scala/schematic/Schema.scala:106: not found: type ?
[error] * #usecase def oneOf[P[_], I](alts: List[Alt[Schema[Unit, P, ?], I, _]]): Schema[Unit, P, I]
[error] ^
[info] No documentation generated with unsuccessful compiler run
Is there any mechanism that I can use to get scaladoc to not attempt to parse or otherwise validate the usecase string?
Given:
scala> import shapeless.nat.
_0 _10 _12 _14 _16 _18 _2 _21 _3 _5 _7 _9 natOps
_1 _11 _13 _15 _17 _19 _20 _22 _4 _6 _8 apply toInt
scala> import shapeless.ops.nat._
import shapeless.ops.nat._
After > 3 minutes, the following code has not compiled/run. Why's that?
scala> Sum[_22, _22]
Also, looking at the above REPL auto-completion, does _44 even exist in shapeless?
Why is it so slow?
Let's start with a smaller number. When you ask for Sum[_4, _4], the compiler is going to go looking for an instance, and it'll find these two methods:
implicit def sum1[B <: Nat]: Aux[_0, B, B] = new Sum[_0, B] { type Out = B }
implicit def sum2[A <: Nat, B <: Nat](implicit
sum: Sum[A, Succ[B]]
): Aux[Succ[A], B, sum.Out] = new Sum[Succ[A], B] { type Out = sum.Out }
The first one is clearly out since _4 is not _0. It knows that _4 is the same as Succ[_3] (more on that in a second), so it'll try sum2 with A as _3 and B as _4.
This means we need to find a Sum[_3, _5] instance. sum1 is out for similar reasons as before, so we try sum2 again, this time with A = _2 and B = _5, which means we need a Sum[_2, _6], which gets us back to sum2, with A = _1 and B = _6, which sends us looking for a Sum[_1, _7]. This is the last time we'll use sum2, with A = _0 and B = _7. This time when we go looking for a Sum[_0, _8] we'll hit sum1 and we're done.
So it's clear that for n + n we're going to have to do n + 1 implicit searches, and during each one the compiler is going to be doing type equality checks and other stuff (update: see Miles's answer for an explanation of what the biggest problem here is) that requires traversing the structure of the Nat types, so we're in exponential land. The compiler really, really isn't designed to work efficiently with types like this, which means that even for small numbers, this operation is going to take a long time.
Side note 1: implementation in Shapeless
Off the top of my head I'm not entirely sure why sum2 isn't defined like this:
implicit def sum2[A <: Nat, B <: Nat](implicit
sum: Sum[A, B]
): Aux[Succ[A], B, Succ[sum.Out]] = new Sum[Succ[A], B] { type Out = Succ[sum.Out] }
This is much faster, at least on my machine, where Sum[_18, _18] compiles in four seconds as opposed to seven minutes and counting.
Side note 2: induction heuristics
This doesn't seem to be a case where Typelevel Scala's -Yinduction-heuristics helps—I just tried compiling Shapeless with the #inductive annotation on Sum and it's still seems pretty much exactly as horribly slow as without it.
What about 44?
The _1, _2, _3 type aliases are defined in code produced by this boilerplate generator in Shapeless, which is configured only to produce values up to 22. In this case specifically, this is an entirely arbitrary limit. We can write the following, for example:
type _23 = Succ[_22]
And we've done exactly the same thing the code generator does, but going one step further.
It doesn't really matter much that Shapeless's _N aliases stop at 22, though, since they're just aliases. The important thing about a Nat is its structure, and that's independent of any nice names we might have for it. Even if Shapeless didn't provide any _N aliases at all, we could still write code like this:
import shapeless.Succ, shapeless.nat._0, shapeless.ops.nat.Sum
Sum[Succ[Succ[_0]], Succ[Succ[_0]]]
And it would be exactly the same as writing Sum[_2, _2], except that it's a lot more annoying to type.
So when you write Sum[_22, _22] the compiler isn't going to have any trouble representing the result type (i.e. 44 Succs around a _0), even though it doesn't have a _44 type alias.
Following on from Travis's excellent answer, it appears that it's the use of the member type in the definition of sum2 which is the root of the problem. With the following definition of Sum and its instances,
trait Sum[A <: Nat, B <: Nat] extends Serializable { type Out <: Nat }
object Sum {
def apply[A <: Nat, B <: Nat](implicit sum: Sum[A, B]): Aux[A, B, sum.Out] = sum
type Aux[A <: Nat, B <: Nat, C <: Nat] = Sum[A, B] { type Out = C }
implicit def sum1[B <: Nat]: Aux[_0, B, B] = new Sum[_0, B] { type Out = B }
implicit def sum2[A <: Nat, B <: Nat, C <: Nat]
(implicit sum : Sum.Aux[A, Succ[B], C]): Aux[Succ[A], B, C] =
new Sum[Succ[A], B] { type Out = C }
}
which replaces the use of the member type with an additional type variable, the compile time is 0+noise on my machine both with and without -Yinduction-heurisitics.
I think that the issue we're seeing is a pathological case for subtyping with member types.
Aside from that, the induction is so small that I wouldn't actually expect -Yinduction-heurisitics to make much of an improvement.
Update now fixed in shapeless.
Using shapeless, I'm trying to define a function:
import shapeless._
import ops.nat._
import nat._
def threeNatsLessThan3[N <: Nat](xs: Sized[List[N], N])
(implicit ev: LTEq[N, _3]) = ???
where it will only compile if the input xs is a List (of sized 3) of Nat where each element is <= 3.
But that fails to compile:
scala> threeNatsLessThan3[_3](List(_1,_2,_3))
<console>:22: error: type mismatch;
found : List[shapeless.Succ[_ >: shapeless.Succ[shapeless.Succ[shapeless._0]] with shapeless.Succ[shapeless._0] with shapeless._0 <: Serializable with shapeless.Nat]]
required: shapeless.Sized[List[shapeless.nat._3],shapeless.nat._3]
(which expands to) shapeless.Sized[List[shapeless.Succ[shapeless.Succ[shapeless.Succ[shapeless._0]]]],shapeless.Succ[shapeless.Succ[shapeless.Succ[shapeless._0]]]]a>
twoNatsFirstLtEqSecond[_3](List(_1,_2,_3))
^
How can I implement the above function correctly?
Also I would appreciate a solution using an HList too, where the HList consists only of Nat elements (if possible).
What you're typing as the signature is a List of size N which contains only elements of type N. To whit, Sized[List[N], N] denotes one of the following: List(_1), List(_2, _2), or finally List(_3, _3, _3), taking into consideration your type level constraint. That's almost what you want and explains the error the compiler is giving you:
required: shapeless.Sized[List[shapeless.nat._3],shapeless.nat._3]
To begin breaking down what you want to accomplish we need to note that you can't have a List[Nat] and also preserve the individual types. The abstractness of Nat would obscure them. So if you want to do things at compile time, you're going to have three choices: work with an HList, choose to fix the type of Nat within the list so that you have List[N] or choose to fix the size of the List[Nat] with Sized.
If you want to say that the List has size less than 3, then
def lessThanThree[N <: Nat](sz: Sized[List[Nat], N])(implicit ev: LTEq[N, _3]) = sz
If you want to say that the List has a Nat of less than three, again with a fixed N within the List:
def lessThanThree[N <: Nat, M <: Nat](sz: Sized[List[N], M])(implicit ev: LTEq[N, _3]) = sz
If you're looking to perhaps work with a Poly where you could define an at for any Nat such that it preserves the LTEq constraint, you'll need to understand that Sized does make working with map conform closer to the standard package map found on most collections, i.e. it requires a CanBuildFrom. That combined with the erasure of the individual Nat in List means that you'll have a lot of difficulty coming up with a solution which gives you the type of flexibility you're looking for.
If you were to work with an HList, you could do the following:
object LT3Identity extends Poly{
implicit def only[N <: Nat](implicit ev: LTEq[N, _3]) = at[N]{ i => i}
}
def lt3[L <: HList, M <: Nat](ls: L)(implicit lg: Length.Aux[L, M], lt: LTEq[M, _3]) = ls.map(LT3Identity)
which does both constrain your size of the Hlist to less than 3 while also only allowing HList that contain Nat of less than or equal to 3.
def typeSafeSum[T <: Nat, W <: Nat, R <: Nat](x: T, y: W)
(implicit sum: Sum.Aux[T, W, R], error: R =:!= _7) = x
typeSafeSum(_3, _4) //compilation error, ambiguous implicit found.
I dont think that error message "ambiguous implicit found" is friendly, how can I customize it to say something like "the sum of 2 NAT value should not equal to 7"
Many thanks in advance
shapeless's =:!= (and similar type inequality operators) inherently exploit ambiguous implicits to encode Prolog-style negation as failure. And, as you've observed, Scala doesn't have a mechanism which allows library authors to provide more meaningful error messages when ambiguity is expected. Perhaps it should, or perhaps Scala should provide a more direct representation of the negation of a type making this encoding unnecessary.
Given that you've couched the question in terms of Nats I think it's probably reasonable that you're trying to work with type inequality. If it weren't Nats my recommendation in answer to another question that a type class directly encoding the relation of interest would apply here too. As it is though, I recommend that same solution as a workaround for not being able to provide better error messages.
import shapeless._, nat._, ops.nat._
#annotation.implicitNotFound(msg = "${A} + ${B} = ${N}")
trait SumNotN[A <: Nat, B <: Nat, N <: Nat]
object SumNotN {
implicit def sumNotN[A <: Nat, B <: Nat, R <: Nat, N <: Nat]
(implicit sum: Sum.Aux[A, B, R], error: R =:!= N): SumNotN[A, B, N] =
new SumNotN[A, B, N] {}
}
def typeSafeSum[T <: Nat, W <: Nat](x: T, y: W)
(implicit valid: SumNotN[T, W, _7]) = x
scala> typeSafeSum(_3, _4)
<console>:20: error: shapeless.nat._3 + shapeless.nat._4 = shapeless.nat._7
typeSafeSum(_3, _4)
^
The technique (hiding an expected ambiguous implicit behind an implicit we expect to be not found in the case of underlying ambiguity) is generally applicable, but is obviously fairly heavyweight ... another reason why type inequalities should be avoided if at all possible.
I see this method in scala List.sum
sum[B >: A](implicit num: Numeric[B]): B
now I understand that it expects any num argument to be implicitly converted to Numeric[B] which means its of typeclass Numeric However what I don't understand is what is this A doing there if the implementation block does not refer to it at all.
the return value is B
and the implementation is
foldLeft(num.zero)(num.plus)
and num is also of type Numeric[B] so if return value does not refer to A and implementation does not refer to A why is it needed?
It needs to be able to act on the contents of the list, which are As. Therefore, B must be a superclass of A, which is what B >: A means.
(In particular, num.plus must accept A arguments to match the signature of fold.)