#14092: hs-boot unfolding visibility not consistent between --make and -c -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * keywords: hs-boot. => hs-boot Comment: Thanks for this explanation ezyang, this is a very tricky area and I think I'm finally starting to understand what's going on. Note that your first example can be modified to exhibit another bug: to A.hs add {{{ h = f }}} to C.hs change to {{{ g = h 2 }}} This compiles in --make mode, even though C should not be able to see h! You say that -c behaviour is correct, and in the sense that it is predictable and deterministic, of course you are right. However, the current --make behaviour produces code that is at least as good(modulo the bug exhibited above), and in your first (A.hs-boot, B.hs, A.hs, C.hs) example, it is better! I wonder if it is possible to exploit laziness to always have unfoldings available even when importing an .hs-boot. trac:13299 seems relevant. I am currently working on an idea to split parsing, typechecking, simplifying, and codegen for the purpose of allowing more parallelism in --make mode. (I have a mostly-working patch, which I hope to have on phab this week, although it will be a little untidy). This might allow having unfoldings available from .hs-boot imports. Regarding "views" into the home package table, I think this may be a fruitful idea. It seems to me to offer nice solutions to this ticket, as well as trac:9370. :pieinthesky: I have thought of storing in interface files, instead of an unfolding, loosely a "map" of (way, OptimizationSettings)->unfolding. This would require the notion of views into the home package table. I think this would help address problems such as trac:10923. It would also allow eliminating the idea of "way" interfaces (.dyn_hi, .p_hi, etc), with all of that information in a single .hi file. I do admit that I'm not sure exactly what benefit removing way interfaces would provide, except that it does seem cleaner to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14092#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler