Using existential types

[Graham Klyne]

At 18:42 02/10/03 -0700, oleg at pobox.com wrote:
>Therefore, when you
>quantify a value, you typically want to impose a constraint
>
>         forall vt. (C vt) => Datatype (DatatypeVal ex vt)

That's a useful observation, thanks.

I've had a enough cases recently where I found that a class doesn't 
actually satisfy my goals, and ended up using an algebraic datatype, that I 
neglected the possibility in this case.  I'll need to think some more about 
this, but it suggests that my DatatypeMap should be replaced by a class of 
which vt is an instance.

...

To check my understanding, when you say:

>Given one of the simplest universes, your code can be written as
>follows. There is no need to existentially quantify anything. Your
>code becomes pure Haskell98.

[...]

>data InjProjMap ex = InjProjMap
>         { mapL2V    :: String -> Maybe Univ
>         , mapV2L    :: Univ -> Maybe String
>         }
>
>
>data Univ = UInt Integer | UBool Bool

I have a couple of questions:

(1) is there any purpose served by having InjProjMap parameterized with 
ex?  I don't see it.

(2) the use of datatype Univ suggests to me that one must know in advance 
all of the datatypes that will be used for my 'vt'.  That is something I'm 
trying to avoid, as I'm explicitly trying to construct a framework in 
which, while I know that there will be such an underlying type with certain 
properties, I don't know anything about how it may be implemented.  (For 
one of my target applications, I want to treat IP addresses as a distinct 
datatype.)

...

[Later]  I tried using a class in my code, but in the end it didn't help:
I still need a value that encapsulates the mapping functions without 
necessarily having an instance of the datatype to hand. Though I can see 
that approach might be useful in other circumstances.

I also reviewed the links you posted, and the comments there did help me to 
see a little more.  Particularly Keith Wansbrough's message:
   http://www.haskell.org/pipermail/haskell/2003-February/011290.html

It seems to me that what I'm trying to do is similar to what Keith 
describes, except that I'm bundling the 'accessor functions' into an 
auxiliary datatype.

I note your messages about safe casts and confess I need to spend more 
effort to fully understand them.  (It seemed to me like shades of generics 
there.)  But mainly, I think that something I don't want to do is cast my 
existential datatype to something I expose.  Rather, what I want to do is 
expose relationships between (textual) representations of a datatype, while 
keeping the actual values used to derive those relationships hidden from view.

Thanks for your input and pointers provided.

#g


------------
Graham Klyne
GK at NineByNine.org