2008/4/1, Claus Reinke
as for the project, the are actually two APIs to consider, GHC's and HaRe's, and the main stumbling points are those things that are not in those APIs (explicitly or at all):
<snip>
Many thanks for the valuable insights. I intend to work in close collaboration with the Kent team, indeed I'll do an internship over the summer with Simon Thompson ! Don't worry on this point. Of course I'll also try to work with the GHC developers on the subject of the GHC API. My objective is to make it work on the 6.8 API but if it appears that certain functions would be useful in the future API I'll be sure to report this to the GHC team. If I can, I would also like to be present during the discussion between the two Simon. Another notion I was interested in was to be able to reproduce a sequence of multi-module refactorings even in the absence of the initial module. It would allow to present a kind of "interface diff" for a distribution which would allow the developer of a module which depends on the distribution to update the call to this library. Of course it wouldn't be perfect and wouldn't convey the semantic modifications of the interface but it would help for all the renaming and usual modifications of external interfaces. To refactor modules that use CPP, I can see some possibilities : transforming the macro into placeholders (undefined) and inversing the transformation after the refactoring, trying every combination of the variables for the #ifdef/ifndef, forgetting those that don't compile and confronting the refactorisation of the others to see if they merge... That would need some work and would probably be very inefficient as it is But all of that should wait after we get HaRe working with the GHC API. :-) -- Chaddaï