Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-WiÃkirchen 08 Jul 2020 20:21 UTC
Am Mi., 8. Juli 2020 um 21:47 Uhr schrieb Wolfgang Corcoran-Mathe <email@example.com>: > > 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 think so (at least as long not arbitrary exceptions but only well-defined are caught). The guard form or any C++/Java/Python exception handler that does not reraise the caught exception does this exactly, namely turning an exception into data. This is certainly an important language construct. One can also see it as protocol conversion, from exception-style programming to a C-style programming where the return value decides about success: (define (delete-file-and-return-success filename) (guard (exc ((file-error? exc) #f)) (delete-file filename) #t)) The point of Eithers is to reason about success and failure (with payloads) in a data-driven style. Many existing APIs, however, use different code paths through exceptions and not data. We want an adapter to the world of Eithers. We can put Eithers in data structures (e.g. to create a list of results). We cannot put raised exceptions in lists. This is just another use case.