[Haskell-cafe] Re: Weird ghci behaviour?
Jules Bean
jules at jellybean.co.uk
Tue Nov 13 17:05:51 EST 2007
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.
Jules
More information about the Haskell-Cafe
mailing list