Hi Chris | If you can remember a few months ago we discused porting HaRe over to GHC, | and at the time I had to focus on writing up my PhD thesis. My PhD thesis | is pretty much ready for submission (within the next couple of days) and I | was wondering if there was an opportunity to continue the porting work | done by Chaddai, or if Chaddai continues to do his porting work, whether | there would be opportunites to speed up the process or to concentrate on | porting specific refactorings of HaRe over to GHC.
It'd be great to continue porting HaRe to the GHC API. If that was We had a productive meeting with Simon T, Claus, Chaddai a few weeks ago. I enclose the notes I took of that meeting. Can you talk to Simon T about how best to proceed? My sense is that * It's best if the initiative lies with you (the HaRe team); else things get stalled on Simon and me * Thomas Schilling is changing the GHC API, and I think we'll fold his changes into 6.10. We're going to want to continue to evolve the API for a while; it's too early to freeze it. * We're very open to suggestions about how to improve the API. It's by *no means* cast in stone. * One big issue that came up at the meeting was the mechanism for preserving comments. We had a plan; I'm not sure how advanced it is. Simon
--- Begin Message ---Generics · GHC can derive Typeable, Data. And standalone deriving is supported, so you can put all these instances (and the libraries that depend on them) in a standalone package. · Having a standalone GHC API extension package, depending on package 'ghc' that comes with GHC, would be a good thing in any case. · Some GHC types are abstract (eg NameSet). a. expose them to the instance module b. hand write instance that uses access functions c. derive the instance in the original source module · We don't need more than Data and Typable at the moment. In due course, to gain efficiency, we might want a. GHC to be able to derive some other class (eg Uniplate) b. or use TH to derive other classes c. or use Derive to derive other classes But this isn't urgent. · Desirable to fix #2438 (nonlinear compilation time for instances) Comments, pragmas, and layout · Currently GHC's parser throws away comments. But keeps Haddock comments and pragmas. · Too much Haddockery is inside GHC. Plan: API should expose a function that Haddock can call, which converts a string to a Name, using the top-level environment to resolve it. (Haddock names are always resolved in the top-level scope, never nested.) · Proposal: lexer can run in two modes: 1. as now: lexer cooperates with parser to generate layout tokens; discards comments 2. new: lexer keeps comments (new kind of token), and generates tokens only for concrete lexemes (no added layout tokens) GHC API would need a new function something like moduleTokenStream :: Module -> Ghc [Token] Chaddi with hand-holding from Simon M · Output phase of Hare uses (2) to re-lex the source file, and combine: 1. The token stream 2. The new AST to produce a new token stream that is printed. This is a Hard Problem, with heuristics, but Hare already does this. This function might be useful to othe people, if offered as a standalone library. · Perhaps Haddock could likewise use (2). That would remove more Haddockery from GHC, esp removing HsDoc fields from GHC's HsSyn data types. · Pragmas that GHC understands are put in the syntax tree. Others are treated as comments. Does Hare want to manipulate RenamedSource or TypecheckedSource? · Ideally the latter, because then Hare gets easy access to type info · But instance declarations are tricky. · And type/class declarations simply don't have a Typechecked syntax tree; instead they've been converted to TyThings · BUT there is no current API call to get the Renamed source, because of TH: o module M where { x = 3; $(f); h = x } o what is the occurrence of 'x' bound to? · Currently, the "checkModule" (Thomas's API: typecheck) returns the post-TH renamed declarations all concatenated. No TH splices => it's just what you'd expect: the renamed module declarations. Multi-module situation · To get access to the source code of each module of a package: o get the module graph, in topological order (there's a function for this) o call typecheckModule on each (or something like that) in dependency order o keep track of the typechecked source returned from each. · For some refactorings, though, typechecking all modules below might be overkill; looking at the interface files alone would be enough. Thomas's work · Instead of printing random error messages, all errors now handled through the Ghc monad. (An error monad + reader monad) · Likewise, now need for 'Maybe' results. The monad checks for success at each call. · Can you use the new extensible exceptions? Perhaps the Ghc monad could be just a Reader monad, and use (extensible) IO exceptions..... Simon and Thomas to discuss offline? · Largely refactoring existing API; but willing to add stuff in response to specific requests from Kent.
--- End Message ---
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
