Template Haskell bikeshedding: UnboundVarE or not?

[Dan Doel]

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
<simonpj at microsoft.com> wrote:
> My instinct is UnboundVarE: it's explicit, and that is seldom bad.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard
> | Eisenberg
> | 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,
> | 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 at 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs