At 18:42 02/10/03 -0700, oleg@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@NineByNine.org