On Tue, Mar 31, 2020 at 8:45 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
>
>
> Am Di., 31. März 2020 um 15:35 Uhr schrieb Duy Nguyen <xxxxxx@gmail.com>:
>>
>> On Mon, Mar 30, 2020 at 11:07 PM Panicz Maciej Godek
>> <xxxxxx@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > when I saw the title this SRFI, I thought to myself that it does not reflect the common idioms that are present in Scheme for solving the problems that are commonly used with Haskell's Maybe and Either types: in the case of Maybe, you use #f for Nothing, and you use the and-let* a.k.a. SRFI-2 to compose the computation, and in the case of Either you'd typically use short-circuited evaluation of "and" and "or"
>> >
>> > When I looked into the document, it asserted the existence of some part of the first idiom, but with a caveat that
>> >
>> > "if the procedure is able to return any value on success, there is no way to distinguish between a successful return of #f and failure"
>> >
>> > As this SRFI attempts to "subvert" the existing idioms, I think that -- in addition to having a reference implementation -- it would benefit from having some set of reference usages, so that they could be easily compared with the idiomatic Scheme solutions.
>>
>> I can see that we can live well without Maybe. If we want to return #f
>> as a value, not as a failure, we can just wrap the result in a cons. I
>> guess it's as heavy as Maybe (maybe a bit adhoc?)
>>
>> However, we can't do something like that with Either where the Left
>> contains the error reason. How do you usually pass error messages
>> around (Maybe I'm missing something).
>
>
> What do you mean by "passing error messages around" in everyday programming? Usually, one would invoke the current error handler or a special failure continuation to signal errors and wouldn't treat errors through a data-directed programming style.
>

Ah that's what I missed. But I think we're dealing with data-directed
programming style here though (returning #f as fail), perhaps not
severe enough to change control flow, just log the errors for more
analysis later.
--
Duy