Ahh ok I see what is meant by the parameter order.... -----Original Message----- From: Peter Verswyvelen [mailto:peter.vers@telenet.be] On Behalf Of Peter Verswyvelen Sent: 03 January 2008 12:02 To: Nicholls, Mark Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell? Hi Mark,

...

"foo1 :: Int -> obj -> String" Yep...I think that's what I'd do....though I would have done... "foo1 :: obj -> Int -> String" Does that matter?

Well, it's a good habit in Haskell to move the "most important" parameter to the end of the argument list. See e.g. http://www.haskell.org/haskellwiki/Parameter_order.

OK but I was going to go onto Interface IX<A> where A : IX<A> {} and Interface IX where A : B {}

No, I would not know how to that in Haskell using type classes. It seems Haskell does not allow cycles in type class definitions. But as I'm new, this does not mean it's not possible. It's more important to know *what* you are trying to do, than to give a solution in a different language, since OO and FP are kind of orthogonal languages.

Where I cannot see a way to do the above in Haskell at all....as interfaces effectively operator on type classes not types....which seems inherently more powerful

Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I started doing everything with interfaces, I found the lack of support for "mixins" or "default implementations" problematic. This ended up in a lot of copy/paste or encapsulating the implementations into a static class with plain functions, a mess.

But if these could be done in Haskell the see what could be made of stuff like....which is obviously problematic in C# it obviously doesn't work....but potentially does make 'sense'. Interface IX<A> : A {}

Ah! That's one of the bigger restrictions in C# yes! C++ can do that; ATL uses it a lot, and I also like that approach. You can emulate "mixins" with that, and still stay in the single inheritance paradigm. In Haskell you don't do that at all of course, since you avoid thinking about "objects and inheritance" in the first place. OO is strange. They offer you the nice concept of inheritance, and then the guidelines tell you: "don't use too many levels of inheritance"... Although I've build huge projects using OO, it always felt a bit like unsafe hacking. I don't really have that feeling with Haskell, but that could also be because I'm too new to the language ;-)

I'm looking at Haskell because of the formality of it's type system....but I'm actually not convinced it is as powerful as an OO one....i.e. OO ones operatate principally (in Haskell speak) on "type classes" not "types"

Maybe you are right, I don't know, my theoritical skills are not high enough to answer that. Haskell just "feels" better to me, although the lack of a friendly productive IDE and large standard framework remains a bit of a burden. Good luck, Peter -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Nicholls, Mark Sent: Wednesday, January 02, 2008 5:41 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell? I'm trying to translate some standard C# constucts into Haskell... some of this seems easy.... Specifically 1) Interface IX { } 2) Interface IX<A> { } 3) Interface IX<A> Where A : IY { } 4) Interface IX<A> : IZ Where A : IY { } I can take a punt at the first 2....but then it all falls apart _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Should be straight forward....simplest example is... class A a data D = D1 instance A D fine.....D is declared to be a member of type class A.... what about..... class A a type T = (forall x.Num x=>x) instance A T error!... " Illegal polymorphic or qualified type: forall x. (Num x) => x In the instance declaration for `A T'" I am simply trying to state that all members of typeclass Num are of typeclass A.... Doesn't like it. Does this mean that instance only operates on 'atomic' (for want of a better word) types? -----Original Message----- From: Peter Verswyvelen [mailto:peter.vers@telenet.be] On Behalf Of Peter Verswyvelen Sent: 03 January 2008 12:02 To: Nicholls, Mark Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell? Hi Mark,

...

"foo1 :: Int -> obj -> String" Yep...I think that's what I'd do....though I would have done... "foo1 :: obj -> Int -> String" Does that matter?

Well, it's a good habit in Haskell to move the "most important" parameter to the end of the argument list. See e.g. http://www.haskell.org/haskellwiki/Parameter_order.

OK but I was going to go onto Interface IX<A> where A : IX<A> {} and Interface IX where A : B {}

