RE: Trees that Grow in the hsSyn AST
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn.
Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it.
2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)?
I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering.
Simon
From: David Feuer [mailto:david@well-typed.com]
Sent: 26 May 2017 01:11
To: Simon Peyton Jones
As in my previous email to Shayan (attached). Wiki page, describe goals, design, approach. Point to prototype implementation. Seek comments. You can say that I am supportive!
Simon
We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1%2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243&sdata=fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D&reserved=0http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf%3chttps:/na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1%2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243&sdata=fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D&reserved=0> [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609
On Friday, May 26, 2017 9:03:15 AM EDT Simon Peyton Jones wrote:
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn.
Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it.
Don't get me wrong. I wasn't suggesting that Core should come first; I have absolutely no basis to make any suggestion in that regard. I was just wondering what led to the decision to start with HsSyn. Are you suggesting that Core wouldn't benefit from these ideas? I surely don't see why not. Information about arity and strictness, at least, is introduced in specific compiler phases. I believe that some information needed for join points is only valid/available between certain phases. Making such things explicit in the types seems like it can only help.
2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)?
I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering.
All right; I figured it wouldn't hurt to ask. May I ask what sorts of scaling problems you mean? David
| just wondering what led to the decision to start with HsSyn. Are you
| suggesting that Core wouldn't benefit from these ideas? I surely don't
Core, unlike HsSyn, is heavily optimised and transformed. It's hard to see how the transformations could soundly maintain arbitrary auxiliary information. Also unlike HsSyn, Core is a very small language, so it's no big deal to transform it into something else.
| All right; I figured it wouldn't hurt to ask. May I ask what sorts of
| scaling problems you mean?
Simply maintaining a finite map from binders to another binder, or arbitrary other info (eg strictness) can be challenging. Try it!
Simon
| -----Original Message-----
| From: David Feuer [mailto:david@well-typed.com]
| Sent: 30 May 2017 22:06
| To: Simon Peyton Jones
participants (2)
-
David Feuer -
Simon Peyton Jones