[Fwd: Application letters at the Haskell workshop: suggestion]

[moran@galconn.com]

This is a multi-part message in MIME format.
--------------12BF5CBDCE0F062989284316
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


[ Meant for this to go to the mailing list ... ]

-- 
Andy Moran                                              Ph.  (503) 526 3472
Galois Connections Inc.                                 Fax. (503) 350 0833
3875 SW Hall Blvd.                                   http://www.galconn.com
Beaverton, OR 97005                                       moran@galconn.com
--------------12BF5CBDCE0F062989284316
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3BA243C6.B8D2EA23@galconn.com>
Date: Fri, 14 Sep 2001 10:52:06 -0700
From: moran@galconn.com
Organization: Galois Connections Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Carroll <mark@chaos.x-philes.com>
Subject: Re: Application letters at the Haskell workshop: suggestion
References: <Pine.LNX.4.21.0109141313160.1300-100000@niagara.nonet>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Carroll wrote:

> For the sort of exception where the function you're calling either returns
> successfully or throws an exception, I'm not sure why things can't be done
> entirely referentially transparently. One would do it in just the same way
> that something might return a 'Succeeded a' or 'Exception String' or
> something as aspects of an algebraic data type. The function, whenever it
> does something that might cause an exception, if it gets a 'Succeeded a'
> returned it goes ahead and returns something based on the a, or else it
> returns the Exception String, except if there's a 'catch' which specifies
> some other value to return if there was an exception.

Exceptions can be encoded in this way, and for a while this was the only way
to have exceptions in Haskell (modulo monadic presentations, etc.).  But what
about division by zero?  It can easily be encoded in the above style:
Exception "Division by Zero".  But now _every_ function that can raise or
wants to handle this exception must be rewritten so that it either wraps
correct results with Succeeded, wraps exceptional results with Exception, and
passes exceptional results upwards.  

The point of the exceptions extension is that you don't need to change
anything; existing code (even that which may cause a division by zero error)
remains as it is.  And we can raise exceptions of our own anywhere.  The
tradeoff is that we can catch these exceptions in the IO monad.  But we can
extend the extension to handle asychronous exceptions (which don't admit this
kind of encoding, AFAIK).

Cheers,

Andy

-- 
Andy Moran                                              Ph.  (503) 526 3472
Galois Connections Inc.                                 Fax. (503) 350 0833
3875 SW Hall Blvd.                                   http://www.galconn.com
Beaverton, OR 97005                                       moran@galconn.com

--------------12BF5CBDCE0F062989284316--