Marcin 'Qrczak' Kowalczyk wrote:
>
> 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 types won't be required to carry dynamic type information. It will
just be there if you need it. It there will be a special function or
the like you can call to get information about the original object. If
you don't won't to use it, you don't have to and you will NEVER know its
there. Also if none of the code uses dynamic typing the compile will be
able to optimize away the dynamic type information.
> 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.
>
I am not going to argue with you here but there are times where some
casting is unavoidable and I think haskell should provide a safe clean
way of allowing it and the Dynamic type library is not it.
> > 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.
Perhaps. However I have also think Haskell's module system is a bit to
simple. One think I really think it needs is the ability to group a
collection of functions with a tag. And then when importing a module
you can ask to only import that tag. For example:
module A
list: head tail foldr foldl
array: index (!!) foldr foldl
...
import A(list)
which will make using modules a LOT more convent.
Also, Haskell currently allows you to explicitly import one module with
another. However, I think that this should be extended to be able to
import part of the module for example:
module Mod1(module Mod2 hiding foo, module Mod3(foo))
and the like. Right now when ever a module uses a prelude function you
have to import it like so:
import Prelude hiding head
import Mod1
which can be VERY annoying when a module overrides a lot of the prelude
functions.
>
> > 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 guess its a matter of personal taste.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
