Thoughts on the design of External Core

[Aaron Tomb]

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