On 01/02/2010 14:25, Max Bolingbroke wrote:
Dominic Orchard and I have come up with a rather radical proposal for
a redesign of the syntax. There are two principal options:
OPTION 1 (preferred)
===============
Advantages:
1) QuasiQuotes are revealed as they really are - as splices. In my
opinion this is much less confusing, because a "quasiquote" is really
about generating *code*, like a $(), not about generating a *data
structure* like the existing [|e|], [t|t|] and [d|d|].
2) Unifies Template Haskell and QQ into one construct
3) QQ looks like "semantic brackets"
4) No list comprehension ambiguity
Disadvantages:
1) Small syntax changes to QQ and TH. Increased verbosity in some common cases.
Start with GHC Haskell. Remove [|e|], [t|t|], [d|d|] and [e|..|] syntax.
Add this new syntax:
Syntax: [|...|]
Type: String
Translation: "..." (i.e. this is an alternative string literal syntax)
Now change the semantics of splice, $(e), like so:
1) If e :: Q Exp and we are in an Exp context in the code, run the
computation and splice the resulting code in
Can you say precisely what it means to be "in an Exp context"? This is
a bit like Simon's type-directed name resolution idea, in that it's
adding in a bit of ad-hoc overloading. To understand this I think you
really need to write down (or at least sketch) the type system that
infers the context: e.g. you have to make clear what information is
taken into account (type signatures? the results of resolving other
overloading opportunities?).
2) (.. similarly if e :: Q Typ in a Typ context or Q [Decl] in a Decl
context. NB: this is what we had to do for TH before anyway)
3) If e :: QuasiQuote then select the appropriate field from the
evaluated "e" based on the context, run the Q computation it contains,
and splice the resulting code in
Where:
data QuasiQuote = QuasiQuote {
quoteExp :: Q Exp
quotePat :: Q Pat
}
Now provide exports from Language.Haskell.TH:
e :: String -> Exp
t :: String -> Type
d :: String -> [Decl]
The TH library would have to include a Haskell parser, which presents
some engineering difficulties. TH can't be mutually recursive with GHC,
so either the haskell-src-exts package has to be used or TH and GHC have
to be merged.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
