| Although I'd read the restriction in advance, I nevertheless
| unwittingly
| contrived to try and write a binding-group style pattern-match against
| an existentially quantified data constructor. Oops. (Actually, I did
| it twice, what's worse...) I can imagine this is indeed an irksome
| thing to TC, but OTOH, it's not a very natural language restriction
| either. What's worse, one is of course not able to use 'selectors' in
| these cases, as they're immediately ill-typed. One saving grace was
You could always use a case expression, no?
There's no difficulty in principle with a non-top-level
non-recursive let, but when pattern bindings and recursion
get mixed up, it's a nightmare. I suppose we could loosen
the rule to let you write non-recursive lets with
existential patterns.
| What's worse, in the other caes, when I replaced the
| let-binding with an auxiliary function call (pattern guards no use in this
case),
| I ran into _another_ restriction: mutually recursive functions needing
| to have the same contexts.
| (That is if one
| has a group like f (EDC x) = ... f' x ...; f' x = ... f (EDC x) ...)
Here you are really calling f' at a fresh type, so you need
polymorphic recursion.
If you are prepared to write the type signature for f' then there is
no difficulty in principle: as Mark has described in his Haskell workshop
paper one can typecheck the bindings without sigs first, then the bindings
with sigs. But GHC still does them all together.
So that's two type-system things that would make your life easier.
Hmm.
- how bad is it to use case?
- would pattern-matching on non-rec lets help you?
Simon
