As this SRFI attempts to "subvert" the existing idioms,
I would say "supplement" rather than "subvert".
Well, maybe. (uhm)
But, in order to use this style of programming meaningfully, you're going to need some functions that return either Maybe or Either.
In addition to the "object or #f" convention, there is also the "failure (and success) continuations" convention, the "object or raise exception" convention, and the CL conventions of "one value or zero values" and "object and boolean values". Each of these has its strengths and weaknesses, and Maybe is no exception.
Yes, and we learn those strengths and weaknesses not by studying the words and grammar, but by studying language usages.
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 have no objection in principle, but I'm not sure what would constitute a good reference. One that comes to mind is making otherwise partial functions total, analogous to the use of NaN in inexact arithmetic.
I think that anything is better than nothing.
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.
I suggest with respect that that is a case of boxed-in thinking: because that's the way we do it, we just don't think of designs that would require another way.
This isn't "a case of boxed-in thinking". This is a request for sample usages, because I think that they are needed to make a fair judgement.
(and I think that everyone will make their own)
Most dictionaries present usage examples in addition to sheer explanations of words' meanings.
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
If they were used to excess, absolutely. But Scheme is a There's More Than One Way To Do It language, which makes it a matter of tasteful rather than exclusive use.
Which is why it would be instructive to see how these features are used in real programs.
For example, I have a fairly succinct implementation of the A* search algorithm described here:
I read your post, but I have to say that I find the original version, despite the imperative style, much easier to understand than yours, so for me at least this is not a good example at all. Something beyond the trivial yet still universally accessible.
I think that it's inevitable that different people have different views, which is absolutely fine.
It doesn't have to be this example. It could be some other one. Anything that would illustrate the usage (and usefulness) of the style of programming that you propose.
If the style was intended to solve some real issues, this shouldn't be difficult: just show the examples that inspired the idea, or the problems that it intended to solve.