Re: Exceptions and functions. Second round?
On 16-Jun-1998, Greg Michaelson [EMAIL PROTECTED] wrote: In SML(sorry...), in: exp1 handle exp2 exp1 is evaluated and any exception raised within it is handled by an appropriate handler in exp2. If there isn't one then the exception is handled in the enclosing environment for the whole construct. Similarly, if an exception is raised in exp2 then it is handled in the enclosing environment. So exception handling follows a stack based regime. Instead, how about having exp2 handle exceptions raised within itself You can do this quite easily: expr1 `recursive_handle` expr2 = expr1 `handle` (\ e - expr2 e `recursive_handle` expr2) (Here I'm using a version of `handle' where the handler is the 2nd argument.) However, doing this might be a bad idea, I think, because if `expr2' raises any exception, this could easily lead to an infinite loop. and also allowing mutually recursive handlers? This is also allowed by the current proposal -- it's quite straightforward: handler1 e = stuff1 `handle` handler2 handler2 e = stuff2 `handle` handler1 -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Exceptions and functions. Second round?
Tony Finch cites Hans Aberg, who comments the posting of Eric Zuurbier who writes that: "... Exceptions are merely a way to structure the code, so that the main line and error handling can be neatly separated." * This is the original idea, but I pointed out that exceptions are in * fact much deeper: They can be used as a programming technique too, * and further, many common language constructs (such as "return", * "break", etc in C++) can be viewed as special cases of exception * handling. [HA] Indeed, in Modula-3, RETURN and EXIT are defined in terms of exceptions. I like the idea of the non-deterministic exception system that has been proposed, but it'll be interesting to see how well it works in real life... Tony. I am afraid that we are repeating what has been already said, but OK, this is the essence of wisdom... I don't think that I would agree with such philosophy. "break" in C is nothing more than a structured "goto". Break from "switch" is just a jump, from a loop it might do some cleanup (if the loop index is stacked). "Return" is also a jump with the cleanup of the last instance frame. As we all know, all this can be represented by continuations, and this is a practical issue, not a statement that "all Turing machines are equal, only some are more equal than the others..." There is - in my opinion - nothing "exceptional" in *standard* imperative control structures. OK, I admit that I am a sinner myself, and I had written some small event-driven programs using (ppardonnez le mot) "longjump" in C, but I believe strongly that the functional programming community with the monadic religion etc. is much more close to the Truth. Jerzy Karczmarczuk Caen, France
Re: Exceptions and functions. Second round?
At 14:01 +0200 98/06/16, Jerzy Karczmarczuk wrote: There is - in my opinion - nothing "exceptional" in *standard* imperative control structures. OK, I admit that I am a sinner myself, and I had written some small event-driven programs using (ppardonnez le mot) "longjump" in C, but I believe strongly that the functional programming community with the monadic religion etc. is much more close to the Truth. I think you are raising the issue of exceptions without handling it properly. :-) Of course, when leaping to the next level of abstraction, exceptions are as exceptional as irrational numbers are irrational and the imaginary complex unit is imaginary in the original linguistic semantic sense, that is, not at all. And C is a language whose trademark is the absence of logical structure described by theory, so what's done in that language is rather misleading if one wants to produce a new generation of languages admitting new abstractions for the convenience to people that can think in terms of abstractions and by that do more efficient work. In fact, the opposite seems to happen, the new concept of exceptions seems to fit those old imperative ad hoc structures into a nice single abstraction. As we sit here with a language, Haskell, which normally does not admit imperative structures, using exceptions might be a neat way to do it. Hans Aberg * Email: Hans Aberg mailto:[EMAIL PROTECTED] * Home Page: http://www.matematik.su.se/~haberg/ * AMS member listing: http://www.ams.org/cml/
Re: Exceptions and functions. Second round?
[EMAIL PROTECTED] (Greg Michaelson) writes: In SML(sorry...), in: exp1 handle exp2 exp1 is evaluated and any exception raised within it is handled by an appropriate handler in exp2. If there isn't one then the exception is handled in the enclosing environment for the whole construct. Similarly, if an exception is raised in exp2 then it is handled in the enclosing environment. So exception handling follows a stack based regime. Instead, how about having exp2 handle exceptions raised within itself and also allowing mutually recursive handlers? No need to wire this into the semantics/implementation - it's easy to implement your "recursive catch" using the plain catch: rcatch :: IO a - (IOError - IO a) - IO a m `rcatch` h = m `catch` \err - (h err `catch` h) but notice that I call plain catch when invoking the handler - so we won't get into infinite loops. If infinite loops are what you want :-), then we have "really recursive catch" rrcatch :: IO a - (IOError - IO a) - IO a m `rrcatch` h = m `catch` \err - (h err `rrcatch` h) Yet another variant would be to invoke the handler up to 10 times (say) before giving up and invoking the outer handler. This might form a very nice inter-process communication mechanism, which may be recognised by people who have written interrupt driven multi-process systems. I sort of see how this might work - but I've only _read about_ such systems - not actually implemented them. Where could I find out more? Alastair ps I'm getting kinda worried about people talking about using the exception handling mechanism to implement various control constructs. While our non-deterministic semantics is (I hope) fine for writing robust programs, I can't see how to build __predictable__ control constructs on top of it and I have no desire to modify the implementation and semantics just so that you can do so. I also think we need to spend some time playing with the GHC-based implementation before we'll really know how it performs. Just how big a problem will it be if an optimiser transforms a program that would have raised an error into a program that enters an infinite loop and triggers a timeout? In some applications, this won't be a problem but it could be a real problem in others.
Re: Exceptions and functions. Second round?
In SML(sorry...), in: exp1 handle exp2 exp1 is evaluated and any exception raised within it is handled by an appropriate handler in exp2. If there isn't one then the exception is handled in the enclosing environment for the whole construct. Similarly, if an exception is raised in exp2 then it is handled in the enclosing environment. So exception handling follows a stack based regime. Instead, how about having exp2 handle exceptions raised within itself and also allowing mutually recursive handlers? This might form a very nice inter-process communication mechanism, which may be recognised by people who have written interrupt driven multi-process systems. It probably has horrendous semantic implications... Greg Michaelson
