- template-haskell - Haskell.org

RE: [Template-haskell] Dec type is missing "NewType"
by Simon Peyton-Jones 19 May '03

19 May '03

Yes, that's true. No deep reason. Ian: would you feel up to adding newtype declarations, since you are Mr THSyntax? Thanks Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Andre Pang | Sent: 17 May 2003 15:14 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Dec type is missing "NewType" | | Hi all, I think the Dec data type in THSyntax.hs (starting at line 174) | is missing the "newtype" declaration. It currently looks like this: | | data Dec | = Fun String [Clause] -- { f p1 p2 = b where decs } | | Val Pat RightHandSide [Dec] -- { p = b where decs } | | Data Cxt String [String] | [Con] [String] -- { data Cxt x => T x = A x | | B (T x) deriving (Z,W)} | | TySyn String [String] Typ -- { type T x = (x,x) } | | Class Cxt String [String] [Dec] -- { class Eq a => Ord a where | ds } | | Instance Cxt Typ [Dec] -- { instance Show w => Show | [w] where ds } | | Proto String Typ -- { length :: [a] -> Int } | | Foreign Foreign | deriving( Show ) | | Am I missing something, or is no way to write a newtype declaration? I | presume it's not the same as either a TySyn or Data. | | Thanks once again, | | | -- | % Andre Pang : trust.in.love.to.save | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

Splicing in class declarations doesn't work
by Andre Pang 18 May '03

18 May '03

