On Sun, Apr 15, 2012 at 7:14 PM, Steffen Schuldenzucker
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-Sco...
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