Maybe, other solutions exists too.īut if we talk about assuming, we are talking about global coherence. Solution seems to be existing: we need some syntax to distinguish whether function requires local coherence or not and we need to define clearly semantics and defaults. The need of this is clear and practical: it allows such a function to use different functions from required typeclass instances without worrying about incompatibility between their implementations. if a function with context-bounded parameters requires local coherence, we can check it at each use of this function. I think we should never assume coherence without proof.Īs far as I understand, we should never talk about blind assuming when we are talking about local coherence, since it can be checked locally each time it is used, i.e. It seems more useful to me to restrict the problem to different type classes that share a common baseclass. I think that would conflict with common idioms like Monad implementing map in terms of flatMap and pure. That would flag any type class that overrides a method in its base class as incoherent. what is the meaning of type-abstracting over a marker trait?įinally, I am not convinced that the best way to model coherence is as a property between a class and its base class. We did that with Singleton but if you think it through it has problems. I am reluctant to introduce more marker traits to signify a property that is not strictly speaking a type. If one absolutely needs an escape hatch, it could be via an annotation or similar, to make it clear that it's a potential soundness hole. I think we should never assume coherence without proof. What I mean by that is that if you use traits that extend the marker trait Typeclass then coherence is always assumed for both context bounds and parameter suggestion also makes sense to me. Println( Big(universe)(collab1)(collab2).tpe)
0 kommentar(er)
