Re: [Haskell-cafe] confusion about 'instance'....
class A a type T = (forall x.Num x=>x) instance A T
"type" declares a synonym, like #define in C - but working only on types. So, essentially, you wrote instance A (forall x.Num x => x) which is not very Haskelly.
I am simply trying to state that all members of typeclass Num are of typeclass A....
You can't do that. But, if there would not be any other instances of A, then you don't need it at all, you can just use Num class. And if there are some, for example data D = D instance A D then it can happen (well, it's unlikely, but possible) that you or some other developer working on your code would declare instance Num D where ... After that, you would have two instances of A for the type D, one defined explicitly and one derived from the Num instance. That's not a problem for this empty class, but if class A is not empty, say class A x where a :: x then the compiler would be unable to decide which instance (and which "a") to choose. So allowing that leads to non-obvious bugs. However, if you trust yourself enough, you can do what you want to in this way: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} class A a instance Num a => A a
class A a type T = (forall x.Num x=>x) instance A T
"type" declares a synonym, like #define in C - but working only on types. So, essentially, you wrote
Yep that's fine..
instance A (forall x.Num x => x)
Yep
which is not very Haskelly.
Hmmm...
I am simply trying to state that all members of typeclass Num are of
typeclass A....
You can't do that.
But, if there would not be any other instances of A, then you don't need it at all, you can just use Num class. And if
Because it wont let me...or because it makes no sense? there
are some, for example
Ok but there may be....I'm just trying to get my head around Haskells type system....
data D = D
instance A D
Yep. D is a member of A
then it can happen (well, it's unlikely, but possible) that you or
some
other developer working on your code would declare
instance Num D where ...
D is a member of Num (and I'm assuming that we've got....All Nums are also members of A....which is fine...so far). So...Num x implies A x.... So...D is a member of A.... Fine.
After that, you would have two instances of A for the type D, one
defined
explicitly and one derived from the Num instance.
I would have 2 declarations that D is a member of A....both consistent.
That's not a problem for this empty class, but if class A is not empty, say
class A x where a :: x
then the compiler would be unable to decide which instance (and which "a") to choose. So allowing that leads to non-obvious bugs.
This slightly bamboozles me..... I only have 1 type. If I say "my name is mark" twice, it doesn't mean I belong to set of objects called Mark twice.... which makes me think that type classes are not simple relations on types after all....they appear to be relations on declarations of types being members of a class. So in my example...there exists two instances of me claiming my name is Mark.
However, if you trust yourself enough, you can do what you want to in
this
way:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
class A a
instance Num a => A a
Hmmm...OK... It all seems a little odd....
Nicholls, Mark wrote:
I only have 1 type.
If I say "my name is mark" twice, it doesn't mean I belong to set of objects called Mark twice....
Typeclasses define not only sets of types, but a common interface for these types, too. An analogy would be to say: I have a name, and it is Marc. I have a name, and it is John. From a "set of things" perspective, there is no problem: you belong to the set of people having a name. But what name should I actually use when I want to adress you? Tillmann
participants (3)
-
Miguel Mitrofanov -
Nicholls, Mark -
Tillmann Rendel