[ghc-steering-committee] Source plugins (#107), Recommendation: accept

[Simon Peyton Jones]

I like this in principle.  I've added some comments on the proposal thread itself.

At the moment the renamer and typechecker are run as one, which leads to extra complexity.  Now we have both untyped and typed splices, I think we can separate the two:

- untyped splices run in the renamer
- typed splices run in the typechecker

So we can completely rename the module, including running any untyped splices (of course the code we actually run is typechecked) before typechecking any of it.

But this design complication isn’t the fault of this proposal.  It's just highlighted by it.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Christopher Allen
|  Sent: 03 April 2018 03:16
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Source plugins (#107),
|  Recommendation: accept
|  
|  Dear Committee,
|  
|  Chris Allen here!
|  
|  GHC source plugins were proposed by Boldizsár Németh.
|  
|  The PR discussing the proposal is here:
|  https://github.com/ghc-proposals/ghc-proposals/pull/107
|  
|  Rendered at:
|  https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-
|  plugins.rst
|  
|  This proposal suggests the extension of the existing tlugin support in
|  GHC with plugins that are able to access and modify the representation
|  of the Haskell syntax tree and its environment. This would allow tool
|  developers to base their tools on GHC plugins.
|  
|  A version of the proposal is already implemented at:
|  https://phabricator.haskell.org/D4342
|  
|  My present main concern would be the issues with recompilation that
|  the current patch introduces but that seems like a problem with an
|  implementation rather than the proposal. That's an issue for the GHC
|  devs themselves to sort out, as I understand it.
|  
|  It's not obvious to me that the unresolved questions could be answered
|  with deliberation rather than implementation and exploration. I am far
|  from an expert on GHC plugins but from what I've been able to read
|  about them I don't see any blockers in this proposal as-written.
|  
|  I reached out to a couple of people that have hacked on or around GHC
|  in the past and it seemed like they were most keen to find out what
|  problems of theirs this proposal would solve. I didn't see any actual
|  objections raised.
|  
|  I recommend we accept this proposal in the current form or with
|  further elaboration at the author's option. However, my recommendation
|  here defers to the experience of others on the committee who know more
|  about the plugins API and the substance of this proposal.
|  
|  --
|  Chris Allen
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee