From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA31834 for caml-redistribution; Tue, 19 Oct 1999 23:46:21 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA15853 for ; Tue, 19 Oct 1999 21:25:10 +0200 (MET DST) Received: from ruby (pm1-29.triode.net.au [203.63.235.45]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA07198 for ; Tue, 19 Oct 1999 21:25:06 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id FAA23101; Wed, 20 Oct 1999 05:19:11 +1000 Sender: weis Message-ID: <380CC42E.772DA81@maxtal.com.au> Date: Wed, 20 Oct 1999 05:19:10 +1000 From: skaller Organization: Maxtal X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Prevost CC: caml-list@inria.fr Subject: Re: Thoughts on O'Labl O'Caml merge. References: <3809AC91.4E85FB85@maxtal.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Prevost wrote: > Guess that row-polymorphic structs aren't such a good idea, then. :) I don't follow your reasoning: the rules are more complex than it might first seem just considering immutable fields. But the correct rules are known, and easy enough to implement. The fact that these rules restrict the correctness of use of mutable fields, is a consequence of correct typing, not an obstacle to implementing the correct rules. :-) > Something I noted when explaining the O'Caml object system to some > friends was a couple of places where choice of interface can be rather > more subtle than, say, in Java. The ocaml object system has the advantage of type correctness, which means that the limitations of object orientation are readily apparent. This is not so obvious in an 'object oriented' language, which is based from the start on a incoherent paradigm. > Specifically in the > point/colored_point, circle/colored_circle examples from the manual > The real problem in both of these cases is that in a powerfully typed > OO world like O'Caml, it's dangerous to treat a class as a container > when it isn't really. My opinion is quite different: object orientation cannot possibly work. It is completely unsupported by any coherent theory and can be so easily discredited by a single example that it is clear adherents were simply ignorant of basic theory. [no binary operator can be correctly represented; more generally, no n-ary relation for n>1] > Okay, so the obvious symptom of the disease is that 'a appears > covariantly in get_center, and contravariantly in set_center. But > what's the root cause of these symptoms? Simple. The covariance problem is a direct consequence of the incorrect assumption that a class can represent an abstraction. We know from category theory that a CATEGORY and NOT a class represents an abstraction, and an instance of the abstraction must be a functor. If you examine 'inheritance' you find it is not functorial. That is the problem. The paradigm is fatally flawed because it fails to obey simple rules of mathematics. An abstract function A --> B in a category must be instantiated as a function A' --> B', and that function is specific. There is no 'polymorphism' here. The polymorphism is entirely contained in the choice of instantiating functor. The different instances are 'unrelated' and cannot interoperate. Object orientation works in exactly one, well defined, case: when the methods of the class all have no arguments. [Technically, a function with an invariant argument is to be viewed as a family of functions with no arguments, for the purpose of this theorem] As I undertand it, in ocaml, a module is effectively a category, so we have the _correct_ model of abstraction in ocaml (even if it is restricted). Furthermore, type variables are simply a shorthand for using modules (with the advantage of implicit instantiation rather than the explicit instantiation required for modules) Please note: this does not mean that classes are useless! Contrarily, they're very convenient. What it means is that _abstraction_ is not representable this way, in general. Some cases are conveniently constructed using classes: since I have an OO background, I do this in my Python compiler. But I use ocaml signature matching .. not inheritance .. and the covariance problem is kept away only with some care, and because the use of the classes and interfaces is not really 'abstract'. [There are a finite set of classes with the signature, which is adjusted to accomdate all the required uses, sometimes with a little hackery thrown in] -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller