On Sun, Apr 15, 2012 at 7:14 PM, Steffen Schuldenzucker <[email protected]> wrote: > > > On 04/13/2012 10:49 PM, Ben Millwood wrote: >> >> I'm pleased to announce my first genuinely original Hackage package: >> notcpp-0.0.1! >> >> http://hackage.haskell.org/package/notcpp >> >> [...] > > > Why is it > >> scopeLookup :: String -> Q Exp > with n bound to x :: T => @scopeLookup n@ evaluates to an Exp containing > @Just x@ > > , not > >> scopeLookup :: String -> Q (Maybe Exp) > with n bound to x :: T => @scopeLookup n@ evaluates to Just (an Exp > containing @x@) > > ? Shouldn't n's being in scope be a compile time decision? That would also > make the "openState: runtime name resolution has its drawbacks :/"[1] a > compile time error. > > -- Steffen > > [1] > http://hackage.haskell.org/packages/archive/notcpp/0.0.1/doc/html/NotCPP-ScopeLookup.html
This way minimises the amount the user has to know about Template Haskell, because the user can just splice the expression immediately and then operate on it as an ordinary value. The design you suggest would require messing about in the Q monad to construct the expression you wanted based on whether you got a Nothing or a Just, which in my view is more awkward. I can see how your version would be useful too, though – in particular I can move the error call to a report call, which throws a compile-time error as you say. I'd be happy to expose both next version _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
