Folks

Julian has discovered another ambiguity in the Haskell 98 Report.  Consider:

        data Ord a => T a = MkT a a 

We know that MkT has type

        MkT :: Ord a => a -> a -> MkT a a

We also know that the dictionary passed to MkT is simply discarded.
The constraint simply makes sure that you can't build a MkT
unless you do have the Ord constraint on the element type.

Now here's the question.  What type does the selector function have:

        fstT (MkT x y) = x

GHC thinks it has type

        fstT :: MkT a a -> a

Hugs thinks it has type

        fstT :: Ord a => MkT a a -> a

The report is inexplicit; at least Mark interpreted it one way
and I interpreted it another.  (I thought of *application* of MkT
as *introducing* a constraint -- hence the type of MkT --
but *pattern-matching* on MkT as *eliminating* a constraint.
But since the dictionary isn't stored in the constructor we can't
eliminate it.)

I think that everyone believes that contexts on data type declarations
are a broken feature of H98; they only stayed in because we thought
we might be able to do something better with the syntax later, a decision
I rather regret.  Still, there it is, and we'd better clear up the static
semantics of pattern matching. 

**  I therefore PROPOSE that when pattern matching on a constructor,
**  any context on the data type declaration is ignored.

This is the simpler choice (Mark says it was very tricky to implement
what Hugs does), and no one has ever noticed the difference!  So let's
do the simpler thing for H98.  This one is isn't worth much of anyone's
time.

Yell if you dislike this; otherwise I'll just add it to the 'bugs' page.

Simon


Reply via email to