Re: [Haskell-cafe] Object Oriented programming for Functional Programmers

Anyway, Type checking is essentially an application of set theory : (I did no search in te literature for this, It is just my perception). When I say (+) :: Num a => a -> a -> a . I mean that (+) takes two elements of the set of Num typeclass and return another. This is in principle a weak restriction, because many functions do it as well, for example (*). A propery check or a contract would be much more restrictive and thus would detect much more program errors. But it seems that no other language but haskell took this set theoretical analysis so exhaustively, and without it, a property check is like detecting microscopic cracks in nuclear waste vessel without first making sure that the cover has been sealed. 2013/1/2 MigMit

On Jan 3, 2013, at 2:09 AM, Gershom Bazerman wrote:

...

On 1/2/13 4:29 PM, MigMit wrote:

...

...

BTW. Why you think that Eiffel type system is unsafe? Well, if I remember correctly, if you call some method of a certain

object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.

...

Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517

Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no real "theory" behind Eiffel, just a bunch of features (or "concepts") boiled together. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alberto.