From simonpj at microsoft.com Thu May 1 03:59:29 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 03:53:54 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <4815FE62.4060102@gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> <4815FE62.4060102@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C50C1@EA-EXMSG-C334.europe.corp.microsoft.com> | Ok. So I counter-propose that we deal with pattern bindings like this: | | The static semantics of a pattern binding are given by the following | translation. A binding 'p = e' has the same meaning as the set of | bindings | | z = e | x1 = case z of { p -> x1 } | ... | xn = case z of { p -> xn } | | where z is fresh, and x1..xn are the variables of the pattern p. | | For bang patterns, I think it suffices to say that a bang at the top | level of p is carried to the binding for z, and then separately define | what banged variable bindings mean (i.e. add appropriate seqs). Fair enough. Although there will still be quite a bit of System F plumbing generated, I do agree that answers my questions about the static semantics of pattern bindings (*provided* we lift the MR). And I agree that it gives a simple, consistent, and explicable story to the programmer. The result may or may not do what you want though: (f, g) = ( (+), (+) ) will generate f :: (Num a, Num b) => a -> a -> a which is ambiguous. In general, pattern bindings for overloaded things are probably useless. Perhaps worth pointing this out in the report. Let's also make sure that the spec explicitly includes type signatures. That is, the above transformation is carried out, and then the individual bindings for the xi are compared with their individual type signatures. Simon From simonpj at microsoft.com Thu May 1 10:21:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 10:15:37 2008 Subject: instance export decls In-Reply-To: <20080422123244.GA18149@scico.botik.ru> References: <20080422123244.GA18149@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists module Foo( data T (f :: * -> *), instance Functor f => Eq (T f), g :: T f -> T f ) The first step is to evolve a well-worked-out design. I think that'd be a very valuable thing for someone to do. Indeed, I'd really like to see it in Haskell', but it doesn't meet the "tried and tested" criterion. I'm a bit reluctant to invest effort in half-way-house solutions, though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 22 April 2008 13:33 | To: glasgow-haskell-users@haskell.org | Subject: instance export decls | | Dear GHC developers, people, | | Do you agree that there exists such a problem for a programmer as | recalling exported instances? | Have Haskell and/or GHC some constructs and tools to help the programmer | to recall the exported instances for a module? | Could GHC support the instance export messages for each module? | | In Haskell-98, the exported instances cannot be named explicitly in the | export list. | Right? | But for easier understanding of a program, it is desirable to allow to | name (in a short form) instances in the export list. | For this reason, I add comments, and write the export like this: | | module Poly | (WithHead(..), WithTail(..), -- classes | Mon(..), Polynomial(..), | lc, polMons | -- , instances | -- for Mon: WithHead, List; | -- for Polynomial: WithHead, Cast Polynomial Mon | ) | The comment of kind "-- , instances ..." | helps to recall which instances are exported, without inspecting all | the (lengthy) module source. | | But when the programmer changes the source, one often forgets to | add/remove the needed comments about instances. | I often forget them (maybe, lazy to recall) when I move pieces of code | between modules. | | So, I suggest the following feature for GHC. | | 1. To allow the export declarations of kind instance {} | (maybe to suggest this for Haskell ?) | 2. If the module under compilation has the word `instance' in its | export list, | then ghc finds the difference set diff for the exported instance | kinds eKinds and the instance kinds nKinds named in the export | list. If not $ null diff, it issues the message: | "Warning: the exported instance kinds and the instance kinds named | in the export differ in the following items: ...". | | Seeing such a message, the user corrects the export list in the source | according to diff. | | For the export list and for their messages, it is probably better to | use a short denotation: the instance kind rather than full instance | declaration. In the instance kind, the part of "(...) =>" is skipped. | | What people think of this suggestion? | | Thank you in advance for your notes and help, | | ----------------- | Serge Mechveliani | mechvel@botik.ru From simonpj at microsoft.com Thu May 1 10:42:53 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 10:37:19 2008 Subject: Haskell' - class aliases In-Reply-To: <20080425234555.GG17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> | Yeah, I disagree here, mainly because I don't want to conflate | superclasses with class aliases. I feel they have different uses, even | though they can sometimes achieve the same thing. Fair enough. But the strange syntax class alias Num a = Eq a => (Additive a, Multiplicative a) *does* seem so say that the (Eq a) behaves in a superclass way, and (Additive a, Multiplicative a) behave in a class-alias way, as it were. That seems inconsistent with the design goal you describe above. Perhaps I can put it like this: if you want the "(Eq a) =>" part of the above decl, then you should also allow method definitions in the same decl. Once this point settles down, would you like to refine your specification in the light of my misunderstandings? The more precise it is, the easier it is to implement. Concerning Twan's idea, my brain is too small to accommodate the similarities and differences (today at any rate). But from an implementer's point of view, it'd be nice to have one proposal on the table rather than two competing ones.... Simon From john at repetae.net Thu May 1 18:14:23 2008 From: john at repetae.net (John Meacham) Date: Thu May 1 18:08:48 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080501221423.GA16331@sliver.repetae.net> On Thu, May 01, 2008 at 03:42:53PM +0100, Simon Peyton-Jones wrote: > | Yeah, I disagree here, mainly because I don't want to conflate > | superclasses with class aliases. I feel they have different uses, even > | though they can sometimes achieve the same thing. > > Fair enough. But the strange syntax > > class alias Num a = Eq a => (Additive a, Multiplicative a) > > *does* seem so say that the (Eq a) behaves in a superclass way, and > (Additive a, Multiplicative a) behave in a class-alias way, as it > were. That seems inconsistent with the design goal you describe > above. Wolfgang suggested the alternate syntax class alias Eq a => Num a = (Additive a, Multiplicative a) where .... The correct reading being: if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a) I think I am coming around to his point of view, do you think this makes it clearer? John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu May 1 18:57:14 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 18:51:38 2008 Subject: Haskell' - class aliases In-Reply-To: <20080501221423.GA16331@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> | > Fair enough. But the strange syntax | > | > class alias Num a = Eq a => (Additive a, Multiplicative a) | > | > *does* seem so say that the (Eq a) behaves in a superclass way, and | > (Additive a, Multiplicative a) behave in a class-alias way, as it | > were. That seems inconsistent with the design goal you describe | > above. | | Wolfgang suggested the alternate syntax | | class alias Eq a => Num a = (Additive a, Multiplicative a) where .... | | The correct reading being: | | if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a) | | I think I am coming around to his point of view, do you think this makes | it clearer? I am not arguing about syntax! You say "class aliases are orthogonal to superclasses", but then you allow this "Eq a" thing in the above alias, which is very like a superclass. I think that if you allow the "Eq a =>" part, you should also allow new methods to be declared in the alias (as I originally thought you did). And if not, then you shouldn't allow superclasses. It's precisely that you allow superclasses (Eq a =>) that makes your feature non-orthogonal to ordinary superclasses. Maybe you can't make them orthogonal, but it quite hard to explain this definition to me. Incidentally, you say that your proposal is just syntactic sugar: if so, can you give the desugaring translation? Simon From john at repetae.net Fri May 2 01:54:57 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 01:49:18 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502055457.GB16331@sliver.repetae.net> On Thu, May 01, 2008 at 11:57:14PM +0100, Simon Peyton-Jones wrote: > | > Fair enough. But the strange syntax > | > > | > class alias Num a = Eq a => (Additive a, Multiplicative a) > | > > | > *does* seem so say that the (Eq a) behaves in a superclass way, and > | > (Additive a, Multiplicative a) behave in a class-alias way, as it > | > were. That seems inconsistent with the design goal you describe > | > above. > | > | Wolfgang suggested the alternate syntax > | > | class alias Eq a => Num a = (Additive a, Multiplicative a) where .... > | > | The correct reading being: > | > | if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a) > | > | I think I am coming around to his point of view, do you think this makes > | it clearer? > > I am not arguing about syntax! oh, I just meant that this syntax is actually a different way of thinking about it for me and it helped me clarify some stuff in my mind so thought it might be clearer for others as well. > > You say "class aliases are orthogonal to superclasses", but then you > allow this "Eq a" thing in the above alias, which is very like a > superclass. I think that if you allow the "Eq a =>" part, you should > also allow new methods to be declared in the alias (as I originally > thought you did). And if not, then you shouldn't allow superclasses. > It's precisely that you allow superclasses (Eq a =>) that makes your > feature non-orthogonal to ordinary superclasses. Maybe you can't make > them orthogonal, but it quite hard to explain this definition to me. Oh, the reason to allow superclasses of class aliases is so methods of the superclass can be used in the default instance methods for your alias. In addition, it allows full emulation of any explicit class you can currently declare. You do not want 'instance 'Num a'' to declare an instance for Eq as that is very different behavior from the old Num class. Yet the default instances for 'Num' may require use of methods from its superclass. it actually would make more sense to call them the context of the class alias rather than the superclass, since they don't declare a super/sub class relationship between the two. > Incidentally, you say that your proposal is just syntactic sugar: if > so, can you give the desugaring translation? Hmm.. okay, here is a rough draft that covers all the important cases I think. assume the following declarations: > class C1 a where > f1 :: t1 > f1 = d1 > class C2 a where > f2 :: t2 > f2 = d2 > f3 :: t3 > f3 = d3 > class alias S a => A a = (C1 a, C2 a) where > f1 = nd1 okay, the desugaring is as follows: there are two different desugaring rules, one for instances, one for the alias appearing anywhere other than an instance declaration: > g :: A a => a -> b > g = ... translates to > g :: (S a, C1 a, C2 a) => a -> b > g = ... the triplet of (S a, C1 a, C2 a) is completely equivalent to (A a) in all ways and all places (other than instance heads), one is just a different way to express the other, just like type synonyms. An alias just expands to the union of the classes it is an alias for as well as its class constraints (superclasses). now for instance declarations > instance A a where > f2 = bf2 expands to > instance (S a) => C1 a where > f1 = nd1 > instance (S a) => C2 a where > f2 = bf2 > f3 = d3 Note that when declaring an instance of a concrete type, like Int, the constraint (S Int) will be trivially satisfied or not at compile time. (bf2 is free to use methods of 'S' of course). this translation is also a bijection, declaring those two instances manually as above is indistinguishable from declaring instances via the alias in all ways. Hopefully the generalization to arbitrary numbers of classes is clear... John -- John Meacham - ?repetae.net?john? From Tom.Schrijvers at cs.kuleuven.be Fri May 2 02:30:59 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri May 2 02:25:44 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502055457.GB16331@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> Message-ID: > Hmm.. okay, here is a rough draft that covers all the important cases I > think. > > assume the following declarations: > >> class C1 a where >> f1 :: t1 >> f1 = d1 > >> class C2 a where >> f2 :: t2 >> f2 = d2 >> f3 :: t3 >> f3 = d3 > > > >> class alias S a => A a = (C1 a, C2 a) where >> f1 = nd1 > > > > okay, the desugaring is as follows: > > there are two different desugaring rules, one for instances, one for the > alias appearing anywhere other than an instance declaration: > >> g :: A a => a -> b >> g = ... > > translates to > >> g :: (S a, C1 a, C2 a) => a -> b >> g = ... > > the triplet of (S a, C1 a, C2 a) is completely equivalent to (A a) in > all ways and all places (other than instance heads), one is just a > different way to express the other, just like type synonyms. An alias > just expands to the union of the classes it is an alias for as well as > its class constraints (superclasses). > > now for instance declarations > >> instance A a where >> f2 = bf2 > > expands to > >> instance (S a) => C1 a where >> f1 = nd1 > >> instance (S a) => C2 a where >> f2 = bf2 >> f3 = d3 > > > Note that when declaring an instance of a concrete type, like Int, the > constraint (S Int) will be trivially satisfied or not at compile time. > (bf2 is free to use methods of 'S' of course). > > this translation is also a bijection, declaring those two instances > manually as above is indistinguishable from declaring instances via the > alias in all ways. > > Hopefully the generalization to arbitrary numbers of classes is clear... What about multiple parameters? Can A have more parameters than the Ci? Should they be in the same order? Should they overlap? What about instance contexts, like: instance I a => A a where ... (What about functional dependencies?) Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From simonpj at microsoft.com Fri May 2 05:00:32 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 04:54:55 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502055457.GB16331@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> John This is good stuff, but I fear that in 3 months time it'll be buried in our email archives. In contrast, your original web page is alive and well, and we were able to start our discussion based on it So can I suggest that you transfer your web page to the Haskell' wiki (simply a convenient, editable place to develop it), or to the haskell.org wiki (likewise). And that, as the design gets fleshed out, you try to reflect the current state of play there? I don't want this work to be lost! Ok, on to your email: =============== Desugaring the class alias decl ================= | there are two different desugaring rules, one for instances, one for the | alias appearing anywhere other than an instance declaration: | | > g :: A a => a -> b | > g = ... | | translates to | | > g :: (S a, C1 a, C2 a) => a -> b | > g = ... | | the triplet of (S a, C1 a, C2 a) is completely equivalent to (A a) in | all ways and all places (other than instance heads) Notice that this part *is* exactly true of a superclass with no methods class (S a, C1 a, C2 a) => A a where {} That's not necessarily bad; but it does make it harder to figure out when to user a superclass and when to use a class alias. Does that make sense? In fact, I suggest the following (**): the class alias > class alias S a => A a = (C1 a, C2 a) where > f1 = nd1 desugars to class (S a, C1 a, C2 a) => A a The class alias decl *also* affects the desugaring of instances, still to come, but by desugaring the class alias into an ordinary class, you don't have to say *anything* about g :: (S a, C1 a, C2 a) => a -> b vs g :: (A a) => a -> b =============== Desugaring instanc decls ================= | now for instance declarations | | > instance A a where | > f2 = bf2 | | expands to | | > instance (S a) => C1 a where | > f1 = nd1 | | > instance (S a) => C2 a where | > f2 = bf2 | > f3 = d3 Do you really mean that? Presumably 'a' is not a type variable here? Furthermore, instance decls typically have a context. Unless I have profoundly misunderstood, I think you mean this: instance (Foo a, Bar b) => A (a,b) where f1 = bf1 expands to instance (Foo a, Bar b) => C1 (a,b) where f1 = nd1 instance (Foo a, Bar b) => C2 (a,b) where f2 = bf2 f2 = d3 Notice the *absence* of an instance for (S (a,b)). It's up to the *user* to ensure that there is such an instance, perhaps, say instance Foo a => S (a,b) where ... In this way S is behaving just like any ordinary superclass. If we have class S a => T a then given an instance instance (Foo a, Bar b) => T (a,b) it's up to the user to ensure that there is an instance for S (a,b). With the desugaring (**) I proposed above, we'd add one more instance: instance (Foo a, Bar b) => A (a,b) | Hopefully the generalization to arbitrary numbers of classes is clear... I'm not sure either way. Let's get this written up first. Simon From john at repetae.net Fri May 2 05:28:06 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 05:22:27 2008 Subject: Haskell' - class aliases In-Reply-To: References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> Message-ID: <20080502092806.GC16331@sliver.repetae.net> On Fri, May 02, 2008 at 08:30:59AM +0200, Tom Schrijvers wrote: >> Note that when declaring an instance of a concrete type, like Int, the >> constraint (S Int) will be trivially satisfied or not at compile time. >> (bf2 is free to use methods of 'S' of course). >> >> this translation is also a bijection, declaring those two instances >> manually as above is indistinguishable from declaring instances via the >> alias in all ways. >> >> Hopefully the generalization to arbitrary numbers of classes is clear... > > What about multiple parameters? Can A have more parameters than the Ci? > Should they be in the same order? Should they overlap? > > What about instance contexts, like: > > instance I a => A a where ... Ah, I originally had instance contexts in my example, but left them out for clarity of the main points. instance contexts are just copied verbatim into each expanded instance. > (What about functional dependencies?) I am leaving out MPTCs and hence fundeps for now, I do not believe they will present an issue, as nothing about the expansion depends on the number of arguments, but I want to make sure we have a clear understanding of what class aliases imply for haskell 98 one constructor type classes first. I think the extension to MPTCs is clear, not so clear for fundeps but not unsolvable, then again, nothing much is clear about the future of fundeps so I don't think that is a big issue. John -- John Meacham - ?repetae.net?john? From john at repetae.net Fri May 2 05:50:20 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 05:44:45 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502095020.GD16331@sliver.repetae.net> This isn't really a response to your email, but I have been mulling the last few hours away from a computer and wanted to get this stream of conciousness out when it is fresh in my mind. The more I think about it, I think 'superclass' is just the wrong terminology for dealing with class aliases. Superclass implies a strict partial order on classes, which just isn't the case for class aliases, for instance > class alias Foo a => Foo a = Bar a where ... Has a defined (if not very useful) meaning with class aliases, but is really odd if you consider 'Foo a' a "superclass". So, I think the following terminology should be used: Context of --+ alias | The alias -+ +--- The expansion of the alias | | | v v v > class alias (S1 a .. Sn a) => A a = (C1 a ... Cn a) where > fd1 = .... > .... > fdn = .... ^ +---- The defaults of the alias given this, the expansion of 'A a' in any context other than an instance head is > A a --> reduce(S1 a .. Sn a, C1 a ... Cn a) where reduce is standard entailment reduction on class contexts (like (Eq a,Ord a, Eq a) reduces to (Ord a)) This expansion is carried out iteratively on all class aliases until a fixed point is reached, then all class aliases are deleted from the result and the remaining context is the final result. (This will always terminate due to there being a finite number of class aliases that can be pulled into the expansion) likewise, for instance declarations: > instance A a where ... --> > foreach C in C1 .. Cn: > instance (S1 a ... Sn a) => C a where ... I left out the default methods here. I need to think about them a bit more to come up with a formal expansion as it is a bit trickier (to typeset if nothing else), but I hope this is somewhat more clear for some... John -- John Meacham - ?repetae.net?john? From martin.sulzmann at gmail.com Fri May 2 06:18:45 2008 From: martin.sulzmann at gmail.com (Martin Sulzmann) Date: Fri May 2 06:13:10 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502095020.GD16331@sliver.repetae.net> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> Message-ID: <481AEA85.40307@gmail.com> Any chance to express this in terms of a formal (constraint rewrite framework). For example, the Haskell rule, do *not* display implied superclasses, can be specified as follows. Consider the special case of class Eq a class Eq a => Ord a Eq a, Ord a <=> Ord a The above rule only applies *after* type inference took place. Martin John Meacham wrote: > This isn't really a response to your email, but I have been mulling the > last few hours away from a computer and wanted to get this stream of > conciousness out when it is fresh in my mind. > > The more I think about it, I think 'superclass' is just the wrong > terminology for dealing with class aliases. Superclass implies a strict > partial order on classes, which just isn't the case for class aliases, > for instance > > >> class alias Foo a => Foo a = Bar a where ... >> > > Has a defined (if not very useful) meaning with class aliases, but is > really odd if you consider 'Foo a' a "superclass". So, I think the > following terminology should be used: > > Context of --+ > alias | The alias -+ +--- The expansion of the alias > | | | > v v v > >> class alias (S1 a .. Sn a) => A a = (C1 a ... Cn a) where >> fd1 = .... >> .... >> fdn = .... >> > ^ > +---- The defaults of the alias > > > > given this, the expansion of 'A a' in any context other than an instance > head is > > >> A a --> reduce(S1 a .. Sn a, C1 a ... Cn a) >> > > where reduce is standard entailment reduction on class contexts (like (Eq > a,Ord a, Eq a) reduces to (Ord a)) > > This expansion is carried out iteratively on all class aliases until a > fixed point is reached, then all class aliases are deleted from the > result and the remaining context is the final result. (This will always > terminate due to there being a finite number of class aliases that can > be pulled into the expansion) > > > likewise, for instance declarations: > > > >> instance A a where ... >> > > --> > > >> foreach C in C1 .. Cn: >> instance (S1 a ... Sn a) => C a where ... >> > > I left out the default methods here. I need to think about them a bit > more to come up with a formal expansion as it is a bit trickier (to > typeset if nothing else), but I hope this is somewhat more clear for > some... > > John > > > > > From john at repetae.net Fri May 2 06:21:23 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 06:15:46 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502102123.GE16331@sliver.repetae.net> On Fri, May 02, 2008 at 10:00:32AM +0100, Simon Peyton-Jones wrote: > John > > This is good stuff, but I fear that in 3 months time it'll be buried > in our email archives. In contrast, your original web page is alive > and well, and we were able to start our discussion based on it > > So can I suggest that you transfer your web page to the Haskell' wiki > (simply a convenient, editable place to develop it), or to the > haskell.org wiki (likewise). And that, as the design gets fleshed > out, you try to reflect the current state of play there? I don't want > this work to be lost! Yes. I will try to do that. if anyone else wants to go ahead and do it, that would be fine too. > Ok, on to your email: > > =============== Desugaring the class alias decl ================= | > there are two different desugaring rules, one for instances, one for > the | alias appearing anywhere other than an instance declaration: | | > > g :: A a => a -> b | > g = ... | | translates to | | > g :: (S a, > > C1 a, C2 a) => a -> b | > g = ... | | the triplet of (S a, C1 a, C2 > > a) is completely equivalent to (A a) in | all ways and all places > > (other than instance heads) > > Notice that this part *is* exactly true of a superclass with no > methods > > class (S a, C1 a, C2 a) => A a where {} No, this isn't true. imagine > f :: (S a, C1 a, C2 a) => a -> Int > f x = g x > g :: A a => a -> Int > g x = .... If A is a class alias, then this compiles just fine, if A is a concrete class with superclasses, then it doesn't necessarily. > That's not necessarily bad; but it does make it harder to figure out > when to user a superclass and when to use a class alias. Does that > make sense? > > In fact, I suggest the following (**): the class alias > > > class alias S a => A a = (C1 a, C2 a) where f1 = nd1 > > desugars to > > class (S a, C1 a, C2 a) => A a > > The class alias decl *also* affects the desugaring of instances, still > to come, but by desugaring the class alias into an ordinary class, you > don't have to say *anything* about g :: (S a, C1 a, C2 a) => a -> b vs > g :: (A a) => a -> b But there is a difference, as noted above. And how can you decide whether the expansion: > class S a > class S a => A a > instance A Int is supposed to declare an instance for 'S Int' as well as 'A Int' or produce an error? Neither is a good choice universally. which is why I made the distinction explicit in my class alias proposal. > =============== Desugaring instanc decls ================= > | now for instance declarations > | > | > instance A a where > | > f2 = bf2 > | > | expands to > | > | > instance (S a) => C1 a where > | > f1 = nd1 > | > | > instance (S a) => C2 a where > | > f2 = bf2 > | > f3 = d3 > > Do you really mean that? Presumably 'a' is not a type variable here? > Furthermore, instance decls typically have a context. Unless I have > profoundly misunderstood, I think you mean this: Yeah, a is likely not a type variable, so it will be of form 'S Foo' for some concrete type 'Foo'. Which is checked at compile time (just as if a method of S were used in a default) and produce an error if such an instance doesn't exist. > instance (Foo a, Bar b) => A (a,b) where f1 = bf1 > > expands to > > instance (Foo a, Bar b) => C1 (a,b) where f1 = nd1 > > instance (Foo a, Bar b) => C2 (a,b) where f2 = bf2 f2 = d3 > > Notice the *absence* of an instance for (S (a,b)). It's up to the > *user* to ensure that there is such an instance, perhaps, say > > instance Foo a => S (a,b) where ... No, the 'S a' as appended to whatever instance context you provide. so > instance (Foo a, Bar b) => A (a,b) where f1 = bf1 expands to > instance (S (a,b), Foo a, Bar b) => C1 (a,b) where f1 = nd1 > instance (S (a,b), Foo a, Bar b) => C2 (a,b) where f2 = bf2 f2 = d3 If 'S (a,b)' is not entailed by the environment in scope then the declaration produces an error. > In this way S is behaving just like any ordinary superclass. If we > have > > class S a => T a then given an instance instance (Foo a, Bar > b) => T (a,b) it's up to the user to ensure that there is an > instance for S (a,b). > > > With the desugaring (**) I proposed above, we'd add one more instance: > instance (Foo a, Bar b) => A (a,b) Yes, but we explicitly did not want to add that instance by using a class alias context rather than putting it in the expansion, for a similar reason we don't create a dummy 'Eq' instance when someone declares something an instance of 'Num' even though Eq is a superclass of Num. The 'class alias context' vs 'class alias expansion' is there to make that distinction clear and unambigous, the expansion is what you declare with an instance, the context is a prerequisite for creating an instance. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Fri May 2 06:24:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 06:18:32 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502095020.GD16331@sliver.repetae.net> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> | The more I think about it, I think 'superclass' is just the wrong | terminology for dealing with class aliases. Superclass implies a strict | partial order on classes, which just isn't the case for class aliases, | for instance | | > class alias Foo a => Foo a = Bar a where ... Crumbs! I have no idea what that means! Did you really mean to repeat "Foo"? According to your expansion in type signatures f :: (Foo a) => ... expands to f :: (Foo a, Bar a) => ... which presumably expands again. I'm totally lost here Have a look at my last message, which gives a variant of your desugaring that IMHO greatly clarifies the meaning of (what I understand by) aliases. Simon From simonpj at microsoft.com Fri May 2 06:45:29 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 06:39:52 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502102123.GE16331@sliver.repetae.net> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502102123.GE16331@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55E6@EA-EXMSG-C334.europe.corp.microsoft.com> | > Notice that this part *is* exactly true of a superclass with no | > methods | > | > class (S a, C1 a, C2 a) => A a where {} | | No, this isn't true. imagine | | > f :: (S a, C1 a, C2 a) => a -> Int | > f x = g x | | > g :: A a => a -> Int | > g x = .... | | If A is a class alias, then this compiles just fine, if A is a | concrete class with superclasses, then it doesn't necessarily. Excellent point. I'll think about that -- meanwhile can you describe this difference explicitly in your writeup? | > =============== Desugaring instanc decls ================= | > | now for instance declarations | > | | > | > instance A a where | > | > f2 = bf2 | > | | > | expands to | > | | > | > instance (S a) => C1 a where | > | > f1 = nd1 | > | | > | > instance (S a) => C2 a where | > | > f2 = bf2 | > | > f3 = d3 | > | > Do you really mean that? Presumably 'a' is not a type variable here? | > Furthermore, instance decls typically have a context. Unless I have | > profoundly misunderstood, I think you mean this: | | Yeah, a is likely not a type variable, so it will be of form 'S Foo' for | some concrete type 'Foo'. Can you give a more general example, like I did, in which we make an instance for A (a,b), where there is a type constructor (your Foo) but also type variables. Perhpas pairs are confusing; try instance ... => A (Foo a b) That's when the context matters! | No, the 'S a' as appended to whatever instance context you provide. so | | > instance (Foo a, Bar b) => A (a,b) where f1 = bf1 | | expands to | | > instance (S (a,b), Foo a, Bar b) => C1 (a,b) where f1 = nd1 | > instance (S (a,b), Foo a, Bar b) => C2 (a,b) where f2 = bf2 f2 = d3 | | If 'S (a,b)' is not entailed by the environment in scope then the | declaration produces an error. I don't understand why. To be concrete, what goes wrong if you omit the (S (a,b))? | of Num. The 'class alias context' vs 'class alias expansion' is there | to make that distinction clear and unambigous, the expansion is what you | declare with an instance, the context is a prerequisite for creating an | instance. I'm not against making such a distinction -- I'm just trying to understand what the distinction is. OK, this is progress. Perhaps rather than responding in detail the next step is to write the proposal up in the light of where we've got to? S From john at repetae.net Fri May 2 06:47:52 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 06:42:14 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502104752.GF16331@sliver.repetae.net> On Fri, May 02, 2008 at 11:24:11AM +0100, Simon Peyton-Jones wrote: > | The more I think about it, I think 'superclass' is just the wrong > | terminology for dealing with class aliases. Superclass implies a strict > | partial order on classes, which just isn't the case for class aliases, > | for instance > | > | > class alias Foo a => Foo a = Bar a where ... > > Crumbs! I have no idea what that means! Did you really mean to repeat "Foo"? According to your expansion in type signatures > f :: (Foo a) => ... > expands to > f :: (Foo a, Bar a) => ... > which presumably expands again. I'm totally lost here Yes I did, because I wanted to make the differences between class alias contexts and superclasses very clear, the above context is valid, if vacuous. the expansion goes as follows . 1. Foo a --> reduce(Foo a,Bar a) -- Foo a expanded 2. reduce(Foo a,Bar a) --> (Foo a,Bar a) -- no entailment reduction possible, reduction is unchanged from H98 3. (Foo a,Bar a) -> reduce(Foo a,Bar a,Bar a) -- Foo a expanded 4. reduce(Foo a, Bar a, Bar a) -> (Foo a, Bar a) -- reductino removes duplicates 5. we notice we are the same as in step #2. fixed point reached, we stop expansion. 6. we remove all class aliases from result: (Foo a, Bar a) -> Bar a 7. 'Bar a' is our final result. informal proof of termination: each step adds a new class or class alias to the context, there are a finite number of classes or class aliases, therefore we must eventually reach a fixed point. > Have a look at my last message, which gives a variant of your > desugaring that IMHO greatly clarifies the meaning of (what I > understand by) aliases. I think the difference in what we mean is that I intend class aliases to be a true bijection in all contexts (isomorphism?) between a single alias and a set of classes. This is opposed to superclasses which are a one directional implication. One of my main motivations is being able to mix unchanged H98 and H' code (with different numerical hierarchies, and both calling each other) without modifications or prefered treatment for either. this means instances for H' must silently and transparently create instances for H98 classes and vice versa, moreso, type signatures should be compatible. As in, the H' specification should be able to make absolutely no reference to H98 and vice versa, yet class aliases allow one to write a compiler that seamlessly allows mixing code from the two without compromising the design of either. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Fri May 2 06:54:13 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri May 2 06:48:35 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502104752.GF16331@sliver.repetae.net> References: <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502104752.GF16331@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55F8@EA-EXMSG-C334.europe.corp.microsoft.com> | > Crumbs! I have no idea what that means! Did you really mean to repeat "Foo"? According to your | expansion in type signatures | > f :: (Foo a) => ... | > expands to | > f :: (Foo a, Bar a) => ... | > which presumably expands again. I'm totally lost here | | Yes I did, because I wanted to make the differences between class alias | contexts and superclasses very clear, the above context is valid, if | vacuous. the expansion goes as follows . | 1. Foo a --> reduce(Foo a,Bar a) | -- Foo a expanded ... Even more crumbs! Is this fixpoint iteration (being careful to avoid infinite expansion) *really* essential to your proposal? That would be a significant and unwelcome thing IMHO. To be concrete, consider f :: (Foo a) => ... In GHC, f really takes an extra dictionary argument for the class Foo. If aliases mean aliases in the sense of type synonyms (which I think you intend) you must expand Foo to find out whether f takes zero, one, or many dictionary arguments. Furthermore, everyone must expand in precisely the same way, so that we agree on the order of these arguments. That's reasonably simple if "expand" simply means "normalise"; but it's more complicated if there's a fixpoint algorithm involved. So is this really crucial? Simon From john at repetae.net Fri May 2 07:33:54 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 07:28:15 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55F8@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502104752.GF16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C55F8@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502113354.GG16331@sliver.repetae.net> On Fri, May 02, 2008 at 11:54:13AM +0100, Simon Peyton-Jones wrote: > Even more crumbs! Is this fixpoint iteration (being careful to avoid > infinite expansion) *really* essential to your proposal? That would > be a significant and unwelcome thing IMHO. > > To be concrete, consider f :: (Foo a) => ... > > In GHC, f really takes an extra dictionary argument for the class Foo. > If aliases mean aliases in the sense of type synonyms (which I think > you intend) you must expand Foo to find out whether f takes zero, one, > or many dictionary arguments. Furthermore, everyone must expand in > precisely the same way, so that we agree on the order of these > arguments. That's reasonably simple if "expand" simply means > "normalise"; but it's more complicated if there's a fixpoint algorithm > involved. Yeah, I do mean normalize I think. There is no run time representation of class aliases at all so this issue doesn't arise. f will just take a 'Bar' dictionary argument. I am envisioning class alias expansion taking place very early in the desugaring, certainly before any transformation to ghc core and turning contexts into dictionary arguments. > So is this really crucial? Probably not, minimal fixpoint calculations are just what I find the simplest way to formally define/think about things. In this case, I am sure a simpler straight up normalization algorithm can be used to get equivalent results... but minimal fixpoints are so easy to implement in haskell and formally well defined that I am not sure of the value of specifying the extension in terms of it. It of course doesn't mean compilers have to perform the fixpoint iteration, it is just a declarative statement of what class aliases are equivalent to. John -- John Meacham - ?repetae.net?john? From claus.reinke at talk21.com Fri May 2 07:51:49 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri May 2 07:46:16 2008 Subject: Haskell' - class aliases References: <20080423041823.GX17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com><20080425234555.GG17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com><20080501221423.GA16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com><20080502055457.GB16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com><20080502095020.GD16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502104752.GF16331@sliver.repetae.net> Message-ID: <00ce01c8ac4a$e974ea50$bf078351@cr3lt> hmm, i thought i understood what class aliases were about, but the recent discussion about superclasses and fixpoints has me confused again. may i suggest that the updated proposal page follows this outline (in particular, providing 1 and 2 before diving into 3): 1. general idea + one simple example to confirm intuition (if there are obvious misinterpretations, it might be useful to list and discard them here) 2. translation scheme (formal enough to run all examples) 3. concrete examples to highlight difficult issues and special cases 4. syntactic sugar to make typical uses easier the way i thought i understood them (and the way i encoded them in the example i sent), class aliases consist of two parts: A aliasing of constraints/classes (this is the semantic part that could also be explained by reduction, or by simple mutual implication encodings) B aliasing of syntax, especially instance definitions (this syntactic part is hard to encode, and simple in terms of syntactic macro expansion) so, in writing class alias A x = (B x,C x) we'd get from A: the semantic equivalence of the constraints, which we usually encode roughly like this class (B x,C x) => A x instance (B x,C x) => A x from B: the syntactic equivalence of different ways of defining instances of A,B, and C, which is best understood by expanding all instance definitions for A into instance definitions of B and C defining instances of B x and C x is equivalent to defining an instance of A x (so defining an instance of A x if either B x or C x already exist leads to duplicate instances) everything else is syntactic sugar, such as having methods or constraints in A that are not present in B or C. if this is wrong somewhere, could you please correct it? otherwise, i'll wait for the updated proposal page to explain the details. claus From claus.reinke at talk21.com Fri May 2 09:06:24 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri May 2 09:00:59 2008 Subject: Haskell' - class aliases References: <20080423041823.GX17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com><20080425234555.GG17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com><20080501221423.GA16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com><20080502055457.GB16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com><20080502095020.GD16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com><20080502104752.GF16331@sliver.repetae.net> <00ce01c8ac4a$e974ea50$bf078351@cr3lt> Message-ID: <010b01c8ac55$5479df90$bf078351@cr3lt> > A aliasing of constraints/classes > (this is the semantic part that could also be explained by > reduction, or by simple mutual implication encodings) > > B aliasing of syntax, especially instance definitions > (this syntactic part is hard to encode, and simple in > terms of syntactic macro expansion) it just occurred to me that there is a precedence for this kind of translation, in associated types and type functions. defining an AT in a class is equivalent to defining a TF outside the class, and connecting the TF to the class with superclass and instance constraints, right? class C a where type CT a c :: (a,CT a) instance C a where type CT a = .. c = .. -- vs type family CT a type instance CT a = .. class CT a ~ b => C a where c :: (a,CT a) instance CT a ~ b => C a where c = .. though the latter form is not yet supported in GHC (#714). which leads me to a problem i have with ATs, which applies to class aliases as well: although the ATs are written as if they were local to the class, they get lifted out of the class in a naive manner. in particular, they can only refer to their parameters, not to other local definitions/types, and their parameters have to match the class parameters. however, i assume that the restrictions/translations/implementations for class aliases are similar to the those for the implementation of ATs in terms of TFs, which might help? claus From Tom.Schrijvers at cs.kuleuven.be Fri May 2 09:37:50 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri May 2 09:32:41 2008 Subject: Haskell' - class aliases In-Reply-To: <20080502095020.GD16331@sliver.repetae.net> References: <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> <20080425234555.GG17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com> <20080501221423.GA16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502055457.GB16331@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502095020.GD16331@sliver.repetae.net> Message-ID: >> class alias Foo a => Foo a = Bar a where ... > > Has a defined (if not very useful) meaning with class aliases, but is > really odd if you consider 'Foo a' a "superclass". So, I think the > following terminology should be used: > > Context of --+ > alias | The alias -+ +--- The expansion of the alias > | | | > v v v >> class alias (S1 a .. Sn a) => A a = (C1 a ... Cn a) where >> fd1 = .... >> .... >> fdn = .... > ^ > +---- The defaults of the alias Should all of the arguments of the Ci be the same type variable `a' as in the alias A a or can they be other types as well, like e.g. C1 [a] or C2 Int? Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From john at repetae.net Fri May 2 18:03:14 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 17:57:36 2008 Subject: instance export decls In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502220314.GB21252@sliver.repetae.net> On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > Indeed! I think it'd be good to allow type signatures, including > instance signatures, in export lists The problem with instance signatures is that it would give the impression that it would be possible to _not_ export an instance, and it wouldn't make explicit the fact that the instances of all modules it depends on are also exported. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Tue May 6 04:55:42 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 6 04:49:52 2008 Subject: Haskell' - class aliases In-Reply-To: <010b01c8ac55$5479df90$bf078351@cr3lt> References: <20080423041823.GX17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com><20080425234555.GG17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com><20080501221423.GA16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com><20080502055457.GB16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com><20080502095020.GD16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com><20080502104752.GF16331@sliver.repetae.net> <00ce01c8ac4a$e974ea50$bf078351@cr3lt> <010b01c8ac55$5479df90$bf078351@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E68F@EA-EXMSG-C334.europe.corp.microsoft.com> | which leads me to a problem i have with ATs, which applies | to class aliases as well: although the ATs are written as if they | were local to the class, they get lifted out of the class in a naive | manner. in particular, they can only refer to their parameters, | not to other local definitions/types, and their parameters have | to match the class parameters. I'm not sure what you mean here, Claus. Can you give a concrete example? Simon From claus.reinke at talk21.com Tue May 6 08:28:18 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue May 6 08:22:34 2008 Subject: Haskell' - class aliases References: <20080423041823.GX17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com><20080425234555.GG17560@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C52D8@EA-EXMSG-C334.europe.corp.microsoft.com><20080501221423.GA16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C543A@EA-EXMSG-C334.europe.corp.microsoft.com><20080502055457.GB16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C5517@EA-EXMSG-C334.europe.corp.microsoft.com><20080502095020.GD16331@sliver.repetae.net><638ABD0A29C8884A91BC5FB5C349B1C32AE54C55BC@EA-EXMSG-C334.europe.corp.microsoft.com><20080502104752.GF16331@sliver.repetae.net><00ce01c8ac4a$e974ea50$bf078351@cr3lt> <010b01c8ac55$5479df90$bf078351@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AE554E68F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <00c101c8af74$ab8e8390$c3128351@cr3lt> >| which leads me to a problem i have with ATs, which applies > | to class aliases as well: although the ATs are written as if they > | were local to the class, they get lifted out of the class in a naive > | manner. in particular, they can only refer to their parameters, > | not to other local definitions/types, and their parameters have > | to match the class parameters. > > I'm not sure what you mean here, Claus. Can you give a concrete example? sure. here's one from practice, even. there was a thread on haskell-cafe on how to re-export FD-based libraries in AT-based form (for better match with AT-based client code). the obvious translation of class FD a b | a -> b would seem to be class AT a where type AT a but, as it turns out, you can't write instance FD a b => AT a where type AT a = b because the 'b' is not in scope! from an AT-based perspective, it ought to be in scope, because the AT definition is local to the instance, but the AT seems to be implemented as sugar for a non-local TF, for which the local 'b' is not available (i'm not sure why there is no lambda-lifting behind the scenes to add that 'b' parameter, in a hidden form?). the thread, and Manuel's explanation, are here: http://www.haskell.org/pipermail/haskell-cafe/2008-March/041168.html this is likely to be less of a problem for class aliases, because the component class instances share not only the same form of instance head, but also the same context (so if a type is functionally determined by the context in one component, it is so in all components). btw, if type family instances could have contexts that functionally determine extra type parameters, the original poster wouldn't have to duplicate his FDs as TFs, as suggested in that email, but could simply write (i think?-): type instance AT a = FD a b => b claus From barsoap at web.de Tue May 6 09:57:21 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 6 09:59:11 2008 Subject: Tackling the atrocious squad Message-ID: <20080506155721.0efbdc06@solaris> Well, it's an unformalised and not much thought about out-of-the-tub idea, but here it goes: Let there be a monad/typeclass representing the denotional semantics of Haskell Do some instances of it, called e.g. GHC or Hugs. so, instead of main :: IO () we have main :: (Haskell h) => h (IO ()) or, if you need some feature of the Haskell runtime system XYZ main :: XYZ (IO ()) or even main :: (FFI h) => h (IO ()) and main :: (SomeLib h) => h (IO ()) , and then go on and define every single language construct as part of this type hierarchy, and define some syntactic sugar to make stuff look exactly like haskell '98 if you're just hacking away. I especially like the metacircularity of this approach, and the fact that every Model (read: implementation) of Haskell would have to admit that it is only a Model (read: instance) of Haskell. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From lennart at augustsson.net Tue May 6 19:40:44 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue May 6 19:34:53 2008 Subject: Tackling the atrocious squad In-Reply-To: <20080506155721.0efbdc06@solaris> References: <20080506155721.0efbdc06@solaris> Message-ID: And what's the denotational semantics of type classes? As far as I know it has never been done, because it's very complex. On Tue, May 6, 2008 at 2:57 PM, Achim Schneider wrote: > Well, it's an unformalised and not much thought about out-of-the-tub > idea, but here it goes: > > Let there be a monad/typeclass representing the denotional semantics of > Haskell > > Do some instances of it, called e.g. GHC or Hugs. > > so, instead of > > main :: IO () > > we have > > main :: (Haskell h) => h (IO ()) > > or, if you need some feature of the Haskell runtime system XYZ > > main :: XYZ (IO ()) > > or even > > main :: (FFI h) => h (IO ()) > > and > > main :: (SomeLib h) => h (IO ()) > > , and then go on and define every single language construct as part of > this type hierarchy, and define some syntactic sugar to make stuff look > exactly like haskell '98 if you're just hacking away. > > I especially like the metacircularity of this approach, and the fact > that every Model (read: implementation) of Haskell would have to admit > that it is only a Model (read: instance) of Haskell. > > -- > (c) this sig last receiving data processing entity. Inspect headers for > past copyright information. All rights reserved. Unauthorised copying, > hiring, renting, public performance and/or broadcasting of this > signature prohibited. > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20080507/9a681ad4/attachment.htm From barsoap at web.de Tue May 6 22:56:57 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 6 22:51:16 2008 Subject: Tackling the atrocious squad References: <20080506155721.0efbdc06@solaris> Message-ID: <20080507045657.0cc80a45@solaris> "Lennart Augustsson" wrote: > And what's the denotational semantics of type classes? As far as I > know it has never been done, because it's very complex. > I have no idea whatsoever, but dare to say that the target language just isn't appropriate, iff it turns out to be complex. As a matter of taste, I'd go for axiomatic semantics instead, exspecially if considering metacircularity. Lisp, for example, can be reduced to get! == set!, leaving all the confusion as an implementation detail. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From simonmarhaskell at gmail.com Wed May 14 11:14:32 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:14 2008 Subject: patch applied (haskell-prime-status): Add issue about qualified names in instance declarations Message-ID: <20080514151431.GA2601@haskell.galois.com> Mon Apr 28 09:51:15 PDT 2008 Simon Marlow * Add issue about qualified names in instance declarations We certainly need to do *something* here M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080428165115-8214f-d6159df5024a20f4992ef8dd5694b557de580c48.gz From simonmarhaskell at gmail.com Wed May 14 11:14:34 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:16 2008 Subject: patch applied (haskell-prime-status): reject the $ proposal Message-ID: <20080514151434.GA2625@haskell.galois.com> Wed Apr 30 09:47:49 PDT 2008 Simon Marlow * reject the $ proposal M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080430164749-8214f-7ea2f68378fa5577fa484c4525395a47a8185709.gz From simonmarhaskell at gmail.com Wed May 14 11:14:35 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:19 2008 Subject: patch applied (haskell-prime-status): reject CompositionAsDot Message-ID: <20080514151435.GA2644@haskell.galois.com> Wed Apr 30 09:49:57 PDT 2008 Simon Marlow * reject CompositionAsDot M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080430164957-8214f-0b8497293fb762b3eca2f467db49f3fb13bf42d4.gz From simonmarhaskell at gmail.com Wed May 14 11:14:36 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:19 2008 Subject: patch applied (haskell-prime-status): accept QualifiedOperators Message-ID: <20080514151436.GA2661@haskell.galois.com> Wed Apr 30 09:50:38 PDT 2008 Simon Marlow * accept QualifiedOperators M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080430165038-8214f-81a70a53e326d741ecdd46e63c895397763f7d11.gz From simonmarhaskell at gmail.com Wed May 14 11:14:38 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:23 2008 Subject: patch applied (haskell-prime-status): add new issue: "Allow GADT syntax for data types" Message-ID: <20080514151438.GA2678@haskell.galois.com> Wed Apr 30 09:56:14 PDT 2008 Simon Marlow * add new issue: "Allow GADT syntax for data types" M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080430165614-8214f-f271b28fddcc1beb2d1057787d4c18a5774203ed.gz From simonmarhaskell at gmail.com Wed May 14 11:14:39 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:23 2008 Subject: patch applied (haskell-prime-status): Accepted: specify the static semantics of pattern bindings Message-ID: <20080514151439.GA2695@haskell.galois.com> Wed May 14 07:57:26 PDT 2008 Simon Marlow * Accepted: specify the static semantics of pattern bindings M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514145726-12142-c9043f9e22b6eee2d15bdc00ae6a71c60aa5ac0c.gz From simonmarhaskell at gmail.com Wed May 14 11:14:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:23 2008 Subject: patch applied (haskell-prime-status): reject MonomorphicPatternBindings Message-ID: <20080514151440.GA2712@haskell.galois.com> Wed May 14 07:58:42 PDT 2008 Simon Marlow * reject MonomorphicPatternBindings M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514145842-12142-59e2d290f53f96cd6544d23c4e4abde588798205.gz From simonmarhaskell at gmail.com Wed May 14 11:14:43 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:30 2008 Subject: patch applied (haskell-prime-status): Accepted: remove the monomorphism restriction Message-ID: <20080514151443.GA2746@haskell.galois.com> Wed May 14 08:12:34 PDT 2008 Simon Marlow * Accepted: remove the monomorphism restriction M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151234-12142-8883dd9b436af3208701e5dcd9b926e38391765c.gz From simonmarhaskell at gmail.com Wed May 14 11:14:42 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:31 2008 Subject: patch applied (haskell-prime-status): separate the various monomorphism restriction proposals Message-ID: <20080514151442.GA2729@haskell.galois.com> Wed May 14 08:12:12 PDT 2008 Simon Marlow * separate the various monomorphism restriction proposals M ./status.hs -1 +17 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151212-12142-28aa86fa87208d58913b72b0fdb6be38e61e9a62.gz From simonmarhaskell at gmail.com Wed May 14 11:14:44 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:31 2008 Subject: patch applied (haskell-prime-status): Reject: make the monomorphism restriction optional Message-ID: <20080514151444.GA2763@haskell.galois.com> Wed May 14 08:12:56 PDT 2008 Simon Marlow * Reject: make the monomorphism restriction optional M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151256-12142-6e980688c7288076506071b462df9750e0bd6d18.gz From simonmarhaskell at gmail.com Wed May 14 11:14:46 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 14 11:08:32 2008 Subject: patch applied (haskell-prime-status): Reject: make variable and pattern bindings monomorphic by default Message-ID: <20080514151445.GA2780@haskell.galois.com> Wed May 14 08:13:16 PDT 2008 Simon Marlow * Reject: make variable and pattern bindings monomorphic by default M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080514151316-12142-96877503c976760e847641936a8b93f5e6e7f3ef.gz