Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 08 Jul 2020 19:47 UTC
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_