These days, hs-boot files are pretty close to source files, with masses of stuff omitted. However, you must process the import declarations of the hs-boot file to figure out the name spaces involved. In the original source file, you can't process the import declarations because those modules have not been compiled yet. It's not clear which ones to omit. Similarly in the body of the source file, there are lots of references to things in imported modules, but those imported modules have not been compiled yet. You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot. But GHC currently requires the programmer to perform (b) manually. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ben Rudiak-Gould | Sent: 23 February 2006 21:26 | To: haskell-prime@haskell.org | Subject: Re: Export lists in modules | | Malcolm Wallace wrote: | > An explicit interface would be useful for many purposes besides | > machine-checked documentation. For instance, it could be used to | > eliminate the hs-boot or hi-boot files used by some compilers when | > dealing with recursive modules. | | Why *does* ghc require hs-boot files? What can be gleaned from an hs-boot | file that couldn't be expressed in the corresponding hs file? For example, | why doesn't ghc simply require that at least one module in a recursive group | contain an explicit export list mentioning only explicitly typed symbols? | | -- Ben | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://haskell.org/mailman/listinfo/haskell-prime
Simon Peyton-Jones wrote:
a) compiling recursive groups "all at once"
just for reference, Sun's java compiler seems to do exactly that, see SEARCHING FOR TYPES in http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html Example: have these mutually dependent classes (each in its own file) class A { static B foo () { return new B (); } } class B { static A foo () { return new A (); } } and you call "javac A.java" (or the other) then it compiles both. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Fri, Feb 24, 2006 at 12:13:14PM -0000, Simon Peyton-Jones wrote:
You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot.
jhc does a, then spits out a single .ho for all files in each recursive group. it then links the .ho file to each of the locations it might be searched for. (but it only needs to be found once) there is a method somewhere in between. Though, it will redo a bit of work but should be easier to implement for ghc. Imagine A and B depend on each other. When ghc comes across module A, it sees it depends on B which depends on A. It then renames and typechecks them together as a group but then discards everything but what is defined in A upon conversion to core. so the .o file ends up containing just what is defined in A as is expected. When the compiler gets around to compiling B, the .hi file for A will already be written and up to date, the cycle is broken and B compiles like normal. the main caveat is that one module in each cycle will get typechecked twice, but compared to the total compile time, that is not much overhead at all. I have been meaning to add transparent native recursive module support to haddock, it is only a hundred lines or so I can port from jhc and it would let me provide haddock docs for the jhc standard library. I assume the version in the fptools darcs repo is the one I should be developing against? John -- John Meacham - ⑆repetae.net⑆john⑈
On Fri, 2006-02-24 at 12:13 +0000, Simon Peyton-Jones wrote:
These days, hs-boot files are pretty close to source files, with masses of stuff omitted. (snip) You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot.
FWIW, I would be thrilled to see automatic resolution of mutually recursive modules. When programs start to get large, this always ends up biting me, and I have to either write & maintain the hi-boot files, or stuff everything into one module. Remembering how to do .hi-boot or .hs-boot files is a bit of a mental barrier for me when I'm trying to refactor and clean up code. peace, isaac
participants (4)
-
isaac jones -
Johannes Waldmann -
John Meacham -
Simon Peyton-Jones