From niklas.broberg at gmail.com Tue Jun 23 20:32:24 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Jun 23 20:15:23 2009 Subject: Proposal: ExplicitForall Message-ID: Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html From simonpj at microsoft.com Wed Jun 24 04:09:52 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jun 24 03:52:57 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> | I would thus like to propose the following formalisation of the | ExplicitForall extension: What you suggest would be fine with me. Presumably ExplicitForall would be implied by RankNTypes and the other extensions? There is a danger of having too *many* choices. (http://www.joelonsoftware.com/items/2006/11/21.html) In particular, you might consider making ScopedTypeVariables synonymous with ExplicitForAll. Once you have given up the keyword, it seems a shame not to allow lexically scoped type variables! On ExistentialQuantification, I personally think we should deprecate the entire construct, suggesting GADT-style syntax instead. If you can form a consensus, go for it. Simon From bulat.ziganshin at gmail.com Wed Jun 24 04:11:31 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Jun 24 03:54:34 2009 Subject: Proposal: ExplicitForall In-Reply-To: References: Message-ID: <122296568.20090624121131@gmail.com> Hello Brandon, Wednesday, June 24, 2009, 8:56:30 AM, you wrote: > but also e.g. if you are actually compiling Haskell98, hierarchical > modules should be illegal. afaik, HM and FFI are just considered to be included in H98 later, so these are part of (revised) standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From niklas.broberg at gmail.com Wed Jun 24 06:59:56 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Jun 24 06:42:52 2009 Subject: Proposal: ExplicitForall In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33F4BAAFDF9@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: > What you suggest would be fine with me. Presumably ExplicitForall would be implied by RankNTypes and the other extensions? Yes, that's the idea. Rank2Types, RankNTypes, PolymorphicComponents, ScopedTypeVariables and LiberalTypeSynonyms would all imply ExplicitForall. > There is a danger of having too *many* choices. (http://www.joelonsoftware.com/items/2006/11/21.html) ?In particular, you might consider making ScopedTypeVariables synonymous with ExplicitForAll. ?Once you have given up the keyword, it seems a shame not to allow lexically scoped type variables! While I agree with you (and Joel) in principle, I think this is the wrong level to hold that discussion. I think the long-term solution should be to keep the registered extensions cleanly separated, and instead supply extension *groups* as a way to limit choice. -fglasgow-exts has fit that niche admirably for a long time, I think a lot of people just use that without thinking twice about what particular extensions they actually use, and nothing wrong with that. I think the move towards LANGUAGE pragmas instead of compiler options is a good one from a standardisation and implementation point of view, but to avoid tedium and unnecessary choice for the programmer I strongly feel that extension groups need to be introduced at this level too. But as I said, that's for a different discussion... > On ExistentialQuantification, I personally think we should deprecate the entire construct, suggesting GADT-style syntax instead. +1, though I was afraid to suggest something that radical. I might write a separate proposal for that then, to keep the discussion here focused on ExplicitForall. > If you can form a consensus, go for it. Alright, let's set an actual discussion period of 2 weeks for ExplicitForall. If there is no opposition by then, we can add ExplicitForall to the registered extensions in cabal as a first step. Cheers, /Niklas From niklas.broberg at gmail.com Sat Jun 27 06:44:49 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Jun 27 06:27:37 2009 Subject: Proposal: Deprecate ExistentialQuantification Message-ID: Hi all, Following the discussion on the use of 'forall' and extensions that use it [1], I would hereby like to propose that the ExistentialQuantification extension is deprecated. My rationale is as follows. With the introduction of GADTs, we now have two ways to write datatype declarations, the old simple way and the GADTs way. The GADTs way fits better syntactically with Haskell's other syntactic constructs, in all ways. The general style is (somewhat simplified) "keyword type 'where' decls", where keyword can in Haskell 98 be class or instance, but with GADTs also data. The old simple way of defining data types is the odd one out. It certainly has its uses though, in particular when defining some simple (but possibly large) enum-like datatype (like cabal's Extension type incidentally), then it obviously becomes tedious to have to restate the trivial type signature for each constructor. Using GADTs style syntax it is possible to allow constructors with existentially quantified arguments with *no additional syntax needed*. It follows nicely from the standard syntax for type signature declarations (assuming explicit foralls), e.g. the following "normal" datatype declaration data Foo = forall a . Show a => Foo a which uses ExistentialQuantification syntax, could be written as data Foo where Foo :: forall a . Show a => a -> Foo which is syntactically just a normal type signature. The upside of deprecating ExistentialQuantification is thus that we keep the syntax cleaner, and we keep the old style of datatype declarations simple (as it should be, IMO). Anything fancier can use the GADTs syntax, which anyone that uses something fancier should be acquainted with anyway. The downside is that we lose one level of granularity in the type system. GADTs enables a lot more semantic possibilities for constructors than ExistentialQuantification does, and baking the latter into the former means we have no way of specifying that we *only* want to use the capabilities of ExistentialQuantification. My own take on that is that what we have now is a wart that should be removed, and that if we think that the latter is a problem then the way to go would be to split the monolithic GADTs extension into several semantic levels. There is of course also the downside that we break existing code, but that's a standard problem with improvement through deprecation which I will pay no mind. Discussion period: 2 weeks Cheers, /Niklas [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-June/017432.html From ml at isaac.cedarswampstudios.org Sat Jun 27 10:51:12 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Jun 27 10:34:17 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <4A4631E0.7070201@isaac.cedarswampstudios.org> Niklas Broberg wrote: > data Foo = > forall a . Show a => Foo a > > which uses ExistentialQuantification syntax, could be written as > > data Foo where > Foo :: forall a . Show a => a -> Foo > The downside is that we lose one level of granularity in the type > system. GADTs enables a lot more semantic possibilities for > constructors than ExistentialQuantification does, and baking the > latter into the former means we have no way of specifying that we > *only* want to use the capabilities of ExistentialQuantification. Is it easy algorithmically to look at a GADT and decide whether it has only ExistentialQuantification features? After all, IIRC, hugs and nhc support ExistentialQuantification but their type systems might not be up to the full generality of GADTs. (GHC's wasn't even quite up to it for quite a long time until around 6.8, when we finally got it right.) -Isaac From malcolm.wallace at cs.york.ac.uk Sat Jun 27 14:55:30 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Jun 27 14:38:17 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> > I would hereby like to propose that the > ExistentialQuantification extension is deprecated. It is worth pointing out that all current Haskell implementations (to my knowledge) have ExistentialQuantification, whilst there is only one Haskell implementation that has the proposed replacement feature, GADTs. Of course, that in itself is not an argument to avoid desirable change to the language, but it is one factor to consider. Regards, Malcolm From niklas.broberg at gmail.com Sat Jun 27 15:37:30 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sat Jun 27 15:20:16 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> References: <98F04925-50ED-43C0-8C85-FCD54A0FB513@cs.york.ac.uk> Message-ID: >> I would hereby like to propose that the >> ExistentialQuantification extension is deprecated. > > It is worth pointing out that all current Haskell implementations (to my > knowledge) have ExistentialQuantification, whilst there is only one Haskell > implementation that has the proposed replacement feature, GADTs. > > Of course, that in itself is not an argument to avoid desirable change to > the language, but it is one factor to consider. The tongue-in-cheek response is that it should be a factor to consider only for how long a deprecation period we want... ;-) Seriously though, it's of course a consideration that should be made. It also ties back to the problem of the monolithic GADTs extension, which isn't trivial to implement in other tools - but the ExistentialQuantification *subset* of GADTs should be easy, for any implementation that already supports the current ExistentialQuantification extension, since then it's just a syntactic issue. So might as well bite that bullet then, what if we did the following split, in the spirit of the various increasing power of the extensions that enable forall-quantified types ((ExplicitForall <=) PolymorphicComponents <= Rank2Types <= RankNTypes): * NewConstructorSyntax: Lets the programmer write data types using the GADTs *syntax*, but doesn't add any type-level power (and no forall syntax). Could probably use a better name (bikeshed warning). * ExistentialQuantification: Implies NewConstructorSyntax (and ExplicitForall). Let's the programmer use existentially quantified arguments to constructors when using the GADTs syntax. Still requires all constructors to have the same type, which is the one given in the header. * GADTs: Implies ExistentialQuantification. Let's the programmer use the full type-level power of GADTs. It might make sense to merge NewConstructorSyntax and ExistentialQuantification, though I'm not sure naming that merge ExistentialQuantification would be accurate (naming is the bikeshed though). Personally I would prefer the full 3-way split, to keep a clean separation between syntactic and semantic extensions, but it's a rather weak preference. If we had something like this split, implementations that already support ExistentialQuantification at the type level would "only" need to change their parsers in a simple way (nothing hard, trust me), and add what should be a simple check that the constructors all have the declared type. Would that be preferable? Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 03:43:16 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 03:25:59 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: Niklas, > My rationale is as follows. With the introduction of GADTs, we now > have two ways to write datatype declarations, the old simple way and > the GADTs way. The GADTs way fits better syntactically with Haskell's > other syntactic constructs, in all ways. The general style is > (somewhat simplified) "keyword type 'where' decls", where keyword can > in Haskell 98 be class or instance, but with GADTs also data. The old > simple way of defining data types is the odd one out. It certainly has > its uses though, in particular when defining some simple (but possibly > large) enum-like datatype (like cabal's Extension type incidentally), > then it obviously becomes tedious to have to restate the trivial type > signature for each constructor. That's why one should really be allowed to group constructor's in a type's definition: data Colour :: * where Red, Green, Blue :: Colour This is consistent with what is allowed for type signatures for functions. More general, whatever way your proposal is going, I think you should have it reflect that there are two, more or less unrelated, issues here: 1. The expressiveness of data types: algebraic data types < existential data types < GADTs. 2. The syntax of type definitions: the classic, Haskell 98 syntax and the new, cool listings-of-constructor-signature syntax. (Don't call the latter NewTypeSyntax or anything similar in a LANGUAGE pragma; choose something descriptive.) These are really orthogonal issues: all three levels of expressiveness of types can be expressed in either syntax. Therefore: keep these issues separated in your proposal. Just my two cents, Stefan From john at repetae.net Sun Jun 28 04:35:06 2009 From: john at repetae.net (John Meacham) Date: Sun Jun 28 04:17:55 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <4A4631E0.7070201@isaac.cedarswampstudios.org> References: <4A4631E0.7070201@isaac.cedarswampstudios.org> Message-ID: <20090628083505.GB22067@sliver.repetae.net> On Sat, Jun 27, 2009 at 10:51:12AM -0400, Isaac Dupree wrote: > Niklas Broberg wrote: >> data Foo = >> forall a . Show a => Foo a >> >> which uses ExistentialQuantification syntax, could be written as >> >> data Foo where >> Foo :: forall a . Show a => a -> Foo > >> The downside is that we lose one level of granularity in the type >> system. GADTs enables a lot more semantic possibilities for >> constructors than ExistentialQuantification does, and baking the >> latter into the former means we have no way of specifying that we >> *only* want to use the capabilities of ExistentialQuantification. > > Is it easy algorithmically to look at a GADT and decide whether it has > only ExistentialQuantification features? After all, IIRC, hugs and nhc > support ExistentialQuantification but their type systems might not be up > to the full generality of GADTs. (GHC's wasn't even quite up to it for > quite a long time until around 6.8, when we finally got it right.) Jhc also supports ExistentialQuantification but not full GADTs. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From niklas.broberg at gmail.com Sun Jun 28 06:17:08 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 05:59:51 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: > That's why one should really be allowed to group constructor's in a type's > definition: > > ?data Colour :: * where > ? ?Red, Green, Blue :: Colour > > This is consistent with what is allowed for type signatures for functions. Totally agreed, and that should be rather trivial to implement too. > More general, whatever way your proposal is going, I think you should have > it reflect that there are two, more or less unrelated, issues here: > > 1. The expressiveness of data types: algebraic data types < existential data > types < GADTs. > 2. The syntax of type definitions: the classic, Haskell 98 syntax and the > new, cool listings-of-constructor-signature syntax. (Don't call the latter > NewTypeSyntax or anything similar in a LANGUAGE pragma; choose something > descriptive.) > > These are really orthogonal issues: all three levels of expressiveness of > types can be expressed in either syntax. Therefore: keep these issues > separated in your proposal. Well, I think my proposal already does reflect this fact, if implicitly. The point of the proposal is that all three levels of expressiveness of types can be expressed in the listings-of-constructor-signature syntax, but to express the type level power of existential data types or GADTs with the classic syntax, we need to extend that syntax. And that's what I'm after, that's we remove this rather ad-hoc add on syntax required to express existential quantification with classic constructor declarations. In other words, in your 2x3 grid of syntactic x expressiveness, I want the two points corresponding to classic syntax x {existential quantification, GADTs} to be removed from the language. My second semi-proposal also makes each of the three points corresponding to the new cool syntax a separate extension. Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 06:23:24 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 06:06:08 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Niklas, > In other words, in your 2x3 grid of syntactic x expressiveness, I want > the two points corresponding to classic syntax x {existential > quantification, GADTs} to be removed from the language. My second > semi-proposal also makes each of the three points corresponding to the > new cool syntax a separate extension. I see, but why are you opposed to have the classic syntax still support existentials (though foralls) and GADTs (through equality constraints). I would make sense to me to keep this support around. Cheers, Stefan From niklas.broberg at gmail.com Sun Jun 28 06:32:47 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 06:15:29 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: >> In other words, in your 2x3 grid of syntactic x expressiveness, I want >> the two points corresponding to classic syntax x {existential >> quantification, GADTs} to be removed from the language. My second >> semi-proposal also makes each of the three points corresponding to the >> new cool syntax a separate extension. > > I see, but why are you opposed to have the classic syntax still support > existentials (though foralls) and GADTs (through equality constraints). I > would make sense to me to keep this support around. I am opposed since a) it requires the addition of extra syntax to the language, and b) we have another, better, way to do it. Somewhat pointed, I don't think the C++ way of putting all imaginable ways to do the same thing into the language is a sound design principle. If we have two ways to do the same thing, and one of them is considered prefered, then I see no reason at all to keep the other around. What I'm arguing here is that the GADT style syntax is truly preferable, and thus the other should be removed. Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 06:47:28 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 06:30:24 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: Niklas, > I am opposed since > a) it requires the addition of extra syntax to the language, and > b) we have another, better, way to do it. > > Somewhat pointed, I don't think the C++ way of putting all imaginable > ways to do the same thing into the language is a sound design > principle. If we have two ways to do the same thing, and one of them > is considered prefered, then I see no reason at all to keep the other > around. What I'm arguing here is that the GADT style syntax is truly > preferable, and thus the other should be removed. I agree. But ;-) since it's obvious not possible to get rid of the classic syntax completely, I see no harm in having it support existentials and GADTs as well. In an ideal word, in which there wasn't a single Haskell program written yet, I'd indeed like to throw the classic syntax out altogether. Cheers, Stefan On Jun 28, 2009, at 12:32 PM, Niklas Broberg wrote: >>> In other words, in your 2x3 grid of syntactic x expressiveness, I >>> want >>> the two points corresponding to classic syntax x {existential >>> quantification, GADTs} to be removed from the language. My second >>> semi-proposal also makes each of the three points corresponding to >>> the >>> new cool syntax a separate extension. >> >> I see, but why are you opposed to have the classic syntax still >> support >> existentials (though foralls) and GADTs (through equality >> constraints). I >> would make sense to me to keep this support around. > > I am opposed since > a) it requires the addition of extra syntax to the language, and > b) we have another, better, way to do it. > > Somewhat pointed, I don't think the C++ way of putting all imaginable > ways to do the same thing into the language is a sound design > principle. If we have two ways to do the same thing, and one of them > is considered prefered, then I see no reason at all to keep the other > around. What I'm arguing here is that the GADT style syntax is truly > preferable, and thus the other should be removed. > > Cheers, > > /Niklas From niklas.broberg at gmail.com Sun Jun 28 07:17:20 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:00:03 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: > I agree. But ;-) since it's obvious not possible to get rid of the classic > syntax completely, I see no harm in having it support existentials and GADTs > as well. In an ideal word, in which there wasn't a single Haskell program > written yet, I'd indeed like to throw the classic syntax out altogether. Ah, but there's the thing. The classic syntax *doesn't* support existentials and GADTs, if by classic you mean Haskell 98. You need a separate syntactic extension, and the one we have is ad-hoc and unintuitive (the whole universal vs existential quantification thing is awkward), not to mention ugly. There's simply no sense to a declaration reading e.g. > data Foo = forall a . (Show a) => Foo a The entities on the right-hand side of that declaration come in the wrong order, intuitively. What you really want or mean when you use the classic syntax with existential quantification is > data Foo = Foo (exists a . (Show a) => a) Having that would make a lot more sense, and would fit well together with the intuition of the classic syntax. If we wanted to keep support for existential quantification together with the classic style, that should IMNSHO be the way to do it. But for various reasons (like not wanting to steal another keyword) we don't do it that way. Instead we have a syntax that is meant to be understood as "constructor Foo has the type forall a . (Show a) => a". But that's exactly what we would express with the GADT-style syntax! :-) Cheers, /Niklas From niklas.broberg at gmail.com Sun Jun 28 07:19:16 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:01:57 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: > ... "constructor Foo has the type forall a . (Show a) => a". Eh, of course I meant "the type forall a . (Show a) => a -> Foo", but you understood that I'm sure. :-) Cheers, /Niklas From stefan at cs.uu.nl Sun Jun 28 07:24:53 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Sun Jun 28 07:07:37 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> Message-ID: <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> Niklas, > What you really want or mean when you use > the classic syntax with existential quantification is > >> data Foo = Foo (exists a . (Show a) => a) > > Having that would make a lot more sense, and would fit well together > with the intuition of the classic syntax. How would you then define data Foo :: * where Foo :: forall a. a -> a -> Foo in which the scope of existentially quantified type variable spans more than one field? Cheers, Stefan From niklas.broberg at gmail.com Sun Jun 28 07:31:22 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Jun 28 07:14:05 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> Message-ID: >> What you really want or mean when you use >> the classic syntax with existential quantification is >> >>> data Foo = Foo (exists a . (Show a) => a) >> >> Having that would make a lot more sense, and would fit well together >> with the intuition of the classic syntax. > > How would you then define > > ?data Foo :: * where > ? ?Foo :: forall a. a -> a -> Foo > > in which the scope of existentially quantified type variable spans more than > one field? Good point, and one I admit I hadn't considered. Using GADT style syntax? ;-) However, your argument certainly speaks against the style using exists, but it doesn't do much to persuade me that the style we now have is any less of a wart. To me it's just another point in favor of deprecating it with the classic syntax completely. Cheers, /Niklas From svein.ove at aas.no Sun Jun 28 17:21:34 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Sun Jun 28 17:04:17 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: <228C1E05-3176-442B-A346-A02D7C0A93BA@cs.uu.nl> <92F5A2B7-E022-46F6-9CE5-119D30D113C1@cs.uu.nl> Message-ID: <221b53ab0906281421r46845a1cq38189acd30566b8a@mail.gmail.com> While I agree in principle that GADTs are the way forward, I have to vote against deprecating anything using the existing syntax in any kind of a hurry. There are syntactic extensions which don't (yet?) work with GADTs that I am loathe to lose, even if they do leave a lot to be desired. Not that I have any real suggestions on what to replace them with, but I think it'd be a good idea to settle that now, before implementing the code that would anyhow need to handle it in half a dozen Haskell implementations. Well, I suppose that's my cue to start noting down ideas. Such a fascinating topic, theorizing about language extensions... -- Svein Ove Aas From simonpj at microsoft.com Mon Jun 29 03:42:02 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jun 29 03:24:45 2009 Subject: Proposal: Deprecate ExistentialQuantification In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3439152691B@EA-EXMSG-C334.europe.corp.microsoft.com> | That's why one should really be allowed to group constructor's in a | type's definition: | | data Colour :: * where | Red, Green, Blue :: Colour Indeed. GHC allows this now. (HEAD only; will be in 6.12.) Simon