id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,os,architecture,failure,difficulty,testcase,blockedby,blocking,related
6062,TH treats non-functions in function position inconsistently,heisenbug,simonpj,"I start GHCi like this:
{{{
~/bin/ghci -XTemplateHaskell
}}}

My aim is to use TH to rewrite certain application-looking (syntactically) constructs to semantically valid haskell code, that passes the type-checker (c.f. Conor McBride's ""idiom brackets"").

But I already fail at very simple things, because GHC seems to type-check the TH quotation's innards...

This works:
{{{
Prelude> :t [| id id |]
[| id id |]
  :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
}}}

This is also accepted, though it is clearly not typeable:
{{{
Prelude> :t [| 1 1 |]
[| 1 1 |]
  :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
}}}

Encouraged by this I try:
{{{
Prelude> :t [| False True |]
<interactive>:1:4:
    Couldn't match expected type `Bool -> t0' with actual type `Bool'
    The function `False' is applied to one argument,
    but its type `Bool' has none
    In the Template Haskell quotation [| False True |]
    In the expression: [| False True |]
}}}

Bummer! Somehow the type-checker does get into business with ""expressions"" inside quotations.

I believe this is a bug, and a quotation should be built for {{{[| False True |]}}} in spite of {{{False True}}} not being typeable.

I know that using quasi-quotations I can build my own parser and rewrite engine around this, but that is a tad heavyweight for me and I'd like to understand the root of the above inconsistency and why the type checker gets active in some cases above, but not in others.",bug,new,normal,7.8.1,Compiler,7.5,,,,Unknown/Multiple,Unknown/Multiple,None/Unknown,Unknown,,,,