3 ms·

In the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. I wasn't awa

by kpmah 11y ago

In the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. I wasn't aware of 'throw' and that certainly weakens my argument. You could maybe argue it is an escape hatch in the same vein as unsafePerformIO, but I don't know how it is viewed by the community. You could argue I'm playing word games here, and I have some sympathy for that argument. What I wanted to get across is checked exceptions ala. Java (although they are too commonly bypassed in that example). Maybe moving it to the documentation section is a good compromise.

dllthomas 11y ago
> In the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. Okay, but in the case of GHC you actually can recover from them. > I wasn't aware of 'throw' and that certainly weakens my argument. You could maybe argue it is an escape hatch in the same vein as unsafePerformIO, but I don't know how it is viewed by the community. Asynchronous exceptions are pretty widely accepted as the way to interrupt a long-running pure computation. `error` is pretty widely used on identifying programming errors and pretty well reserved to that case. There is some dispute over whether exceptions or Either is more appropriate to dealing with exceptional conditions in IO; more reluctance around exceptions for reporting exceptional conditions outside of IO (partly because of the "only catch in IO" restriction, and substantially because we have other, good methods). > What I wanted to get across is checked exceptions ala. Java (although they are too commonly bypassed in that example). I'd like to see some language flesh out checked exceptions with parametric polymorphism. Alack, this is not what Haskell has (yet?) done.
- kpmah 11y ago
  Ok, I think you have me convinced. Haskell doesn't quite measure up here. One more point to Idris!
  - dllthomas 11y ago
    Note that I don't think there's really a better story out there for async exceptions - which are necessarily able to interrupt (almost) any bit of your computation. Ideally we may be able to make assertions about stack or heap overflow (especially for a non-Turing complete fragment of the language), but I'm not sure whether Idris is able to provide that. "ThreadKilled" and "UserInterrupt" are inherently unrelated to local program flow. For synchronous exceptions Haskell is sort of middle-of-the-road, differing from other languages mostly in providing other options that are substantially better for many use cases.

by kpmah 11y ago

dllthomas 11y ago

> In the case of error, assert and undefined, I wouldn't class them as exceptions but as unrecoverable errors, as discussed in the linked wiki page. Okay, but in the case of GHC you actually can recover from them. > I wasn't aware of 'throw' and that certainly weakens my argument. You could maybe argue it is an escape hatch in the same vein as unsafePerformIO, but I don't know how it is viewed by the community. Asynchronous exceptions are pretty widely accepted as the way to interrupt a long-running pure computation. `error` is pretty widely used on identifying programming errors and pretty well reserved to that case. There is some dispute over whether exceptions or Either is more appropriate to dealing with exceptional conditions in IO; more reluctance around exceptions for reporting exceptional conditions outside of IO (partly because of the "only catch in IO" restriction, and substantially because we have other, good methods). > What I wanted to get across is checked exceptions ala. Java (although they are too commonly bypassed in that example). I'd like to see some language flesh out checked exceptions with parametric polymorphism. Alack, this is not what Haskell has (yet?) done.

kpmah 11y ago
Ok, I think you have me convinced. Haskell doesn't quite measure up here. One more point to Idris!
- dllthomas 11y ago
  Note that I don't think there's really a better story out there for async exceptions - which are necessarily able to interrupt (almost) any bit of your computation. Ideally we may be able to make assertions about stack or heap overflow (especially for a non-Turing complete fragment of the language), but I'm not sure whether Idris is able to provide that. "ThreadKilled" and "UserInterrupt" are inherently unrelated to local program flow. For synchronous exceptions Haskell is sort of middle-of-the-road, differing from other languages mostly in providing other options that are substantially better for many use cases.