[Haskell-cafe] Re: Weird ghci behaviour?

Jules Bean jules at jellybean.co.uk
Wed Nov 14 02:03:48 EST 2007


Aaron Denney wrote:
> On 2007-11-13, Jules Bean <jules at jellybean.co.uk> 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.

Just to be clear: my proposal is that if you want it to go faster you do

ghci foo.hi

or

ghci foo.o

... so you still have the option to run on compiled code.

My suggestion is simply that "ghci foo.hs" is an instruction to load 
source code (similarly :load); while "ghci foo.o" is obviously an 
instruction to load compiled code.

Jules


More information about the Haskell-Cafe mailing list