| 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:da...@well-typed.com] | Sent: 30 May 2017 22:06 | To: Simon Peyton Jones <simo...@microsoft.com> | Cc: Alan & Kim Zimmerman <alan.z...@gmail.com>; ghc-devs@haskell.org | Subject: Re: Trees that Grow in the hsSyn AST | | 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs