

Defer Haskell type errors to runtime: new GHC 7.6 developers' flag - dons
http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime

======
_delirium
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
_all_ 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.

~~~
cageface
I have found it ironic that Haskell packages seem a lot more brittle than
packages in a language like Ruby. It's possible to get into "dll hell" with
gems of course, but my limited experience fiddling around with Cabal suggests
it can be much more difficult to get exactly the right set of versions in
Haskell.

Maybe this means that there are a lot of undetected bugs lurking in the
typical gemset but at least you can get something off the ground.

~~~
Uchikoma
I don't think this has anything to do with Ruby (dynamic) or Haskell (static).

Scala is a dll hell b/c of binary incompatibility and a community that wants
all frameworks on bleeding edge Scala (RC even) versions.

Compared to Java, where many frameworks still work with Java 1.5 and
dependency management is a joy.

~~~
cageface
The difference seems to be that languages with dynamic type systems or very
simple static type systems aren't as difficult as languages that encode a lot
more information into their types.

Maybe it's not fair to generalize from just those few examples though.

------
nightski
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.

------
fdr
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.

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.

------
ac
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.

EDIT: Okay, I can see the point. The linked ticket
<http://hackage.haskell.org/trac/ghc/ticket/5624> 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?

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.

~~~
dons
> 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.

~~~
ac
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.

~~~
jrockway
_Anyway, sorry for the offtop, I think we should get back to discussing why
would GHC want to become a Python interpreter._

Really? You're going to troll _dons_ on Hacker News?

Massive downvote.

------
nabilhassein
This reminds me of this quote from [1]:

"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."

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.

[1] [http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-
hack-...](http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-and-
haskell-is.html)

~~~
fusiongyro
Until "expressiveness" has a defined meaning, I encourage us all to stop using
it to describe programming languages. We just beat each other up with it
without really saying anything meaningful.

Programs that were right before continue to be right. Programs that were wrong
before continue to be wrong. What's changed is that programs which were wrong
before can now be wrong at runtime rather than at compile time. The parts of
the program that don't explode now wouldn't have exploded before. So I don't
think that really changes the expressiveness, whatever that means.

I think this change will do wonders for Haskell marketing but I don't think it
will have much effect on the day-to-day lives of Haskell programmers.

------
MBlume
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.

~~~
dons
Prod builds would explicitly disable this (and other dangerous flags) with
`-Wall -Werror` and friends. Shipping with this on is like shipping with
incomplete patterns, which would be caught by `-Wall`.

Summary: useful for developing, capital offense for production code.

------
AntiRush
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.

------
olalonde
Sorry for the stupid question but how is this even possible for a compiled
language? Will the program simply crash without an error message?

~~~
ralfn
Well, they just fix the error by replacing the offending code with code that
emits a run-time type error.

~~~
olalonde
Thanks, that explains it.

------
spitfire
Do not want this. This will be abused by less experienced developers.

~~~
tikhonj
I've never understood this rationale. Pretty much _any_ feature can be abused
by "less experienced" developers. I think you should _never_ leave out useful
features just because they _could_ be abused--trying to protect developers
from their own incompetence is never going to be completely successful and is
rather arrogant at that.

I could see leaving out or modifying features that lead to a lot of mistakes,
like manual memory management, but this is just a flag useful for debugging--
you never _have_ to use it and it does not affect your code at all if you
don't use it.

Also, this feature is more like replacing unsafe functions with undefined
rather than making everything dynamically typed. For example, it will _always_
error if you run a poorly typed function, regardless of what argument you pass
in. And, of course, if you're worried about your co-workers using this flag,
you can just recompile without it and fix all the errors.

~~~
spitfire
So you're a perl programmer then?

~~~
tikhonj
Amusingly, I used to be :).

Also, Perl's philosophy is actually not that far from Haskell's in some ways:
Haskell embraces TMTOWTDI and tends to favor more concise code.

------
dscrd
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?

------
ZephyrP
Ladies and Gentlemen,

This is real life.

