- template-haskell - Haskell.org

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

12 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 10 Feb '03

10 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 09 Feb '03

09 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 06 Feb '03

06 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 06 Feb '03

06 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 06 Feb '03

06 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 06 Feb '03

06 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

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

06 Feb '03

I've been chasing this TH bug down. There are two issues. One is the question of pattern splices, which I'll put in a separate email. However, Sean's suggestion: pcons x xs = pcon "GHC.Base::" [x,xs] should have worked fine, and didn't. (The form Foo:baz is an "original name" for the thing.) The failure turned out to be a consequence of the fact that the Exp data type in THSyntax says; data Exp = Var String | Con String | ... | Infix (Maybe Exp) String (Maybe Exp) | ... The String was assumed to be the name of a variable, not a data constructor. So GHC looked it up in a different name space than the namespace of constructors. Notice, in contrast, that Exp distinguishes Var and Con occurrences all by themselves. This inconsistency led to the bug. For now, I have changed Exp to say Infix (Maybe Exp) Exp (Maybe Exp) where the operator is expected to be either "Var s" or "Con s". Not ideal, but it'll make it all work again, I think. OK, so now it works. A bit of a wild goose chase. I attach working Zip and Main files. Simon | -----Original Message----- | From: Alain Cremieux [mailto:alcremi@pobox.com] | Sent: 26 January 2003 22:07 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] The ':' operation with patterns ? | | Hi, | | I'm trying to code the exemples of "Template Meta-Programming" for | Haskell. Since there are differences in the implementation, I'm obliged | to understand what I code, which is a good exercise. | | At present I'm stuck in the mkZip function, because I'm unable to create | a pattern which is a list concatenation of 2 patterns. | For expressions I can use 'listExp', but what is the equivalent for | patterns ? | | the code : | | -- call : $(zipN 3) as bs cs | | zipN :: Int -> Expr | zipN n | | (n <= 0) | = fail "Incorrect arg to 'zipN' - zipN n, n >= 1" | | otherwise | = [| let zp = $(mkZip n [| zp |]) | in zp |] | | mkZip :: Int -> Expr -> Expr | mkZip n name = lam pYs (caseE (tup eYs) [m1, m2]) | where | pXs, pYs, pXSs :: [Patt] | eXs, eYs, eXSs :: [Expr] | (pXs, eXs) = genPE "x" n -- x1, x2,... | (pYs, eYs) = genPE "y" n -- y1, y2,... | (pXSs, eXSs) = genPE "xs" n -- xs1, xs2,... | --pcons x xs = [p| $x : $xs |] | pcons :: Patt -> Patt -> Patt | pcons x xs = ptup (x : [xs]) -- NOT correct, gives (x, xs) | instead of x : xs | b :: Expr -- ((x1, x2,...) : (zp xs1 xs2 ...)) | b = listExp [tup eXs, apps (name : eXSs)] | m1 :: Mtch -- ((x1:xs1), (x2:xs2),...) -> ((x1, x2,...) : (zp | xs1 xs2 ...)) | m1 = alt (ptup (zipWith pcons pXs pXSs)) b | m2 :: Mtch -- (_, _,...) -> [] | m2 = alt (ptup (replicate n pwild)) (listExp []) | | -- alt = (a1, a2, ..., an) -> ai -- the match part of a case clause | (just an example) | alt :: Patt -> Expr -> Mtch | alt p e = | do x <- e | return (Mat p (Normal x) []) | | Thanks, | Alain | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] A subtle bug with GHC
by Simon Peyton-Jones 06 Feb '03

06 Feb '03

I believe I have fixed this problem. The current HEAD has the fix. Thanks for reporting it -- sorry for slow service! Simon | -----Original Message----- | From: Sean Seefried [mailto:seefried@itee.uq.edu.au] | Sent: 20 January 2003 05:28 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] A subtle bug with GHC | | I've noticed a subtle bug with TH. It took me some time to realise what | was happening. First I will present my source files. | | --- [Splices.hs] ---- | module Splices where | | import Char | import Language.Haskell.THSyntax | | debug f = [| do { putStrLn (show ( $(f) + 3)) ; | putStrLn "Hello World!" } |] | | ---------------------------- | --- [ Main.hs] --------- | | module Main where | | import Language.Haskell.THSyntax | import Splices | | main = $(debug [| (1::Integer) |]) | ----------------------------- | | When I compile this from scratch using the command line: | | prompt> ghc --make -fglasgow-exts -package haskell-src -package | haskell98 Main.hs -o test | | we get | | prompt> | Chasing modules from: Main.hs | Compiling Splices ( Splices.hs, ./Splices.o ) | Compiling Main ( Main.hs, ./Main.o ) | Loading package base ... linking ... done. | Loading package haskell98 ... linking ... done. | Loading package haskell-src ... linking ... done. | Linking ... | | And the program works as expected. But I noticed that when I made a | small change to Main.hs and recompiled the following would occur: | | Skipping Splices ( Splices.hs, ./Splices.o ) | Compiling Main ( Main.hs, ./Main.o ) | Loading package base ... linking ... done. | Loading package haskell98 ... linking ... done. | Loading package haskell-src ... linking ... done. | | No instance for (Monad IO) | arising from a do statement at <compiler-generated-code> | In a right-hand side of function `main': | $[splice](debug [| (1 :: Integer) |]) | In the definition of `main': | main = $[splice](debug [| (1 :: Integer) |]) | make: *** [all] Error 1 | | | I can repeat this error at will. As long as Splices.hi and Splices.o | are in existence the above error will occur when trying to recompile | Main.hs. | | I was using ghc-5.05.20030118 | | Sean Seefried | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0