> On Mar 30, 2020, at 7:09 AM, 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 mention this because I suspect that the resulting code might turn out much more cumbersome than idiomatic code, whereas -- frankly speaking -- I have never found the lack of distinction between #f and failure to be a problem in practice, because when #f is used to represent a lack of result, then result typically isn't a boolean, and when the result is a boolean, then the problem does not appear.
>
> (The only case that I can imagine where a result could potentially be a boolean is when you're using a function such as SRFI-1's "find" on a list that might contain the #f value. But then again, I don't recall this situation to ever appear in practice, and can't even imagine any meaningful use case that would lead to such situation)
>
> So while I can see the benefits of having Maybe and Either in Haskell (partly because they are used in type signatures, which is informative, and partly because of their uniform treatment within Haskell's "do-notation"), my fear is that the transplant of those ideas to Scheme will only make the actual programs more verbose and harder to read, which is why I'd appreciate some non-contrived, real life examples.
>
> For example, I have a fairly succinct implementation of the A* search algorithm described here:
>
> https://www.quora.com/What-are-the-pros-and-cons-of-functional-programming-compared-to-imperative-programming/answer/Panicz-Godek
>
> It would be interesting to see a corresponding variant that would use SRFI-189.

+1

Marc