Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson <[EMAIL PROTECTED]> pisze:
> 1) Dynamic types. You can't cast up. That is you can't recover the
> original type from an object in a existential collection. You need to
> use a dynamic type library for that. And the library proved with hugs
> and ghc leaves a lot to be desired. In an OO langauge all classes
> automatically cary dynamic typing information.
Please, no. Don't require existentials to carry dynamic type
information. IMHO it's as ugly as Dynamic.
The concept of existentials works well without it. The essence of
existential is that you don't care what type is inside as long as it
has the stated properties. If you need it, I think this is either
wrong design (e.g. the operation that would use the cast should be
put inside the existential as a method) or some more fundamental lack
in the Haskell's type system. Don't break existentials.
If you like this, you must also like Dynamic, so simply require the
type under the existential to be Typeable and cast it through Dynamic.
The effect would be the same, without a penalty to those that don't
use it.
In simple cases where the set of types that need to be casted is
fixed, there can be methods returning `Maybe ACastedType', with
obvious semantics.
Sorry that I really can't explain well why I think that this concept
does not fit into Haskell. I must have heard that such "typecase"
is most often a bad design.
> 2) More specific types, you can't _easilly_ call the more general type.
> For example in OO this is very commen:
>
> class Base
> virtual foo()
> do stuff....
>
> class Derived, extends Base
> foo()
> call Base::foo()
> doo stuff
Yes, subtyping is an interesting issue that Haskell lacks that *may* be
good. It is not obvious however, what exactly it could mean in Haskell.
IMHO it is not as useful as in some imperative languages. In C++ or
Java you typically have methods mutating objects, where in functional
languages you have functions returning new objects. Analogous to
methods Base::foo(int) and Derived::foo(int) are functions of types
`Base -> Int -> Base' and `Derived -> Int -> Derived'. Here their
signatures differ not only on the first argument, as in imperative OO,
but also on the result. So you cannot say that the second function
is simply the first one specialized to the case of Derived.
They may however be methods of type `a -> Int -> a' in some class,
that is, where types are instances of an interface, not the other
type - because you don't have "values of type AHaskellClass" which
could be passed through such a function yielding another "value of
type AHaskellClass". Instead the types of argument and result are
constrained to be the same at the place of the usage, no matter what
the actual type is. In other words, it's good that Haskell makes
a difference between an interface and a concrete type, and in a
functional language instances of an interface make more sense than
instances of a type (i.e. subtypes).
It is also more general in the way that there may be more than
one argument of the "self" type (as (==) in Eq), or none (as pi
in Floating). Type inference makes the latter case convenient.
> 3) Encapsulation. You can't have private and protected members. Some
> of this can be done using modules. However it is more work.
Please, no. C++'s friends are symptoms that this does not work well.
This belongs to the module system.
Functions does not "belong" to the type of objects they act on, which
is obvious when we consider functions working symmetrically on more
than one argument: which does it belong to? And what about constants:
in what sense does the emptySet belong to a Set type? I have never
accepted the OO way, where the first argument is distinguished as
the owner.
When thinking about whether the implementation details of something are
known to a function, it should be obvious that they are "more known"
to a function in the same file acting on different types than to some
function defined in other file, even acting on the same type.
Haskell's modules, unlike Pascal's, can reexport entities imported
from other modules, so there may be views of a family of entities
with various levels of visibility of the inner details.
> 4) Cleaner more natural syntax.
I know no other language that has cleaner and more natural syntax
than Haskell :-)
In particular I dislike typical OO syntax: object.method(args).
It's good that Haskell makes field selection functions look like
normal functions, because they _are_ normal functions that could be
defined elsewhere. Or else you could argue that fst and head should
look like pair.fst and list.head. Please, no.
* * *
I have escaped from the way to OO because I don't believe it is as
good as many people claim. Haskell designed surprisingly many things
in the way that I either have thought about before and liked (elegant
design, strong typing, parametric polymorphism, types with types as
arguments, type classes, field access as functions, no syntactic
difference between functions and "methods", no unneeded RTTI, the
module system). It's even not the fact that it's functional that
attracted me to Haskell. I only later realized that functionalness
together with laziness perfectly cleanes up the mess with references /
pointers, passing by value / by reference / by name, deep and shallow
copying, evaluation of arguments of && and ||, uninitialized variables.
And now you come and propose things to make Haskell more OO, changing
the things I like the most and adding exactly what I think that OO
gets wrong :-)
I don't say that Haskell is perfect. There are many things that are
only extensions of GHC and Hugs that should get into the standard.
There are things that I don't know how to express well in Haskell's
type system, e.g. a kind of binary methods that I posted about some
time ago; it's bad that IOError cannot be extensible, that a divide
by zero crashes the whole universe, that various collections are not
given uniform class interfaces, and finally that programs are too slow.
But not every change is an improvement, even if it does not make any
previous programs illegal.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
