On 08-Nov-1999, Fergus Henderson <[EMAIL PROTECTED]> wrote:
> On 08-Nov-1999, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> > [someone wrote:]
> > | I wonder why it was hard in GHC?
> >
> > It wasn't hard.
>
> We're currently in the process of implementing existential types
> in Mercury. Whenever we make a change, we record how long (roughly)
> we think it took us to make that change. I went back over the cvs logs
> of our changes to add existential types, and found that there were
> about 280 hours worth of changes that were related to the addition of
> existential types. And we still have more work to do before it is
> finished. I'd guess we'll clock up at least another 20 hours
> (maybe lots more, if we decide to add more functionality).
>
> Supporting existential types in Mercury poses some additional difficulties
> that don't occur in Haskell, due to the interaction between existential
> types and Mercury's modes and mode reordering. Supporting existential types
GHC has some similar difficulties which arise when doing pattern
matching using existentials. But I think the implicit directionality
of pattern matching makes the problem easier to handle in Haskell.
> ... stuff deleted ...
>
> But there were a number of other issues which could have occurred
> if Mercury were just a functional language, rather than a combined
> logic/functional language:
>
> * Supporting existential quantifiers on the types for functions
> required changes to the code for inlining and specialization,
> because when you inline and specialize code, this may bind
> type variables in the callee rather than just binding type
> variables in the caller.
GHC doesn't support existential quantifiers on functions, just on
data constructors (not that this changes expressiveness, it's just a
cleaner syntax). So the problem tackled in Mercury was a little more
substantial than the one tackled by GHC.
Tyson.
