Hi!
Dear Panicz,
I have a few comments to make on SRFI 202. There are some things that should be addressed before this SRFI is finalized.
(1) The SRFI claims that it provides a conservative extension of SRFI 2's and-let* form. This, however, is not universally true:
(and-let* ((_ <expression>))
<body>)
is
an example where in the original and-let* specification `_` is viewed
as a variable and will thus be bound to the result of <expression>
in the <body>. The identifier `_`, however, stands for a
particular pattern in some of the pattern matchers described in SRFI
200. Thus, with the extensions of SRFI 202, `_` won't be bound in
<body> to the result of <expression>.
It will. As long as thevthing on the left is an identifier, it is bound using the let form (see the reference implementation)
This becomes more problematic when the pattern matcher used has more special forms that could look like variables.
I mean, it would (which is why it doesn't)
The obvious way out is to make it explicit in the syntax when there is a pattern and not a variable on the left.
(2)
The syntax used for the variant that supports multiple values does not
fit in smoothly when we remember that zero values are possible. In that
case, the obvious syntax would clash with the syntax used for expression
guards.
That's right, but it's also a problem for the originall and-let*
(3)
Ignoring additional multiple values and short-circuiting when there are
not enough values is not in the spirit of Scheme (and may lead to
silent bugs). For extra multiple values, SRFI 202 is yet missing a
syntax that allows a rest argument as in R7RS's <formals>.
I'd say that providing a variable number of multiple values is not in the spirit of Scheme ;]
But I guess it's in the eye of the beholder.
I've been considering a srfi-71-style way of handling this, but I'm not really convinced of its practical usefulness
For
example, if SRFI 202 was changed so that patterns always have to appear
in parentheses, "rest" patterns could be allowed. This would also solve
issues (1) and (2).
(4)
In the multiple-values case, picking out the first pattern/variable for
the and test, is rather arbitrary. With (3), also this can be dropped.
Yeah, maybe it is an argument for having the SRF-71-style values option