Haskell interface files: Why used? What about same data in object files?
Hi, I am trying to understand the design of the Haskell interface files. Why are they a separate file rather than having the same data in the object file generated by the compiler? (Naively, it seems to me this would work also. Am I missing something?) Thanks. Howard B. Golden Northridge, California, USA
I am trying to understand the design of the Haskell interface files. Why are they a separate file rather than having the same data in the object file generated by the compiler? (Naively, it seems to me this would work also. Am I missing something?)
Placing interface information into object files would be a perfectly reasonable design decision for a compiler. The language standard itself does not mandate the use of interface files (although it did once, around Haskell 1.2), nor any particular format, so a compiler is free to use whatever strategy it wishes. Some good reasons for having a separate interface are: they can be human-readable and human-writable (ghc's do not fulfill this criterion); they can be used to bootstrap mutually recursive modules in the absence of any object files (ghc uses .hs-boot files instead); other tools can extract information about modules without having to understand either the full Haskell syntax or the object language. Regards, Malcolm
Hi
Some good reasons for having a separate interface are: they can be human-readable and human-writable (ghc's do not fulfill this criterion); they can be used to bootstrap mutually recursive modules in the absence of any object files (ghc uses .hs-boot files instead); other tools can extract information about modules without having to understand either the full Haskell syntax or the object language.
An additional reason is that for some changes of .hs file (where just the implementation changes) the .o file can be regenerated without touching the .hi file. This allows more accurate build dependencies and less recompilation. Thanks Neil
Hello,
On Tue, Aug 4, 2009 at 2:50 PM, Neil Mitchell
Hi
Some good reasons for having a separate interface are: they can be human-readable and human-writable (ghc's do not fulfill this criterion); they can be used to bootstrap mutually recursive modules in the absence of any object files (ghc uses .hs-boot files instead); other tools can extract information about modules without having to understand either the full Haskell syntax or the object language.
An additional reason is that for some changes of .hs file (where just the implementation changes) the .o file can be regenerated without touching the .hi file. This allows more accurate build dependencies and less recompilation.
Is that really the case? I thought that GHC may add code to the interface files for cross-module inlining purposes, which means that changing the implementation might change the interface too. -Iavor
for some changes of .hs file (where just the implementation changes) the .o file can be regenerated without touching the .hi file. This allows more accurate build dependencies and less recompilation.
Is that really the case? I thought that GHC may add code to the interface files for cross-module inlining purposes, which means that changing the implementation might change the interface too.
Indeed, GHC _may_ change the interface file for such reasons, but it may equally decide to leave the interface untouched, e.g. if there are no new inlinings. Regards, Malcolm
participants (4)
-
Howard B. Golden -
Iavor Diatchki -
Malcolm Wallace -
Neil Mitchell