| Existential types seem to have vanished ... | | > data Appl = MkAppl (a -> Int) a (a -> a) | | hugs (Version: 990121 Beta, -98 mode) complains | ... Fear not! They're still there, but the syntax changed; you need to add an explicit forall. For more details, please see the attached email from Hugs-users, posted last November. Hope this helps, All the best, Mark
The new versions of Hugs that I announced last week supports all the type system extensions of Hugs 1.3c, but there is one change in syntax that I forgot to mention. In Hugs 1.3c, existentially quantified components in datatypes were introduced rather implicitly by leaving type variables unbound, as in: data Appl = MkAppl (a -> Int) a (a -> a) Experience showed that this tended to trip up users, particularly when they had simply forgotten to mention a parameter on the left, or had made a typo (e.g., using "int" when they really wanted "Int"). Instead of detecting these errors, Hugs 1.3c would happily accept the datatype definition, only to report strange errors later when the datatype was actually used. To avoid these problems, and as part of the general plan to use common syntax for common extensions in both GHC and Hugs, we now require existentially quantified variables to be explicitly bound. data Appl = forall a. MkAppl (a -> Int) a (a -> a) Using forall to bind what we're calling an existentially quantified variable may seem odd, but if you think about the type of the MkAppl constructor, which is indeed polymorphic over a, then it makes good sense. (If you disagree, fair enough, but hugs-users isn't the right forum to discuss it; this is an issue of potential interest to both Hugs and GHC users.) The only other difference in the type system is that there is now an iteration depth limit for predicate entailment ... I don't think most users will ever need to worry about it, but anybody who wants to experiment might consider playing with the -c flag (also known locally as the `Fergus' flag :-). All the best, Mark
