Email list hosting service & mailing list manager

maybe-let* Shiro Kawai (03 Jul 2020 03:11 UTC)
Re: maybe-let* Marc Nieper-Wißkirchen (03 Jul 2020 05:54 UTC)
Re: maybe-let* Marc Nieper-Wißkirchen (03 Jul 2020 07:22 UTC)
Re: maybe-let* Wolfgang Corcoran-Mathe (03 Jul 2020 17:19 UTC)
Re: maybe-let* Marc Nieper-Wißkirchen (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* Marc Nieper-Wißkirchen (04 Jul 2020 09:55 UTC)
Re: maybe-let* John Cowan (05 Jul 2020 22:40 UTC)
Re: maybe-let* Marc Nieper-Wißkirchen (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.