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

Or better yet, retain my idea and eliminate the covariant requirement on B:

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

Then we (not only eliminate the harmful intermediate use of Bool in 
Martin's solution and also) unconflate the covariance of the contain List 
and the multiple relationships that can be expressed with typeclasses.

Hmmm. Then the advantage of Scala over Haskell is that we can marry 
covariance for containers (i.e. object oriented programming) with the 
freedom to break out of that linear relationship on inheritance for 
multiple interfaces (relationships) on data.

Am I homing in on the generative essence? Nobody has been able to 
succinctly and concretely explain to me why I need Scala and not Haskell 
disregarding the Java compatibility or lazy by default differences.

On Tuesday, June 16, 2015 at 3:36:34 PM UTC+8, Shelby wrote:
>
> 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.