| 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
| Cc: Alan & Kim Zimmerman ; 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
