On Friday 19 October 2001 11:02, George Russell wrote:
> Recently I've been experimenting with a sort of OOP with GHC, [...]
I find your discussion rather intriguing, but I'm not sure I fully understand
what you are trying to do.
Existential typing allows for what I would call "dynamic dispatch", which
allows for the dynamic lookup of class members (i.e. methods). What you
appear to be trying is something resembling dynamic typing. Dynamic typing
can be "emulated" using dynamic dispatch.
If GHC had true existential typing, as opposed to just existential datatypes,
you could reasonably code what I think you want like this:
class A a where
basicA :: Bool
nextA :: a -> (EX a'. A a' => a')
basicA = True
nextA = id
data WrappedA = forall a. A a => WrappedA a
instance A WrappedA where
basicA = False
nextA (WrappedA a) = a
data A1 = A1
instance A A1
--... similarly for B ...
class AB a b where
toBool :: a -> b -> Bool
instance (A a, B b) => AB a b where
toBool a b
| (basicA :: a) && (basicB :: b) = True
| (basicA :: a) || (basicB :: b) = False
| otherwise = toBool (nextA a) (nextB b)
In this new setting, class AB seems a little silly. You could simply get rid
of it.
Of course, GHC doesn't work this way. Instead, you have to introduce a
datatype "StupidA" to wrap your existential type in. For the benefit of
this new stupid datatype, you'll also need to change the type of basicA from
(:: Bool) to (:: a -> Bool). This datatype also introduces unnecessary
overhead, as you end up having chains of StupidA constructors that do
essentially nothing.
You could look at my attached code if you really want to. It has been beaten
throughly with an ugly stick.
>From the purely denotational point of view of semantics, I love existential
typing. I think this example really drives the point across that
existential datatypes are not nearly as useful as existential typing. I can
think of several similar situations in actual code of mine. However, using
existential datatypes was overkill for the situation, and thus I opted for a
different solution altogether.
I don't understand all the implementation consequences of existential typing.
Most importantly, how does existential typing effect the operational
semantics? Mercury has existential typing, but then again, Mercury is newer
and its design philosophy is far more ambitious.
best,
leon
class A a where
basicA :: a -> Bool
nextA :: a -> StupidA
basicA _ = True
nextA a = StupidA a
data StupidA = forall a . A a => StupidA a
instance A StupidA where
basicA (StupidA a) = basicA a
nextA (StupidA a) = StupidA (nextA a)
data WrappedA = forall a . A a => WrappedA a
instance A WrappedA where
basicA _ = False
nextA (WrappedA a) = StupidA a
data A1 = A1
instance A A1
class B b where
basicB :: b -> Bool
nextB :: b -> StupidB
basicB _ = True
nextB b = StupidB b
data StupidB = forall b . B b => StupidB b
instance B StupidB where
basicB (StupidB b) = basicB b
nextB (StupidB b) = StupidB (nextB b)
data WrappedB = forall b . B b => WrappedB b
instance B WrappedB where
basicB _ = False
nextB (WrappedB b) = StupidB b
data B1 = B1
instance B B1
toBool :: (A a, B b) => a -> b -> Bool
toBool a b
| basicA a && basicB b = True
| basicA a || basicB b = False
| otherwise = toBool (nextA a) (nextB b)
main = return ()
