Re: InstanceSigs -- rationale for the "must be more polymorphic than"

[Anthony Clayden]

On Tue, 10 Aug 2021 at 21:15, Simon Peyton Jones 
wrote:

>
>
> I think you see why the instance sig must be at least as polymorphic ...
>

Thanks Simon, I do now see, but I'd have to say there's a heck of lot of
questions on StackOverflow (most not from me) being surprised/asking why.
See more below.


>
>
I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>

(1) is documented in the User Guide, but the magic words "compiler-checked"
don't appear.

(2) is documented and illustrated, but in that example the ScopedTyVar is
superfluous.


> There is no compelling reason to make the instance signature *more*
> polymorphic
>

I think there's an ergonomics reason (which is illustrated but not
explained):

(5) If the instance is constrained, there's no need to repeat the
constraints in the InstanceSig, so reducing clutter/making the Sig easier
to read (as you say). This results in making the InstanceSig more
polymorphic:

>data T a = MkT a a>instance Eq a => Eq (T a) where*>   *   (==) :: T a 
> -> T a -> Bool   -- The signature*>   *   (==) (MkT x1 x2) (MkTy y1 y2) = 
> x1==y1 && x2==y2

That Sig could be

*>*  (==) :: Eq a => T a -> T a -> Bool   -- repeat constraint, but clutter



> – that is, doing so does not increase expressiveness.  But it might make a
> briefer, more comprehensible type for the reader.  The only alternative
> would be to insist that the two types are the same, a completely redundant
> test, but one you might conceivably want on stylistic grounds.
>

More to the point: it would bring into scope the ScopedTyVars.


>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
>
[Discussion cont. from first para]:

 ... [more polymorphic] than the instantiated signature from the class –
> because that’s what the client is going to expect.  We are building a
> record of functions, and they must conform to the class signature.
>

