#5844: Panic on generating Core code
---------------------------------+------------------------------------------
Reporter: JamesFisher | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: External Core | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by simonpj):
Short answer Yes... but there is a longer and more interesting answer.
External Core is designed to round-trip, thus:
* External Core is a '''data type''' defined in `coreSyn/ExternalCore`.
* Core is converted to the External Core data type by
`coreSyn/MkExternalCore`
* The External Core data type is printed by `PprExternalCore` into
concrete syntax.
* The modified External Core can be parsed by `parser/ParserCore`.
However, it is not parsed into the External Core data type, but rather
into "Iface Core" defined in `iface/IfaceSyn`.
* The Iface Core data type (thus parsed) can be converted to Core by
`iface/TcIface`.
What is Iface Core? Iface Core is a data type that GHC uses every time
you compile a module. During compilation, GHC converts Core into Iface
Core, and then serialises Iface Core into the "M.hi" interface file, in a
binary format. This is done by `iface/BinIface`. Then, when GHC wants to
read an interface file, it de-serialises M.hi into Iface Core, and then
converts Iface Core into Core with `iface/TcIface`. ''What this means is
that Iface Core gets plenty of love: it is on our critical path.''
Why does "External Core" do the round trip via the ''External Core'' data
type on the way our, but via ''Iface Core'' data type on the way in? This
mis-match just an aretefact of an earlier era: when we first implemented
External Core, there ''was'' no Iface Core.
I think the Right Thing to do is to complete the change that we have
already started:
* Abandon the Exgternal Core data type entirely.
* The conversion from Core to Iface Core is already done (in
`iface/MkIface`), because GHC uses it every time it compiles a moudle.
* Change the pretty-printer for External Core to pretty-print the Iface
Core rarther than External Core. In fact there already ''is'' a pretty-
printer for Iface Core, in `iface/LoadIface.pprModIface`, although it
might require minor modification.
The bottom line is that we'd be abandoning the External Core ''data type''
(though not its concrete syntax), and switching entirely to Iface Core,
which is much better maintained. Less code, more robust to change; what's
not to like?
Now, while I say that there is a pretty printer for Iface Core already, it
is designed mainly for humans; it is used when you say `ghc --show-iface
M.hi`, and for no other purpose. The External Core concrete syntax, on
the other hand, is designed to be '''parseable''' as well, so that the
round-trip mechanism (print Exgternal Core, modify it, and read it back
in) works right. But I think it would be quite acceptable to modify the
Iface Core pretty-printer to use External Core syntax, because the Iface
Core pretty printer has an output-only role in GHC. (If you do this, I
suggest you put the new pretty-printer in a module of its own, perhaps
`iface/PprIface`.)
If this was done, the maintenance burden of External Core, if/when we add
new features to Core, would be reduced to
* Designing new concrete (ASCII) syntax for the new features
* Writing the pretty-printer and parser for this new syntax
I do think that the concrete syntax of External Core should be described
by a human-readable BNF grammar, not only by a Happy parser. We have a
very old Latex document describing External Core (including is syntax);
I'd like to see it become a full part of the documentation, perhaps by
convrting it to SGML and making it a full part of the GHC user manual.
This isn't a big task, and it's one that is well separated from the rest
of GHC. Would anyone like to take it on? I'd be happy to advise if so.
I wonder who uses External Core?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5844#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
