Fergus Henderson wrote:
> I think there's lots of other things lacking too, including the ability
> to do destructive update (as with the Hugs/ghc ST module, for example),
> optional dynamic typing, existential types, unsafePerformIO, a portable
> foreign language interface, etc.
I agree. What I was trying to say was that most of the "core" language
is as it should be. What we are talking about now are "higher level"
features.
> Existential types will give you most of the benefits of this with
> fewer drawbacks. E.g.
>
> data AnyFoo = Foo t => MkAnyFoo t
>
> instance Foo AnyFoo where
> f (MkAnyFoo x) = f x
> g (MkAnyFoo x) = g x
>
> h :: [AnyFoo] -> [Int]
> h elems = map f elems
>
> h [MkAnyFoo 1, MkAnyFoo 1.0] == [1,2]
>
The essence seems to be the same. When applying a function to an
instance of AnyFoo, the actual computation depends on the type of the
object wrapped inside. That is exactly what I'm after. It would be nice,
though, if I didn't have to explicitly wrap my objects. That's why I
suggested to use a construct that would do it automatically. The
drawback is, of cause, that it calls for another set of rules to
determine the type of an expression. What is the type of [1, 1.0]? It
cannot be an "ordinary" Haskell type as the types Int and Double are not
unifiable. It must be something like the most specialized common
superclass of the deduced types. If there are more of those you are in
trouble...
So I must say I agree in your conclusion. Existential types are a better
alternative because it fits nicely within the existing Haskell type
system.
--
Joergen Froejk Kjaersgaard <[EMAIL PROTECTED]>
Systems Engineer, Informaticon
...Linux - for freedom of choice... www.linux.org
