SRFI-144 requires that (flmin) returns +inf.0 and that
(flmax) returns -inf.0, so these procedures can't really
be aliases to the Chibi implementation of R7RS max and min.
The problem with the original `case-lambda` tests is that they could
actually pass if the `+` and `*` procedures were implemented correctly
but `case-lambda` itself wasn’t.
Specifically, an attempted optimized `case-lambda` implementation
which looked at the length of its arguments list and subsequently
erroneously always chose the variadic clause of the `plus` procedure
would still pass the test, because `plus` in this case recreated the
behaviour of the `+` procedure used for the test; it was never
actually observable whether the `args` clause or one of the more
specific clauses had been used to generate the result. Similar applies
to the `mult` test: although in that case an implementation could only
have erroneously chosen the `(x y . z)` clause in the two-argument
case, it would still have been an error invisible to the test cases.
I’ve also added a test which attempts to ensure that a redundant
clause will never match. This may cause a warning on Schemes which
detect such clauses at compile time, but R7RS does not explicitly
define such `case-lambda` expressions as erroneous in any way, so it
would be wrong (and non-conformant) for it to stop the tests running
altogether.
(This patch mainly useful because Chibi’s R7RS tests are sometimes
used by other implementations to ensure conformance. Chibi passed
these tests in any case.)
Without this patch, parse-commit will unconditionally use a faillure
continuation which simply returns `#f`. This may be undesirable in
some situations. As such, this commit allows (optionally) passing
a custom failure continuation as a second argument. If none is passed
the old behavior is used, hence this commit doesn't cause any backwards
incompatible API changes.
See #822
While testing a `(chibi parser)`-based parser I noticed that
`parse-string` is the only provided parser combinator which uses a list,
instead of a string, as a failure reason. It is not explicitly
documented but since all other standard parser combinator use a string
for the error reason I assume this to be a bug and have adjusted the
`parse-string` combinator accordingly in this commit.
