- template-haskell - Haskell.org

RE: [Template-haskell] Pattern matching against lists.
by Simon Peyton-Jones 26 May '03

26 May '03

2 1

RE: [Template-haskell] Release
by Simon Peyton-Jones 25 May '03

25 May '03

| > > * Use a naming scheme for the functions that avoids having | > > to suffix some with "E" or "D" and some not. Example: we | > > have "cond", but "letE". Better *uniformly* use a single | > > suffix for all functions of the same class; eg, "condExp" | > > and "letExp" (or "condE" and "letE" if you desperately | > > want to save letters). I'm sorry that I didn't respond to this at the time. I agree with the first sentence, but I had not absorbed the full glory of making every single constructor three or four characters longer. Like Tim, I don't think this is a good plan. We don't say JustMaybe and NothingMabye. Instead, we just choose constructor names that don't clash within a particular module. (Between unrelated modules, we can rely on qualified names etc.) My suggestion for resolving the occasional clash (and there were only a handful) would be to change the constructor name. For example, we have a let form in Exp and in Stmt. Let's just give one a different name. The Stmt type is much less used than the Exp type. Perhaps 'Bind', 'Let', 'NoBind' and 'Par' are a bit cryptic because Stmts are so much less common, so perhaps 'LetStmt' or 'StmtLet' would indeed be a good choice. Similarly for Foreign, the constructor 'ImportForeign' or 'ForImport' seems good; plain 'Import' is rather cryptic. But for the big hitters, Exp, RHS, Dec, Pat, Typ, my personal preference would be for short constructor names. Manuel, it sounds as though you disagree with this? I would like to see the type 'Typ' change to 'Type', though! Changing DotDot to Range is fine with me. A process question, though: TH is for everyone, and Ian L is doing us all a service by doing work on the design and implementation. So he gets a big vote. Please do not take this as having a "don't fiddle" subtext. I for one am really grateful for your help. Simon

3 2

Pattern matching against lists.
by Hampus Ram 24 May '03

24 May '03

Hi, reading through THSyntax.hs I can find no way of matching against lists when creating functions. Is there something obvious that I've missed or is this something that is relly missing? /Hampus -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: d00ram(a)dtek.chalmers.se "Det är aldrig försent att ge upp"

2 1

RE: [Template-haskell] Release
by Simon Marlow 23 May '03

23 May '03

> On Fri, May 23, 2003 at 11:26:31AM +0100, Simon Peyton-Jones wrote: > > My suggestion would be to back out Ian's changes until we evolve a > > consensus. The consensus may ultimately turn out to be > exactly what Ian > > has done, but it's probably sensible to avoid the risk of TH users > > having to make a double change. > > > > Renewed apologies for not bleating earlier about this. > > > > ok with you, Ian? (It's easy to re-apply the patch later, > so there's no > > danger of losing the work if we end up adopting it.) > > How about backing it out in the 6.0 branch but leaving the HEAD as-is? > > The reason being that I also rearranged some bits, added a few type > signatures and things so I think it would be easier to re-rename from > the current HEAD. Also wouldn't have to worry about merging with any > changes between now and concensus. > > TH users would then be strongly advised to use the 6.0 branch until > things settle down. Done; 6.0 will have the original names. Cheers, Simon

1 0

RE: [Template-haskell] Release
by Simon Peyton-Jones 23 May '03

23 May '03