No, I would not know how to that in Haskell using type classes. It seems Haskell does not allow cycles in type class definitions. But as I'm new, this does not mean it's not possible. It's more important to know *what* you are trying to do, than to give a solution in a different language, since OO and FP are kind of orthogonal languages.

Where I cannot see a way to do the above in Haskell at all....as interfaces effectively operator on type classes not types....which seems inherently more powerful

Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I started doing everything with interfaces, I found the lack of support for "mixins" or "default implementations" problematic. This ended up in a lot of copy/paste or encapsulating the implementations into a static class with plain functions, a mess.

But if these could be done in Haskell the see what could be made of stuff like....which is obviously problematic in C# it obviously doesn't work....but potentially does make 'sense'. Interface IX<A> : A {}

Ah! That's one of the bigger restrictions in C# yes! C++ can do that; ATL uses it a lot, and I also like that approach. You can emulate "mixins" with that, and still stay in the single inheritance paradigm. In Haskell you don't do that at all of course, since you avoid thinking about "objects and inheritance" in the first place. OO is strange. They offer you the nice concept of inheritance, and then the guidelines tell you: "don't use too many levels of inheritance"... Although I've build huge projects using OO, it always felt a bit like unsafe hacking. I don't really have that feeling with Haskell, but that could also be because I'm too new to the language ;-)

I'm looking at Haskell because of the formality of it's type system....but I'm actually not convinced it is as powerful as an OO one....i.e. OO ones operatate principally (in Haskell speak) on "type classes" not "types"

Maybe you are right, I don't know, my theoritical skills are not high enough to answer that. Haskell just "feels" better to me, although the lack of a friendly productive IDE and large standard framework remains a bit of a burden. Good luck, Peter -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Nicholls, Mark Sent: Wednesday, January 02, 2008 5:41 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell? I'm trying to translate some standard C# constucts into Haskell... some of this seems easy.... Specifically 1) Interface IX { } 2) Interface IX<A> { } 3) Interface IX<A> Where A : IY { } 4) Interface IX<A> : IZ Where A : IY { } I can take a punt at the first 2....but then it all falls apart _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks for your response, I think you helped me on one of my previous abberations. Hmmm....this all slightly does my head in....on one hand we have types....then type classes (which appear to be a relation defined on types)....then existential types...which now appear not to be treated quite in the same way as 'normal' types....and in this instance the syntax even seems to change....does "instance Num a => A a" Mean the same thing as "instance A (forall a.Num a=>a)" seems like a weird questions, as you're saying my version doesn't mean anything....but does it mean that "forall types 'a', if 'a' is a member of the class Num, then 'a' is a member of class 'A'".... and secondly in what way can this construct lead to "undecidable instances" What are the instances, and what about them is undecidable....seems pretty decidable to me? What is the ramifications of turning this option on? -----Original Message----- From: Luke Palmer [mailto:lrpalmer@gmail.com] Sent: 10 January 2008 13:14 To: Nicholls, Mark Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] confusion about 'instance'.... On Jan 10, 2008 1:03 PM, Nicholls, Mark wrote:

Should be straight forward....simplest example is...

class A a

data D = D1

instance A D

fine.....D is declared to be a member of type class A....

what about.....

class A a

type T = (forall x.Num x=>x)

instance A T

error!...

" Illegal polymorphic or qualified type: forall x. (Num x) => x In the instance declaration for `A T'"

I am simply trying to state that all members of typeclass Num are of typeclass A....

Doesn't like it.

Does this mean that instance only operates on 'atomic' (for want of a better word) types?

-----Original Message----- From: Peter Verswyvelen [mailto:peter.vers@telenet.be] On Behalf Of Peter Verswyvelen Sent: 03 January 2008 12:02 To: Nicholls, Mark Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Is there anyone out there who can

C# generics into Haskell?

Hi Mark,

...

...

"foo1 :: Int -> obj -> String" Yep...I think that's what I'd do....though I would have done... "foo1 :: obj -> Int -> String" Does that matter?

