February 2003 - template-haskell

instance declaration issue
by Derek Elkins 13 Feb '03

13 Feb '03

Generating a set of pattern matched function declarations in an instance declaration (see below) causes a "Conflicting definition error" upon linking. instance (G a) => F (Tree a) where f (Leaf x) = g x f (Branch x y) = g x `h` g y rewritten as instance (G a) => F (Tree a) where f x = case x of Leaf x -> g x Branch x y -> g x `h` g y works. I suspect that it has to do with the "level" the source code is considered. I.e. the transformation from the above into the below is already considered done by the compiler. The problem (it it's a problem) may be in the way I'm generating the code. If you can't get it to happen, I'll email my code. _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

RE: [Template-haskell] Contexts on Datatype - question/bug?
by Derek Elkins 13 Feb '03

13 Feb '03

>| On a side note: why not toss up a TH page on the Haskell wiki, >especially if >| the answer to my second question is no? > >by all means go ahead. Consider it done: http://www.haskell.org/wiki/wiki?TemplateHaskell It's pretty sparse now. >| data (Eq a) => Tree a = Leaf a | Branch (Tree a) (Tree a) >| >| main = do output <- runQ $ reifyDecl Tree >| putStr $ show output >| >| will cause the impossible to happen. >| I went in and changed DsMeta.hs to pass the cxt for reifyDecl >(repTyClD for >| case TyData), which kept the impossible from happening, but then >realized >| (at least partially) why it wasn't there before. THSyntax.Data >doesn't >| support contexts. >| >| Except that a diagnostic rather than death would be preferable, is >this an >| omission, on a todo list, or purposely left out? > >I think Contexts in data declarations are a mis-feature of Haskell (i.e. >they shouldn't be there in the first place). But I suppose that since >they are there, TH had better support them. To do! > >Simon I suspected something like that (hence suggesting purposely left out). This isn't anything that was causing me problems. If no one else wants it, I'd be more than content with just an explanatory warning message: "warning: contexts on datatypes not supported just because" ;). Or just silently accept them. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

RE: [Template-haskell] Contexts on Datatype - question/bug?
by Simon Peyton-Jones 13 Feb '03

13 Feb '03

| Also, is there a todo-list | somewhere or a document with a fairly comprehensive listing of how far along | the implementation is and known bugs? There isn't, but it's a good idea. Here's a start http://research.microsoft.com/~simonpj/Haskell/TH.html Pls suggest improvements I'd put it in the GHC Commentary, only that isn't being updated at the moment for some reason. (Manuel will doubtless fix that shortly.) [urk: I'm not sure our website mirroring is working right either; if the link doesn't work, try again in a few hrs.] | On a side note: why not toss up a TH page on the Haskell wiki, especially if | the answer to my second question is no? by all means go ahead. | data (Eq a) => Tree a = Leaf a | Branch (Tree a) (Tree a) | | main = do output <- runQ $ reifyDecl Tree | putStr $ show output | | will cause the impossible to happen. | I went in and changed DsMeta.hs to pass the cxt for reifyDecl (repTyClD for | case TyData), which kept the impossible from happening, but then realized | (at least partially) why it wasn't there before. THSyntax.Data doesn't | support contexts. | | Except that a diagnostic rather than death would be preferable, is this an | omission, on a todo list, or purposely left out? I think Contexts in data declarations are a mis-feature of Haskell (i.e. they shouldn't be there in the first place). But I suppose that since they are there, TH had better support them. To do! Simon

1 0

Contexts on Datatype - question/bug?
by Derek Elkins 11 Feb '03

11 Feb '03

Datatypes can take contexts. Currently TH dies if you try to reifyDecl a datatype with a context e.g. import Language.Haskell.THSyntax (runQ) data (Eq a) => Tree a = Leaf a | Branch (Tree a) (Tree a) main = do output <- runQ $ reifyDecl Tree putStr $ show output will cause the impossible to happen. I went in and changed DsMeta.hs to pass the cxt for reifyDecl (repTyClD for case TyData), which kept the impossible from happening, but then realized (at least partially) why it wasn't there before. THSyntax.Data doesn't support contexts. Except that a diagnostic rather than death would be preferable, is this an omission, on a todo list, or purposely left out? Also, is there a todo-list somewhere or a document with a fairly comprehensive listing of how far along the implementation is and known bugs? On a side note: why not toss up a TH page on the Haskell wiki, especially if the answer to my second question is no? _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

