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
