Trees that Grow in the hsSyn AST

[Simon Peyton Jones]

| 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 at well-typed.com]
| Sent: 30 May 2017 22:06
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: Alan & Kim Zimmerman <alan.zimm at gmail.com>; ghc-devs at 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