I'll just pipe up here that Galois is interested in any effort
put into refactoring tools.
If you ever want beta testers, or advice on real world refactoring
issues, yell.
simonpj:
> 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
> Date: Thu, 7 Aug 2008 16:20:32 +0100
> From: Simon Peyton-Jones <[EMAIL PROTECTED]>
> To: Simon Peyton-Jones <[EMAIL PROTECTED]>, Thomas Schilling
> <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>, Simon Marlow <[EMAIL PROTECTED]>,
> Huiqing Li
> <[EMAIL PROTECTED]>, "C. M. Brown" <[EMAIL PROTECTED]>, Simon Thompson
> <[EMAIL PROTECTED]>, Chaddaï Fouché
> <[EMAIL PROTECTED]>
> Subject: GHC Api meeting
>
> 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.
> _______________________________________________
> Cvs-ghc mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
