#4372: Extending quasiquotation support
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Template Haskell  |      Version:  6.12.3      
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by gershomb):

 This is all shorthand, you're right. But the syntactic sugar makes a huge
 difference here. In quasiquote syntax, the only quotation issue that an
 end user has to worry about is the bar followed by close bracket. In
 standard splice syntax, the quoted expression is forced to respect all the
 rules of haskell. Multiline strings either use the \ syntax are have to be
 written with explicit appends. Double quotes need additional escaping,
 etc. Furthermore, error messages can't give nearly as nice locality.

 With quasiquotes, its possible to write very fluently in an embedded dsl
 with almost arbitrary concrete syntax. Template Haskell splices on their
 own make doing so very painful.

 Most of the libraries using quasiquotation that I now know of would be
 extremely painful to use without the shorthand syntax provided by
 quasiquotation.

 In general, Kathleen's preference is fine -- super lightweight syntax for
 the simple case, and extended syntax for the extended case. This causes a
 bit more work at the lexing level, and in the parser (but only a few
 lines), but subsequent to that there's a single code path which is as
 simple as or simpler than what exists now.

 In fact, '[$' for introducing an extended quoter and '|' alone for
 introducing the quotee, which is what I've now implemented, seems fine to
 me as well, unless there is strong sentiment otherwise.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4372#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to