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.

Marc

 

Though frankly I'm not thrilled at sprinkling the "either-" prefix
everywhere when dealing with Either objects. Haskell has a special
syntax to make it easier to read and write monads. It's not the same
in Scheme...
--
Duy