Well, it's a good habit in Haskell to move the "most important" parameter to the end of the argument list. See e.g. http://www.haskell.org/haskellwiki/Parameter_order.

...

OK but I was going to go onto Interface IX<A> where A : IX<A> {} and Interface IX where A : B {}

No, I would not know how to that in Haskell using type classes. It seems Haskell does not allow cycles in type class definitions. But as I'm new, this does not mean it's not possible. It's more important to know *what* you are trying to do, than to give a solution in a different language, since OO and FP are kind of orthogonal languages.

...

Where I cannot see a way to do the above in Haskell at all....as interfaces effectively operator on type classes not types....which seems inherently more powerful

Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I started doing everything with interfaces, I found the lack of support for "mixins" or "default implementations" problematic. This ended up in a lot of copy/paste or encapsulating the implementations into a static class with plain functions, a mess.

...

But if these could be done in Haskell the see what could be made of stuff like....which is obviously problematic in C# it obviously doesn't work....but potentially does make 'sense'. Interface IX<A> : A {}

Ah! That's one of the bigger restrictions in C# yes! C++ can do that; ATL uses it a lot, and I also like that approach. You can emulate "mixins" with that, and still stay in the single inheritance paradigm. In Haskell you don't do that at all of course, since you avoid thinking about "objects and inheritance" in the first place.

OO is strange. They offer you the nice concept of inheritance, and

Ahh, you want: instance Num a => A a Sorry to lead you on, but that actually is not legal (and -fallow-undecidable-instances will make it legal, but you don't want that, because instances of this particular form are very likely to lead to an infinite loop). Adding supertypes like this is not possible in Haskell. I really want it to be, but alas... Luke translate then

the guidelines tell you: "don't use too many levels of inheritance"... Although I've build huge projects using OO, it always felt a bit like unsafe hacking. I don't really have that feeling with Haskell, but that could also be because I'm too new to the language ;-)

...

I'm looking at Haskell because of the formality of it's type system....but I'm actually not convinced it is as powerful as an OO one....i.e. OO ones operatate principally (in Haskell speak) on "type classes" not "types"

Maybe you are right, I don't know, my theoritical skills are not high enough to answer that. Haskell just "feels" better to me, although the lack of a friendly productive IDE and large standard framework remains a bit of a burden.

Good luck, Peter

-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Nicholls, Mark Sent: Wednesday, January 02, 2008 5:41 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell?

I'm trying to translate some standard C# constucts into Haskell... some of this seems easy....

Specifically

1)

Interface IX { }

2)

Interface IX<A> { }

3)

Interface IX<A> Where A : IY { }

4)

Interface IX<A> : IZ Where A : IY { }

I can take a punt at the first 2....but then it all falls apart _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Jan 10, 2008 1:36 PM, Bulat Ziganshin wrote:

Hello Mark,

Thursday, January 10, 2008, 4:25:20 PM, you wrote:

"instance Num a => A a"

...

Mean the same thing as

...

"instance A (forall a.Num a=>a)"

programmers going from OOP world always forget that classes in Haskell doesn't the same as classes in C++. *implementation* of this instance require to pass dictionary of Num class along with type. now imagine the following code:

f :: A a => a -> a

f cannot use your instance because it doesn't receive Num dictionary of type `a`. it is unlike OOP situation where every object carries the generic VMT which includes methods for every class/interface that object supports

I'm not sure that's a good argument. It doesn't need a Num dictionary, it only needs an A dictionary. That's what it says. You only need a Num dictionary in order to construct an A dictionary, which seems perfectly reasonable. Luke

On Jan 10, 2008 2:04 PM, Nicholls, Mark wrote:

I can translate OO into mathematical logic pretty easily, I was trying to do the same thing (informally of course) with Haskell....but things are not quite what they appear....not because of some OO hang up (which I probably have many)...but because of what "type class" actually means.

