On 2007-11-13, Jules Bean <[EMAIL PROTECTED]> wrote: > Simon Peyton-Jones wrote: >> | "For technical reasons, GHCi can only support the *-form for modules >> | which are interpreted, so compiled modules and package modules can >> | only contribute their exports to the current scope." But it does mean >> | the interpreter isn't referentially transparent, which is weird for a >> | language that puts so much stress on referential transparency. >> >> Well it depends on what you mean by "referential transparency" -- but I'll >> agree 100% that the behaviour you described in your original message is >> surprising, and therefore unwelcome. >> >> Nevertheless, I think there's a good reason for it. The "technical reasons" >> are not just laziness on our part. By exporting only the functions named in >> the export list, GHC can inline everything else vigorously, and that can in >> turn give big performance improvements. We don't want to arrange that every >> top-level definition is treated as exported *just in case* someone wants to >> GHCi that module. >> >> This is behaviour that could be changed. E.g. we could say that the >> top-level scope remains available unless you optimise with -O2. Or >> something. But there has to be a surprise lurking somewhere. > > I don't suggest a change to your ABI or anything like that. > > I just suggest that the interpreter - ghci - should, by default, always > load a ".hs" file in interpreted mode, ignoring the .hi and .o already > present. After all, a ".hs" file contains source code and ghci is a > source code interpreter; I submit this would be the least surprising > thing to do. > > When it loads dependent modules, I think it can safely load the .o/.hi > versions as it does now if they exist, since we don't expect full symbol > table access there.
I _like_ being able to interactively apply bits of code, whether compiled or not, and I like being able to compile them and get it to go faster. This would be a step back, for me. -- Aaron Denney -><- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
