From simonpj at microsoft.com Tue Aug 1 12:52:29 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 1 12:41:50 2006 Subject: [Template-haskell] Internal type consistency of quoted expressions In-Reply-To: <20060731212554.GA17878@matrix.chaos.earth.li> References: <3a3c7cee0607280432k361d9ff3p2f374596d754f110@mail.gmail.com> <20060731212554.GA17878@matrix.chaos.earth.li> Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116062414F0@EUR-MSG-21.europe.corp.microsoft.com> Some quick replies | [2] I am sane, right? I mean, is there any other reason for the | internal type-consistency check other than to detect /potential/ | errors /earlier/? Quite correct. But detecting errors earlier, perhaps much, much earlier, is a Good Thing, right? | I actually proposed something similar way back: | http://www.haskell.org//pipermail/template-haskell/2003-April/000048.htm l | for specifying rewrite rules which weren't all type correct in | themselves, but the total effect of fully applying them all was type | safe. I didn't push it much as it wasn't that important to me and no-one | else seemed interested (plus it felt a bit hackish). Your proposal seems entirely reasonable to me. By not typechecking the quotation at all, it pushes towards the extreme of more flexibility but later error reporting. (MetaML is at the other extreme.) And if that is what you want, it seems like a reasonable thing to me. If you want to commit a patch that does it, go ahead. Please document the change in the manual; and perhaps add a section on the TH wiki page to explain what it's good for. I don't hear a lot about TH these days, but occasionally I hear people saying "I used TH to do X or Y". So I think that is good news; it works well enough to be useful. But I'm sure it could be better in many ways. Simon From igloo at earth.li Fri Aug 11 18:25:02 2006 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 11 18:13:49 2006 Subject: [Template-haskell] GADTs Message-ID: <20060811222502.GA6816@matrix.chaos.earth.li> Hi all, Currently we do not have GADT support in Template Haskell, but I need it for something I'm working on. The relevant datastructures currently look like this: data Dec = ... | DataD Cxt Name [Name] [Con] [Name] | ... data Con = NormalC Name [StrictType] | RecC Name [VarStrictType] | InfixC StrictType Name StrictType | ForallC [Name] Cxt Con I propose altering Dec thus: data Dec = ... | DataD Cxt Name [Name] Cons [Name] | ... (changing [Con] to Cons) and adding new datastructures: data Cons = NormalCons [Con] | GadtCons [GadtCon] deriving( Show, Eq ) data GadtCon = GadtC [Name] Cxt Name [StrictType] Type deriving( Show, Eq ) (this follows the style used to add pattern guards to the datastructures). Complete patches for GHC and the template-haskell library are at http://urchin.earth.li/~ian/th-gadts/ If you have any objections or comments then please let me know; otherwise I think it would be great to get this into GHC 6.6. Thanks Ian From ekarttun at cs.helsinki.fi Sat Aug 12 03:26:06 2006 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Sat Aug 12 03:10:52 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060811222502.GA6816@matrix.chaos.earth.li> References: <20060811222502.GA6816@matrix.chaos.earth.li> Message-ID: <20060812072606.GA30039@localdomain> On 11.08 23:25, Ian Lynagh wrote: > If you have any objections or comments then please let me know; > otherwise I think it would be great to get this into GHC 6.6. Why not simple represent all data declarations as GADT to the user? Generally TH code should not care between: data Foo = Foo Int and data Foo where Foo :: Int -> Foo data B = forall Show x. B x and data B where B :: Show a => a -> B But any way to support GADTs would be better than the current situation. - Einar Karttunen From igloo at earth.li Sat Aug 12 05:26:12 2006 From: igloo at earth.li (Ian Lynagh) Date: Sat Aug 12 05:15:04 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060812072606.GA30039@localdomain> References: <20060811222502.GA6816@matrix.chaos.earth.li> <20060812072606.GA30039@localdomain> Message-ID: <20060812092612.GA18533@matrix.chaos.earth.li> On Sat, Aug 12, 2006 at 10:26:06AM +0300, Einar Karttunen wrote: > On 11.08 23:25, Ian Lynagh wrote: > > If you have any objections or comments then please let me know; > > otherwise I think it would be great to get this into GHC 6.6. > > Why not simple represent all data declarations as GADT to the user? Because GADTs cannot represent record constructors. I didn't make GadtC a constructor for Con as I don't think you could pretty-print a datatype with both GADT and record constructors. Also, TH tries to present the completely sugared language to the user; otherwise it would probably work on something more like core. Thanks Ian From ekarttun at cs.helsinki.fi Sat Aug 12 07:50:55 2006 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Sat Aug 12 07:36:04 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060812092612.GA18533@matrix.chaos.earth.li> References: <20060811222502.GA6816@matrix.chaos.earth.li> <20060812072606.GA30039@localdomain> <20060812092612.GA18533@matrix.chaos.earth.li> Message-ID: <20060812115055.GA30508@localdomain> On 12.08 10:26, Ian Lynagh wrote: > On Sat, Aug 12, 2006 at 10:26:06AM +0300, Einar Karttunen wrote: > > On 11.08 23:25, Ian Lynagh wrote: > > > If you have any objections or comments then please let me know; > > > otherwise I think it would be great to get this into GHC 6.6. > > > > Why not simple represent all data declarations as GADT to the user? > > Because GADTs cannot represent record constructors. I didn't make GadtC > a constructor for Con as I don't think you could pretty-print a > datatype with both GADT and record constructors. GHC 6.5 does support that. http://www.haskell.org/hawiki/GADT_20with_20record_20syntax > Also, TH tries to present the completely sugared language to the user; > otherwise it would probably work on something more like core. > Point. Usually when using TH I *wish* it was more like core - or that there would be at least a way to simplify expressions. - Einar Karttunen From bulat.ziganshin at gmail.com Sat Aug 12 08:50:33 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Aug 12 13:15:04 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060812115055.GA30508@localdomain> References: <20060811222502.GA6816@matrix.chaos.earth.li> <20060812072606.GA30039@localdomain> <20060812092612.GA18533@matrix.chaos.earth.li> <20060812115055.GA30508@localdomain> Message-ID: <487407267.20060812165033@gmail.com> Hello Einar, Saturday, August 12, 2006, 3:50:55 PM, you wrote: > Point. Usually when using TH I *wish* it was more like core - > or that there would be at least a way to simplify expressions. it may be written as lib. you already implemented something of this kind in SerTH (and i borrowed this code :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon Aug 14 04:51:08 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 14 04:39:50 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060812092612.GA18533@matrix.chaos.earth.li> References: <20060811222502.GA6816@matrix.chaos.earth.li><20060812072606.GA30039@localdomain> <20060812092612.GA18533@matrix.chaos.earth.li> Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> | Also, TH tries to present the completely sugared language to the user; | otherwise it would probably work on something more like core. This really is a tension, and one I don't really know how to resolve. GHC does represent fully-sugared syntax, including even the placement of parens. I don't think TH need go to these lengths. TH generates code that we might read, but which is mainly intended to be compiled. It's *also* intended to be processed by other TH code, so the smaller the TH data type, the better. I conclude that TH should avoid gratuitous syntactic sugar. Anything that can be converted to a simpler equivalent form, should be. Hence I rather think that infix operators in TH are a mistake. What do they really buy us? Similarly an if-expression, and arithmetic sequence, and list expressions. On the other hand, a list comprehension is much more complicated to desugar, so probably deserves to be there. It'd be good to discuss this and perhaps agree some changes. Concerning data types, I think it'd be fine to present data types in a single, canonical representation as a data type, probably something like the GADT style. That'd be a breaking change, mind you. Because there are design choices here, I'm dubious about getting any of this into 6.6. Time is very short, and we don't want to make a change that we re-change later. Simon From bulat.ziganshin at gmail.com Mon Aug 14 06:07:01 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 14 06:16:33 2006 Subject: [Template-haskell] GADTs In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> References: <20060811222502.GA6816@matrix.chaos.earth.li><20060812072606.GA30039@localdomain> <20060812092612.GA18533@matrix.chaos.earth.li> <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <1974943363.20060814140701@gmail.com> Hello Simon, Monday, August 14, 2006, 12:51:08 PM, you wrote: > I don't think TH need go to these lengths. TH generates code that we > might read, but which is mainly intended to be compiled. It's *also* > intended to be processed by other TH code, so the smaller the TH data > type, the better. i propose to place this question into more global frame - what is a TH unique place among other Haskell extensions? imho, TH is (at least) an attempt to develop macro-preprocessing feature that is able to accomplish tasks in ways not accessible to the bare language this means that TH competes with such tools as Lisp macros and C preprocessor. and imho, TH should evolve in the way that will eventually allow to include it in the Haskell standard. this means, in particular, that we should divide it into Haskell-compatible features and GHC extensions second, it will be interesting to implement TH as true preprocessing tool generating Haskell code that can be compiled by any *hc third, as you said, TH should simplify two different tasks - analyzing of existing Haskell code and generating new one. For that, we can allow to use full Haskell/GHC power in code constructed by user functions but at the same time pass to these functions already desugared code; i.e. make input data as simple as possible while allow to use in output data as much features as one want another solution will be implementing desugaring functions that accepts full-fledged Exp/Dec/... and returns desugared one. this solution don't need any changes in existing code and can be implemented without any changes to core TH implementation, it's just additional user-level functions > I conclude that TH should avoid gratuitous syntactic sugar. Anything > that can be converted to a simpler equivalent form, should be. Hence I > rather think that infix operators in TH are a mistake. What do they > really buy us? Similarly an if-expression, and arithmetic sequence, and > list expressions. On the other hand, a list comprehension is much more > complicated to desugar, so probably deserves to be there. > It'd be good to discuss this and perhaps agree some changes. > Concerning data types, I think it'd be fine to present data types in a > single, canonical representation as a data type, probably something like > the GADT style. That'd be a breaking change, mind you. this will break almost all existing TH programs, made Dec ghc-specific and require incompatible changes that we should wait until ghc 6.8 on the other side, adding new variant to existing Dec type is obvious. one can then write desugarer that turns any type definition into GADT one so i propose to keep TH declarations a mirror of official H98 syntax, add new variants for GHC-specific extensions, and implement desugaring functions to simplify TH usage. at the last end, we can got official H2098 report where Haskell syntax defined in terms of Haskell data structures and desugarer as Haskell program :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ekarttun at cs.helsinki.fi Mon Aug 14 09:28:08 2006 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Mon Aug 14 09:15:42 2006 Subject: [Template-haskell] GADTs In-Reply-To: <1974943363.20060814140701@gmail.com> References: <20060812092612.GA18533@matrix.chaos.earth.li> <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> <1974943363.20060814140701@gmail.com> Message-ID: <20060814132808.GA21123@localdomain> On 14.08 14:07, Bulat Ziganshin wrote: > this means that TH competes with such tools as Lisp macros and C preprocessor. > and imho, TH should evolve in the way that will eventually allow to > include it in the Haskell standard. this means, in particular, that > we should divide it into Haskell-compatible features and GHC > extensions Having a generic Dec that supports GADT in the most general form possible would be good for standardization. Each implementation would only generate the subset of legal definitions in that implementation and complain if the user tried to use more generic ones. All standard data declarations can be easily expressed as a GADT. This would make code work easier in different compilers with different extensions. > third, as you said, TH should simplify two different tasks - analyzing > of existing Haskell code and generating new one. For that, we can > allow to use full Haskell/GHC power in code constructed by user > functions but at the same time pass to these functions already > desugared code; i.e. make input data as simple as possible while allow > to use in output data as much features as one want Simple datatypes + intelligent constructors. > another solution will be implementing desugaring functions that > accepts full-fledged Exp/Dec/... and returns desugared one. this > solution don't need any changes in existing code and can be > implemented without any changes to core TH implementation, it's just > additional user-level functions This means that pattern matching will be always incomplete - which is not nice. > this will break almost all existing TH programs, made Dec > ghc-specific and require incompatible changes that we should wait > until ghc 6.8 Dec is already GHC-specific. I agree that 6.6 is too soon. > on the other side, adding new variant to existing Dec type is > obvious. one can then write desugarer that turns any type definition > into GADT one The more variants we add the harder using TH comes. Just version the package and keep an old version installed alongside the new one. Thus old libraries will be fine. > so i propose to keep TH declarations a mirror of official H98 syntax, > add new variants for GHC-specific extensions, and implement desugaring > functions to simplify TH usage. at the last end, we can got official > H2098 report where Haskell syntax defined in terms of Haskell data > structures and desugarer as Haskell program :) TH has never been H98. I think we should have the actual datatypes as simple as possible to make pattern matching easy. Providing intelligent constructor functions to support language constructs should be the way. - Einar Karttunen From bulat.ziganshin at gmail.com Mon Aug 14 10:17:25 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 14 10:23:42 2006 Subject: [Template-haskell] GADTs In-Reply-To: <20060814132808.GA21123@localdomain> References: <20060812092612.GA18533@matrix.chaos.earth.li> <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> <1974943363.20060814140701@gmail.com> <20060814132808.GA21123@localdomain> Message-ID: <1946790252.20060814181725@gmail.com> Hello Einar, Monday, August 14, 2006, 5:28:08 PM, you wrote: > Having a generic Dec that supports GADT in the most general form > possible would be good for standardization. Each implementation > would only generate the subset of legal definitions in that > implementation and complain if the user tried to use more > generic ones. > All standard data declarations can be easily expressed as a GADT. > This would make code work easier in different compilers with > different extensions. this looks fine except that ghc-specific language facilities will be exposed to other compilers > Simple datatypes + intelligent constructors. good alternative. i agree that this is the better. except perhaps for situations when one want to know exact syntax what was used in some Haskell code. but is anyone need this? >> another solution will be implementing desugaring functions that >> accepts full-fledged Exp/Dec/... and returns desugared one. this >> solution don't need any changes in existing code and can be >> implemented without any changes to core TH implementation, it's just >> additional user-level functions > This means that pattern matching will be always incomplete - which > is not nice. yes, it's not ideal solution. but adding new features to language and mirroring them in TH datatypes also makes old code incomplete ;) >> this will break almost all existing TH programs, made Dec >> ghc-specific and require incompatible changes that we should wait >> until ghc 6.8 > Dec is already GHC-specific. I agree that 6.6 is too soon. i propose to drive TH into the direction of making general Haskell utility that at some moment may become part of the official language instead of increasing this incompatibility >> on the other side, adding new variant to existing Dec type is >> obvious. one can then write desugarer that turns any type definition >> into GADT one > The more variants we add the harder using TH comes. Just version > the package and keep an old version installed alongside the new > one. Thus old libraries will be fine. i'm not sure that this will work with TH, which needs compiler support. Is GHC 6.8 should support generation of ASTs for all TH versions ever developed? :) >> so i propose to keep TH declarations a mirror of official H98 syntax, >> add new variants for GHC-specific extensions, and implement desugaring >> functions to simplify TH usage. at the last end, we can got official >> H2098 report where Haskell syntax defined in terms of Haskell data >> structures and desugarer as Haskell program :) > TH has never been H98. i propose to drive it into this direction. Of course, it will not become even part of H' standard, but at least making TH subset that supports current Haskell standard will be a good step toward TH standardization and making it available for other compilers > I think we should have the actual datatypes > as simple as possible to make pattern matching easy. Providing > intelligent constructor functions to support language constructs > should be the way. yes, that's great and, i think that adding TH constructs for all new language features in 6.6 is really important for all TH developers. otherwise, we will be like one-armed invalid. if SPJ don't want to change TH datatypes after 6.6 release, it should be done just now -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon Aug 14 10:43:25 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 14 10:32:05 2006 Subject: [Template-haskell] GADTs In-Reply-To: <1946790252.20060814181725@gmail.com> References: <20060812092612.GA18533@matrix.chaos.earth.li><036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com><1974943363.20060814140701@gmail.com><20060814132808.GA21123@localdomain> <1946790252.20060814181725@gmail.com> Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116063DA177@EUR-MSG-21.europe.corp.microsoft.com> | and, i think that adding TH constructs for all new language features | in 6.6 is really important for all TH developers. otherwise, we will | be like one-armed invalid. if SPJ don't want to change TH datatypes | after 6.6 release, it should be done just now Quite the reverse. I think it's dangerous to fiddle just now, because there is only a matter of days before 6.6 is fixed. But after 6.6 we can review the data types and change them if there's a consensus. The exact design isn't something about which I feel strongly, apart from the principle in my previous message (avoiding gratuitous sugar) Simon From robdockins at fastmail.fm Mon Aug 14 11:34:19 2006 From: robdockins at fastmail.fm (Robert Dockins) Date: Mon Aug 14 11:10:57 2006 Subject: [Template-haskell] GADTs In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> References: <20060811222502.GA6816@matrix.chaos.earth.li><20060812072606.GA30039@localdomain> <20060812092612.GA18533@matrix.chaos.earth.li> <036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <9FCC5396-88D2-4830-A68C-57757D733214@fastmail.fm> On Aug 14, 2006, at 4:51 AM, Simon Peyton-Jones wrote: > | Also, TH tries to present the completely sugared language to the > user; > | otherwise it would probably work on something more like core. > > This really is a tension, and one I don't really know how to resolve. > > GHC does represent fully-sugared syntax, including even the > placement of > parens. > > I don't think TH need go to these lengths. TH generates code that we > might read, but which is mainly intended to be compiled. It's *also* > intended to be processed by other TH code, so the smaller the TH data > type, the better. > > I conclude that TH should avoid gratuitous syntactic sugar. Anything > that can be converted to a simpler equivalent form, should be. > Hence I > rather think that infix operators in TH are a mistake. What do they > really buy us? Similarly an if-expression, and arithmetic > sequence, and > list expressions. On the other hand, a list comprehension is much > more > complicated to desugar, so probably deserves to be there. > > It'd be good to discuss this and perhaps agree some changes. > > Concerning data types, I think it'd be fine to present data types in a > single, canonical representation as a data type, probably something > like > the GADT style. That'd be a breaking change, mind you. I'd just like to voice my agreement with this general idea. I might even suggest going one step further; divorce the world of TH from the Haskell front end altogether. Specify that TH operates in a convenient core language which is general enough to cover all the interesting haskell extensions (say, Fc http://research.microsoft.com/ %7Esimonpj/papers/ext%2Df/). Then, various implementations of TH can simply differ in the TH programs they accept (eg, a pure H98 impl might only accept the Fc fragment with sort TY). But I think the important thing is to specify TH in a way that is at least somewhat independent of other haskell extensions. Of course, the devil's in the details... > Because there are design choices here, I'm dubious about getting > any of > this into 6.6. Time is very short, and we don't want to make a change > that we re-change later. > > Simon Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG From bulat.ziganshin at gmail.com Mon Aug 14 11:22:06 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 14 12:27:16 2006 Subject: [Template-haskell] GADTs In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116063DA177@EUR-MSG-21.europe.corp.microsoft.com> References: <20060812092612.GA18533@matrix.chaos.earth.li><036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com><1974943363.20060814140701@gmail.com><20060814132808.GA21123@localdomain> <1946790252.20060814181725@gmail.com> <036EAC76E7F5EC4996A3B3C3657D4116063DA177@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <386430724.20060814192206@gmail.com> Hello Simon, Monday, August 14, 2006, 6:43:25 PM, you wrote: > | and, i think that adding TH constructs for all new language features > | in 6.6 is really important for all TH developers. otherwise, we will > | be like one-armed invalid. if SPJ don't want to change TH datatypes > | after 6.6 release, it should be done just now > Quite the reverse. I think it's dangerous to fiddle just now, because > there is only a matter of days before 6.6 is fixed. But after 6.6 we > can review the data types and change them if there's a consensus. The > exact design isn't something about which I feel strongly, apart from the > principle in my previous message (avoiding gratuitous sugar) i hope that you will include this in 6.6.1 despite the fact that it backward incompatible change? otherwise, postponing using of GADTs with TH until 6.8 will be not so great.. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon Aug 14 13:01:31 2006 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 14 12:50:12 2006 Subject: [Template-haskell] GADTs In-Reply-To: <386430724.20060814192206@gmail.com> References: <20060812092612.GA18533@matrix.chaos.earth.li><036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com><1974943363.20060814140701@gmail.com><20060814132808.GA21123@localdomain> <1946790252.20060814181725@gmail.com> <036EAC76E7F5EC4996A3B3C3657D4116063DA177@EUR-MSG-21.europe.corp.microsoft.com> <386430724.20060814192206@gmail.com> Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116063DA24A@EUR-MSG-21.europe.corp.microsoft.com> Patch-level releases *never* change interfaces, so we can't do this in 6.6.1. It's a pity all this has come up days before the 6.6 freeze. It's a year since 6.4 came out, so there's been plenty of time! There are always more things to put in, so one has to stop somewhere. You can argue, if you like, to delay 6.6 by a month. But we don't even know how long it would take to have the design discussion Simon | -----Original Message----- | From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] | Sent: 14 August 2006 16:22 | To: Simon Peyton-Jones | Cc: Bulat Ziganshin; Einar Karttunen; template-haskell@haskell.org | Subject: Re[4]: [Template-haskell] GADTs | | Hello Simon, | | Monday, August 14, 2006, 6:43:25 PM, you wrote: | | > | and, i think that adding TH constructs for all new language features | > | in 6.6 is really important for all TH developers. otherwise, we will | > | be like one-armed invalid. if SPJ don't want to change TH datatypes | > | after 6.6 release, it should be done just now | | > Quite the reverse. I think it's dangerous to fiddle just now, because | > there is only a matter of days before 6.6 is fixed. But after 6.6 we | > can review the data types and change them if there's a consensus. The | > exact design isn't something about which I feel strongly, apart from the | > principle in my previous message (avoiding gratuitous sugar) | | i hope that you will include this in 6.6.1 despite the fact that it | backward incompatible change? otherwise, postponing using of GADTs | with TH until 6.8 will be not so great.. | | | | -- | Best regards, | Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Aug 14 13:26:59 2006 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 14 13:19:18 2006 Subject: [Template-haskell] GADTs In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116063DA24A@EUR-MSG-21.europe.corp.microsoft.com> References: <20060812092612.GA18533@matrix.chaos.earth.li><036EAC76E7F5EC4996A3B3C3657D41160635FE1A@EUR-MSG-21.europe.corp.microsoft.com><1974943363.20060814140701@gmail.com><20060814132808.GA21123@localdomain> <1946790252.20060814181725@gmail.com> <036EAC76E7F5EC4996A3B3C3657D4116063DA177@EUR-MSG-21.europe.corp.microsoft.com> <386430724.20060814192206@gmail.com> <036EAC76E7F5EC4996A3B3C3657D4116063DA24A@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <889427324.20060814212659@gmail.com> Hello Simon, Monday, August 14, 2006, 9:01:31 PM, you wrote: > Patch-level releases *never* change interfaces, so we can't do this in > 6.6.1. > It's a pity all this has come up days before the 6.6 freeze. It's a > year since 6.4 came out, so there's been plenty of time! There are > always more things to put in, so one has to stop somewhere. > You can argue, if you like, to delay 6.6 by a month. But we don't even > know how long it would take to have the design discussion well, i never mind to stay between you and your release date. it's like staying between bullet and it's target :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Rene_de_Visser at hotmail.com Thu Aug 24 15:43:23 2006 From: Rene_de_Visser at hotmail.com (Rene de Visser) Date: Thu Aug 24 15:38:22 2006 Subject: [Template-haskell] Small TH demo: generating instances Message-ID: I am hoping that this example is small, simple and well commented enough to help people generate instances with TH. The instance generation is used to create instances to render haskell code to TH code that generates the original haskell code. there is an example in Test.hs The instance generation function is in Base.hs. TH_Render.hs is where the instances are derived. Rene. begin 666 TH_render.hs M>RTC($]05$E/3E,@+69G;&%S9V]W+65X=',@+69T:" C+7T-"GLM(R!/4%1) M3TY3("UF86QL;W6YT87@-"@T*:6UP;W)T(%1(7W1O;VQS+D)A2!N M=6UB97(@;V8@87)G=65M96YT' @82!R('=H97)E#0H@(" @8G5I;&0G(#HZ($AS17AP("T^(&$@ M+3X@<@T*#0II;G-T86YC92 H5$A?4F5N9&5R(&$I(#T^($)U:6QD2'-%>' @ M82!(' @8B!R*2 ]/B!"=6EL9$AS17AP(&$@*&(M M/G(I('=H97)E#0H@(" @8G5I;&0G(&P@>"!Y(#T@8G5I;&0G("A("DI("!Y#0H-"B M+6)U:6QD(#HZ(&9O" ](&)U:6QD M)R H9G5N8U]O=70@9G5N8RD@> T*#0IF=6YC7V]U="!F(#T@2'-687(@)"!5 M;E%U86P@)"!(2!W:&5R90T*(" @' -"B @(')E;F1E7!E*2!W:&5R90T* M("!R96YD97(@*&YA;64L('-T7!E(&YA;64@*'-T6)E($5X<"D@=VAE7!E M*2!W:&5R90T*("!R96YD97(@*'-T7!E('-T7 -"@T*:6YS=&%N8V4@5$A?4F5N9&5R("A'=6%R M9"P@17AP*2!W:&5R90T*(" @' L(&5X<"D@ M/2!B=6EL9" G;F]R;6%L1T4@9V5X<"!E>' -"B @(')E;F1E'1S(#T@2'-0 M87)E;B D("AF=6YC7V]U=" G8WAT*2!@2'-!<'!@("A(RTC($]05$E/3E,@+69G;&%S9V]W+65X=',@+69T:" C+7T-"FUO9'5L92!4 M2%]T;V]L6YT87@-"@T*:6UP M;W)T($1A=&$N0VAA<@T*#0II;G-T86YC92!3:&]W($EN9F\@=VAE7!E26YF;R!M(#T-"B @(" @9&\@9" \+2!M#0H@(" @ M(" @(&-A7!E1"!?(%\@7R!C(%\I(#T@6R!T97)M02!C(%T-"@T*(" @(" @("!T97)M M02 H3F]R;6%L0R!C('AS*2 @(" @(" @/2 H8RP@;6%P("A<>" M/B H3F]T M:&EN9RP@',I(" @(" @(" @(" @/2 H',I#0H@(" @(" @(&-O;D$@*$EN9FEX0R!?(&,@7RD@(" @(" @ M(" ]("AS:6UP;&5.86UE(&,L(#(I#0H-"B @(" @(" @;F%M92 H1&%T840@ M7R!N(%\@7R!?*2 @(" @(#T@;@T*(" @(" @("!N86UE("A.97=T>7!E1"!? M(&X@7R!?(%\I(" @/2!N#0H@(" @(" @(&YA;64@9" @(" @(" @(" @(" @ M(" @(" @(" ](&5R7!E($9U;F-?;F%M92 ]($YA;64-"G1Y<&4@0V]N7!E*5TI#0IT>7!E($-O;G-? M=F%R'!170T*='EP92!&=6YC=&EO;E]B;V1Y(#T@17AP40T*='EP M92!'96Y?9G5N8R ]($-O;G-T7!E($9U;F-S(#T@6RA&=6YC7VYA;64L($=E;E]F=6YC M*5T@#0H-"BTM(&-O;G-T7!E(&9O7!E#0HM+2!F=6YC7!E*0T*(" @ M("AM87 @9G5N8U]D968@9G5N8W,I( T*(" @(" @=VAE'!172 M/B!%>'!1 M*2 M/B!#;VYS=')U8W1O2!D871A7V-O;D H8V]N7VYA;64L(&-O;7!O;F5N=',I(#T@#0H@(" @ M(" M+2!C2D@/2 H=&],;W=EF4@ M.CH@6T-H87)=("T^(%M#:&%R70T*=6Y#87!A;&EZ92 H>#IY*2 ]("AT;TQO M=V5R('@I.GD-"@T*+2T@1V5N97)A=&4@86X@:6YT86YC92!O9B!T:&4@8VQA M7!.86UE#0IG96Y?7!.86UE(#T-"B @ M9&\@*%1Y0V]N22!D*2 \+2!R96EF>2!T>7!.86UE("TM($=E="!A;&P@=&AE M(&EN9F]R;6%T:6]N(&]N('1H92!T>7!E#0H@(" @("AT>7!E7VYA;64L7RQ? M+&-O;G-TRTC($]05$E/3E,@+69G;&%S9V]W+65X=',@+69T:" C+7T-"FUO9'5L92!4 M2%]T;V]L6YT87@-"@T*:6UP M;W)T($QA;F=U86=E+DAA7!E(%1E#,@/2 D*&1O(&]U=" \+2 @='EP95]C;VUP7!E(%1EC4@/2!;9'P@>" ](#%\70T*>C8@/2!P2!Z('HI(@T*<#0@/2!P87)S94UO9'5L92 B M>2 ](%LQ+#(L,UTB#0H-"G R("A087)S94]K(' I(#T@<')E='1Y4')I;G0@ M< T*#0IP,R ](' R(' Q#0H-"G(Q(#HZ(%$@26YF;PT*2 G M)T1E8PT*" ]("0H2 G)T1E8R @/CX](&QI9G0@+B!S M:&]W("X@='EP94EN9F\@+B!T>6-O;FDI#0H-"G@T(#T@)"AD;R H5'E#;VY) M(&0I(#PM(')E:69Y("C@@/2!P"D@/2!(2D@/2!("D@?%T-"BTM(&]U M='!U="!O9B!F=6YC=&EO;B!Z. T*)"AS97%U96YC92!;*&EN Hello I remember someone having written a small utility to preprocess a Haskell source file with TH definitions and generate a new file with the TH bits replaced by their resulting slices. If anyone knows the utility or a way to do this pointers would be nice. I am trying to use Haddock to create documentation, but datatypes are created with TH... - Einar Karttunen From lemmih at gmail.com Wed Aug 30 18:00:43 2006 From: lemmih at gmail.com (Lemmih) Date: Wed Aug 30 17:48:30 2006 Subject: [Template-haskell] Tool to preprocess template haskell definitions? In-Reply-To: <20060830214840.GA5437@localdomain> References: <20060830214840.GA5437@localdomain> Message-ID: On 8/30/06, Einar Karttunen wrote: > Hello > > I remember someone having written a small utility > to preprocess a Haskell source file with TH definitions > and generate a new file with the TH bits replaced > by their resulting slices. > > If anyone knows the utility or a way to do this > pointers would be nice. I am trying to use > Haddock to create documentation, but datatypes > are created with TH... http://darcs.haskell.org/~lemmih/zerothHead/ I'm not sure if it has bitrotted, tho. -- Cheers, Lemmih From ekarttun at cs.helsinki.fi Wed Aug 30 20:58:08 2006 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Wed Aug 30 20:45:37 2006 Subject: [Template-haskell] Fix pprinting global names Message-ID: <20060831005808.GA7492@localdomain> Hello The recent commit added package names to pprinting global names. The attached patch reverts that - which is nice for actually using the pprinted representation and agrees with the comments in the file. e.g. base:GHC.Show.Show -> GHC.Show.Show Patch attached. - Einar Karttunen -------------- next part -------------- New patches: [Omit package names when pretty-printing Names. Einar Karttunen **20060831005500] { hunk ./Language/Haskell/TH/Syntax.hs 423 - show (Name occ (NameG ns p m)) = pkgString p ++ ":" ++ modString m - ++ "." ++ occString occ + show (Name occ (NameG ns p m)) = modString m ++ "." ++ occString occ } Context: [bump version to 2.0 Simon Marlow **20060811152924] [Improve pretty-printing for Template Haskell simonpj@microsoft.com**20060807093127 Fixes Trac #842 ] [Add Show instances simonpj@microsoft.com**20060622102114] [Fix a bug in mkName; merge to STABLE simonpj@microsoft.com**20060622101910 The little qualified-name parser inside mkName was mis-parsing names like ".&." (which is exported by Data.Bits). This commit fixes the problem. It should merge into 6.3 ] [Modifications required by the changes to package support in GHC Simon Marlow **20060725141918 A NameG now needs to store the package name, too. ] [Drop dependency to haskell98 package Einar Karttunen **20060209224626] [TAG Initial conversion from CVS complete John Goerzen **20060112154138] Patch bundle hash: a046baddb1616f25be77e4a2c6aa7b9cf03188c4