RE: [Template-haskell] Building in Cygwin with Mingw gcc
by Simon Peyton-Jones 10 Feb '03

10 Feb '03

I'm sorry you're having trouble. It looks as if you may not be following the instructions in the Building Guide. I believe that if you ruthlessly do what it says, it'll work. http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html You don't give a lot of evidence in your message, but the instructions say nothing about a "--build" flag to "configure". I'm not sure what it does and I have no confidence that it'll work. I'm not sure how you "tried to build the CVS head in Cygwin, using both gcc 2.95 and gcc 3.1 and both a Cygwin and a Mingw version of the compiler". The instructions don't say anything about that either. Give it a try as described, and see if that helps. You might want to start from a fresh tree. Simon | -----Original Message----- | From: David Bergman [mailto:davidb@home.se] | Sent: 09 February 2003 22:30 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Building in Cygwin with Mingw gcc | | Now I have tried to build the CVS head in Cygwin, using both gcc 2.95 | and gcc 3.1 and both a Cygwin and a Mingw version of the compiler, I | give up... | | The reason that this post is found here is simply because I need to test | out the Template Haskell implementation. | | Anyone else having tried to build it using Cygwin? I would love to have | it up and running on a box beside my Linux one... | | Using "./configure --build=i386-unknown-mingw32" with a 2.95 Mingw gcc I | get the following error: | | ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude | -#includ | HsBase.h -Icbits/regex -funbox-strict-fields -package-name base -O | -Rghc-timin | -split-objs -c Foreign/Storable.hs -o Foreign/Storable.o -ohi | Foreign/Sto | ble.hi | | Foreign/Storable.hs:179: | Type constructor or class not in scope: `NotReallyAType' | | Foreign/Storable.hs:180: | Type constructor or class not in scope: `NotReallyAType' | | Foreign/Storable.hs:181: | Type constructor or class not in scope: `NotReallyAType' | | Foreign/Storable.hs:182: | Type constructor or class not in scope: `NotReallyAType' | make[2]: *** [Foreign/Storable.o] Error 1 | make[1]: *** [all] Error 1 | make[1]: Leaving directory `/lang/haskell/ghc/fptools/libraries' | make: *** [build] Error 1 | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

Re: [Template-haskell] Template Haskell progress
by John O'Donnell 10 Feb '03

10 Feb '03

Dear CTHF (Cherished Template Haskell folk), I can give quick replies to some of Simon PJ's questions: 1. I'm using TH in order to automate a program transformation needed for Hydra, a computer hardware description language (CHDL) that is embedded in Haskell. More generally, I'm interested in the technology of embedded implementations of "domain specific languages", and for that reason I'm interested in exploring further what fits within the TH view of things, and what doesn't. There is a second language design I'm involved with that may well also need TH; this is HaskTwoL, which provides a mixture of task-parallelism and data-parallelism. 2. What went well? I'm still in the early stages, but the good news is that the Hydra transformations appear to be working. There is a lot still to do, and the system is incomplete and also fragile right now, but so far it looks like TH is just the ticket. More generally, two things helped me a lot: both Tim and Simon PJ were very quick to respond to my queries, and that enabled me to get unstuck and make some useful progress. Thanks very much to both of you! The second thing was making the nightly builds available; it's great to be able to experiment with the current system, without needing to wait for a heavyweight release. 3. what (unfixed) bugs you found. I encountered a bug that was already reported by Sean Seefried, so I didn't report that one again. Haven't found any others yet, but there's always tomorrow... The rest of Simon's questions are harder to answer; I'd rather wait until I have a fully working prototype before deciding what the highest priorities for me should be. I don't want to say that "x is essential and urgent, drop all else and do it" without a little more thought :-) Cheers to the TH users as well as implementors, John O'Donnell

2 1

RE: [Template-haskell] Incomplete implementation of declaration reification
by Simon Peyton-Jones 07 Feb '03

07 Feb '03

Thanks. I've fixed this. Simon | -----Original Message----- | From: Sean Seefried [mailto:seefried@itee.uq.edu.au] | Sent: 23 January 2003 03:23 | To: template-haskell | Subject: [Template-haskell] Incomplete implementation of declaration reification | | You are probably already aware of this but a declaration such as | | d1 = [d| id :: a -> a | id x = x |] | | cannot be reified as of yet because the function "trans" in | ghc/compiler/hsSyn/Convert.lhs does not contain a clause for the type | constructor TForall. | | The relevent error message is: | | ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): | hsSyn/Convert.lhs:284: Non-exhaustive patterns in function trans | | | Sean | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

Template Haskell progress
by Simon Peyton-Jones 07 Feb '03

07 Feb '03

Cherished Template Haskell folk, I've returned from two trips in January, and Tim tells me that he is emerging from teaching and grant-application purdah, so we may be able to focus some attention on Template Haskell again. Clearly some of you are using TH for something. If you have tried TH would you like to send a message to the list summarising your experience? - what you tried to use it for - what went well - what (unfixed) bugs you found - what design/impl shortcomings you found - what the highest priorities for the future should be That way we'd all get a more global picture of what is going on. Simon

1 0

FW: Patterns and types
by Simon Peyton-Jones 07 Feb '03

07 Feb '03

Sorry, I forgot to enclose the message I promised. Here it is. -----Original Message----- From: Simon Peyton-Jones Sent: 04 November 2002 14:20 To: 'Tim Sheard (Tim Sheard)' Cc: 'Ian Lynagh'; 'Oege de Moor (Oege de Moor)'; Simon Peyton-Jones Subject: Patterns and types Tim We claim to allow you to write splices in (a) types and (b) patterns. I'm very dubious about (b). Consider] x = 4 y :: Patt y = [p| ... |] f $y = x Question: where is x bound? It looks as though x can be bound by the spliced-in pattern or by the top-level binding. You can't tell without knowing what $y expands to. We argue in our paper against non-top-level declaration splices because that would lead to ambiguity of exactly this sort. It turns out that it's very inconvenient to implement pattern splices in GHC, for exactly this reason. We can't figure out the binding structure till we expand the splice. We can't expand the splice till typechecking time. But the renamer currently fixes the binding structure before type checking. Changing this would be a big upheaval. Conclusion: pattern splices are hard to implement, and dubious from a programming point of view. I propose to drop them, for now at least. Type splices have some similar echoes. Consider y :: Type y = [t| a -> a |] f :: $y What is f polymorphic in? The trouble concerns Haskell's implicit quantification. I guess there are three possibilities: a) $y expands to "a -> a", and that is implicitly universally quantified to "forall a. a->a". b) The implicit quantification happens at the [t| ...|] brackets, so that $y expands to "forall a. a->a" c) $y expands to "a -> a" with no implicit quantification anywhere. I'm pretty sure that we should adopt (b). After all, we want a lexical-scoping rule for TH, so we have to say where 'a' is bound. That would still in principle allow y :: Type y = return (Tvar "a" `Arrow` Tvar "a") Since it's the renamer that does implicit quantification, it'd be quite awkward to make the implicit quantification at the splice site "see" the free variables 'a'. The link with the pattern stuff is this. If you see f :: $y -> b then what are the implicit for-alls? My answer: the implicit for-alls are just for "b", not for any free vars of $y. Simon

1 0

RE: [Template-haskell] The ':' operation with patterns ?
by Simon Peyton-Jones 07 Feb '03

07 Feb '03

Sean says : | Firstly, if we defined | | pcons :: Patt -> Patt -> Patt | pcons x xs = [p| $x : $xs |] | | as per the Template Haskell paper we get the error message | | MkZip.hs:23: Parse error in pattern Indeed, pattern splices are not implemented, nor are pattern quotes. Why not? Below is a message I sent to Tim about this. I'd be interested to know the thoughts of other TH folk. When I sent my message to Tim I was thinking about pattern splices in an expression context, thus (\ $p -> e). But Sean's difficulty shows how useful pattern quotes and splices might be to build bigger patterns: [p| $x : $xs |]. Indeed, I hadn't thought of that. I suppose it might be possible to allow pattern splices inside pattern quotes. Seems a bit weird and ad-hoc, though. I don't know how hard it would be to implement. Simon

1 0