| Using this we could say (on the toplevel of a module): | addDeriving ("Fold", deriveFold) | | Note that this would let us derive not only instances but new | functions or even new data types. Mega Awsome! Can't you do this already? data T = MkT Int $(deriveFold 'T) where deriveFold :: TH.Name -> Q [Dec] | Splicing pragmas | =============== | | It would be nice to be able to splice in compiler pragmas. For example | if one writes a TH module for deriving folds and builds one would like | to generate rules pragmas so that GHC can fuse these functions when | they are used. Generating self-optimising code :). | | Concretely one would add a constructor to the Dec data type. Something | like this: | | data Dec = ... | | PragmaD Pragma Yes, more and more GHC extensions are creeping into TH, and maybe that's OK. It is tiresome, but not difficult, to extend the abstract syntax and to-and-fro conversions. Ian Lynagh has become quite good at it. OK with me! | >From Meta Haskell to Meta X | =========================== I don't know how to make a good job of this, but it seems like a good problem for someone to study. The thing is that language X has scoping and typing rules that are different to Haskell's. How to express them? It's not just syntax! Simon
On Tue, 27 Apr 2004, Simon Peyton-Jones wrote:
| Using this we could say (on the toplevel of a module): | addDeriving ("Fold", deriveFold) | | Note that this would let us derive not only instances but new | functions or even new data types. Mega Awsome!
Can't you do this already?
data T = MkT Int
$(deriveFold 'T)
where deriveFold :: TH.Name -> Q [Dec]
Ahh, right. I'm still about to learn about the newer additions to TH. However, using the above requires the user of my library to be aware of TH and to set the -fth flag. With a deriving mechanism we can do away with that. But sure, the above is quite OK.
| >From Meta Haskell to Meta X | ===========================
I don't know how to make a good job of this, but it seems like a good problem for someone to study. The thing is that language X has scoping and typing rules that are different to Haskell's. How to express them? It's not just syntax!
Well, the sml/nj guys are happy with only syntax, their extension doesn't do more than that. But I realise now that if it should still work with TH then it needs to be more than syntax. Typechecking is not an issue here though AFAICS. TH only does typechecking just before generating code from a splice. But we won't be generating any code here, the toplevel splice construct will be unaltered. This proposal will only make it easier to write pieces of object code and not having to use (the Haskell representation of) the abstract syntax but to use the concrete syntax instead. But then there is ofcourse the issue of scoping which does indeed require some thought. I don't have a solution here, Anyway, thanks for the response! /Josef
participants (2)
-
Josef Svenningsson -
Simon Peyton-Jones