Hello. Here is one ghci feature that I find mildly annoying: If ghci (re-)reads a module that contains some error, then it considers the module loading as a complete failure, and at the prompt I get the Prelude environment. I'd like to have at least the import statements executed, and possibly the declarations that were error-free. That would help me in interactively debugging the erraneous part of the module. (Often the error is some type error, related to some imported entity; but when my module contains the error, then the imports are gone.) Perhaps I'm doing something wrong, then please educate me; or perhaps there's an easy way to implement partial reading and typechecking. (It'd be enough to have this for the "current" module, of course.) Thanks - Johannes Waldmann.
On Sat, Feb 16, 2008 at 10:53 AM, Johannes Waldmann
If ghci (re-)reads a module that contains some error, then it considers the module loading as a complete failure, and at the prompt I get the Prelude environment.
I'd like to have at least the import statements executed, and possibly the declarations that were error-free.
Seconded.
Perhaps I'm doing something wrong, then please educate me;
Seconded, again. -- Denis
On Sat, Feb 16, 2008 at 04:53:24PM +0100, Johannes Waldmann wrote:
Hello.
Here is one ghci feature that I find mildly annoying:
If ghci (re-)reads a module that contains some error, then it considers the module loading as a complete failure, and at the prompt I get the Prelude environment.
I'd like to have at least the import statements executed, and possibly the declarations that were error-free. That would help me in interactively debugging the erraneous part of the module. (Often the error is some type error, related to some imported entity; but when my module contains the error, then the imports are gone.)
Perhaps I'm doing something wrong, then please educate me; or perhaps there's an easy way to implement partial reading and typechecking. (It'd be enough to have this for the "current" module, of course.)
Thanks - Johannes Waldmann.
This is fairly easy for type errors - just have the 'type of expression' function return errors using Either etc, and at the top level drop all expressions with error type. As for parse errors - good luck. Haskell is incredibly difficult to parse even if you ignore several of its less-friendly features. If you allow them... for a long time I said it had never even been proven possible, but then I found a workable algorithm exponential in the file size. Now, how do you propose handling parse errors? Here's an example of why it's hardly trivial: foo = x + y + z where { x = 2; y = 3; z = 4; } Stefan
Sure. Syntax errors are usually easy to spot and fix (for the programmer who uses some reasonable code layout); the motivation for my proposal was type errors. I think it would be perfectly acceptable if ghci rejects modules with parse errors (as it does now) but handles modules with type errors more gracefully. Since type checking a group of declarations (= a module) often considers all declarations at the same time, there may be no sensible way to proceed after a type error. Then it would even be OK to not bind any of the identifiers of the module, as long as the import declarations are available at ghci prompt. (This would still be an improvement over the present situation.) Best regards, Johannes.
On Sat, Feb 16, 2008 at 06:58:29PM +0100, Johannes Waldmann wrote:
Sure.
Syntax errors are usually easy to spot and fix (for the programmer who uses some reasonable code layout); the motivation for my proposal was type errors.
I think it would be perfectly acceptable if ghci rejects modules with parse errors (as it does now) but handles modules with type errors more gracefully.
Since type checking a group of declarations (= a module) often considers all declarations at the same time, there may be no sensible way to proceed after a type error.
Then it would even be OK to not bind any of the identifiers of the module, as long as the import declarations are available at ghci prompt. (This would still be an improvement over the present situation.)
Implementing Haskell polymorphism requires that the functions be sorted into dependancy groups, so that undepended definitions can be generalized. Example: foo x = 2 bar = foo 'a' + foo True If this were typechecked all at once (using the standard Damas-Milner algorithm) you would get a "cannot match Bool to Char" type error. Stefan
That's a fair suggestion. (With the subsequent clarification about getting through the parser and renamer first.) Would you like to check the open feature requests (in case it's there already) and add it as a feature request? Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Johannes Waldmann | Sent: 16 February 2008 15:53 | To: glasgow-haskell-users@haskell.org | Subject: ghci feature request: partially read modules | | Hello. | | Here is one ghci feature that I find mildly annoying: | | If ghci (re-)reads a module that contains some error, | then it considers the module loading as a complete failure, | and at the prompt I get the Prelude environment. | | I'd like to have at least the import statements executed, | and possibly the declarations that were error-free. | That would help me in interactively debugging | the erraneous part of the module. | (Often the error is some type error, related to some imported entity; | but when my module contains the error, then the imports are gone.) | | Perhaps I'm doing something wrong, then please educate me; | or perhaps there's an easy way to implement partial reading | and typechecking. (It'd be enough to have this for the "current" | module, of course.) | | Thanks - Johannes Waldmann. | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (4)
-
Denis Bueno -
Johannes Waldmann -
Simon Peyton-Jones -
Stefan O'Rear