I may as well send my reply to the list too, then! (-: On Fri, 14 Sep 2001 moran@galconn.com wrote:
Mark Carroll wrote: (snip)
Oh, certainly, but couldn't the compiler do all the rewriting for you, though, so existing code would still work and new code would still look nice?
I'm not sure how this would interact with type inference; what's the difference between a function that I mean to be rewritten and one that I don't? Perhaps what you're wanting is that every type implicitly has an exception constructor tacked on. This is in effect what one gets with the exception extension.
Yes, I suppose you're correct, although I'd add that I'd expect that the compiler could often do lots of optimisation so that it only needs to check for the exceptional condition when checking the result of a function from which exceptions can arise, and in that case it can go right up to the handler, so in practice I bet that you could implement this without every single calculation being tainted by such overhead even though there's no semantic difference.
(Although, the main point of my Succeeded/Exception example is just to show that for much exception stuff monads needn't be necessitated.)
I'm not sure what you mean here. For hand-written exception code, monads make the code easier to read in most cases. But I don't think you mean that; it sounds like you mean "exceptions can be expressed already, so there's no need for new stuff". I don't buy that in general (since otherwise, why not just use the raw lambda calculus, or Turing machines), or in this specific case, since the encoding is a lot of work, and needs to be done for almost everything you might use (including things one usually doesn't have access to, like the Prelude and library code). But maybe you don't mean that.
I sort of do mean that, with the compiler doing the work you mention. There would be "new stuff" in how the "throws/catch" stuff the programmer would write would interact with how the compiler would implement the synchronous exceptions, but it would look reasonable to the programmer and not require them to catch such exceptions from within monads. (snip)
Well, if you can deal with only catching in the IO monad, then what you want is avilable now, with the extension (GHC only at the moment I think). Otherwise, you're stuck encoding it. Now, you may well be able to structure your code better if you employed an exception monad (not the IO monad, just an ordainary monad), or perhaps a continuation monad. (Aside: it seems as though you're lumping general monads, usable anywhere without affecting the rest of the program, together with the IO monad, which is the top-level put-impure-things-here monad. It's important to see that there's a difference. I apologise if you do; if you don't, feel free to ask probing questions.)
(-: Really, I just want to be able to use exceptions that behave more or less as I've suggested without having to catch them from within monads. It would indeed be especially irritating to have to catch them all within the IO monad, as I would now if I wasn't doing the ugly manual encoding that I currently have to that I figure could easily be done behind the scenes with some much nicer syntactic sugar on top. I may not understand monads enough, though. I think of them being inextricably linked with actions, probably sequenced ones, and I'm wanting to use exceptions in purely declarative code where actions shouldn't be relevant concept. Perhaps I should be writing this code in a monadic style, though, and thinking in terms of actions. -- Mark