| > I'm a bit confused about TupleT . Is is supposed to be only used when | > synthesizing types? (i.e. reify will never output such a type)? | | Quasiquotes produce it: | | Prelude Language.Haskell.TH> $( do t <- [t| (Int, Bool) |]; runIO $ print t; [| 1 |] ) | AppT (AppT (TupleT 2) (ConT GHC.Base.Int)) (ConT GHC.Base.Bool) | | > Should this be considered a bug or a feature? IMHO it's quite ugly to | > have two valid representations for the same type in the same AST | > structure. | | I wouldn't be opposed to removing it (in fact, I think there is a | general feeling that lots of redundancies in the TH syntax should be | removed, e.g. the subthread starting with | http://www.haskell.org/pipermail/template-haskell/2006-August/000572.html | but no-one has yet taken the lead and proposed something). I agree. As in: I would not be opposed to removing it. But we'd just need to be sure there was a convenient way of conjuring up the appropriate data constructor for an n-tuple. Simon

I've been thinking about it for a while and the special TupleT constructor still seems pretty useful. However, I think it should only be kept if there's a way to guarantee that reify is consistent with the definition of Type (i.e. it should alwa produce TupleT and not "ConT ''(,,,)" and friends ) Furthermore I would find it more appropiate to split Type into Constructors and Types themselves (just like it happens in Data.Typeable and Language.Haskell.Syntax) data Cons = Cons Name | SpecialCons data SpecialCons = Arrow | Tuple Int | List data Type = ForallT [Name] Cxt Type | VarT ConT Cons | AppT Type Type On 11/2/07, Alfonso Acosta wrote:

On 11/2/07, Simon Peyton-Jones wrote:

...

I agree. As in: I would not be opposed to removing it. But we'd just need to be sure there was a convenient way of conjuring up the appropriate data constructor for an n-tuple.

TH.Syntax already provides:

tupleTypeName :: Int -> Name tupleDataName :: Int -> Name

IMHO, that should be enough