RE: IOError vs. Exception vs. IOException
Just a thought, but what are the ramifications of taking the other route, relaxing the haskell 98 spec to allow implementations to expand the set of valid exceptions? a function can be used to determine whether it is something not covered by the haskell 98 spec (even if we dont know anything else about it..) and we can at least rethrow it or 'show' it in logs or whatever. lots of useful little functions can be written which are haskell 98 but should be general enough to handle random exceptions, it would be silly to have to keep 2 versions around... <snip>
It's difficult to "relax the Haskell 98 spec" in this way, since most compilers can be used in a strict Haskell 98 mode. Up to now this hasn't required using a different set of libraries, but if -fglasgow-exts changed the meaning of IO.catch then it would. Instead, I'd suggest deprecating System.IO.catch and perhaps the rest of the IOError support in System.IO. It is all available from System.IO.Error and Control.Exception anyhow. Cheers, Simon
I actually meant relax the haskell 98 spec in the quite literal sense of changing the spec to allow for the set of exceptions to be undefined. the only requirement should be that 'isHaskell98Exception' (or whatever) is accurate so unknown errors can be rethrown and the exceptions mentioned in the report exist (even if they are not thrown in a given implementation). It would encourage good programing techniques anyway, (testing for specific exceptions rather than doing a 'catch-all'). John on another note, when i catch and want to rethrow an exception, should i use ioError or throw? does it matter in an exception handler? On Fri, Nov 15, 2002 at 10:01:18AM -0000, Simon Marlow wrote:
Just a thought, but what are the ramifications of taking the other route, relaxing the haskell 98 spec to allow implementations to expand the set of valid exceptions? a function can be used to determine whether it is something not covered by the haskell 98 spec (even if we dont know anything else about it..) and we can at least rethrow it or 'show' it in logs or whatever. lots of useful little functions can be written which are haskell 98 but should be general enough to handle random exceptions, it would be silly to have to keep 2 versions around... <snip>
It's difficult to "relax the Haskell 98 spec" in this way, since most compilers can be used in a strict Haskell 98 mode. Up to now this hasn't required using a different set of libraries, but if -fglasgow-exts changed the meaning of IO.catch then it would.
Instead, I'd suggest deprecating System.IO.catch and perhaps the rest of the IOError support in System.IO. It is all available from System.IO.Error and Control.Exception anyhow.
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
I actually meant relax the haskell 98 spec in the quite literal sense of changing the spec to allow for the set of exceptions to be undefined.
The set of exceptions is already undefined. The IOError type is deliberately abstract (i.e., you can't see the constructors) so that the set of exceptions can be extended. (It would have been more convenient if you could see the constructors so that you could use pattern matching but making it extensible won out over convenience.) But, whatever exception is used, changing the haskell98 spec so that catch (print (1/0)) print is not equal to bottom (as in the current spec) is a pretty big step. I helped design non-determinstic exceptions and I still think the idea is a pretty radical idea that needs more discussion and more experience before it is added to the language. -- Alastair Reid ps In case it sounds like I've changed my mind about non-deterministic exceptions. This is not so - I continue to believe that languages without exception handling are useless toys (however beautiful) and that ND-exceptions are the only viable way of adding exceptions to Haskell. What I'm saying is that I'm not sure that a concensus exists and that there may be worthwhile minor variations on the idea that should be explored.
On Saturday, 2002-11-16, 05:24, CET, Alastair Reid wrote:
[...]
The set of exceptions is already undefined. The IOError type is deliberately abstract (i.e., you can't see the constructors) so that the set of exceptions can be extended. (It would have been more convenient if you could see the constructors so that you could use pattern matching but making it extensible won out over convenience.)
Hello, AFAICS, there is no discrepancy between making IOError extensible and revealing constructors. A specification could guarantee that IOError has certain data constructors while not forbidding that it has more than these.
[...]
Wolfgang
On Fri, Nov 15, 2002 at 10:01:18AM -0000, Simon Marlow wrote:
Instead, I'd suggest deprecating System.IO.catch and perhaps the rest of the IOError support in System.IO. It is all available from System.IO.Error and Control.Exception anyhow.
That sounds like a sensible separation. You'd also want System.IO.Error to export the IOError versions of catch and try (which it doesn't now).
participants (5)
-
Alastair Reid -
John Meacham -
Ross Paterson -
Simon Marlow -
Wolfgang Jeltsch