scala> import cats.data.OneAnd
import cats.data.OneAnd
scala> import cats.data.OneAndInstances
import cats.data.OneAndInstances
scala> case class F[A](x: Int)
defined class F
scala> OneAnd[F, Int](555, F[Int](1234))
res1: cats.data.OneAnd[F,Int] = OneAnd(555,F(1234))
I faintly recall asking a similar question a while ago in a Haskell library. I think that the answer involved "constraints are not implemented at the data type
level," but that's a very weak memory.
Thanks,
Kevin
I faintly recall asking a similar question
Putting the constraint in the tree structure itself makes the type
more precise, in that it can now store only values which can be
compared at the nodes, at the cost of making it less reusable. This
is a tradeoff we often have to consider when defining new data
types.
> I'd be wary to trust the conventional Haskell design approach given that type class coherence/confluence/uniqueness has been broken for more than half a decade already, with no fix in sight.Simon - could you please post a link for me to read more about what this means. I don't follow how it's broken, but ,first, I'd like to know what typeclass coherence means.
Prof. Edwin Brady's Type-Driven Development with Idris book comments when discussingwhether to put the `Ord` restraint on the data structure (Binary Tree) or the `insert` method:Putting the constraint in the tree structure itself makes the type
more precise, in that it can now store only values which can be
compared at the nodes, at the cost of making it less reusable. This
is a tradeoff we often have to consider when defining new data
types.
> I'd be wary to trust the conventional Haskell design approach given that type class coherence/confluence/uniqueness has been broken for more than half a decade already, with no fix in sight.Simon - could you please post a link for me to read more about what this means. I don't follow how it's broken, but ,first, I'd like to know what typeclass coherence means.