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.has
Jonathan Cast wrote:
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 lo
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
Simon Marlow wrote:
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 curre
On Nov 14, 2007, at 3:28 , Simon Peyton-Jones wrote:
I agree that an informative error message is worth 100 manual
pages. The trouble is that at this stage GHCi doesn't even *know*
that 'x' ever existed, because it's not mentioned in the interface
file, so it's hard to do even give the er
I was also bitten by this. I consider it to be a
serious problem with the UI for ghci.
My vote is:
o The default should be to make all symbols available
whenever possible.
o It should be easy for experts, like Aaron Denney,
to get the current behavior. (E.g., a flag, that can
be turned on or off
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 g
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 impl
| > 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 intera
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 (si
Aaron Denney wrote:
On 2007-11-13, Jules Bean <[EMAIL PROTECTED]> 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." B
On 2007-11-13, Jules Bean <[EMAIL PROTECTED]> 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 me
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
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?
it does!-) watch the prompt, which says '*M>', if all of M's top-level
is in scope, or 'M>', if only M's exports are in scope. check here:
http://www.h
2007/11/13, Simon Peyton-Jones <[EMAIL PROTECTED]>:
>
> | "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 r
On Nov 13, 2007, at 13:32 , Dan Piponi wrote:
On Nov 13, 2007 3:00 AM, Simon Peyton-Jones <[EMAIL PROTECTED]>
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
On Nov 13, 2007 3:00 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> 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
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
| "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 tha
"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
On Nov 12, 2007 1:59 PM, Henning Thielemann
<[EMAIL PROTECTED]> wrote:
> See
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html
I guess the key sentence is:
"For technical reasons, GHCi can only support the *-form for modules
which are interpreted, so compi
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 GHC
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 acc
23 matches
Mail list logo
