Using existential types

Jan-Willem Maessen jmaessen at MIT.EDU
Fri Oct 3 11:18:09 EDT 2003


Tomasz Zielonka <t.zielonka at zodiac.mimuw.edu.pl> wrote:
> I think I have used unconstrained existentially quantified types in a
> useful way. Below is a combinator library for calculating statistics
> with aggregate functions (type Stat). 
>
> [BIG SNIP]
> 
> data Stat i o = -- aggregate function taking i's on input and producing o
>     forall s. Stat
> 	s		-- init
> 	(s -> i -> s)	-- update
> 	(s -> o)	-- result

I really liked this example, as it neatly crystallizes a few issues
about existential types:

* Existential types only make sense if you include a function which
  takes the type as an argument (here the update and result
  functions).  Sometimes this function is the method of a class.

* But it bugs me that an awful lot of examples of existential typing
  could be obtained simply by currying / lazy evaluation.  In this
  case, however, the "update" function lets us absorb additional input
  as in the subsequent message (which I've now accidentally deleted):

> oneInput :: Stat i o -> i -> Stat i o
> oneInput (Stat s update result) i = Stat (update s i) update result

I'd like to know, for my own edification:

THEORY 1: It is possible to eliminate an existential type s from any
data structure unless the structure includes one function (possibly a
method) which mentions type s in both covariant and contravariant
positions, and one function or data structure which mentions s only in
covariant position [or did I mean contravariant here?].

Is this theory correct?  This would go a long way to explaining why we
might *need* (as opposed to merely "want") existential types.

Of course, in the bad old days (or in Haskell 98) we'd just include
extra type parameters.  A bit ugly, but arguably we do the same thing
whenever we write state transformers.

-Jan-Willem Maessen
jmaessen at alum.mit.edu

PS - I note that the type "Stat" is a classic OO-style iterator that
does basically the same thing as foldl.  Interestingly, by writing in
this way we can just include bits of the equational theory of foldl.
The function pair is a great example of this:

> pair :: Stat a b -> Stat a c -> Stat a (b,c)


More information about the Haskell-Cafe mailing list