[Haskell-cafe] Object Oriented programming for Functional Programmers

[Alberto G. Corona]

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 <miguelimo38 at yandex.ru>

>
> On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gershomb at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130103/01332882/attachment.htm>