Hallo all, I think I've found a bug with declaring classes, or more specifically, declaring functions which instances of the classes are required to implement. Splicing in the following code works fine: spliceTest = [d| class Foo f where {} |] However, splicing in this code doesn't work: spliceTestDeux = [d| class Bar b where { baz :: Int -> Int } |] 3:30 ~/th/newnew % ghci -fglasgow-exts -ddump-splices ObjCTypesTHTest.hs ... ObjCTypesTHTest.hs:1: Splicing declarations spliceTest ======> class Foo f'0 ObjCTypesTHTest.hs:1: Splicing declarations spliceTestDeux ======> class Bar b'1 where { baz :: GHC.Base.Int -> GHC.Base.Int; } Variable not in scope: `baz' Misplaced type signature: baz :: Int -> Int Failed, modules loaded: ObjCTypesTH. *ObjCTypesTH> Splicing in a "raw" declaration: spliceTestDeux :: Q [Dec] spliceTestDeux = return [ Class [] "Bar" ["b"] [Proto "baz" (tappsArr [intCon, intCon])] ] where intCon = Tcon (TconName "Int") doesn't work either (with exactly the same error message). (BTW, should I send TH-related bugs to template-haskell, put them in the bug tracker, or both?) Thanks again, -- % Andre Pang : trust.in.love.to.savee

1 0

RE: [Template-haskell] Splicing in a TypQ == parse error?
by Simon Peyton-Jones 15 May '03

15 May '03

| How do you splice in a type in Template Haskell? The quasi-quote | notation seems to work succesfully, but attempting to splice it gives | me a parse error: At the moment you can't. See http://haskell.org/pipermail/template-haskell/2003-February/000021.html I'd like to solve that. Tim is visiting next week, so we'll be discussing it. Meanwhile, do others have opinions? Simon

1 0

Splicing in a TypQ == parse error?
by Andre Pang 14 May '03

14 May '03

Hi all, How do you splice in a type in Template Haskell? The quasi-quote notation seems to work succesfully, but attempting to splice it gives me a parse error: MyTypes.hs: module MyTypes where import Language.Haskell.THSyntax stringType = [t| String |] SpliceType.hs: module SpliceType where import Language.Haskell.THSyntax foo :: $(stringType) -> $(stringType) foo x = x ++ "foo" Compiling it: 18:28[18] ~/th/new % ghc -fglasgow-exts SpliceType.hs SpliceType.hs:7: parse error on input `$(' The same happens if I try to to write "data Foo = Foo $(stringType)" in SpliceType.hs. Am I getting the syntax wrong, or is splicing types not implemented yet? I'm using a May 13, 2003 build of GHC. Merci, -- % Andre Pang : trust.in.love.to.save

1 0

Calling foreign functions in a splice doesn't work
by André Pang 13 May '03

13 May '03

Hi all, I've been trying to call a foreign function (i.e. via the FFI) inside a splice, which doesn't seem to work. As an example, I'll attach a small program which does work, and then modify it so it doesn't work. So, here's a program which does work: Splicer.hs: > module Main where > > import Templates > > main :: IO () > main = do > putStrLn (show ($(doubleWrapper) 5)) Templates.hs: > module Templates where > > import Language.Haskell.THSyntax > > doubleWrapper :: Expr > doubleWrapper = [| \x -> myDouble x |] > > myDouble :: Int -> Int > myDouble x = x * 2 Pretty simple: the program splices in an Expr named doubleWrapper; doubleWrapper in turn calls myDouble, which is a simple function of type Int -> Int. Execution: > 20:10 ~/th/ffi-bug % ghc -fglasgow-exts --make Splicer.hs > ... > 20:10 ~/th/ffi-bug % ./a.out > 10 So that works. Here's a version of the program which modifies the 'myDouble' function so that it's now a foreign C function rather than a Haskell function. (Note that the main function and doubleWrapper functions are exactly the same): SplicerFFI.hs: > module Main where > > import TemplatesFFI > > main :: IO () > main = do > putStrLn (show ($(doubleWrapper) 5)) TemplatesFFI.hs: > module TemplatesFFI where > > import Language.Haskell.THSyntax > > doubleWrapper :: Expr > doubleWrapper = [| \x -> myDouble x |] > > foreign import ccall safe "c_double.h myDouble" > myDouble :: Int -> Int c_double.h: > int myDouble (int x); c_double.c: > int myDouble (int x) > { > return x * 2; > } Compiling the FFI version of this small program doesn't work: > 20:20 ~/th/ffi-bug % gcc -c c_double.c > 20:20 ~/th/ffi-bug % ghc -fglasgow-exts --make c_double.o > SplicerFFI.hs c_double.o > Chasing modules from: SplicerFFI.hs > Compiling TemplatesFFI ( TemplatesFFI.hs, ./TemplatesFFI.o ) > Compiling Main ( SplicerFFI.hs, ./SplicerFFI.o ) > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package haskell-src ... linking ... done. > > TemplatesFFI.o: unknown symbol `_myDouble' > > SplicerFFI.hs:7: > Exception when trying to run compile-time code: > Code: doubleWrapper > Exn: > In the first argument of `show', namely > `($[splice]doubleWrapper 5)' > In the first argument of `putStrLn', namely > `(show ($[splice]doubleWrapper 5))' > In the result of a 'do' expression: > putStrLn (show ($[splice]doubleWrapper 5)) I suspect the compilation isn't working because the 'myDouble' symbol in c_double.o isn't being loaded _at splice time_ into the list of symbols that GHC knows about -- which is also why the exception occurs. I've tried all sorts of kludges to convince GHC to load the symbol from the foreign object file, like doing "ar rcs libcdouble.a c_double.o" and then putting -L. -lcdouble on the commandline, passing additional linker/compiler flags with -optl and -optc, etc, and none of them have worked so far. This was tested with GHC on Mac OS X built from CVS 9 March 2003; my apologies for a fairly out-of-date GHC build, but I'm having trouble building the recent GHCs on Mac OS X. Can somebody verify that this also occurs on Linux with a recent build of GHC, and hopefully fix it or give me a clue on where to start looking for the bug? Thanks very much! -- % Andre Pang : just.your.average.bounty.hunter

2 1

RE: [Template-haskell] reifyDecl: syntax and semantics
by Simon Peyton-Jones 07 May '03

07 May '03

| > -------------------- | > d1 = [d| data T = ... |] | > | > splice d1 | | I definitely prefer your solution which just avoids reification, for | one simple reason: it works ! | Question is: is there any case where reification is indispensable or is | this trick general ? (and then why bother with reification ?) | | However, I'm still not very happy with this solution, because (again) | thinking of a library working on the reified declarations, then the | part above has to be written by the "user". I think the main reason for reifyDecl etc is so that you can write ordinary Haskell declarations, and subsequently (in another module, even) write (reifyDecl T) to get the decl for T. It is rather dependent on being able to *name* the thing whose decl you want; hence the difficulty with instance decls (which are anonymous) and defn vs type-signature for functions (where one name names two things). As to the "language-construct" question, the difficulty is this. If reifyDecl has type reifyDecl :: String -> Decl then the string would have to be looked up in some environment. Just which environment? The environment at which the 'reifyDecl' call is written? Or when the reifyDecl monadic computation is performed (perhaps much later). I guess the latter is what we want. That means the Q monad must support looking up strings in an environment, something I've been meaning to add for some time. For example, suppose we say in current TH foo (reifyDecl T) where T is some data type data T = MkT String Then 'foo' might walk over the constructors of T, and over the constructor's argument type(s), and might ultimately come across a type constructor "String" in that argument type. At that point, foo might want to reify the defn of String, so that it can see what manner of beast it might be. And bingo there's that monadic look up again. No one has actually asked for this yet, mind you, so it's kind of vaguely on my list. Simon

1 0

Re: [Template-haskell] reifyDecl: syntax and semantics
by François-Régis Sinot 03 May '03

03 May '03

> Reification is difficult for lots of reasons. But here is a trick that > you might be able to use. > > Break your program into pieces, where you split the use of decls > you want to reify into two parts. > > -------------------- > d1 = [d| data T = ... |] > > splice d1 > > --------------------- > > Then you have a meta-variable "d1" with the reified form, and the > real data declaration because of the splice. > > Tim Sheard I definitely prefer your solution which just avoids reification, for one simple reason: it works ! Question is: is there any case where reification is indispensable or is this trick general ? (and then why bother with reification ?) However, I'm still not very happy with this solution, because (again) thinking of a library working on the reified declarations, then the part above has to be written by the "user". Thanks. -fr-

1 0

reifyDecl: syntax and semantics
by François-Régis Sinot 03 May '03

03 May '03

Hi there "Reification is a language construct, not a function", as said in the paper. I would like to discuss this choice a bit, focusing on reifyDecl. First, I don't really see any justification for this restriction. As far as I can see, if we say, for instance: reifyDecl :: String -> Decl as long as the result is in the quotation monad, it should be okay, or shoudln't it ? Maybe there are some implementation considerations that I can't see behind that choice. I think at least constructs of the form reifyDecl $(con "Tree") should be allowed. At present, the parser rejects that. My second point is that the syntax is inconsistent with the intended semantics: for example, the documentation says that it should be possible to reify a function definition and a prototype. But if I ask reifyDecl length, what do I expect ? The def or the proto ? Same thing with reification of instance declarations. As a matter of fact, the present implementation does not seem to handle the cases of prototypes and instances, and I don't think it is an urgent matter. However, I think the syntax should not already forbid that. My last point, is that it is really impractical. I think it is a pity that such a powerful construct is in fact almost unusable because of poor syntactic restrictions. For example, I want to reify a datatype declaration and then generate a declaration, say for a function, depending on the structure of the datatype. I can do that, but I can't abstract from the original datatype, which I am not happy with. If you're not convinced yet, I can be a bit more specific about what I want to do. So, what do you think about that ? -fr-

2 3

RE: [Template-haskell] Representation of unboxed primitives in TH
by Simon Peyton-Jones 01 May '03

01 May '03

OK. Ian, I suggest that if you want to put the unboxed stuff in meanwhile, then go ahead. Simon | -----Original Message----- | From: Tim Sheard [mailto:sheard@cse.ogi.edu] | Sent: 30 April 2003 16:27 | To: Simon Peyton-Jones; Ian Lynagh; Simon Peyton-Jones | Cc: Sean Seefried; template-haskell(a)haskell.org | | At 12:25 PM 4/30/2003 +0100, Simon Peyton-Jones wrote: | >I'd like to hear from Tim Sheard. Tim: do you have an opinion? | | My original goal was for the data-structure that represented code | to be as simple as possible. But I can see that this isn't going | to work, since users want to "represent" any program they can write | in GHC, and that includes (generally) all the GHC extensions. | | I guess we need a strategy to address these things. This is some thing | we should address when I come to Cambridge next month. | | Tim Sheard |

1 0

RE: [Template-haskell] Representation of unboxed primitives in TH
by Tim Sheard 30 Apr '03

30 Apr '03

At 12:25 PM 4/30/2003 +0100, Simon Peyton-Jones wrote: >I'd like to hear from Tim Sheard. Tim: do you have an opinion? My original goal was for the data-structure that represented code to be as simple as possible. But I can see that this isn't going to work, since users want to "represent" any program they can write in GHC, and that includes (generally) all the GHC extensions. I guess we need a strategy to address these things. This is some thing we should address when I come to Cambridge next month. Tim Sheard

1 0