This seems nice for prototyping, since it'd allow a Lisp-style approach to changes and refactoring, where you can incrementally refactor, and run the intermediate results. Traditionally that's been difficult in Haskell, because if you e.g. change the type of a function, you have to change or comment out <i>all</i> the code that calls that function before it'll compile. That's particularly annoying when doing sketchy speculative prototyping, during which it's common to frequently change your mind about how things should be put together.
Maybe a year ago I would of been very against a feature like this. But now, working on a Haskell code base for quite some time that has grown I have wished for something like this many times. Most often it is when changing intra-module data structures and functions just to try something out, and I do not want to update the rest of the module quite yet. Sure I could comment out the offending code and replace with undefined, but that is essentially what this switch will do for free. So I for one am looking forward to this feature.
Looking at the comments, I am shocked how many people are concerned that people will ship things with type errors into production or this would somehow relax the standards of Haskell programs, going to the length to suggest that some short of sabotage should be levied when the flag to enable this is on.<p>This is a very good, and rather unique feature. I have wished for an equivalent when figuring out some stuff in C programs for long time; I cannot imagine a person who has to maintain and change a large program and cannot understand the huge utility of this device.
I don't buy it. Why have erroneous code that is not used anyway in your program? Why not comment it out? If you still need to have that code, there's an easier way to typecheck -- use 'error'. (I don't assume dons doesn't know that, though). There are so many good features one can add to haskell and the surrounding eco-system, but turning off the static type system is not one of them.<p>EDIT: Okay, I can see the point. The linked ticket <a href="http://hackage.haskell.org/trac/ghc/ticket/5624" rel="nofollow">http://hackage.haskell.org/trac/ghc/ticket/5624</a> gives a better motivation: being able to load a module that doesn't type check in GHCI and view inferred types, and, maybe, invoke some isolated functions. But why not just limit it to GHCI, though?<p>And, FFS, would SPJ and Co. please stop breaking core libraries and tools with minor releases? We had to wait for cabal-install to be ported for 7.2 and 7.4 for a couple of months, at least. Why have the bloody Haskell-Platform if you can't keep up with the compiler releases.
This reminds me of this quote from [1]:<p>"In this mythical, not yet-existing, but clearly on-the-horizon "Haskell", you'll be able to choose how much safety you want. You'll have "knobs" for increasing or decreasing compile-time checks for any property and invariant you desire."<p>It might not be "Haskellish" or safe in the way that I or some others are used to, but it does seem to be a clear increase in the expressiveness of the language.<p>[1] <a href="http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-and-haskell-is.html" rel="nofollow">http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-...</a>
I'm just wondering how soon someone will push some haskell into production with this flag in place because they can't be bothered to track down all their type errors.
This seems like it will be great for Light Table and other such systems. It will be much easier to do the incremental compile//show results on incomplete and in-progress files if type errors can be ignored.
Is Haskell suffering from a research language problem where the only things considered valuable are things that can be made into papers, i.e. only new additions?