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 17:38 UTC

Am Fr., 3. Juli 2020 um 19:19 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> I'd prefer to avoid adding let-values syntax to the basic
> maybe/either-let* forms.  (Anecdotally, some Schemers dislike
> let-values and let*-values merely because of the extra parens, and,
> while procedures can always return multiple values, it's the rare
> Scheme programmer who uses the multiple-value-aware forms everywhere.)
> I'd also prefer to avoid mixing single- and multiple-value syntax
> (à la SRFI 71, for example).
>
> My suggestion to John was to add maybe/either-let*-values forms,
> which handle (<formals> <container-expression>) claws in a way
> analogous to let-values, but with the unwrapping of the value of
> <container-expression>.  (The (id) and ((expr)) claws have exactly
> the same semantics that they do in the -let* forms.)  They're simple
> variations on maybe/either-let* and easy to add; programmers who
> only intend to use single-valued containers can pretend they don't
> exist.

If XXX-let*-values is provided, it makes perfect sense to restrict
XXX-let* to single-valued XXXs much like let* is a restricted version
of let*-values. So I think this is a very good idea!

However, XXX-let*-values is still missing in the current draft. I hope
it was an oversight.

PS The SRFI uses the language "an error is signaled" in conjunction
with the new syntax again. That's an error, which I am herewith
signaling again. Unfortunately, the signaled error hasn't been caught
by the SRFI's author yet. :)

(The impossibility to write a robust test for this requirement proves
one shortcoming.)