Deferring type errors until runtime is a feature which probably helps a lot with the adoption of Haskell. Newcomers can get the encouragement of a mostly-working program even if there are type errors in a few places. I can write foo = 1 + 1 bar = head True main = print foo and still run the program or load it in GHCi. Does anyone think it would also be beneficial to have "-fdefer-name-errors"? If I write foo = 1 + 1 bar = baz main = print foo but baz doesn't exist it would still be nice to let the program run or be loaded in GHCi. This could be achieved by replacing all missing variables by "error 'baz was not defined'" or similar. If a suitable parser could be written it might even be possible to defer syntax errors! This kind of thing would make the experience with Haskell gentler for newcomers, but also more pleasant for veterans! Tom
Wow, I just posted to reddit asking about the same thing. Should have checked my email first. :) http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/ Obviously, I concur that this would make Haskell more pleasant for me. I just used -fdefer-type-errors today, which turned out to be a huge convenience, and I would have similarly benefited from -fdefer-name-errors. -- Dan Burton On Thu, May 28, 2015 at 1:26 AM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:
Deferring type errors until runtime is a feature which probably helps a lot with the adoption of Haskell. Newcomers can get the encouragement of a mostly-working program even if there are type errors in a few places. I can write
foo = 1 + 1 bar = head True main = print foo
and still run the program or load it in GHCi.
Does anyone think it would also be beneficial to have "-fdefer-name-errors"? If I write
foo = 1 + 1 bar = baz main = print foo
but baz doesn't exist it would still be nice to let the program run or be loaded in GHCi. This could be achieved by replacing all missing variables by "error 'baz was not defined'" or similar.
If a suitable parser could be written it might even be possible to defer syntax errors!
This kind of thing would make the experience with Haskell gentler for newcomers, but also more pleasant for veterans!
Tom
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
That is a great idea. I'd like to add that introducing a new option might not be necessary. How about automatically turning unresolved name errors into named type holes? That way, they would be deferred automatically with the existing option. Michal On Thursday, May 28, 2015 at 4:27:11 AM UTC-4, Tom Ellis wrote:
Deferring type errors until runtime is a feature which probably helps a lot with the adoption of Haskell. Newcomers can get the encouragement of a mostly-working program even if there are type errors in a few places. I can write
foo = 1 + 1 bar = head True main = print foo
and still run the program or load it in GHCi.
Does anyone think it would also be beneficial to have "-fdefer-name-errors"? If I write
foo = 1 + 1 bar = baz main = print foo
but baz doesn't exist it would still be nice to let the program run or be loaded in GHCi. This could be achieved by replacing all missing variables by "error 'baz was not defined'" or similar.
If a suitable parser could be written it might even be possible to defer syntax errors!
This kind of thing would make the experience with Haskell gentler for newcomers, but also more pleasant for veterans!
Tom
_______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Personally, I'd generally prefer if GHC got a little more interactive about
name errors: "I couldn't find heod. Did you mean head?" And if the answer
is yes, it could optionally edit the file for you, as well as continuing
compilation.
On May 28, 2015 9:22 AM, "Michal Antkiewicz"
That is a great idea.
I'd like to add that introducing a new option might not be necessary. How about automatically turning unresolved name errors into named type holes? That way, they would be deferred automatically with the existing option.
Michal
On Thursday, May 28, 2015 at 4:27:11 AM UTC-4, Tom Ellis wrote:
Deferring type errors until runtime is a feature which probably helps a lot with the adoption of Haskell. Newcomers can get the encouragement of a mostly-working program even if there are type errors in a few places. I can write
foo = 1 + 1 bar = head True main = print foo
and still run the program or load it in GHCi.
Does anyone think it would also be beneficial to have "-fdefer-name-errors"? If I write
foo = 1 + 1 bar = baz main = print foo
but baz doesn't exist it would still be nice to let the program run or be loaded in GHCi. This could be achieved by replacing all missing variables by "error 'baz was not defined'" or similar.
If a suitable parser could be written it might even be possible to defer syntax errors!
This kind of thing would make the experience with Haskell gentler for newcomers, but also more pleasant for veterans!
Tom
_______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
On Thu, May 28, 2015 at 09:26:58AM +0100, Tom Ellis wrote:
Does anyone think it would also be beneficial to have "-fdefer-name-errors"? [...]
Via hamishmack on Haskell Reddit[1] there's already a Trac issue about this[2]. [1] http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/crn... [2] https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19
The request for -fdefer-name-errors is indeed in #5910, but very much buried under other stuff. If you want this, make a new feature request, referencing #5910. Of course, even better would be a full specification (on a wiki page) and a patch! I expect the challenge here is coming up with a nice design more so than a nice implementation.
Thanks!
Richard
On May 28, 2015, at 9:26 AM, Tom Ellis
On Thu, May 28, 2015 at 09:26:58AM +0100, Tom Ellis wrote:
Does anyone think it would also be beneficial to have "-fdefer-name-errors"? [...]
Via hamishmack on Haskell Reddit[1] there's already a Trac issue about this[2].
[1] http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/crn... [2] https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (5)
-
Dan Burton -
David Feuer -
Michal Antkiewicz -
Richard Eisenberg -
Tom Ellis