And that answer is unsatisfactory. It amounts to: we didn't think in
advance how useful it would be to put tighter constraints on methods --
particularly for the tyvars that are 'private' to the method/not from the
instance head -- that is within Constructor classes. Allowing that would be
a partial (heh, heh) way towards 'Restricted Data Types' Hughes 1999 and
Eisenberg et al 2020 (ref'ing many earlier attempts), and indeed Haskell
Language Report vintage 1990 (the design before 'stupid theta').

I suppose it's beyond a wild dream to allow the InstanceSig to be at least
as polymoprhic wrt the types/vars from the instance head but possibly less
polymorphic wrt the method's private types/vars? The actual type inferred
would be the mgu of the InstanceSig given with the substitution from the
instance head & constraints.




>
>
> *From:* Glasgow-haskell-users  *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden 
> *Cc:* GHC users 
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >lessPolyPlus :: Integral a => a -> a -> a
>
> >lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly becaus

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

[David Feuer]

Ah, I see. Yes, you're right. Sorry.

On Tue, Aug 10, 2021, 3:15 PM Simon Peyton Jones 
wrote:

> Do you have a concrete example?
>
>
>
> I think that the recursive calls will all go via the original class method
> with its original type – we can’t know that it’s calling **this**
> instance till much later.   So I still don’t get it.  An example would
> clear it up.
>
>
>
> Simon
>
>
>
> *From:* David Feuer 
> *Sent:* 10 August 2021 12:01
> *To:* Simon Peyton Jones 
> *Cc:* Anthony Clayden ; GHC users <
> glasgow-haskell-users@haskell.org>
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> Simon, there are times when a function has to be generalized to be made
> polymorphic recursive. Perhaps the method takes an argument of type x (not
> a class parameter), but to call itself, it needs to be able to take types
> x, T x, T (T x), etc. That additional polymorphism can be introduced in the
> instance signature. The alternative is to introduce a helper function with
> extra polymorphism.
>
>
>
> On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones 
> wrote:
>
> AntC,
>
>
>
> I think you see why the instance sig must be at least as polymorphic than
> the instantiated signature from the class – because that’s what the client
> is going to expect.  We are building a record of functions, and they must
> conform to the class signature.
>
>
>
> I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>
> There is no compelling reason to make the instance signature *more*
> polymorphic – that is, doing so does not increase expressiveness.  But it
> might make a briefer, more comprehensible type for the reader.  The only
> alternative would be to insist that the two types are the same, a
> completely redundant test, but one you might conceivably want on stylistic
> grounds.
>
>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users  *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden 
> *Cc:* GHC users 
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >lessPolyPlus :: Integral a => a -> a -> a
>
> >lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
>
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
>
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
>
>
> >maxPolyPlus :: Num a => a -> a -> a
> >maxPolyPlus = (+)
> >
>
> >class C a  where foo :: a -> T a
> >instance Integral a => C a  where
> >  foo :: Num a => a -> T a
> >  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
>
>
> Is there a persuasive example (to put in the User Guide)?
>
>
>
> AntC
>
>
>
> _

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

[Simon Peyton Jones via Glasgow-haskell-users]

Do you have a concrete example?

I think that the recursive calls will all go via the original class method with 
its original type - we can't know that it's calling *this* instance till much 
later.   So I still don't get it.  An example would clear it up.

Simon

From: David Feuer 
Sent: 10 August 2021 12:01
To: Simon Peyton Jones 
Cc: Anthony Clayden ; GHC users 

Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

Simon, there are times when a function has to be generalized to be made 
polymorphic recursive. Perhaps the method takes an argument of type x (not a 
class parameter), but to call itself, it needs to be able to take types x, T x, 
T (T x), etc. That additional polymorphism can be introduced in the instance 
signature. The alternative is to introduce a helper function with extra 
polymorphism.

On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
AntC,

I think you see why the instance sig must be at least as polymorphic than the 
instantiated signature from the class - because that's what the client is going 
to expect.  We are building a record of functions, and they must conform to the 
class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of 
which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - 
that is, doing so does not increase expressiveness.  But it might make a 
briefer, more comprehensible type for the reader.  The only alternative would 
be to insist that the two types are the same, a completely redundant test, but 
one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a 
necessity.

If you would like to offer a patch for the user manual to explain this better, 
that would be great.

Simon

From: Glasgow-haskell-users 
mailto:glasgow-haskell-users-boun...@haskell.org>>
 On Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>>
Cc: GHC users 
mailto:glasgow-haskell-users@haskell.org>>
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They 
can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general 
signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's 
this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) 
the type inferred from the term:

>lessPolyPlus :: Integral a => a -> a -> a
>lessPolyPlus x y = x + y

Or

>lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the 
InstanceSigs, and all is well-typed. (Even the example alleging to use 
-XScopedTypeVariables in a where sub-decl: you could just put random `xs :: 
[b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, 
suitably instantiated, is less polymorphic than inferred from the term. IOW the 
suitably instantiated type restricts what would otherwise be inferred. 
Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and 
braces' for the instantiated -- possibly because the instantiation is hard to 
figure out; possibly because you want to use -XScopedTypeVariables within a 
where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably 
instantiated.

But the docos don't give any example where it's essential to provide an 
InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and 
annotations are just superfluous:

>maxPolyPlus :: Num a => a -> a -> a
>maxPolyPlus = (+)
>
>class C a  where foo :: a -> T a
>instance Integral a => C a  where
>  foo :: Num a => a -> T a
>  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

[David Feuer]

Simon, there are times when a function has to be generalized to be made
polymorphic recursive. Perhaps the method takes an argument of type x (not
a class parameter), but to call itself, it needs to be able to take types
x, T x, T (T x), etc. That additional polymorphism can be introduced in the
instance signature. The alternative is to introduce a helper function with
extra polymorphism.

On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones 
wrote:

> AntC,
>
>
>
> I think you see why the instance sig must be at least as polymorphic than
> the instantiated signature from the class – because that’s what the client
> is going to expect.  We are building a record of functions, and they must
> conform to the class signature.
>
>
>
> I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>
> There is no compelling reason to make the instance signature *more*
> polymorphic – that is, doing so does not increase expressiveness.  But it
> might make a briefer, more comprehensible type for the reader.  The only
> alternative would be to insist that the two types are the same, a
> completely redundant test, but one you might conceivably want on stylistic
> grounds.
>
>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users  *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden 
> *Cc:* GHC users 
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >lessPolyPlus :: Integral a => a -> a -> a
>
> >lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
>
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
>
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
>
>
> >maxPolyPlus :: Num a => a -> a -> a
> >maxPolyPlus = (+)
> >
>
> >class C a  where foo :: a -> T a
> >instance Integral a => C a  where
> >  foo :: Num a => a -> T a
> >  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
>
>
> Is there a persuasive example (to put in the User Guide)?
>
>
>
> AntC
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
>
>
_

RE: -dinline-check for symbolic names?

[Simon Peyton Jones via Glasgow-haskell-users]

It's hard to tell what is happening without a repro case. Can you share one?

You suggested that it might have something to do with using an operator.   Does 
the same thing happen if you replace the operator with an alpha-numeric name?

Simon

| -Original Message-
| From: Glasgow-haskell-users 
| On Behalf Of Michael Sperber
| Sent: 06 August 2021 13:44
| To: glasgow-haskell-users@haskell.org
| Subject: Re: -dinline-check for symbolic names?
| 
| [You don't often get email from sper...@deinprogramm.de. Learn why this
| is important at http://aka.ms/LearnAboutSenderIdentification.]
| 
| On Fri, Aug 06 2021, Michael Sperber  wrote:
| 
| > On Wed, Aug 04 2021, Carter Schonwald 
| wrote:
| >
| >> I'm not sure about the pragma debugging, but are you using it in
| >> point free style? Cause I'm that case it may not be inclined because
| >> it's not being fully applied on the left hand side?
| >
| > Good point, but I checked, and it's fully applied. :-(
| 
| Another note: Once I change the INLINE to INLINE [0], everything works:
| (&&&) gets inlined, and -dinline-check works.  Explanation welcome ...
| 
| --
| Regards,
| Mike
| 
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=04%7C01%7Csimonpj%40microsoft.com%7C7b8c76634e3c4ce86a7008
| d958d801ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63763850704993823
| 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
| haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZHraN9nVbZMWxmekmYP2sAqRBh1qNbVWUlo
| JQdKnkc%3D&reserved=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

[Simon Peyton Jones via Glasgow-haskell-users]

AntC,

I think you see why the instance sig must be at least as polymorphic than the 
instantiated signature from the class - because that's what the client is going 
to expect.  We are building a record of functions, and they must conform to the 
class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of 
which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - 
that is, doing so does not increase expressiveness.  But it might make a 
briefer, more comprehensible type for the reader.  The only alternative would 
be to insist that the two types are the same, a completely redundant test, but 
one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a 
necessity.

If you would like to offer a patch for the user manual to explain this better, 
that would be great.

Simon

From: Glasgow-haskell-users  On 
Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden 
Cc: GHC users 
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They 
can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general 
signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden 
mailto:anthony.d.clay...@gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's 
this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) 
the type inferred from the term:

>lessPolyPlus :: Integral a => a -> a -> a
>lessPolyPlus x y = x + y

Or

>lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the 
InstanceSigs, and all is well-typed. (Even the example alleging to use 
-XScopedTypeVariables in a where sub-decl: you could just put random `xs :: 
[b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, 
suitably instantiated, is less polymorphic than inferred from the term. IOW the 
suitably instantiated type restricts what would otherwise be inferred. 
Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and 
braces' for the instantiated -- possibly because the instantiation is hard to 
figure out; possibly because you want to use -XScopedTypeVariables within a 
where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably 
instantiated.

But the docos don't give any example where it's essential to provide an 
InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and 
annotations are just superfluous:

>maxPolyPlus :: Num a => a -> a -> a
>maxPolyPlus = (+)
>
>class C a  where foo :: a -> T a
>instance Integral a => C a  where
>  foo :: Num a => a -> T a
>  foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users