Comments on draft #3 Marc Nieper-WiÃkirchen 26 Apr 2020 10:22 UTC
(0) As someone who has lobbied for making this SRFI multiple-values-aware, I am, of course, delighted to see that multiple values have made it into this draft. (1) MAYBE-REF and EITHER-REF should call FAILURE and SUCCESS in tail context. (2) In EITHER-REF, it should be an error if the default value of FAILURE is invoked and the Left payload consists of zero or more than one value. (This allows the implementation to do what is currently in the spec, but it shouldn't be mandated because it somehow muddies the idea multiple values. In a Scheme where the RAISE procedure is multiple-values-aware and can thus take more than one value or zero values, RAISE should be applied to the Left payload without a change, which the current spec wouldn't allow.) (3) The new interface to MAYBE-SEQUENCE and EITHER-SEQUENCE looks good to me. I should make COMPUTATION-SEQUENCE of SRFI 166 compatible with the final version (which should also go into an abstract monadic framework). I would suggest making some arguments optional. The default value of INNER-CONSTRUCTOR should be the VALUES procedure (making it an error of a payload has more than one or zero values), the default value of OUTER-CONSTRUCTOR should be the LIST procedure. The default value of MAPPER should be `map'. (4) The type of an object of name `mapper' should be listed in the specification. (5) How would the sequence operations look for a general monad? (6) In LIST->MAYBE and LIST->EITHER the idea behind multiple values is muddied. A Just with no values is in no way a Nothing. To preserve these procedures for Maybes/Eithers with single-valued payloads, I would strongly suggest making it an error if the LIST argument contains more than one value or, in case of MAYBE->LIST, if MAYBE is a Just containing not a single value. I am not yet sure what to do with the procedure EITHER->LIST (also in view of EITHER->MAYBE). (7) Please add versions of LIST->MAYBE and LIST->EITHER and vice versa that are multiple-values aware. These versions would return #f in the Nothing case. Here we are making use of the fact that in Scheme the empty list is not #f, so we are not confusing a Just with no value with a Nothing. (8) If we allow MAYBE->EOF to be called on a Just without a single value, for symmetry, EOF->MAYBE should take more than one value. The same goes for LISP->MAYBE. However, I would rather make it an error to use MAYBE->LISP and MAYBE->EOF in the multiple values case. (9) Make it an error if MAYBE->VALUES and EITHER->VALUES are applied to a Just/Right without a single value. An implementation would still be free to choose what the current spec mandates, but it doesn't make much sense logically. (10) In the paragraph below VALUES->MAYBE and VALUES->EITHER, some formatting seems to be wrong. I think the two procedures do too much; they should be separated in the inverse of MAYBE->VALUES/EITHER->VALUES (restricted to the single-value situation) and MAYBE->LISP-VALUES/EITHER->LISP-VALUES. (11) MAYBE-UNFOLD and EITHER-UNFOLD should take more than one value for SEED. (12) MAYBE-IF shouldn't have to signal an error. This is not R6RS.