At the moment HsExpr includes the following two constructors | ExprWithTySig (LHsExpr id) (LHsSigWcType id) | ExprWithTySigOut -- Post typechecking (LHsExpr id) (LHsSigWcType Name) -- Retain the signature, -- as HsSigType Name, for -- round-tripping purposes I do not understand why we need the second one, which hard-codes Name instead of id. There are a couple of places where there is an XXXOut variant with hard coded Name parameter, and these complicate creating any kind of custom class intended to work on a parameterised AST as it ripples out and forces Name instances of it everywhere. Perhaps we should introduce HsExprLR id id to cope with renaming? Alan
Yes this is annoying. The thing is that with the first constructor only we'd get (LHsSigWcType Id) after type checking, but we don't have such a thing. `HsTypes` are typechecked to `Types`. Perhaps we could have (LHsSigWcType (StopAtRenamer d)) where type family StopAtRenamer a where StopAtRenamer Id = Name StopAtRenamer x = x If this pattern happened a lot it might be worth it. But I think this is the only occurrence. Better ideas welcome. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan | & Kim Zimmerman | Sent: 19 December 2015 13:15 | To: ghc-devs@haskell.org | Subject: ExprWithTySigOut | | At the moment HsExpr includes the following two constructors | | | ExprWithTySig | (LHsExpr id) | (LHsSigWcType id) | | | ExprWithTySigOut -- Post typechecking | (LHsExpr id) | (LHsSigWcType Name) -- Retain the signature, | -- as HsSigType Name, for | -- round-tripping purposes | | I do not understand why we need the second one, which hard-codes Name | instead of id. | | There are a couple of places where there is an XXXOut variant with | hard coded Name parameter, and these complicate creating any kind of | custom class intended to work on a parameterised AST as it ripples out | and forces Name instances of it everywhere. | | Perhaps we should introduce HsExprLR id id to cope with renaming? | | Alan | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b | 3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX | bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d
Hi, Btw, I also used that annoying pattern in https://phabricator.haskell.org/D1185 to represent type-signature sections before/after typechecking: -- | Type-signature operator sections | TySigSection (LHsType id) (PostRn id [Name]) -- wildcards | TySigSectionOut (LHsType Name) (PostTc id Type) (PostTc id Coercion) I'd be interested in better ideas as well... On 2015-12-21 at 09:46:58 +0100, Simon Peyton Jones wrote:
Yes this is annoying.
The thing is that with the first constructor only we'd get (LHsSigWcType Id) after type checking, but we don't have such a thing. `HsTypes` are typechecked to `Types`.
Perhaps we could have (LHsSigWcType (StopAtRenamer d))
where type family StopAtRenamer a where StopAtRenamer Id = Name StopAtRenamer x = x
If this pattern happened a lot it might be worth it. But I think this is the only occurrence.
Better ideas welcome.
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan | & Kim Zimmerman | Sent: 19 December 2015 13:15 | To: ghc-devs@haskell.org | Subject: ExprWithTySigOut | | At the moment HsExpr includes the following two constructors | | | ExprWithTySig | (LHsExpr id) | (LHsSigWcType id) | | | ExprWithTySigOut -- Post typechecking | (LHsExpr id) | (LHsSigWcType Name) -- Retain the signature, | -- as HsSigType Name, for | -- round-tripping purposes | | I do not understand why we need the second one, which hard-codes Name | instead of id. | | There are a couple of places where there is an XXXOut variant with | hard coded Name parameter, and these complicate creating any kind of | custom class intended to work on a parameterised AST as it ripples out | and forces Name instances of it everywhere. | | Perhaps we should introduce HsExprLR id id to cope with renaming? | | Alan | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b | 3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX | bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- "Elegance is not optional" -- Richard O'Keefe
participants (3)
-
Alan & Kim Zimmerman -
Herbert Valerio Riedel -
Simon Peyton Jones