#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 Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs