John, Wolfgang,

first of all, thank you very much for publishing this SRFI. In my opinion, it is a valuable and very helpful addition to the Scheme language.

On a first glance, the following thoughts came to my mind:

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

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

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

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

(5) Minor: I am not sure whether I think that the names `maybe->lisp' and `lisp->maybe' are a good choice.

Thanks again,

Marc