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
A first version would just extend the forall - always prop to only 1 input 1 derived, 2 input 1 derived, 1 input 2 derived, 2 inout 2 derived.
The main difference with ScalaCheck Prop.forall, which just has hand coded props for arities from 1 to 8 by using currying, is that the combination of input and derived dstreams lead to 8 x 8 = 64 possibilities. Also it is not clear that currying could be applied here. Hence consider Shapeless HList https://github.com/milessabin/shapeless/wiki/Feature-overview:-shapeless-2.0.0
to simulate heterogeneously typed varargs, instead of relaying on several overload for different arities. But it is important that the user only needs to use raw tuples, use the typpe reconstruction capabitilies of .cast, or "facilities for abstracting over arity": we can ask the user to use a convention based on position of the argument, but the type should be preserved.
The text was updated successfully, but these errors were encountered:
A simpler solution is using a fixed number of arguments, which fixes the number of type variables, and using Option to express optional arguments, e.g. Option[Gen[Seq[Seq[Ei]]]]. Then we'd have a single complex version of DStreamProp.forAll, and all the other version with simpler parameters would be wrappers on particular calls to the complex one
for #16 implementation schema completed, missing
extra overloads of forAllDStream based on generic
version, and supporting up to 4 generators and
transformation, currently only 2 for routinary work
A first version would just extend the forall - always prop to only 1 input 1 derived, 2 input 1 derived, 1 input 2 derived, 2 inout 2 derived.
The main difference with ScalaCheck Prop.forall, which just has hand coded props for arities from 1 to 8 by using currying, is that the combination of input and derived dstreams lead to 8 x 8 = 64 possibilities. Also it is not clear that currying could be applied here. Hence consider Shapeless HList https://github.com/milessabin/shapeless/wiki/Feature-overview:-shapeless-2.0.0
to simulate heterogeneously typed varargs, instead of relaying on several overload for different arities. But it is important that the user only needs to use raw tuples, use the typpe reconstruction capabitilies of .cast, or "facilities for abstracting over arity": we can ask the user to use a convention based on position of the argument, but the type should be preserved.
The text was updated successfully, but these errors were encountered: