maybe-let*
Shiro Kawai
(03 Jul 2020 03:11 UTC)
|
Re: maybe-let* (no sender) (03 Jul 2020 05:54 UTC)
|
Re: maybe-let*
(no sender)
(03 Jul 2020 07:22 UTC)
|
Re: maybe-let*
Wolfgang Corcoran-Mathe
(03 Jul 2020 17:19 UTC)
|
Re: maybe-let*
(no sender)
(03 Jul 2020 17:38 UTC)
|
Re: maybe-let*
John Cowan
(04 Jul 2020 00:48 UTC)
|
Re: maybe-let*
Wolfgang Corcoran-Mathe
(04 Jul 2020 01:48 UTC)
|
Re: maybe-let*
(no sender)
(04 Jul 2020 09:55 UTC)
|
Re: maybe-let*
John Cowan
(05 Jul 2020 22:40 UTC)
|
Re: maybe-let*
(no sender)
(07 Jul 2020 14:19 UTC)
|
Re: maybe-let* Marc Nieper-WiÃkirchen 03 Jul 2020 05:54 UTC
Am Fr., 3. Juli 2020 um 05:11 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>: > > Ok, I updated Gauche's implementation according to draft #8. > > - The value returned from the case of empty claws and empty body can be explicitly stated (Just/Right of an undefined value). It can be deduced from the parallel of and-let* and maybe-and, but less room of misinterpretation. We can also explicitly state about the non-empty claws and empty body case. As and-let* unwraps the Just/Rights, an empty (maybe-let*) should return #t. > - Would it be too much to handle multi-value Just/Right in claws? We can define CLAW as > (VAR ... MAYBE-EXPR). I think the same syntax than in let*-values should be used. So single values need one more level of parentheses compared to SRFI 2's and-let*. Excluding multiple values would destroy one main use case for the Maybe protocol. > Potential drawback is that, with that definition, (MAYBE-EXPR) looks like expecting a zero-value Just, while in the current definition it can be any Just. Zero values would be (() MAYBE-EXPR), which is just fine.