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
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
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
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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (3)
-
Dan Doel -
Richard Eisenberg -
Simon Peyton Jones