Am Di., 31. März 2020 um 20:34 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:
Am Di., 31. März 2020 um 17:55 Uhr schrieb Panicz Maciej Godek <xxxxxx@gmail.com>:


wt., 31 mar 2020 o 02:35 John Cowan <xxxxxx@ccil.org> napisał(a):

John's original email seems to be missing.
 


On Mon, Mar 30, 2020 at 12:07 PM Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

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.

The "one value or zero values" looks by far like the worst convention in my opinion.

When the success continuation naturally accepts multiple values, not all approaches are equivalent and it is not just a matter of programming style. What I have in mind is, say, a procedure `parse-lambda' that takes a Scheme form and yields, in case it is a lambda, two values, namely the <formals> and the <body>. In case it is not a valid lambda form, it shall yield an error.

For such a function procedure, the "object of #f" convention doesn't work well, and the CL convention doesn't either. What does work is the "object or raise exception" convention and the "failure and success continuations" convention. The drawback of the latter conventions is, though, that they change the control-flow, which is not always desirable.

If the authors of this SRFI become comfortable with my argument why Just, Left and Right should really accept an arbitrary number of values, this SRFI would provide a convention that fills a niche no other convention can.

Example code (which uses control-flow change just for illustration) could look like:

(maybe-cond
  ((parse-lambda form) => (lambda (formals body) ...))
  (else ...))

--
Marc
 
 
 
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.

As Scheme differentiates between #f and (), the "object or #f" convention works for most use cases; that appears uncontroversial to me. Apart from "that's the way we do it", its merit is that it is very fast. Maybe types need extra unboxing. (Of course, one can implement Maybe/Either types as efficiently by reserving value tag bits, but these are a rare resource in a Scheme implementation.)
 

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.

I agree. And the nice thing with Scheme is that you can deliver at the same time syntax that makes it pleasant to work with new concepts and that integrates them well into the rest of the Scheme language.

 

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.