Am Fr., 28. Aug. 2020 um 14:35 Uhr schrieb Panicz Maciej Godek <
xxxxxx@gmail.com>:
pt., 28.08.2020, 13:19 użytkownik Marc Nieper-Wißkirchen <
xxxxxx@nieper-wisskirchen.de> napisał:
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)
If this is supposed to be true not only for the reference implementation then it should be added to the specification section that a single identifier is never read as a pattern but always as a variable.
I'll add this.
(Unfortunately, this excludes some use cases like (and-let* (... (_ (display "Logging...")) ...) ...), where we just want to ignore the return value.
If display does not return #f, then it does not, because you aren't forced to use the identifier anywhere. If it could return #f, then you'd either need to write this explicitly, as in (and-let* (... (#f (display "Logging ...")) ...) ...), or use the `,_ pattern instead.
(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*
The original and-let* is dealing with single values, which is just fine. If we ever specify an extension that handles multiple values (well), it should be able to handle the case of an arbitrary number of values and not just an arbitrary number greater than zero.
(We can probably only extend and-let* once, so if we do this we have to get it right from the beginning.)
(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 ;]
It depends (yielding multiple values is just passing arguments to an (implicit) continuation and calling procedures with a variable number of arguments is quite common). But, whatsoever, what does it have to do with the point raised?
The thing with the and-let* form is that (in my understanding) it just uses #f to represent any error. In my experience, having it raising an error is a surprising behavior.
I will add the SRFI-71-style "values" form to the current specification.
Yeah, maybe it is an argument for having the SRF-71-style values option
This way, all arbitrariness would go away, wouldn't it?
Not all of it, as I won't remove the old option of handling multiple values (I think it's nice and concise, but indeed examining the first pattern does feel arbitrary. Perhaps I could modify it so that if there's more than one value, then the requirement that the first one is non-#f goes away -- but I'm not convinced of that either)