| (*) a standard haskell' api providing the commands of ghci/hugs | style interactive systems would be a start, together with an | annotated AST, parser/typer/pretty printer. more detailed | specifications could be left for future revisions. A reasonable suggestion, but I'm unsure what you actually have in mind.
what I have in mind are things to come, which would be quite different from the initial steps we could reasonably expect Haskell' to take. initially, a separate libary may be an acceptable start; but ultimately, I don't want two separate Haskell implementations shipped for each installation. for the moment, I'd like the Haskell' committe to say this is useful, and commit to making a start, then see how far we can get. at the very least, Language.Haskell needs to be expanded on, to cope with modules, to provide type information, and to cope with language extensions [also, one might want to check whether SYB-style traversals, which are so useful for annotated ASTs, are permitted within the limitation of Haskell']. but even there, adding and maintaining a type/module system implementation would be more work than exposing the existing one, and the same goes if we want loading/evaluation as well. the difference between such an extended Language.Haskell and the standardized interface I suggested is that the former is one naive implementation of the latter. the difference between an extended Language.Haskell and the implementation by reflection I had in mind is that the latter reuses the underlying Haskell implementation to provide the same interface more efficiently (even if that might involve translating between internal types and those in Language.Haskell+). It is meta-programming because it allows Haskell programs to operate on representations of Haskell programs. It may use reflection to do so, if it permits Haskell programs access to their own representations and to parts of the implementation they are running on. I don't say to do it all perfectly for Haskell', but just to make a start that goes beyond current Language.Haskell. For that start, it may still be sufficient to leave most things in an library (**), and it doesn't have to support everything GHC's API does (though it does have to define implementation-independent interfaces). But ultimately, there will be ramifications for future language definitions (how to pass from programs to representations and back? how to type these things? how to extend programs at runtime? ... all the issues common to Template Haskell, hs-plugins, and type Dynamic [as done in Clean, not the poor man's version of Haskell]). Simon M adds extensible data types to the list. I'm sure there's more, once we start looking. I find it interesting to note the the folks who claim this is a libary-only problem are willing to put up with lots of non-Haskell' hacks, not to mention partially functioning work-arounds for features that belong in the language definition (a proper type Dynamic, for instance, with support for polymorphism, and with a way to address the issue of representations of types originating from separate programs). I'd prefer to flush out these secret hacks hidden in so-called libraries, and to call a language feature a language feature. Cheers, Claus "Ideals are like stars. You may never be able to reach them, but you can navigate by them." (**) one of the attractive things about early Haskell reports was the combination of language definitions and libraries.