Splices returning splices

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Splices returning splices

J. Garrett Morris-4
Hello,

I'm attempting to write a quasiquoter with relatively full antiquotation
support.  In doing so, I've arrived at I think an odd problem: the
expression grammar in Language.Haskell.TH.Syntax doesn't seem to include
splices.  This seems to mean that my antiquotations can't themselves
include splices, which is quite limiting.  Am I misinterpreting?  The
type system in "Template metaprogramming for Haskell" seems to imply no
such restriction on the occurrences of splices.

(As an additional complication: what I really need to do is return typed
splices; my "quasiquoter" relies on its expected type to determine its
behavior.  However, this seems like an uninteresting extension of the
above problem.)

Thanks,

 /g

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: Splices returning splices

Simon Peyton Jones
Currently it just isn't supported.  Suppose you say

f x = [| ....$(g y).... |]

...$(f 3)....

Does $(f 3) mean "run (f 3) returning some code with embedded splices, and then run those", or does it mean (as now) "call (f 3), and to do so run (g y) first, to generate some code that is spliced into the code returned by f"?

A quasiquoter is really a splice. That is [foo| blah |] is the same as $(foo "blah").  So it might be easier to discuss your question in the context of ordinary splices and quotes.  You want foo to return code with a splice, thus:

foo input_string = [| ...$(other_fun args).... |]

But foo is in the Q monad anyway, so why not just run (other_fun args) right there in the quasiquoter?

Or perhaps make a tiny example to show what you mean (but not using quasiquotation).

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of J. Garrett Morris
|  Sent: 23 March 2015 12:47
|  To: GHC users
|  Subject: Splices returning splices
|  
|  Hello,
|  
|  I'm attempting to write a quasiquoter with relatively full antiquotation
|  support.  In doing so, I've arrived at I think an odd problem: the
|  expression grammar in Language.Haskell.TH.Syntax doesn't seem to include
|  splices.  This seems to mean that my antiquotations can't themselves
|  include splices, which is quite limiting.  Am I misinterpreting?  The
|  type system in "Template metaprogramming for Haskell" seems to imply no
|  such restriction on the occurrences of splices.
|  
|  (As an additional complication: what I really need to do is return typed
|  splices; my "quasiquoter" relies on its expected type to determine its
|  behavior.  However, this seems like an uninteresting extension of the
|  above problem.)
|  
|  Thanks,
|  
|   /g
|  
|  --
|  The University of Edinburgh is a charitable body, registered in Scotland,
|  with registration number SC005336.
|  
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  [hidden email]
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Splices returning splices

J. Garrett Morris-4
On Mon, Mar 23, 2015 at 3:43 PM, Simon Peyton Jones
<[hidden email]> wrote:

> A quasiquoter is really a splice. That is [foo| blah |] is the same as
> $(foo "blah").  So it might be easier to discuss your question in the
> context of ordinary splices and quotes.  You want foo to return code
> with a splice, thus:
>
> foo input_string = [| ...$(other_fun args).... |]
>
> But foo is in the Q monad anyway, so why not just run (other_fun args)
> right there in the quasiquoter?
>
> Or perhaps make a tiny example to show what you mean (but not using
> quasiquotation).

This may not make any sense, but consider something like this:

  $$(p "a: 1, b: $$(p \"x: 2, y: 3\"), c: 3")

Now, my understanding is that 'p' has a type like 'String -> Q (TExp
a)', where 'a' is instantiated with the expected type of the resulting
expression.  But I don't see how to synthesize the expected type for the
nested (antiquoted) call to 'p' without implementing my own version of
Haskell type inference.  I'd like to be able to return a term that
includes the antiquoted expression, and then rely on the type checker to
properly make the second call to 'p'.

 /g

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users