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 | > | >