Ian said:

Can you please give a complete testcase for the problem you're seeing?

I took my test case and started deleting lines from it to simplify it. And now I'm not seeing the problem at all and I can't reproduce it, even though when I originally posted I was getting it repeatably. I'm either hallucinating or it's a problem that comes up intermittently. Maybe it's some kind of network time skew issue that has nothing to do with ghc. If I catch it happening again I'll make sure to do more investigation. -- Dan

Several months late I now have a simple test case for what I think is either a GHC bug or a "misexpectation" on my part. This is with GHC 6.8.1 and I've tested both under Linux and MacOSX. It took a while to reproduce it because I thought the problem had gone away, but actually I'd just misunderstood when it happens. Here's a transcript of a complete session with a shell to make it easy to reproduce. Note how on the second run, ghci behaves differently. --------------------------------------

cat > bug.hs x = 1

main = do print x

ghci bug.hs GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> main 1 *Main> x 1 *Main> :q Leaving GHCi. ghc bug.hs ghci bug.hs GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main 1 Prelude Main> x

<interactive>:1:0: Not in scope: `x' Prelude Main> Leaving GHCi. ----------------------------------------------- On Jul 23, 2007 10:46 AM, Dan Piponi wrote:

Ian said:

...

Can you please give a complete testcase for the problem you're seeing?

On Mon, 12 Nov 2007, Chris Smith wrote:

Dan Piponi wrote:

...

Several months late I now have a simple test case for what I think is either a GHC bug or a "misexpectation" on my part.

Here's what it looks like to me.

If there is a .hi and .o file sitting around for a module, then GHCi will load it in compiled mode, and only let you access those symbols that are exported by the .hi file. If you compile a source file that has no module header, it compiles to the module Main and *only* exports the symbol main. You can fix it by adding a module header explicitly, or by deleting either the .hi or .o file.

See http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluati...

"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.

iirc, you can use -fforce-recomp with GHCi, to make it look for sources, ignoring compiled code, if that is what you want: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation... claus

On Tue, 13 Nov 2007, Simon Peyton-Jones wrote:

Meanwhile, though, the best we can do is improve the documentation:

Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling?

... or even better - words that GHCi can say, when it loads modules?

On Nov 13, 2007, at 13:32 , Dan Piponi wrote:

On Nov 13, 2007 3:00 AM, Simon Peyton-Jones wrote:

...

Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling?

I guess the thing that would have helped best would have been an error message like "'x' not in scope, use -fforce-recomp to see all symbols" when running interactively in ghci with a previously compiled top level module.

FWIW, I'm thinking the right thing to do is -fforce-recomp explicitly loaded (:l) modules by default, with documentation specifying to -fno- force-recomp if you don't want that for some reason. If you're using ghci, most of the time you *don't* want the normal ghc symbol behavior. (The above would still be useful, if you then switched to a module pulled in by the explicitly loaaded one and tried to work with a non- exported symbol. I do that a fair bit when developing/debugging.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Hello Simon, Wednesday, November 14, 2007, 11:28:23 AM, you wrote:

I can think of some other possibilities:

(a) It would be possible to record in the .hi file the fact that there originally *was* a top-level 'x', and so produce the message you suggest. But it'd be one more thing to implement, document, and maintain.

and this will increase amount of recompilation for large projects

(b) We could decide *never* to use compiled modules (M.o) for home-package modules, but only for other-package modules. Then at least all the home-package modules would have their names in scope. So the home package would be always interpreted. (The home package is the modules of your current project, not installed as a "package".) This'd be pretty easy.

it may be great if such behavior enabled by some option, such as -force-recomp. in many cases, we need to run compiled code inside ghci how about such variant? d) when printing message about undefined symbol, add note about reloading sources: "Symbol `x` undefined; if it's a top-level symbol in some loaded module M, please reload this module source-wise: :load M.hs" and implement directive ":load M.hs" as interpreted loading of the module -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2007/11/13, Simon Peyton-Jones :

| "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.

Plus, I just discovered, by reading this thread, WHY this happen.

Meanwhile, though, the best we can do is improve the documentation:

Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling?

Granted, I'm lazy. I read release notes only and only few first pages to see what's new. Couldn't GHCI be improved to at least give some hints? Cheers, Radek.

Claim: The "ghci modulename" and ":load modulename" command are confusing because they have two behaviors. Short form of my proposal: Make two separate commands that each have a predictable behavior. Make "ghci modulename" default to source loading, and require a flag to load a binary. I don't give a bikeshed what they are called. I don't care if the magic ":load" stays or goes or ends up with only one behavior. This is different/orthogonal to the .o or .hs file extension sensitive proposal. My arguments: I run into annoyances because I often poke at things in ghci when trying to get my package to compile. So depending on which modules succeeded or failed to compile I get different behavior when loading into ghci. I am no longer confused by this, but just annoyed. I would say that the user gets surprised which leads to feeling that there is a lack of control. The '*' in the '*Main>' versus 'Main>' prompt is a UI feature for experts, not for new users. Making this more obvious or verbose or better documented does not fix the lack of control the user feels. The only flags that the user can easily find are those listed by --help:

chrisk$ ghci --help Usage:

ghci [command-line-options-and-input-files]

The kinds of input files that can be given on the command-line include:

- Haskell source files (.hs or .lhs suffix) - Object files (.o suffix, or .obj on Windows) - Dynamic libraries (.so suffix, or .dll on Windows)

In addition, ghci accepts most of the command-line options that plain GHC does. Some of the options that are commonly used are:

-fglasgow-exts Allow Glasgow extensions (unboxed types, etc.)

-i<dir> Search for imported modules in the directory <dir>.

-H32m Increase GHC's default heap size to 32m

-cpp Enable CPP processing of source files

Full details can be found in the User's Guide, an online copy of which can be found here:

http://www.haskell.org/ghc/documentation.html

The -fforce-recomp and -fno-force-recomp flags only exist in the User's Guide. Thus they are hard to find. Is there a ticket open for adding at least a list of the recognized flags to ghc and ghci usage messages? Ideally, I want a ":load modulename" to get the source and a ":bin modulename" to get the binary (and a ":m ..." to get the binary). I want "ghci modulename" to get the source and "ghch -bin modulename" to get the binary. Simple and predictable and no surprises. Cheers, Chris K

It's worth saying that right now, all you have to do to get the source file loaded is

:! touch M.hs :reload

Put this in a macro, if you want:

:def src \s -> return (":! touch "++s)

I hear the arguments in this thread, and others have suggested changes before: http://hackage.haskell.org/trac/ghc/ticket/1205 http://hackage.haskell.org/trac/ghc/ticket/1439 One of the suggestions was that if you name the source file rather than the module name, you get the source file loaded for that file, and any object code is ignored. So any files you explicitly want to have full top-level scope for must be named in :load or on the GHCi command line. The only problem with this is that someone who isn't aware of this convention might accidentally be ignoring compiled code, or might wonder why their compiled code isn't being used. Well, perhaps this is less confusing than the current behaviour; personally I find the current behaviour consistent and easy to understand, but I guess I'm in the minority! The other suggestion is to have a variant of :load that ignores compiled code (or for :load to do that by default, and rename the current :load to something else). I don't have a strong preference. Cheers, Simon

Short form of my proposal: Make two separate commands that each have a predictable behavior. Make "ghci modulename" default to source loading, and require a flag to load a binary. I don't give a bikeshed what they are called. I don't care if the magic ":load" stays or goes or ends up with only one behavior.

This is different/orthogonal to the .o or .hs file extension sensitive proposal.

My arguments:

I run into annoyances because I often poke at things in ghci when trying to get my package to compile. So depending on which modules succeeded or failed to compile I get different behavior when loading into ghci. I am no longer confused by this, but just annoyed.

I would say that the user gets surprised which leads to feeling that there is a lack of control.

The '*' in the '*Main>' versus 'Main>' prompt is a UI feature for experts, not for new users. Making this more obvious or verbose or better documented does not fix the lack of control the user feels.

The only flags that the user can easily find are those listed by --help:

...

chrisk$ ghci --help Usage:

ghci [command-line-options-and-input-files]

The kinds of input files that can be given on the command-line include:

- Haskell source files (.hs or .lhs suffix) - Object files (.o suffix, or .obj on Windows) - Dynamic libraries (.so suffix, or .dll on Windows)

In addition, ghci accepts most of the command-line options that plain GHC does. Some of the options that are commonly used are:

-fglasgow-exts Allow Glasgow extensions (unboxed types, etc.)

-i<dir> Search for imported modules in the directory <dir>.

-H32m Increase GHC's default heap size to 32m

-cpp Enable CPP processing of source files

Full details can be found in the User's Guide, an online copy of which can be found here:

http://www.haskell.org/ghc/documentation.html

The -fforce-recomp and -fno-force-recomp flags only exist in the User's Guide. Thus they are hard to find. Is there a ticket open for adding at least a list of the recognized flags to ghc and ghci usage messages?

Ideally, I want a ":load modulename" to get the source and a ":bin modulename" to get the binary (and a ":m ..." to get the binary). I want "ghci modulename" to get the source and "ghch -bin modulename" to get the binary. Simple and predictable and no surprises.

Cheers, Chris K

On Thu, 15 Nov 2007, Jules Bean wrote:

Anecdotes have little value, but for what it's worth: in around 5 years of ghc use, I have never, not even once, wanted to load the module I was working on in its compiled form. I've occasionally noticed that dependent modules get loaded quickly from their .o's and thought that was handy, but that's all. During that time I have many times been annoyed that a .hs file which I load from the command line or via :load (or via C-c C-l in emacs mode) get loaded in interpreted form :)

I found compiled modules useful in GHCi when using computation intensive functions, like those for signal processing.

On 2007-11-13, Jules Bean 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 -><-

On 13 Nov 2007, at 11:03 PM, Jules Bean wrote:

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.

Even just having :m + *Foo always interpret Foo (giving an error only if the source isn't installed) would be an improvement. And wouldn't alter any /non-error/ behavior that exists now. jcc