But you can think of a type class as a set of types! The problem is that if we allow certain kinds of instances (such as the Foo instance I gave earlier) then the set is allowed to be non-recursive (only recursively enumerable), so determining whether a particular type is a member of it would be undecidable. Luke

Nicholls, Mark wrote:

My confusion is not between OO classes and Haskell classes, but exactly are the members of a Haskell type class...I'd naively believed them to be types (like it says on the packet!)...but now I'm not so sure.

Which packet? Classes are not types. Classes are groups of types. Sets of types. Classifications of types. For any type, you can ask the quesiton "is this type a member of this class, or not?" Without wishing to split hairs too finely, I find it a useful intuition not to consider the class context "part of the type" somehow. So, when you see this: (Num a, Eq b) => a -> b -> a Rather than thinking of that whole thing as a type, it helps to think of the part on the right of the => as the 'actual type' and the part on the left of the => as "some extra constraints on the type". So you might say this has the type "a -> b -> a", providing that a is a Num and b is an Eq. Jules

Nicholls, Mark wrote:

...

Classes are groups of types. Sets of types. Classifications of types.

I had them down as an n-ary relation on types....someone's said something somewhere that's made me question that...but I think I misinterpreted them....so I may default back to n-ary relation.

Yes, and 1-ary relations are sets. And haskell98 only supports unary type classes, and all our discussion so far had been about unary type classes. But, since you mention it, yes MPTCs are n-ary relations. Jules

On Jan 10, 2008 1:25 PM, Nicholls, Mark wrote:

Thanks for your response, I think you helped me on one of my previous abberations.

Hmmm....this all slightly does my head in....on one hand we have types....then type classes (which appear to be a relation defined on types)....then existential types...which now appear not to be treated quite in the same way as 'normal' types....and in this instance the syntax even seems to change....does

"instance Num a => A a"

Mean the same thing as

"instance A (forall a.Num a=>a)"

Uh... that second one is pretty much nonsensical to me. I could imagine it meaning the type (forall a.Num a => a) itself is an instance of A, but not specializations of it (like Int). But without an identity in the type system, the meaning of that would be convoluted. It's kind of off topic, but just for the interested, here are two similar, legal constructions: Existential: newtype Numeric = forall a. Num a => Numeric a Universal: newtype Numeric' = Numeric' (forall a. Num a => a) Both of which are easily declared to be instances of Num. They're not what you want though, because Haskell doesn't support what you want :-(. Anyway, if you have a value of type Numeric, you know it contains some value of a Num type, but you don't know what type exactly (and you can never find out). If you have a value of type Numeric', then you can produce a value of any Num type you please (i.e. the value is built out of only operations in the Num class, nothing more specific). But that was a digression; ignore at your leisure (now that you've already read it :-).

and secondly in what way can this construct lead to "undecidable instances"

Okay, read: instance A a => B b (where a and be might be more complex expressions) not as "b is an instance of B whenever a is an instance of A", but rather as "b is an instance of B, and using it as such adds a constraint of A a". Let's look at a slightly more complex (and contrived) example: class Foo a where foo :: a -> a instance (Foo [a]) => Foo a where foo x = head $ foo [x] Then when checking the type of the expression foo (0::Int), we'd have to check if Foo Int, Foo [Int], Foo [[Int]], Foo [[[Int]]], ad infinitum.

What are the instances, and what about them is undecidable....seems pretty decidable to me?

What is the ramifications of turning this option on?

Theoretically, compile time fails to guarantee to ever finish. Practically, ghc will give you a very-difficult-to-reason-about message when constraint checking stack overflows. Luke

On Thu, 10 Jan 2008, Nicholls, Mark wrote:

...

Existential: newtype Numeric = forall a. Num a => Numeric a

My compiler doesn't like this...." A newtype constructor cannot have an existential context,"

...

Universal: newtype Numeric' = Numeric' (forall a. Num a => a)

Not so sure I understand the difference here.....

Looks like http://www.haskell.org/haskellwiki/Generic_number_type