[GHC] #4372: Extending quasiquotation support

[GHC]

#4372: Extending quasiquotation support
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Template Haskell  |                 Version:  6.12.3
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by songzh):

 Replying to [comment:19 gershomb]:
 > At this point I consider this a "nice idea" but I'm not sure how to
 modify the parser to handle it within the many grammatical constraints we
 already have. The somewhat clunky syntax that was pointed out by Simon
 upthread is actually adequate for this. This, for example is the style
 adopted by Manuel's language-c-inline:
 >

 I am sorry for not being a GHC developer, I will try to be one. I have
 skimmed the parser in the source code. My understanding is that the
 quoters do not need to be all kinds of expressions since allowing only
 function application will be more than enough. If expression like CondE,
 MultiIfE, DoE, CompE should be not allowed in quoter position, the guarded
 expression and other syntax problem will vanish. For achieving this, maybe
 a specific parser for quoter position is needed. I am just blind guessing
 here.

 > {{{
 > nslog msg = $(objc ['msg :> ''String] (void [cexp| NSLog(@"Here is a
 message from Haskell: %@", msg) |]))
 > }}}
 >


 > Here, we use the quasiquoter to capture the expression, and then embed
 that quasiquoted expression itself within a TH block, in order to pass in
 additional information during codegen.
 >
 > If a lighter-weight syntax was possible, I'd remain all for it. But, I
 honestly can't think how to provide it given the constraints we have -- my
 patch at the time didn't really solve the problem, and I haven't had any
 better ideas since :-)

 I will look into the c-language package and your patch. Thanks.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler