Date: Wed, 20 Oct 1999 05:19:10 +1000
From: skaller <skaller@maxtal.com.au>
To: John Prevost <prevost@maya.com>
Subject: Re: Thoughts on O'Labl O'Caml merge.
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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:27 MET