[ghc-steering-committee] Steering committee discussions

[Simon Peyton Jones]

Friend on the GHC proposals steering committee

I think it is helpful to have our shepherding process to drive debate to a conclusion.

But I think we are losing value by holding technical discussions on the email list, rather than on the proposal's own thread.  I'm not sure if the steering committee email list is visible to all; but even if it is, the info on a particular proposal is harder to find.

The thread below is a case in point.  Good stuff from Joachim, but not visible to the author or the world; result, lost insights.

Suggestion: could we hold all the committee debase on the proposal thread, thereby allowing the author to chime in if need be?   There might be some messages we want to be private -- very well, use the email list for those, but my sense is that 95% are absolutely publishable.

What changes when the shepherd kicks in?  Answer: the committee switches from observer (and contribute if you like) mode, to obligation-to-consider mode.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 20 February 2018 03:37
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Plugin recompilation avoidance
|  interface (#108)
|  
|  Hi Ben,
|  
|  thanks for kicking this off.
|  
|  Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari:
|  > The proposal addresses a long-standing limitation (#7414) of the GHC
|  > plugin interface which has become increasingly visible to users in
|  > recent years. While the particular approach proposed breaks existing
|  > plugin users, it is expressive enough to allow GHC to perform more
|  > aggressive recompilation avoidance in the future [1]. Moreover, the
|  > smart constructors proposed should make for a reasonably smooth
|  > migration path.
|  >
|  > Given that the plugins appears to have buy-in from a few notable
|  > plugin authors, I recommend that we accept this proposal.
|  
|  How realistic is it to do the partial module recompilation thing that
|  warrants multiple PluginRecompile values per module? For this to be
|  useful the compiler would have to
|  
|   * calculate the typechecker plugin’s hash for module M
|   * notice that it has changed, and start compiling M
|   * but then, when we have core, magically notice that the output of
|  the
|     desugarer has not changed, and consider to abort calculation
|   * but then notice that a core2core plugin was involved, and ask that
|     for the new hash
|   * and then this hash must be unchanged
|   * and then really the compilation has ended.
|  
|  Is that realistic? Can someone fill this example with concrete life?
|  
|  Maybe I am just not seeing what people have in mind – but I feel
|  unless this really is more than a very vague idea, we should consider
|  the simpler variant where each plugin gets to calculate a single hash
|  per module – and not possibly many in various stages.
|  
|  Another way of putting it: The compiler pipeline is (simplified)
|  
|   1. decide what to compiler
|   2. parse
|   3. typecheck
|   4. desguar
|   5. optimize
|   6. code gen
|  
|  Plugins so far hook into step 3 and 5. Every one of these steps
|  probably eventually deserves a plugin hook. This proposal is about
|  adding one to step 1. With this view, I find the “add a single
|  function to Plugin”, as described in
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F108%23issuecomment-
|  362671438&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b7e868
|  c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654694617
|  3205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
|  JBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=C4lfSbadTT23lvfARKolUVSPfPfJSt5PvqJDTvJfYFQ%3D&reserved=0
|  much more convincing.
|  
|  Cheers,
|  Joachim
|  
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b
|  7e868c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636546
|  946173205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
|  zIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=w7Bv0He4imipDZAdnZhNc2EEwXCo7ejMNZ1o%2BGp7HWU%3D&reserved=0