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 <miguelim...@yandex.ru> > > On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gersh...@gmail.com> 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.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
