6 ms·

Defer Haskell type errors to runtime: new GHC 7.6 developers' flag

68 points by dons 14y ago

spitfire 14y ago
Do not want this. This will be abused by less experienced developers.
- vitno 14y ago
  I completely concur. This seems to not be "haskelly" at all.
- mavelikara 14y ago
  Reminds me of zedshaw's post last week.
- tikhonj 14y ago
  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 14y ago
    So you're a perl programmer then?
    - tikhonj 14y ago
      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.
- jrockway 14y ago
  How? Your continuous integration system won't have this flag on, so their non-typechecked code will never reach production. What they do while developing is not much of a concern; this is simply a faster way to put "--" in front of a lot of lines of code. This is not about making Haskell dynamically typed. It's about not type-checking code that never runs.
ac 14y ago
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 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.
- Chirono 14y ago
  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.
  - ac 14y ago
    > 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.
    - Chirono 14y ago
      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/StgSyn.lhs https://github.com/ghc/ghc/blob/master/compiler/stgSyn/StgSy...
olalonde 14y ago
Sorry for the stupid question but how is this even possible for a compiled language? Will the program simply crash without an error message?
- IsTom 14y ago
  It will simply crash with an error message.
- Chirono 14y ago
  Instead of failing with an error at compile time, it will emit code that, if run, will fail with a 'type error' at run time.
- strager 14y ago
  In short, compiled type errors are replaced with `assert(0);` (which doesn't return).
- gtani 14y ago
  Perfectly valid question. This explains the practice in incremental dev or refactoring of using "undefined" in stub/placeholder functions to get the type signatures but not function bodies in: http://www.fatvat.co.uk/2009/09/generating-text-in-haskell.html http://www.fatvat.co.uk/2009/09/generating-text-in-haskell.h... Also: 2 longish threads about this http://www.reddit.com/r/programming/duplicates/tjeg3/haskell_was_a_statically_typed_language_now_you/ http://www.reddit.com/r/programming/duplicates/tjeg3/haskell...
- ralfn 14y ago
  Well, they just fix the error by replacing the offending code with code that emits a run-time type error.
  - olalonde 14y ago
    Thanks, that explains it.
_delirium 14y ago
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 14y ago
  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.
  - fusiongyro 14y ago
    cabal-install leaves something to be desired in the dependency management area. There are active projects under way to improve the situation, largely borrowing from Ruby along the lines of rvm and bundler.
  - Uchikoma 14y ago
    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 14y ago
      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.
MBlume 14y ago
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 14y ago
  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.
- chc 14y ago
  I'm guessing the kind of people who have Haskell to push into production are not the kind of people who would be inclined to do that.
- rpearl 14y ago
  It would be cool if this feature implied no optimizations applied or something along those lines, making it intractable to use for production code.
- jrockway 14y ago
  I'm wondering how soon someone will push some code into production without writing unit tests because they can't be bothered to write unit tests. People will write bad code regardless of language features. Ignore those people and worry about how people writing good code will use your new feature. If it saves them time, makes their life happier, or lets them write safer code, then it's a win. Similarly, if a feature helps bad programmers avoid today's bad-pattern-du-jour but prevents good programmers from writing good code, you should think twice before adding it. In summary: ignore bad programmers, they can't be saved by language features.
nightski 14y ago
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 14y ago
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.
deleted 14y ago
[deleted]
- exim 14y ago
  >/me still waiting for my compiled, statically-typed pythonic language :\ Pike, Groovy++ or golang?
AntiRush 14y ago
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.
nabilhassein 14y ago
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-and-haskell-is.html http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-...
- fusiongyro 14y ago
  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.
ZephyrP 14y ago
Ladies and Gentlemen, This is real life.
dscrd 14y ago
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?

68 points by dons 14y ago

spitfire 14y ago

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

vitno 14y ago
I completely concur. This seems to not be "haskelly" at all.
mavelikara 14y ago
Reminds me of zedshaw's post last week.
tikhonj 14y ago
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 14y ago
  So you're a perl programmer then?
  - tikhonj 14y ago
    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.
jrockway 14y ago
How? Your continuous integration system won't have this flag on, so their non-typechecked code will never reach production. What they do while developing is not much of a concern; this is simply a faster way to put "--" in front of a lot of lines of code. This is not about making Haskell dynamically typed. It's about not type-checking code that never runs.

ac 14y ago

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

Chirono 14y ago
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.
- ac 14y ago
  > 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.
  - Chirono 14y ago
    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/StgSyn.lhs https://github.com/ghc/ghc/blob/master/compiler/stgSyn/StgSy...

olalonde 14y ago

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

IsTom 14y ago
It will simply crash with an error message.
Chirono 14y ago
Instead of failing with an error at compile time, it will emit code that, if run, will fail with a 'type error' at run time.
strager 14y ago
In short, compiled type errors are replaced with `assert(0);` (which doesn't return).
gtani 14y ago
Perfectly valid question. This explains the practice in incremental dev or refactoring of using "undefined" in stub/placeholder functions to get the type signatures but not function bodies in: http://www.fatvat.co.uk/2009/09/generating-text-in-haskell.html http://www.fatvat.co.uk/2009/09/generating-text-in-haskell.h... Also: 2 longish threads about this http://www.reddit.com/r/programming/duplicates/tjeg3/haskell_was_a_statically_typed_language_now_you/ http://www.reddit.com/r/programming/duplicates/tjeg3/haskell...
ralfn 14y ago
Well, they just fix the error by replacing the offending code with code that emits a run-time type error.
- olalonde 14y ago
  Thanks, that explains it.

_delirium 14y ago

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 14y ago
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.
- fusiongyro 14y ago
  cabal-install leaves something to be desired in the dependency management area. There are active projects under way to improve the situation, largely borrowing from Ruby along the lines of rvm and bundler.
- Uchikoma 14y ago
  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 14y ago
    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.

MBlume 14y ago

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 14y ago
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.
chc 14y ago
I'm guessing the kind of people who have Haskell to push into production are not the kind of people who would be inclined to do that.
rpearl 14y ago
It would be cool if this feature implied no optimizations applied or something along those lines, making it intractable to use for production code.
jrockway 14y ago
I'm wondering how soon someone will push some code into production without writing unit tests because they can't be bothered to write unit tests. People will write bad code regardless of language features. Ignore those people and worry about how people writing good code will use your new feature. If it saves them time, makes their life happier, or lets them write safer code, then it's a win. Similarly, if a feature helps bad programmers avoid today's bad-pattern-du-jour but prevents good programmers from writing good code, you should think twice before adding it. In summary: ignore bad programmers, they can't be saved by language features.

nightski 14y ago

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 14y ago

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.

deleted 14y ago

[deleted]

exim 14y ago
>/me still waiting for my compiled, statically-typed pythonic language :\ Pike, Groovy++ or golang?

AntiRush 14y ago

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.

nabilhassein 14y ago

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-and-haskell-is.html http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-...

fusiongyro 14y ago
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.

ZephyrP 14y ago

Ladies and Gentlemen, This is real life.

dscrd 14y ago

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?