RE: [Template-haskell] quasi quotes and Q monad
I've read your message, but I can't figure out what problem you are trying to solve. Can you give a small example that demonstrates it? Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Ch. A. Herrmann | Sent: 02 January 2006 16:17 | To: template-haskell@haskell.org | Subject: [Template-haskell] quasi quotes and Q monad | | Dear TH experts, | | I have a problem concerning the interaction of quasi quotes and the | quotation monad. Assume a code generating function f (... -> Q Exp) | which is parameterized by a code generating function g (of type | Exp -> Q Exp, or(?) Q Exp -> Q Exp). | | Expressing the problem in the simplest form, the actual instance for g | is (\x -> [| h($x) |]), where h is a toplevel Haskell function working | on arbitrary types, and function f instantiates x | with an expression which consists just of a single variable (VarE). In | order to splice x in the code ($x), the type of x must be (Q Exp). The | reason for that, as mentioned in the 2002 paper | by Sheard and Peyton Jones "Template Metaprogramming for Haskell", is | that the computation of x must be able to access the Q monad. The place | inside f where the actual name for the variable x is generated, has | already access to the Q monad and the *result* of g is | embedded in this monad, no problem. However, I cannot figure out how | this monad can be passed as an *argument* to g and conceptually, there | is no justification to pass this monad: it is just an offspring version | of the one where the lexical scope of g belongs to. | | The value I want to pass for x is of type Exp. Of course, I could turn | this type into (Q Exp) by applying return, but this artificial instance | of the Q monad would come from nowhere, not being connected with the | regular instance used, e.g., for the fresh name generation. | | Especially, I have the following questions: | * Is there a simple solution to this problem? If so, please tell me and | forget about the following questions. | * Is the quasi quote mechanism at all appropriate for what I want to do | or should one better change to the concrete AST representation? That | | would be unfortunate because my aim is to develop Template Haskell | examples which demonstrate ease of use. | * If return is used to turn an expression into monadic form before | splicing, is it possible that | (a) the consistency of fresh name generation is lost, even if one | does the name generation for the spliced expression oneself, | (b) something else goes wrong? | | Many thanks in advance and a Happy New Year | -- | Christoph Herrmann | | | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell
Hi Simon, I have reduced the program to the parts interesting for our topic. The program is attached. Function f looks nice with the quasi quotation, but in case we have to use the low-level style the argument to g must be a monadic value, which I did here by using return, e.g. (return (VarE x)). I worried whether the function f in low-level style with this use of return is equivalent to the quasi-quoted version. Somehow I felt the need to connect the argument of g with the monad of which the value of g's result belongs to. It appeared to me that this is what the quotation brackets [|y|] are establishing, because y is also in the scope of the outer brackets. On the one hand, I wonder why the name generation history, when code generation for a quotation part is finished, is not reset to the state before. This would be the case with the separate monad for g's argument. On the other hand, it must be possible to nest quotation brackets and still establish that names at the different levels are distinct, if it is wanted. Many thanks in advance for any enlighting explanation -- Christoph Simon Peyton-Jones wrote:
I've read your message, but I can't figure out what problem you are trying to solve.
Can you give a small example that demonstrates it?
Simon
| -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Ch. A. Herrmann | Sent: 02 January 2006 16:17 | To: template-haskell@haskell.org | Subject: [Template-haskell] quasi quotes and Q monad | | Dear TH experts, | | I have a problem concerning the interaction of quasi quotes and the | quotation monad. Assume a code generating function f (... -> Q Exp) | which is parameterized by a code generating function g (of type | Exp -> Q Exp, or(?) Q Exp -> Q Exp). | | Expressing the problem in the simplest form, the actual instance for g | is (\x -> [| h($x) |]), where h is a toplevel Haskell function working | on arbitrary types, and function f instantiates x | with an expression which consists just of a single variable (VarE). In | order to splice x in the code ($x), the type of x must be (Q Exp). The | reason for that, as mentioned in the 2002 paper | by Sheard and Peyton Jones "Template Metaprogramming for Haskell", is | that the computation of x must be able to access the Q monad. The place | inside f where the actual name for the variable x is generated, has | already access to the Q monad and the *result* of g is | embedded in this monad, no problem. However, I cannot figure out how | this monad can be passed as an *argument* to g and conceptually, there | is no justification to pass this monad: it is just an offspring version | of the one where the lexical scope of g belongs to. | | The value I want to pass for x is of type Exp. Of course, I could turn | this type into (Q Exp) by applying return, but this artificial instance | of the Q monad would come from nowhere, not being connected with the | regular instance used, e.g., for the fresh name generation. | | Especially, I have the following questions: | * Is there a simple solution to this problem? If so, please tell me and | forget about the following questions. | * Is the quasi quote mechanism at all appropriate for what I want to do | or should one better change to the concrete AST representation? That | | would be unfortunate because my aim is to develop Template Haskell | examples which demonstrate ease of use. | * If return is used to turn an expression into monadic form before | splicing, is it possible that | (a) the consistency of fresh name generation is lost, even if one | does the name generation for the spliced expression oneself, | (b) something else goes wrong? | | Many thanks in advance and a Happy New Year | -- | Christoph Herrmann | | | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell
Hello Ch., Wednesday, January 04, 2006, 5:44:53 PM, you wrote: sorry, but i read your message only now. try to read http://freearc.narod.ru/th.htm - it contains my own unfinished tutorial on TH, which may be helpful for you. in brief, all TH syntax sugar in form of quotation brackets is translated to low-level expressions, which runs in the global quotation monad environment CAH> I worried whether the function f in low-level style with this CAH> use of return is equivalent to the quasi-quoted version. CAH> Somehow I felt the need to connect the argument of g with CAH> the monad of which the value of g's result belongs to. It CAH> appeared to me that this is what the quotation brackets [|y|] are CAH> establishing, because y is also in the scope of the outer brackets. CAH> On the one hand, I wonder why the name generation history, when CAH> code generation for a quotation part is finished, is not reset to the state CAH> before. This would be the case with the separate monad for g's CAH> argument. On the other hand, it must be possible to nest quotation CAH> brackets and still establish that names at the different levels are CAH> distinct, if it is wanted. CAH> Many thanks in advance for any enlighting explanation -- Best regards, Bulat mailto:bulatz@HotPOP.com
Christoph You have probably forgotten all about this, but it's been in my mailbox all along... Anyway, since today is a peaceful day, I have taken a look. Sorry for the long delay. I attach the same file you attached, to give the context. The short answer is: yes, the two versions of f do the same thing. I still can't figure out why you are worried. You say "Somehow I felt the need to connect the argument of g with the monad of which the value of g's result belongs to", but I'm not sure what you mean. Nor did I understand your last paragraph. In any case, is there a problem here? The quasi-quoted version of f works just fine. Simon | -----Original Message----- | From: Ch. A. Herrmann [mailto:herrmann@infosun.fmi.uni-passau.de] | Sent: 04 January 2006 14:45 | To: Simon Peyton-Jones | Cc: template-haskell@haskell.org | Subject: Re: [Template-haskell] quasi quotes and Q monad | | Hi Simon, | | I have reduced the program to the parts interesting for | our topic. The program is attached. | | Function f looks nice with the quasi quotation, but in case | we have to use the low-level style the argument to | g must be a monadic value, which I did here by using | return, e.g. (return (VarE x)). | | I worried whether the function f in low-level style with this | use of return is equivalent to the quasi-quoted version. | Somehow I felt the need to connect the argument of g with | the monad of which the value of g's result belongs to. It | appeared to me that this is what the quotation brackets [|y|] are | establishing, because y is also in the scope of the outer brackets. | | On the one hand, I wonder why the name generation history, when | code generation for a quotation part is finished, is not reset to the state | before. This would be the case with the separate monad for g's | argument. On the other hand, it must be possible to nest quotation | brackets and still establish that names at the different levels are | distinct, if it is wanted. | | Many thanks in advance for any enlighting explanation | -- | Christoph | | Simon Peyton-Jones wrote: | | >I've read your message, but I can't figure out what problem you are | >trying to solve. | > | >Can you give a small example that demonstrates it? | > | >Simon | > | >| -----Original Message----- | >| From: template-haskell-bounces@haskell.org | >[mailto:template-haskell-bounces@haskell.org] On | >| Behalf Of Ch. A. Herrmann | >| Sent: 02 January 2006 16:17 | >| To: template-haskell@haskell.org | >| Subject: [Template-haskell] quasi quotes and Q monad | >| | >| Dear TH experts, | >| | >| I have a problem concerning the interaction of quasi quotes and the | >| quotation monad. Assume a code generating function f (... -> Q Exp) | >| which is parameterized by a code generating function g (of type | >| Exp -> Q Exp, or(?) Q Exp -> Q Exp). | >| | >| Expressing the problem in the simplest form, the actual instance for g | >| is (\x -> [| h($x) |]), where h is a toplevel Haskell function working | >| on arbitrary types, and function f instantiates x | >| with an expression which consists just of a single variable (VarE). In | >| order to splice x in the code ($x), the type of x must be (Q Exp). The | >| reason for that, as mentioned in the 2002 paper | >| by Sheard and Peyton Jones "Template Metaprogramming for Haskell", is | >| that the computation of x must be able to access the Q monad. The | >place | >| inside f where the actual name for the variable x is generated, has | >| already access to the Q monad and the *result* of g is | >| embedded in this monad, no problem. However, I cannot figure out how | >| this monad can be passed as an *argument* to g and conceptually, there | >| is no justification to pass this monad: it is just an offspring | >version | >| of the one where the lexical scope of g belongs to. | >| | >| The value I want to pass for x is of type Exp. Of course, I could turn | >| this type into (Q Exp) by applying return, but this artificial | >instance | >| of the Q monad would come from nowhere, not being connected with the | >| regular instance used, e.g., for the fresh name generation. | >| | >| Especially, I have the following questions: | >| * Is there a simple solution to this problem? If so, please tell me | >and | >| forget about the following questions. | >| * Is the quasi quote mechanism at all appropriate for what I want to | >do | >| or should one better change to the concrete AST representation? | >That | >| | >| would be unfortunate because my aim is to develop Template Haskell | >| examples which demonstrate ease of use. | >| * If return is used to turn an expression into monadic form before | >| splicing, is it possible that | >| (a) the consistency of fresh name generation is lost, even if one | >| does the name generation for the spliced expression oneself, | >| (b) something else goes wrong? | >| | >| Many thanks in advance and a Happy New Year | >| -- | >| Christoph Herrmann | >| | >| | >| | >| _______________________________________________ | >| template-haskell mailing list | >| template-haskell@haskell.org | >| http://www.haskell.org/mailman/listinfo/template-haskell | > | >
participants (3)
-
Bulat Ziganshin -
Ch. A. Herrmann -
Simon Peyton-Jones