6 ms·

This is why Haskell recently got a flag to turn type errors into warnings: now you came make a change, get a bunch of type errors (as warnings!) and fix them on

by tikhonj 10y ago

This is why Haskell recently got a flag to turn type errors into warnings: now you came make a change, get a bunch of type errors (as warnings!) and fix them one at a time, loading and testing each part as you change it. You don't have to update everything to play around with your module. This isn't dynamic typing though: if you tried to use an expression that did not typecheck, you will get a runtime value immediately. It's the moral equivalent of automatically replacing the broken expression with an `undefined` exception.

talles 10y ago
That's very, very nice. Is this exclusive to Haskell?
- jerf 10y ago
  Well, Haskell got it from Agda [1], but Agda is even farther in the direction of Haskell than Haskell relative to mainstream programming languages, and beyond the "currently practical" language horizon. [1]: https://wiki.haskell.org/GHC/Typed_holes https://wiki.haskell.org/GHC/Typed_holes
  - dllthomas 10y ago
    Typed holes are quite a different thing than deferred type errors. Does Agda actually have something like the latter? (Results seem negative from the tiny bit of searching I've just done, but that's awfully low confidence...)
    - jerf 10y ago
      Whoops, you're right! I was too hasty.
- jdmichal 10y ago
  Eclipse does a similar thing with Java. It will replace methods that don't compile with a stub that throws an exception with the compilation error.
  - talles 10y ago
    But is that transparent or they pollute the source code?
    - jdmichal 10y ago
      It's completely transparent, done only in the compiled class files. The signature of the method remains exactly the same, just the body is replaced.
kornish 10y ago
For anyone reading and interested in checking out the docs, the flag is -fdefer-type-errors: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...
- kazinator 10y ago
  Why don't they just add the dynamic typing when that happens. There could then be a class of Haskell programs that are statically ill-formed, yet actually free of errors. Maybe adding dynamic typing to a thoroughbred static language could turn out more fruitful than efforts to go the other way.
  - dllthomas 10y ago
    > Why don't they just add the dynamic typing when that happens. Haskell (at least, GHC Haskell) has support for dynamic typing, in three(ish) parts. "Dynamic typing" in the sense of being able to ask the types at runtime is available in the Typeable typeclass. This is provided by the compiler automatically for known types; it must be visibly asked for for polymorphic types - partly for visibility and to preserve reasoning (https://www.reddit.com/r/haskell/comments/4mu30y/what_is_the_point_of_typeable/d3yakg6 https://www.reddit.com/r/haskell/comments/4mu30y/what_is_the...) and partly to clarify what dictionaries need to be passed where. "Dynamic typing" in the sense of foregoing static checks in favor of runtime checks can, of course, usually be done in a constrained way simply by choosing looser types. That said, depending on language, that can often mean substantial boilerplate. GHC does provide Dynamic, which will wrap any value up with its type annotations and let you apply (possibly wrapped) functions to these wrapped values in a dynamically checked way. Lastly, I'd kind of put "existential quantification" in play here. It's sometimes the case that you only need to show that some pieces of "the same type" are internally consistent, without knowing their precise shape. As for why it's not added, I'm not 100% sure what you mean. If you mean on every build, making that the only option, then I would say "because many of us who choose Haskell find static checks a huge help (particularly when refactoring) and wouldn't want to give that up". If you mean in place of the current behavior of -fdefer-type-errors, I expect it's sometimes quite useful to know earlier when you're exercising magically untyped code (as compared to deliberately demarcated untyped code). If you mean, "why don't they add -fdynamic-type-errors", an additional flag that subs in use of Dynamic in place of inconsistently typed code, that's certainly an interesting idea; given that terms are sometimes derived from types (typeclass polymorphism) it may not always be possible, and in any case may be a large engineering effort - I suspect Simon and company simply haven't gotten around to it.

by tikhonj 10y ago

talles 10y ago

That's very, very nice. Is this exclusive to Haskell?

jerf 10y ago
Well, Haskell got it from Agda [1], but Agda is even farther in the direction of Haskell than Haskell relative to mainstream programming languages, and beyond the "currently practical" language horizon. [1]: https://wiki.haskell.org/GHC/Typed_holes https://wiki.haskell.org/GHC/Typed_holes
- dllthomas 10y ago
  Typed holes are quite a different thing than deferred type errors. Does Agda actually have something like the latter? (Results seem negative from the tiny bit of searching I've just done, but that's awfully low confidence...)
  - jerf 10y ago
    Whoops, you're right! I was too hasty.
jdmichal 10y ago
Eclipse does a similar thing with Java. It will replace methods that don't compile with a stub that throws an exception with the compilation error.
- talles 10y ago
  But is that transparent or they pollute the source code?
  - jdmichal 10y ago
    It's completely transparent, done only in the compiled class files. The signature of the method remains exactly the same, just the body is replaced.

kornish 10y ago

For anyone reading and interested in checking out the docs, the flag is -fdefer-type-errors: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...

kazinator 10y ago
Why don't they just add the dynamic typing when that happens. There could then be a class of Haskell programs that are statically ill-formed, yet actually free of errors. Maybe adding dynamic typing to a thoroughbred static language could turn out more fruitful than efforts to go the other way.
- dllthomas 10y ago
  > Why don't they just add the dynamic typing when that happens. Haskell (at least, GHC Haskell) has support for dynamic typing, in three(ish) parts. "Dynamic typing" in the sense of being able to ask the types at runtime is available in the Typeable typeclass. This is provided by the compiler automatically for known types; it must be visibly asked for for polymorphic types - partly for visibility and to preserve reasoning (https://www.reddit.com/r/haskell/comments/4mu30y/what_is_the_point_of_typeable/d3yakg6 https://www.reddit.com/r/haskell/comments/4mu30y/what_is_the...) and partly to clarify what dictionaries need to be passed where. "Dynamic typing" in the sense of foregoing static checks in favor of runtime checks can, of course, usually be done in a constrained way simply by choosing looser types. That said, depending on language, that can often mean substantial boilerplate. GHC does provide Dynamic, which will wrap any value up with its type annotations and let you apply (possibly wrapped) functions to these wrapped values in a dynamically checked way. Lastly, I'd kind of put "existential quantification" in play here. It's sometimes the case that you only need to show that some pieces of "the same type" are internally consistent, without knowing their precise shape. As for why it's not added, I'm not 100% sure what you mean. If you mean on every build, making that the only option, then I would say "because many of us who choose Haskell find static checks a huge help (particularly when refactoring) and wouldn't want to give that up". If you mean in place of the current behavior of -fdefer-type-errors, I expect it's sometimes quite useful to know earlier when you're exercising magically untyped code (as compared to deliberately demarcated untyped code). If you mean, "why don't they add -fdynamic-type-errors", an additional flag that subs in use of Dynamic in place of inconsistently typed code, that's certainly an interesting idea; given that terms are sometimes derived from types (typeclass polymorphism) it may not always be possible, and in any case may be a large engineering effort - I suspect Simon and company simply haven't gotten around to it.