Me:
> | 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
SPJ:
> You could always use a case expression, no?
This is true. However, I dislike case expressions moderately intensely
at the best of times on aesthetic grounds, and using them as a let-alike
I find more than usually unspeakable. Yet more so in the midst of a
do-block...
> | 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.
I don't immediately see why this is an instance of polymorphic recursion:
in what sense does the call of f' involve a fresh type? But it would seem
reasonable enough to require an explicit type sig. (Partial or otherwise!)
> So that's two type-system things that would make your life easier.
>
> Hmm.
> - how bad is it to use case?
The existing alternatives are pretty easily liveable-with (though case
happens to be my least favoured option), they just seem odd as restrictions,
and look a tad peculiar.
> - would pattern-matching on non-rec lets help you?
It would have; I'd be happy with this, though a small part of me
wonders if doing this might not enrage some future user who bumps into
the thus-moved limitation in a less clearly circumscribed case.
To wit, is it better to say, no recusive bindings, or, more syntactically
simply, no lets or wheres?
Cheers,
Alex.
