| Ok. So I counter-propose that we deal with pattern bindings like this:
|
|The static semantics of a pattern binding are given by the following
|translation. A binding 'p = e' has the same meaning as the set of
|bindings
|
| z = e
| x1 = case z of { p - x1 }
| ...
|
Indeed! I think it'd be good to allow type signatures, including instance
signatures, in export lists
module Foo(
data T (f :: * - *),
instance Functor f = Eq (T f),
g :: T f - T f
)
The first step is to evolve a well-worked-out design. I think that'd be a very
On Thu, May 01, 2008 at 03:42:53PM +0100, Simon Peyton-Jones wrote:
| Yeah, I disagree here, mainly because I don't want to conflate
| superclasses with class aliases. I feel they have different uses, even
| though they can sometimes achieve the same thing.
Fair enough. But the strange
| Fair enough. But the strange syntax
|
| class alias Num a = Eq a = (Additive a, Multiplicative a)
|
| *does* seem so say that the (Eq a) behaves in a superclass way, and
| (Additive a, Multiplicative a) behave in a class-alias way, as it
| were. That seems inconsistent with the design
On Thu, May 01, 2008 at 11:57:14PM +0100, Simon Peyton-Jones wrote:
| Fair enough. But the strange syntax
|
| class alias Num a = Eq a = (Additive a, Multiplicative a)
|
| *does* seem so say that the (Eq a) behaves in a superclass way, and
| (Additive a, Multiplicative a) behave in a
