On 2020-07-08 16:27 +0200, Marc Nieper-Wißkirchen wrote:
> While it is true that this syntax can always be added later (as can,
> in principle, every part of this SRFI), it would be unfortunate to
> leave out exactly 'either-guard' because it will certainly be used
> much more often than a number of other procedures in this SRFI and
> sets a clear style for idiomatic code:

The more I think about a form for converting exceptions to Eithers,
the more there seems to be something fundamentally flawed about the
idea.  The exception-based and data-directed approaches to
error-handling seem to me to be very difficult to reconcile, at
least in the exception->data direction; you're taking an exception,
possibly asynchronous, signalled outside the normal flow of control
of a program, and jumping back into that flow with a datum encapsulating
that exception.  In contrast, going the other way (e.g. by raising
the payload of a Left) is simple and idiomatic.  This suggests to
me that converting exceptions to Eithers, as an idiom, is the Wrong
Thing.

I don't have anything to back this opinion up with, though, so
please take it with a grain of salt.  If the consensus is that
either-guard should be added, let it be so.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"In a bureaucracy, the file cards are reality. Punching
new holes recreates the world." --Alan Moore, _V For Vendetta_