Application letters at the Haskell workshop: suggestion

[Mark Carroll]

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