multiple-values and chain-and Dr. Arne Babenhauserheide (24 Aug 2020 11:51 UTC)
Re: multiple-values and chain-and Marc Nieper-Wißkirchen (24 Aug 2020 12:02 UTC)
Re: multiple-values and chain-and Dr. Arne Babenhauserheide (24 Aug 2020 14:03 UTC)
Re: multiple-values and chain-and Marc Nieper-Wißkirchen (24 Aug 2020 14:13 UTC)
Re: multiple-values and chain-and Dr. Arne Babenhauserheide (29 Aug 2020 11:38 UTC)
Re: multiple-values and chain-and Adam Nelson (28 Aug 2020 02:47 UTC)

Re: multiple-values and chain-and Marc Nieper-Wißkirchen 24 Aug 2020 14:13 UTC

Am Mo., 24. Aug. 2020 um 16:03 Uhr schrieb Dr. Arne Babenhauserheide
<xxxxxx@web.de>:

> Ah, I remember. That was the discussion about making this generic. I
> didn’t quite understand why that’s essential: If there are more than 10
> values, the added overhead of λ(_ ...) wouldn’t hurt much, but when you
> have just 3 values, the relative impact of the required λ is much
> bigger.
>
> So why not enable elegant simple cases with _ _0 _1 _2 _3 _4 _5 _6 _7 _8
> and _9 (making _0 a synonym for _)?

In principle, this would be possible. One could limit the maximal
number to 9 for pure syntax-rules implementations, while syntax-case
implementations could, in principle, support any number following "_"
in conjunction with the auxiliary keyword SRFI 206.

But I am wondering whether we really need this complication. Wouldn't
an explicit "let*-values" be easier here?

> > That would have very special semantics. Just taking the first value is
> > rather arbitrary and the case of zero values wouldn't fit into this model
> > as well.
>
> I thought about just using the first value, because that is the value
> you would receive when calling the procedure without handling of
> multiple values.
>
> I didn’t think of zero values in this, though. That could never be #f
> then.

One could make this feature optional, but I still find the semantics a
bit arbitrary.

Marc