Re: [Haskell-cafe] [GSoC] Porting HaRe to use the GHC API
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ï
|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. refactorings crossing external APIs are a very real problem, and when i last checked (several years ago..), published solutions went little further than establishing informal work-patterns ("if you do it like this, you'll save yourself and us some trouble. if you want to stay on our project, you'd better do it like this") or boundaries to limit the spread of refactoring effects over distributed projects. my own favourite approach expresses the process as a "buffered refactoring", with an adapter module serving as the buffer and formal spec of your "interface diff" (with apologies for ascii art;-): L: some library code I: L's external API C: some external client of L 0. C uses L, via I: L |I| C 1. introduce internal proxy/adapter A: { L |I| A } |I| C 2. refactor internally, leaving external API I unchanged while creating new internal API I': { L' |I'| A' } |I| C 3. publish L's new interface I', together with refactored adapter A', and deprecate old interface I: L' |I'| { A' |I| C } 4. clients can refactor to new interface, eliminating adapter A': L' |I1'| C' when it works, this approach has the advantage of formalizing every part of the process as a sequence of refactorings, and clients have the choice either to continue using the adaptor, ignoring the new interface in favour of the old one, or to get rid of the indirection and to use the new interface directly, by pushing the refactoring that started in the library code into their own code base. you could combine that with giving clients the sequence of refactorings that turned A (just re-export) into A' (implement old API in terms of new one), as it might help them to proceed. |But all of that should wait after we get HaRe working with the GHC API. :-) good to hear that - it is all too easy to get side-tracked when there are so many interesting problems!-) i just wanted to point out that soon after you get it working, there might be some disappointments due to GHC's source-less distribution installation model, use of cpp, etc. .. which just means that there'll be more work left after this necessary first step. claus
participants (2)
-
Chaddaï Fouché -
Claus Reinke