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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
