Thoughts on the design of External Core
atomb at soe.ucsc.edu
Wed Feb 14 19:49:37 EST 2007
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.
* 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
* 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
* 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.
* 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.
More information about the Glasgow-haskell-users