ANNOUNCE: AbortT-transformers version 1.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ANNOUNCE: AbortT-transformers version 1.0

Gregory Crosswhite-2
 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".

An abortable monadic computation runs until either it is finished or it
is aborted by calling the "abort" function.  All steps in the
computation after "abort" has been called are ignored, which means that
abort can be assigned an arbitrary type for its value within the
computation.

My implementation uses an Either type which is Left if the computation
has been prematurely terminated and Right of the computation is
continuing to proceed as normal.  I could have implemented the
functionality using the Continuation monad, but that seemed to be
overkill in cases where the user only wants a simple abort monad.

Cheers,
Greg
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Henning Thielemann-4
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?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Gregory Crosswhite-2
 On 09/08/10 12:54, Henning Thielemann wrote:
> 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
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Henning Thielemann

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.

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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Colin Paul Adams
>>>>> "Henning" == Henning Thielemann <[hidden email]> 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Henning Thielemann-4
Colin Paul Adams schrieb:

>>>>>> "Henning" == Henning Thielemann <[hidden email]> 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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Brandon S Allbery KF8NH
In reply to this post by Henning Thielemann
-----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]      [hidden email]
system administrator  [openafs,heimdal,too many hats]  [hidden email]
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-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Brandon S Allbery KF8NH
In reply to this post by Henning Thielemann-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/9/10 12:16 , Henning Thielemann wrote:

> Colin Paul Adams schrieb:
>>>>>>> "Henning" == Henning Thielemann <[hidden email]> 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]      [hidden email]
system administrator  [openafs,heimdal,too many hats]  [hidden email]
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-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: AbortT-transformers version 1.0

Ertugrul Söylemez
Brandon S Allbery KF8NH <[hidden email]> wrote:

> On 9/9/10 12:16 , Henning Thielemann wrote:
> > Colin Paul Adams schrieb:
> >
> >> 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.

No, it's just a coincidence that 'abort' and 'abnormal' start with the
same two letters. =)

But indeed, abortion is often used for abnormal termination, not only in
programming.  I think one of 'to cancel' or 'to discontinue' would be
more appropriate.


Greets,
Ertugrul


--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe