[Haskell-cafe] Re: Weird ghci behaviour?

[Simon Marlow]

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