RE: [Template-haskell] Pattern reification in Template Haskell
Yes, I'm afraid that pattern quotations and splices are very much not implemented. There's a whole raft of design questions which we sort-of answer in that design note, but not terribly satisfactorily. I do have a bunch of things on my TH to-do list. Pattern splices aren't at the top of it, in fact, but name-splicing -- the ability to splice a name in a binding position -- would be very useful. But there was so little reaction to my last few messages to this list that TH has slipped down my priority list. (Currently I'm busy with GADTs.) I'm not sure whether the quietness of the TH list is because (a) TH works so well that there's no need to say anything or (b) no one is using it. Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Sean Seefried | Sent: 20 October 2004 02:02 | To: Template Haskell Mailing List | Subject: [Template-haskell] Pattern reification in Template Haskell | | Hi all, | | Just a quick question about pattern reification. | | In Tim Sheard and Simon Peyton Jones' notes on Template Haskell paper | we are told that the following declaration would be valid: | | p1 = [p| (x,y) |] | | And that this is literally equivalent to: | | return (Ptuple [Pvar (mkBndr "x"), Pvar (mkBndr "y")]) | | But when I try it I get told that x and y are not in scope. But isn't | that precisely the point? I'm introducing new scope. | I realise there is still some development to be done on Template | Haskell and I was wondering whether this was just one of the things | still on the todo list or whether I was doing something wrong. | | Cheers, | | Sean | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell
"Simon Peyton-Jones"
I do have a bunch of things on my TH to-do list. Pattern splices aren't at the top of it, in fact, but name-splicing -- the ability to splice a name in a binding position -- would be very useful. But there was so little reaction to my last few messages to this list that TH has slipped down my priority list. (Currently I'm busy with GADTs.) I'm not sure whether the quietness of the TH list is because (a) TH works so well that there's no need to say anything or (b) no one is using it.
I had a crazy idea to emulate hs-plugins' dynamic loading in a completely type-safe way by running an entire application in the TH compile loop. Well, maybe it can still generate code that fails type-checking, but at least you get to carry the type-checker around with you, and you don't have to worry about separate type tables from static and dynamic linking. But I could never figure out a good way to turn a source module into a template haskell structure... Also, some other people suggested that it might run very slowly. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby
On 21/10/2004, at 11:11, Shae Matijs Erisson wrote:
"Simon Peyton-Jones"
writes: I do have a bunch of things on my TH to-do list. Pattern splices aren't at the top of it, in fact, but name-splicing -- the ability to splice a name in a binding position -- would be very useful. But there was so little reaction to my last few messages to this list that TH has slipped down my priority list. (Currently I'm busy with GADTs.) I'm not sure whether the quietness of the TH list is because (a) TH works so well that there's no need to say anything or (b) no one is using it.
I had a crazy idea to emulate hs-plugins' dynamic loading in a completely type-safe way by running an entire application in the TH compile loop.
Well, maybe it can still generate code that fails type-checking, but at least you get to carry the type-checker around with you, and you don't have to worry about separate type tables from static and dynamic linking.
But I could never figure out a good way to turn a source module into a template haskell structure...
Also, some other people suggested that it might run very slowly.
Wow, what a crazy idea. Is the basic idea that you have a program that never exits the TH compile loop and when dynamic loading is required it reads in a source program, places it inside reification brackets and then tries to splice it in? Sure this might work, but what about unloading such code? Surely this is an important part of hs-plugins? This reminds me of getting C++ templates to do things they should be doing - it might work but it's surely not the most elegant or user friendly solution. Sean
Sean Seefried
Wow, what a crazy idea. Is the basic idea that you have a program that never exits the TH compile loop and when dynamic loading is required it reads in a source program, places it inside reification brackets and then tries to splice it in? Sure this might work, but what about unloading such code?
Ok, I have no idea how to reload existing code. Shadow existing definitions and compile more?
Surely this is an important part of hs-plugins? This reminds me of getting C++ templates to do things they should be doing - it might work but it's surely not the most elegant or user friendly solution.
True, but I can't think of another solution that carries around the entire typechecker. Lauri Alanko mentioned that hs-plugins is only as type-safe as Dynamics, this was my proposed improvement. This also beats the problem of having two different type-tables, one static and one dynamic, and never the twain shall meet. Even so, Don's recent solution of dynloading everything on a tiny static core is better there. Ok, maybe it's not such a great idea :-) So, next crazy TH idea. Can I use today's version of rType[1] to dump a TH-evaluable type representation that I can send across a network connection? In essence, can I make mobile types by using TH to dump the type description, and hs-plugins to compile and load those type descriptions on another running RTS that's never seen this type before? Even if that works, I'm still not sure how to transport functions to actually work on the new datatypes... [1] see rType in this post, http://www.haskell.org/pipermail/template-haskell/2003-September/000172.html -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby
"Simon Peyton-Jones"
I do have a bunch of things on my TH to-do list. Pattern splices aren't at the top of it, in fact, but name-splicing -- the ability to splice a name in a binding position -- would be very useful. But there was so little reaction to my last few messages to this list that TH has slipped down my priority list. (Currently I'm busy with GADTs.) I'm not sure whether the quietness of the TH list is because (a) TH works so well that there's no need to say anything or (b) no one is using it.
I had a crazy idea to emulate hs-plugins' dynamic loading in a completely type-safe way by running an entire application in the TH compile loop. Well, maybe it can still generate code that fails type-checking, but at least you get to carry the type-checker around with you, and you don't have to worry about separate type tables from static and dynamic linking. But I could never figure out a good way to turn a source module into a template haskell structure... Also, some other people suggested that it might run very slowly. -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby
participants (3)
-
Sean Seefried -
Shae Matijs Erisson -
Simon Peyton-Jones