Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 current behaviour consistent and easy to understand, but I guess I'm in the minority! 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 :) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
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 load source code (similarly :load); while ghci foo.o is obviously an instruction to load compiled code. Even just having :m + *Foo Currently :m doesn't load any modules, it just alters the context (what's in scope at the prompt), and fails if you ask for a module that isn't loaded. It would make sense for :m +M to behave like :add if M wasn't loaded, though. And perhaps :add *M or :load *M should ignore compiled code for M - that's another option. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
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.) -idir Search for imported modules in the directory dir. -H32m Increase GHC's default heap size to 32m -cppEnable 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
RE: [Haskell-cafe] Re: Weird ghci behaviour?
| 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. 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 error message you suggest. (I forgot to mention that GHCi will let you run code in modules that are only available in compiled form, such as ones from other packages -- there is no source code to consult.) 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. (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. (c) The last thing I can think of is that we could *read the source code* for home-package modules M (to find the top-level definitions), but still use the M.o files if they exist (to get faster execution). Then we could produce the message you suggest. If any of this seems important enough to you to be worth doing, would you like to create a feature-request ticket for it, and summarise the discussion and alternatives? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Weird ghci behaviour?
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
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.) -idir Search for imported modules in the directory dir. -H32m Increase GHC's default heap size to 32m -cppEnable 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
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 at the ghci command, during a session, or as the local default in dot-ghci.) o Whenever it is not possible to make all symbols available, give the user a clear warning. I don't think it's necessary to go overboard with details in the warning. A simple, clear, generic warning at load time is enough. For example: If we looked for the source code and did not find it, this might be a beginner who accidentally deleted it. So we say: Module 'Foo' loaded. Warning: Source code not found for 'Foo', so only its exported symbols are available. If it was requested, we say: Module 'Foo' loaded. Only the compiled module was loaded, as requested, so only its exported symbols are available. So someone who requested this in error will realize that. Experts should be able to turn off this message - but not the previous one - and rely upon the subtle hint in the command prompt. These give enough information that anyone who gets into the wrong situation by mistake will know (or be able to figure out) exactly what happened. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 error message you suggest. Not really. Include the hint on the first symbol not found error after loading a binary module as a Perhaps you need to -fforce- recomp?; it doesn't really matter if it turns out the symbol-not- found was actually e.g. a typo. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Weird ghci behaviour?
| 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. It's just another of those things on GHC's now-large surface area that could probably be improved if someone sat down and thought about it carefully. 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? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Weird ghci behaviour?
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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, use -fforce-recomp to see all symbols when running interactively in ghci with a previously compiled top level module. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 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] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#ghci-scope claus - notice how in this example session, the ghci prompt before compilation is '*Main', whereas it is 'Prelude Main' after compilation (ghci adds the Prelude because otherwise only 'main' would be in scope): - $ ghcii.sh u.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. [1 of 1] Compiling Main ( u.hs, interpreted ) Ok, modules loaded: Main. *Main :q Leaving GHCi. $ ghc --make u [1 of 1] Compiling Main ( u.hs, u.o ) Linking u.exe ... $ ghcii.sh u.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main :q Leaving GHCi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
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 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 -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
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. This is not new with GHC 6.8. For example, it's why I had to sneakily add a module declaration to the top of a source file when I wrote http://www.haskell.org/haskellwiki/Learn_Haskell_in_10_minutes#Function_definitions -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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-evaluation.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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 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. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
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.html#recomp claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
