I'm not much of a TH user, but this would be my choice, too. Requiring error/exception handling to get a piece of information doesn't seem like a typical design for Haskell libraries (and I'm happy that's the case).
On Fri, Oct 9, 2015 at 5:31 PM, Simon Peyton Jones <[email protected]> wrote: > My instinct is UnboundVarE: it's explicit, and that is seldom bad. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:[email protected]] On Behalf Of Richard > | Eisenberg > | Sent: 09 October 2015 17:32 > | To: [email protected] 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 > | [email protected] > | 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 > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
