On Tue, Feb 18, 2014 at 3:40 PM, Brandon Allbery wrote:

On Tue, Feb 18, 2014 at 3:11 PM, Doug McIlroy wrote:

...

What potential evil motivates the prohibition of repeated type parameters in an instance declaration? (Restriction removed by FlexibleInstances)

Isn't that just related to constraints not being part of instance selection? (Assuming that `instance SomeClass a a` is interpreted as `instance (a ~ b) => SomeClass a b`, since I don't quite see how it would work otherwise given how instances work; the constraint is not necessarily obvious from looking at it. Also note that standard Haskell can't therefore describe this instance properly.)

These two instances do not actually work the same way. instance (a ~ b) => SomeClass a b says that any context containing 'SomeClass a b' can be reduced to a context containing (a ~ b) instead. instance SomeClass a a says that a 'SomeClass a b' constraint can be discharged if we enter a state in which the type checker _decides_ that a = b. In a sense, the first instance can provide information, while the second requires it. Whether there should be such a distinction is left up to the reader. -- Dan

The spec doesn't allow multi-parameter type classes at all, so I don't see how you could run into this problem while writing extensionless Haskell. I guess it's still a valid question whether the MultiParamTypeClasses extension should allow repeated type parameters. -Karl On Feb 18, 2014, at 12:53 PM, AntC wrote:

...

Doug McIlroy writes:

What potential evil motivates the prohibition of repeated type parameters in an instance declaration?

Hi Doug,

I guess the first reason would be to catch accidental duplicate names of typevars.

But as to "potential evils", the only point of such an instance:

instance C a a where ...

would be to have another instance:

instance C a b where ...

So we're into overlapping instances. (And discriminating on type equality - - which only works if the types are grounded. See the HList paper, section 9 'By chance or design?')

Overlapping instances like that will probably need FunDeps. So the more recent (and probably more blessed) approach is to use the Closed type families/branched instances doo-hicky upcoming with GHC 7.8. http://www.haskell.org/haskellwiki/GHC/Indexed_types#Type_instance_declarat ions

AntC

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Feb 28, 2014 at 9:44 AM, Casey McCann wrote:

The restriction to distinct type variables, and the resulting issues with unification, apply equally to instances for applied type constructors. This disallows e.g. writing a Monoid instance for (a -> a) directly without a newtype wrapper, not that we'd want to do that anyway.

This was once the instance defined in Data.Monoid. It was changed to the current one in GHC 6.6. -- Dan