(1) SRFI 158 and the read procedure use the eof object to mark that generator has run out of values. If SRFI 189 were in existence before, it would have possibly made more sense for generators to use the Maybe protocol. Are there any plans to adapt SRFI 158 or to add adapters to SRFI 189? At the moment, generators cannot yield any eof object asd a value; if they used the Maybe protocol, they could yield any value.
The reason I adopted the EOF object for generators, besides its existing use in read procedures, was that it is deliberately second-class: it is forbidden in the standard to have a datum representation (see eof-object?), though some Schemes allow #!eof or the like.
I will add two more conversion procedures that convert between EOF objects and Nothing, and wrap/unwrap any other object with Just.
(2) The "old Scheme way" of returning #f on failure and any other value on success plays nicely with a number of special forms like `cond'/`=>' and `and-let*'. It would be nice if this SRFI provided a similar special forms for Maybe objects.
Good idea. I'll add maybe-if, which signals an error if its first argument is not a Maybe.
(3) One disadvantage of the "old Scheme way" to indicate success and failure is that it doesn't play well with multiple values in the success case as the accepting continuation needs to be able to accept an unknown number of arguments. SRFI 189 doesn't have to impose this restriction. It would be very schemely and elegant if the `just' constructor accepted an arbitrary number of values. (Contrary to Haskell, Scheme's procedures can accept more than one argument or none.) This will make a change of the specification of the `either-values' procedure necessary.
I don't quite see how this would work. In order to store multiple values, you have to reify them into a container of some sort anyway. Can you explain further?
(4) As described in the rational, this SRFI will help in catching programming errors by clearly separating types and forcing the programmer to unpack the Maybe objects. Unfortunately, some procedures in the current draft blur the line again, for example `maybe-join' that behaves differently whether the argument is a Maybe object or not. Therefore, there may be the danger that a programming error is not caught because the programmer has/has not unpacked a Maybe object, which `maybe-join' accepts silently.
The maybe-join procedure specifies its argument as _maybe_, which means it is an error if its argument is not a Maybe. This is a standard specification convention. But perhaps you mean the behavior if the payload of the argument is or is not a Maybe. I will add a clarification that that case is an error also. The point of maybe-join is to reduce a Maybe containing a Maybe to a non-nested Maybe.
(5) Minor: I am not sure whether I think that the names `maybe->lisp' and `lisp->maybe' are a good choice.
They are not, but I wasn't able to think of any better name for this convention that is not excessively verbose.