Subject: bug#72370: srfi-64: test-apply requires at least one specifier

From: Taylan Kammer <[email-masked]>
Date: Mon, 30 Sep 2024 20:50:48 +0200

On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-apply:
>
>> If one or more specifiers are listed then only tests matching the specifiers
>> are executed.
> That implies that specifiers are optional and the following code should work:
>
>     (use-modules (srfi srfi-64))
>     (test-apply (λ () #t))
>
> However it does not:
>
>     Backtrace:
>     In ice-9/boot-9.scm:
>       1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>     In unknown file:
>                7 (apply-smob/0 #<thunk 7fdf6ecc4300>)
>     In ice-9/boot-9.scm:
>         724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handler (k proc)>)
>     In ice-9/eval.scm:
>         619:8  5 (_ #(#(#<directory (guile-user) 7fdf6ecc7c80>)))
>     In ice-9/boot-9.scm:
>        2836:4  4 (save-module-excursion _)
>       4388:12  3 (_)
>     In srfi/srfi-64/testing.scm:
>        947:34  2 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/tests/s…>)
>        938:47  1 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/test…> . _)
>     In unknown file:
>                0 (reverse #t)
>
>     ERROR: In procedure reverse:
>     In procedure reverse: Wrong type argument in position 1: #t
>
> Have a nice day
> Tomas Volf

If anyone's wondering why I don't want to work with the upstream SRFI-64 code, reading the implementation of test-apply is all you need. :-)

It almost makes me think it must be machine-generated code, or intentionally obfuscated. But anyway.

My implementation actually had a similar bug, but it should be fixed now with this commit:

    https://codeberg.org/taylan/scheme-srfis/commit/3091e3b863d53a012b4be4376814bb67bf09020d

I've also noticed the other issue with test-apply that you reported as a separate bug report, and will fix that later.

Thanks a ton for all these reports, because it seems you've really caught a ton of edge-cases, and some glaring issues in seldom-used parts of the API.

- Taylan