> Why have the bloody Haskell-Platform if you can't keep up with the compiler releases.

The HP doesn't chase the compiler. It is supposed to mean stable 6 monthly dev cycles, independent of what GHC HQ is up to. It is explicitly not about chasing the bleeding edge GHC.

I wasn't talking about the bleeding edge GHC -- merely the stable releases available to download from the official web-page with both sources and binaries. If that's "bleeding edge", it should clearly be specified as such. Anyway, I don't even use HP -- which leaves cabal-install as the only viable option. And why do I even not want to use the GHC version which is not in HP? Well, surprise-surprise, it turns out that Hackage is more than content to use the "bleeding edge" compiler to build packages and will happily report all the compilation errors (instead of using the usable baseline version included in HP). Well, it's a sore topic to say the least. Anyway, sorry for the offtop, I think we should get back to discussing why would GHC want to become a Python interpreter.

Sure, for small programs, that's probably a better approach. But this could really come in handy when your program is split across 100 files and you change a central data type. Now you can update and test in batches without having to refactor 1000s of lines in one go.

> Now you can update and test in batches without having to refactor 1000s of lines in one go.

If a change in a datatype forces you to update 1000s of LoCs, you are doing something wrong.

A common purpose of changing something is fixing something that was done wrong.

Consider, for example, fixing the Monad class to subclass Applicative. Or to remove the "fail" or (>>) methods.

This would incur a change to many thousands of lines of code.

Similarly, a core/base type of a whole project can be used across an entire codebase. It is possible to discover desirable changes to such a base type, and it will incur a huge change.

Yes, things like changes to core library types are disastrous. But, if you have a core data-type that you know will change and you haven't isolated the impact of these changes by, say, using accessor functions, you're the one to blame. See my long-ish reply in the sibling thread for details. And, yeah, I've learned all this the hard way :(

One of the nice things about Haskell, is that changes that are disastrous in other languages are not necessarily disastrous.

I think any notion of blame is really irrelevant here. The discussion was whether this kind of feature is useful. I think you implied it wasn't, because the cases it were useful in are those in which you did something wrong. But that does not follow at all. It is very possible one is to blame for a horrible mistake in the codebase, and that it still needs and can be fixed. This feature makes that fix cheaper and more practical.

I mentioned earlier that I found the GHCI use-case extremely useful (see my root comment after EDIT). But I have an issue with the uses like turning off the typesystem and have the project compile just so that you could feel good about yourself. I don't believe that would help your bottom-line. But, as long as I don't have to work with you or your software, I don't care. And, large refactoring efforts are necessary in every complex and evolving system, irrespective of your language of choice -- but turning off your type checker or any other static guarantees isn't the way to go. Programming is hard enough even in the presence of type-checking and automated analyses -- why make it even harder? Anyway, I feel like I've made my point enough -- take it or leave it.

> But I have an issue with the uses like turning off the typesystem and have the project compile just so that you could feel good about yourself

That's a strawman. The claim is that it is useful to be able to compile a partially-valid program so that you can:

* Test actually running stuff

* Get the inferred types of expressions

The idea is to temporarily turn it off just to run some tests or infer some types, and then turn it on again for the rest of the work.

I think that you're arguing against a point that no one is making. Everyone agrees you should not use this feature for any other purpose except to temporarily allow some tests and exploration.

Hmmm, you're probably right. I had in mind something like GenStgExpr[1] that make up the STG type in GHC. I'd imagine with all the optimisations, serialization and code-gen that is based directly off that data structure, any significant change will have at least 1000 line nock-on effect. Perhaps I'm over estimating though. I'd guess it comes down to the size of the project.

1) https://github.com/ghc/ghc/blob/master/compiler/stgSyn/StgSy...

GHC is a bit of a pathological case, which doesn't make it less valid. I wouldn't really dare to estimate how much refactoring you need to do if you change, say, one constructor of GenStgExpr, primarily, because I don't know the GHC codebase. In my work I have had instances when I had to change datatypes drastically and refactor the code accordingly. I'd say, in all cases the type system was helpful -- I just go to every error location (very easy with, e.g., ghc-mod), and it's invariably a pattern-matching case, so I fix a bit of code here and there (20 LoCs at most) and it all worked. But the thing is, of course, if you change your datatypes all the time even these kind of small changes will soon become tedious. But then if one programs in Haskell in a hacking mode ("meh, let's try throwing this thing in, maybe it will miraculously start working") -- it just won't work. Haskell requires one to think well, before programming -- that's why I love it. I think, in the end it saves time. Another problem might be that the datatype you are refactoring is fundamental to your program and is used in most modules -- I think it's just short-sighted design. GHC, for example, has several different program representations (Haskell, STG, Core, maybe some others), so a change to one representation would only affect a part of the compilation pipeline (namely, the translation to and from that rep and the associated optimisations/analyses). But if you really need such a fundamental mega-type that will change during the lifetime of the program, why not write an easier to manage interface to it? Either use the record syntax or write setter/getter functions by hand. Just $ my $0.02 where my=id