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... 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

This looks like a natural extension of what we currently do. I'm in favor. Richard
On Apr 2, 2018, at 10:16 PM, Christopher Allen
wrote: 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...
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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

Hi, Am Montag, den 02.04.2018, 21:16 -0500 schrieb Christopher Allen:
I recommend we accept this proposal in the current form or with further elaboration at the author's option.
we only got positive responses here, so accepted as the 17ths proposal. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
participants (4)
-
Christopher Allen
-
Joachim Breitner
-
Richard Eisenberg
-
Simon Peyton Jones