Over the last few days, I've put some more thought into the overall design of External Core. I looked through some of the GHC code some more, and I'm leaning toward a preference for using IfaceSyn throughout the whole External Core processing path. Simon, feel free to digest this at your leisure when you return. I also welcome feedback from anyone else. I don't assume that either of the following lists is complete or fully correct, and would like to hear any comments or criticism. Now, on to what I see as the pros and cons of using the Iface infrastructure for all aspects of External Core. Pros: * The input segment of this path is largely complete already. It needs a little fixing up (some of which I've already done), but the general design seems sound. * The code in HscMain that calls emitExternalCore is in the middle of the Iface processing pipeline. So, full Iface information is already available. If I understand things correctly, this means that all of the code of the current module is already in scope in IfaceSyn format. Maybe I'm wrong, though, and only type signatures are fully present? * Though I hear that the Iface typechecker generally assumes the absence of errors, the best long-term design decision might be to beef it up to the point where it can really tell you what's wrong when given ill-typed input. It is an external representation, after all. Currently, it's only likely to have come from GHC itself. Perhaps in the future other tools will also manipulate .hi files, however. Using IfaceSyn for External Core would encourage us to improve the typechecker, which would make interfacing with such tools more viable. * It looks like it would be straightforward to pretty-print IfaceSyn in ExternalCore format directly. It has almost exactly the same set of data constructors as (the old) ExternalCore does. The conversion from Core -> Abstract ExternalCore -> Concrete ExternalCore seems unnecessary. We could just do IfaceSyn -> Concrete ExternalCore. Cons: * If the Iface typechecker is indeed less than helpful in the face of errors, it will need to be improved. * I may be missing complications that would make the picture less rosy than I've implied. * One approach to the architecture of GHC (which I had in mind originally) is that all "source code", in whatever format, should somehow go through the HsSyn portion of the compiler. Thus, this part of the compiler does all of the real error checking, whereas the rest can assume certain correctness properties. Using IfaceSyn for External Core would violate this architectural assumption. Aaron