On Mon, Sep 8, 2008 at 12:29 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > I think that's a separate question. > > I'm saying that if you want to read in a ExtCore file, you'd better not have > recompiled any of the modules it depends on. But that's true for linking > too! If A imports B, and you recompile B you may well get link errors if you > link the old A.o with the new B.o. It's not specific to ExtCore at all. > > Maybe I'm missing your point?
Maybe I didn't state my point clearly, or maybe it was so obvious as to be easily missed. An External Core file should be like a Haskell source file at least in the sense that it doesn't depend on any strange names that appear in .hi files for libraries but that might not exist if your installed GHC had a set of libraries that was compiled with different flags or with a different version of GHC. It should be portable, in that so long as I have some installed version of any libraries it depends on, I should be able to compile it in a different environment than the one I generated under. I don't expect that if I send my Haskell files to someone else, I'll have to include sources for all the standard libraries as well. I also don't expect to be able to ship .o files around arbitrarily, because that's not what they're meant for, so while it's true that you would have the same problem with object code, External Core isn't object code. So I think if it's inescapably true that you can't read back in External Core files if you've recompiled libraries in the meantime, that's a pretty serious limitation of External Core, perhaps something that makes it not useful as a stand-alone format, even. Suppose J. Random Hacker builds the libraries unoptimized, generates some ext-core files for test programs, frobs them with some external tool, and then realizes it would be a good idea to rebuild the libraries with optimization on; then tries to get GHC to read in the ext-core files that were compiled against unoptimized libraries. I think it would be kind of surprising to find that GHC would refuse to accept a program that was generated from a perfectly valid Haskell file, and transformed in a perfectly valid way. It's perfectly OK that if I recompile any of my own Core modules, I have to recompile the rest. But I would expect libraries to behave differently. You were talking before about the possibility of only doing inlining within the same package -- or at least of having a flag that causes that behavior -- which I think would be solve the problem completely. I hope this makes more sense, but somehow I fear not. -t -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
