[Template-haskell] quasi quotes and Q monad

[Simon Peyton-Jones]

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 at infosun.fmi.uni-passau.de]
| Sent: 04 January 2006 14:45
| To: Simon Peyton-Jones
| Cc: template-haskell at 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 at haskell.org
| >[mailto:template-haskell-bounces at haskell.org] On
| >| Behalf Of Ch. A. Herrmann
| >| Sent: 02 January 2006 16:17
| >| To: template-haskell at 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 at haskell.org
| >| http://www.haskell.org/mailman/listinfo/template-haskell
| >
| >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gen.hs
Type: application/octet-stream
Size: 1014 bytes
Desc: Gen.hs
Url : http://www.haskell.org//pipermail/template-haskell/attachments/20060414/561f26e8/Gen.obj