Hmm.. okay, here is a rough draft that covers all the important cases I
think.
assume the following declarations:
class C1 a where
f1 :: t1
f1 = d1
class C2 a where
f2 :: t2
f2 = d2
f3 :: t3
f3 = d3
class alias S a => A a = (C1 a, C2 a) wh
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)
| > 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 d
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
| 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 syntax
class alias Num a = Eq a => (Additive a, Multiplicative a)
*does* see
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
valu
| 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 }
| ...
|
