My instinct is UnboundVarE: it's explicit, and that is seldom bad. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard | Eisenberg | Sent: 09 October 2015 17:32 | To: ghc-devs@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, | though.) | | So, what do you think? To UnboundVarE or not to UnboundVarE, that is the | question. | | Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267 | Diff: https://phabricator.haskell.org/D835 | | Thanks! | Richard | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c31384b65553a47651fa | a08d2d0c721fc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WBXdy40hgMEz3EP | n5OX8OXc30PkNJIY6B91Q0BDb%2beY%3d