Template Haskell bikeshedding: UnboundVarE or not?
Simon Peyton Jones
simonpj at microsoft.com
Fri Oct 9 21:31:10 UTC 2015
My instinct is UnboundVarE: it's explicit, and that is seldom bad.
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard
| Sent: 09 October 2015 17:32
| To: ghc-devs at haskell.org Devs
| Subject: Template Haskell bikeshedding: UnboundVarE or not?
| Hi devs,
| Jan Stolarek has been hard at work allowing Template Haskell to deal with
| holes in expressions. Thanks, Janek. In this patch, any unbound variable
| is treated like a hole, which is exactly the way that GHC normally treats
| unbound variables these days. This is great -- it allows TH quotes to work
| with unbound names.
| The question is this: suppose a user writes [| x |], where x is unbound.
| Should that produce a (VarE (mkName "x")) or an (UnboundVarE (mkName
| "x")), where UnboundVarE is a new constructor for Exp?
| Reasons for UnboundVarE:
| - It communicates information GHC has to clients of TH.
| Reasons against UnboundVarE:
| - UnboundVarE and VarE are treated identically in *splices*. The only
| point of UnboundVarE is in the output of *quotes*. This may be confusing
| to users.
| - The information communicated by GHC to TH can be gotten by other means.
| Specifically, if you try to `reify` an unbound name, you'll get an error
| (which can be caught gracefully). Bound names `reify` correctly. So a TH
| client can figure out the boundedness of a variable, albeit awkwardly and
| in a monad. This counts as a reason against UnboundVarE because the
| distinction between UnboundVarE and VarE is technically redundant. (You
| could also probably learn this information by looking to see if a Name has
| a Unique attached to it. But that's a bit dirty. At least it's pure,
| So, what do you think? To UnboundVarE or not to UnboundVarE, that is the
| Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267
| Diff: https://phabricator.haskell.org/D835
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs