RE: [Haskell-cafe] confusion about 'instance'....

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