Gregory Crosswhite schrieb:

...

For whatever reason, nobody seems to have gotten around to implementing an Abort monad transformer (outside the monadLib package), so I decided to write one myself since I wanted the functionality but I use "transformers" rather than "monadLib". Is AbortT different from ErrorT, ExceptionalT and friends? Yes, for a couple of reasons. First, computations in the AbortT monad always "succeed"; they just might succeed earlier than expected. This contrasts with the computations in the ErrorT, etc. monads where aborting earlier is a signal that an error has occurred. Second, AbortT is not isomorphic to ErrorT because ErrorT requires that terminating early returns not just any value but a value which is an instance of Error; furthermore, even if this were not a problem, it would be a

On 09/08/10 12:54, Henning Thielemann wrote: problem that pattern match failures would have the effect of stuffing a string into your value that you probably didn't want and returning it early as if it were the correct answer. ExceptionT is a different matter because it handles "fail" as an uncaught error and places no restrictions on the error type, so one could implement the same functionality as AbortT by using ExceptionalT and requiring the end result be a monadic value of type "ExceptionalT e m e", where the exception and result types are the same. However, I believe that it is better to have the AbortT functionality available as a separate simple library specialized for this purpose than to have its functionality buried inside a more general library that is really intended to be used for a different purpose. Cheers, Greg

...

...

...

...

"Henning" == Henning Thielemann writes:

Henning> On Wed, 8 Sep 2010, Gregory Crosswhite wrote:

ExceptionT is a different matter because it handles "fail" as an >> uncaught error and places no restrictions on the error type, so >> one could implement the same functionality as AbortT by using >> ExceptionalT and requiring the end result be a monadic value of >> type "ExceptionalT e m e", where the exception and result types >> are the same. However, I believe that it is better to have the >> AbortT functionality available as a separate simple library >> specialized for this purpose than to have its functionality >> buried inside a more general library that is really intended to >> be used for a different purpose.

Henning> If we get rid of the notion of an exception as being Henning> something bad, and instead consider an exception as being Henning> early exit for whatever reason, I see no problem. E.g. you Henning> may well use an exception to terminate a successful search, Henning> returning the search result as exception value. So where is the exceptional nature? Is a successful conclusion to a search so exceptional? It seems to me that you want to get rid of the notion of an exception as something exceptional, in which case it would be better to give it a different name. -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/10 12:16 , Henning Thielemann wrote:

Colin Paul Adams schrieb:

...

...

...

...

...

> "Henning" == Henning Thielemann writes:

Henning> On Wed, 8 Sep 2010, Gregory Crosswhite wrote:

...

ExceptionT is a different matter because it handles "fail" as an >> uncaught error and places no restrictions on the error type, so >> one could implement the same functionality as AbortT by using >> ExceptionalT and requiring the end result be a monadic value of >> type "ExceptionalT e m e", where the exception and result types >> are the same. However, I believe that it is better to have the >> AbortT functionality available as a separate simple library >> specialized for this purpose than to have its functionality >> buried inside a more general library that is really intended to >> be used for a different purpose.

Henning> If we get rid of the notion of an exception as being Henning> something bad, and instead consider an exception as being Henning> early exit for whatever reason, I see no problem. E.g. you Henning> may well use an exception to terminate a successful search, Henning> returning the search result as exception value.

So where is the exceptional nature? Is a successful conclusion to a search so exceptional?

You search as long as you don't find what you are looking for. So not finding what you search seems to be the rule and finding it seems to be the exception. :-)

...

It seems to me that you want to get rid of the notion of an exception as something exceptional, in which case it would be better to give it a different name.

English is not my native tongue. If 'abort' is more appropriate than 'exception' we may rename modules from Exception to Abort.

"Abort" is even worse, as it implies *ab*normal termination (to my mind, at least, this suggests something closer to "error" than "exception"). In some sense this seems closer to Prolog's cut than any kind of exception. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJNAEACgkQIn7hlCsL25U2mwCggCsGcC1zJAjqmW+7tiXLlQ9i LGEAnig9tA2HZOc3uhVS6sDHLPuufCA2 =lmI1 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/8/10 18:43 , Henning Thielemann wrote:

On Wed, 8 Sep 2010, Gregory Crosswhite wrote:

...

ExceptionT is a different matter because it handles "fail" as an uncaught error and places no restrictions on the error type, so one could implement the same functionality as AbortT by using ExceptionalT and requiring the end result be a monadic value of type "ExceptionalT e m e", where the exception and result types are the same. However, I

If we get rid of the notion of an exception as being something bad, and instead consider an exception as being early exit for whatever reason, I see no problem. E.g. you may well use an exception to terminate a successful search, returning the search result as exception value.

But that's not an *exception*. It's probably best referred to as a "signal" (of the Qt/Gtk+ variety, not the Unix one). - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJM1EACgkQIn7hlCsL25VpRwCeNPcG9JVvLBqpCXCKynA4zwDe 5gIAnioNUIytSOxLiNqGv8wryOvBxWY3 =w2i0 -----END PGP SIGNATURE-----