Llvm is also a good reference for compiler plugin design; it would appear that Scala borrowed from their approach.
-scooter
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: austin seipp
Austin
| So, given that 7.2 will be released much earlier than the normal | release cycle, is there any room for anything else to get into HEAD | for the 7.2 release before everything is switched? In particular I | fixed up Max Bolingbroke's old compiler plugin work to be usable with | the latest HEAD, and all the fundamental work is there and done, just | some additional small things are needed (notably having ghc dump | plugin information a la -ddump flags, and testsuite patches are about | it I think.) The patch itself is pretty small and doesn't touch *too* | much code, mostly adding dynamic loading and the plugin API, but it's | arguably adding a 'big' feature for users of GHC to start utilizing, | and perhaps a release in 7.2 would cause problems merging changes | until you cut a new STABLE branch with git, like you said.
I'm sorry I've been slow on this. "Review and apply the plugins patch" is in my inbox, but it's been queued up behind too many other things, notably making the new typechecker work.
That's fine! One thing at a time. The typechecker overhaul is great IMO, and I've noticed it's fixed many strange GHC bugs relating to type system feature interactions (including a few I hit.) Much appreciated work!
I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change.
This is very reasonable and I was going to mention it once someone responded. Up to this point, Max has really been the main person to write any plugins for GHC using the current interface. I would really welcome anybody interested in hacking on GHC look at the current API in the patch - my main concern up to this point is that the actual means of installing passes into the Core pipeline, the installation function of type `[CoreToDo] -> CoreM [CoreToDo]`, is a little fragile. Scala's approach seems to be to have plugins specify 'runAfter' and 'runBefore' constraints, which specify what compiler phases should run before and after the plugin's pass in question (and certain phases may run multiple times, so as a consequence, so does your plugin.) If I remember correctly, this was somewhat similar to the original design Max proposed which was to specify in which phase the pass is run, and it essentially amounted to a phase constraint. Perhaps Max can elaborate on why this design was rejected in favor of the current one, so we can see how and where it falls down, and what we really want. Thomas pointed out the Scala compiler plugin design document, so I'll be sure to read over it this weekend when I get the chance to cook up ideas. Also worth noting, like I said, is I would inevitably like to extend compiler plugins to work on Cmm, once the new codegen (using hoopl) hits. Maybe even allow you to write a new backend ultimately if you wanted to, although I'd call that the last and ultimate challenge at this point (because from my cursory glances, it would require quite a bit of re-engineering and re-design of the driver and compilation pipeline, much more so than just the Core plugins did or Cmm plugins might. That's a bit more time than I have... at the moment ;) To accumulate ideas and comments I've spent the past few days writing up a wiki page (mostly written in the wee hours of the morning no less), documenting the current API, how it might be improved, and future work like C-- plugins or plugins implementing new backends. Most of it is half baked. And half-written. Probably grammatical errors and run-on sentences. Incomplete sections. Likely with big, stupid ideas. Caveat emptor, etc. The wiki page in all its (horrid, half-written and mangled) glory can be located here: http://hackage.haskell.org/trac/ghc/wiki/NewPlugins If people can comment and add ideas, it will be much easier to determine if this should go into 7.2.1. If the current API is too fragile or needs to be expanded, it would likely be best to back out and do some work, and try again for 7.4.1. That will also give a much bigger window for feedback and testing, since 7.2 will be on a much shorter cycle it seems. I'll probably end up throwing up a RFC on both glasgow-haskell-users and cvs-ghc sometime in the next week to get feedback after more brainstorming, because it's the most important thing as of right now and for any future work in this area, in my opinion, since it will be a publicly exposed API for users to write code against.
The fact that you are actively engaged, have done the work with Max, and are (I assume) happy to respond to user queries, fix bugs etc, is a major incentive. Thank you!
I'm more than happy to respond to any user queries and respond to bugs people come up with, yes (Max seems to be working on lots of other things at the moment, and I like this functionality and would be willing to support it.)
So yes, because of that I undertake to do this for 7.2 [unless Simon M tells me no :-)]. I'll add a few thoughts to the ticket right now. http://hackage.haskell.org/trac/ghc/ticket/3843. Interested parties, add yourselves to the cc list of the ticket.
Simon
Thanks for your time Simon. -- Regards, Austin _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users