Hi Alex,
| > I think the way that Hugs 1.3c handles it ...
| ...
| AKA "Proposal A" in SPJ's recent message on this topic:
|
| http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
Exactly, although I hadn't been referring to that at the
time. The only negative point for proposal A listed there
is that: "Can't capture variables appearing within type contexts".
I don't actually see why this is needed.
| it's "B" (and hence, SPJ's Composite Motion, A+B)
| that worries me, for the reasons I alluded to.
I share your concerns!
| > In recent discussions with Simon, we discovered that
| > this approach also works better if existential types are included in the
| > language.
|
| That makes at least intuitive sense to me (a "monomorphic type
| varible" _is_ some sort of existential quantification, isn't it,
| in at least some vague, hand-wavey way?) -- could you expand a
| little on the details of this, though?
Sure. I think I can see where you're headed with your comments,
but I actually meant something else. Specifically, if you allow
datatypes like:
data Twee = forall a. MkTwee (a -> Int) a
where the a parameter is locally quantified, and you write functions
like:
f (MkTwee g u) = ...
then you can use a type annotation such as:
f (MkTwee g (u::a)) = ...
if you want to refer to the type of the existentially quantified
variable in the body of f. There's no way to name that type with
the B proposal alone.
Hope that clears things up!
Mark