My suggestion would be to back out Ian's changes until we evolve a consensus. The consensus may ultimately turn out to be exactly what Ian has done, but it's probably sensible to avoid the risk of TH users having to make a double change. Renewed apologies for not bleating earlier about this. ok with you, Ian? (It's easy to re-apply the patch later, so there's no danger of losing the work if we end up adopting it.) Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Simon Marlow | Sent: 23 May 2003 09:34 | To: Simon Peyton-Jones; Tim Sheard; Ian Lynagh; Manuel M T Chakravarty | Cc: template-haskell(a)haskell.org | Subject: RE: [Template-haskell] Release | | | > | > > * Use a naming scheme for the functions that avoids having | > | > > to suffix some with "E" or "D" and some not. Example: we | > | > > have "cond", but "letE". Better *uniformly* use a single | > | > > suffix for all functions of the same class; eg, "condExp" | > | > > and "letExp" (or "condE" and "letE" if you desperately | > | > > want to save letters). | > | > I'm sorry that I didn't respond to this at the time. I agree with the | > first sentence, but I had not absorbed the full glory of making every | > single constructor three or four characters longer. Like Tim, I don't | > think this is a good plan. We don't say JustMaybe and NothingMabye. | > Instead, we just choose constructor names that don't clash within a | > particular module. (Between unrelated modules, we can rely | > on qualified names etc.) | | We need to decide what naming scheme is going to be in GHC 6.0. I | already merged through Ian's renaming changes, so the current situation | is that GHC 6.0 has the longer names. Time is short, so I could just | back out to the previous story if there's no concensus. | | Cheers, | Simon | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] Release
by Simon Marlow 23 May '03

23 May '03

> | > > * Use a naming scheme for the functions that avoids having > | > > to suffix some with "E" or "D" and some not. Example: we > | > > have "cond", but "letE". Better *uniformly* use a single > | > > suffix for all functions of the same class; eg, "condExp" > | > > and "letExp" (or "condE" and "letE" if you desperately > | > > want to save letters). > > I'm sorry that I didn't respond to this at the time. I agree with the > first sentence, but I had not absorbed the full glory of making every > single constructor three or four characters longer. Like Tim, I don't > think this is a good plan. We don't say JustMaybe and NothingMabye. > Instead, we just choose constructor names that don't clash within a > particular module. (Between unrelated modules, we can rely > on qualified names etc.) We need to decide what naming scheme is going to be in GHC 6.0. I already merged through Ian's renaming changes, so the current situation is that GHC 6.0 has the longer names. Time is short, so I could just back out to the previous story if there's no concensus. Cheers, Simon

1 0

RE: [Template-haskell] Release
by Simon Peyton-Jones 23 May '03

23 May '03

| As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). Yes, that's a good idea. | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: It's all to do with Tim's "two-level types" scheme, but I do agree with you that it seems more trouble than its worth. Tim: how vigorously do you want to defend this? If not, can we let Ian remove the parameterisation? Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell- | admin(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 08 April 2003 13:17 | To: template-haskell(a)haskell.org | | | As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). | | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: | | class ToDec a where | to_dec :: a -> Dec | | instance ToDec Dec where | to_dec = id | | class ToExp a where | to_exp :: a -> Exp | | instance ToExp Exp where | to_exp = id | | instance (ToExp e, ToDec d) => Foo (Match p e d) where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Which I'd much rather be able to write as | | instance Foo Match where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Previous discussions about this have all petered out before reaching a | conclusion, but I haven't seen anyone actually stand up and defend the | parameterised types, and it's hard to see how they could be useful | without everything being parameterised anyway. Can we get rid of them? | Please? Or at least have an explanation of why not... | | Hmmm, or maybe I should be asking for them to be extended to cover all | the types to make it easier to have a type of reification that annotates | the tree with type and strictness information. I'd still have the | problem above, but at least more things would be possible. | | Anyway, I'm confused, but sitting in the middle is just driving me mad! | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

4 4

Dec type is missing "NewType"
by Andre Pang 20 May '03

20 May '03

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

2 1

RE: [Template-haskell] Calling foreign functions in a splice doesn't work
by Simon Peyton-Jones 19 May '03

19 May '03

OK, I reckon I've fixed this. You can now specify any extra C libraries on the command line (c_double.o), and they'll get linked if any TH runs happen. Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | André Pang | Sent: 12 May 2003 16:14 | To: template-haskell(a)haskell.org | Cc: chak(a)cse.unsw.edu.au | Subject: [Template-haskell] Calling foreign functions in a splice doesn't work | | 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 | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] Splicing in class declarations doesn't work
by Simon Peyton-Jones 19 May '03

19 May '03

Fixed, thank you. 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 18:41 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Splicing in class declarations doesn't work | | 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 | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0