Re: [scala-language] The cake’s problem, dotty des ign and the approach to modularity.

As an aside, I have taken into consideration Bracha's point that Bool 
should be considered harmful because it unnecessarily discards information. 
Thus I would prefer:

def contains[B >: A](x: B)(implicit areEqual: (A, B) => 
Option[A]): Option[A]

This works because although the return value is contravariant, the use of A 
in a type parameter is covariant. However my assumption about the caller 
knowing the actual intersection type of A falls apart due to erasure if A 
was only received by the caller's function as a type parameter.

I've noticed a fundamental problem with my idea in that I proposed the 
types in the intersection of type B won't inherit from A (although B can be 
subtype of A because A can be an intersection), thus B must invariantly be 
one of those types in the intersection. The problem is that extant areEqual 
(and I should probably be modeling it as method instead) could relate types 
not in the intersection, e.g. two types that both implement the Ord 
interface (one in the intersection of types in A and the other B). Thus 
that appears to be the weakness of Haskell's inability to inherit is we 
can't support Liskov Substitution Principle.

Thus apparently the only viable solution to the above problem is to abandon 
the idea for typeclasses and retain the one Martin proposed:

def contains[B >: A](x: B)(implicit ev: Eq[B]): Option[A]

wherein we must be careful about the semantics of interplay between extant 
Eq[_] and inheritance.

Also note the correction of the typo below from <: to >:.

On Tuesday, June 16, 2015 at 2:52:04 PM UTC+8, Shelby wrote:
>
>   def contains[B >: A](x: B)(implicit areEqual: (A, B) => Bool): Bool
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.