On 2026-09-07 10:18, Daphne Preston-Kendal wrote:

> On 2 Sep 2026, at 14:16, Andrew Tropin <xxxxxx@trop.in> wrote:
>
>>> But this doesn’t answer the problem that the recommendation which seems to justify the existence of ‘set-current-test-runner!’ is ill advised. To clarify: if I import multiple libraries that provide test runners (because, for example, I want to make it a run time option to my test suite which is used), and each of them calls set-current-test-runner! to establish its own runner as the default, then under Scheme’s semantics it is unspecified which of those calls to set-current-test-runner! will run last and thus ‘win’, or indeed whether any of the calls at all will run.
>>
>> It's very unlikely case that multiple testing libraries will be loaded
>> at the same time and if so, it's a responsibility of the user to set a
>> proper default test runner.  I believe they will figure out how to setup
>> their REPL environment for this case.
>
> Sorry, I think I wasn’t clear enough about what the problem is here and only confused the issue by mentioning importing multiple test runners.
>
> If a program (in the sense of the R6RS or R7RS small) to run a test suite looks like this:
>
> (import (srfi :269)
>         (rot13)
>         (spiffing-test-runner))
> (test "example library test" ()
>   (is (string=? (string-rot13 "er") "re")))
>
> And the (spiffing-test-runner) library looks like this:
>
> (library (spiffing-test-runner)
>   (export run-tests-spiffingly)
>   (import (srfi :269)
>           (rnrs)
>           #;etc)
>   (define (run-tests-spiffingly arg)
>     #| code defines the test runner |#)
>   (set-default-test-runner! run-tests-spiffingly))
>
> Then it is unspecified whether the test will run with the run-tests-spiffingly procedure or with no test runner at all (unexpectedly triggering the ‘should produce a diagnostic indicating that no runner has been configured’). Because it is not lexically apparent to the compiler that the program actually depends on any identifiers from the (spiffing-test-runner) library, because none of its exported identifiers, the compiler may decide never to instantiate the library and thus may never run the set-default-test-runner! call. This is what I mean about the ‘may call set-default-test-runner! upon loading so that end users need not configure it manually’ recommendation being ill advised.
>
> (Note that not all Scheme implementations have REPLs. A SRFI intended to be generally useful to Schemers of all stripes should be designed with a static ahead-of-time compiler in mind, as well as a highly interactive implementation like Guile.)

There is no need to call set-default-test-runner! if the scheme
implementation doesn't support REPL or have hard to predict module
loading behavior.  SRFI just gives a tip that library may do so to
provide some convinince, but it doesn't have to.

As for your example, top-level undelayed test definitions are not
recommended.  It's better to always use define-suite or do
(define name
 (suite-loader ...))

to make sure the forms are not evaluated and no messages are sent to
test runner on module loading.

The overall workflow looks like this:

(with-current-test-runner spiffing-test-runner
  (load-necessary-modules)
  (define suite-loaders (collect-suite-definitions-from-necessary-modules))
  (for-each (lambda (sl) (sl)) suite-loaders)
  ((current-test-runner) `((type . runner/run-tests))))

Of course, it can be (and should be) automated and/or integrated into
IDE/REPL.

>
>> This implemementation looks uglier, but seems to work.
>
> This implementation will fail on static ahead-of-time compilers if
> there *aren’t* local bindings called ‘quote’ and ‘metadata’, because
> it will still insert a free reference to identifiers with those names
> into the expansion. It will be in dead code, but it will still be
> there.
>
> Again, please just use a regular auxiliary syntax keyword and forget
> the ‘quote’. You can’t do what you’re trying to do in syntax-rules,
> because this is not how the syntax of Scheme is intended to work.

I tried to implement (metedata `((my . meta))) syntax and it doesn't
look any better internally.  It suffer from the same syntax-rules
limitations and probably will have the same problems with AOT.

Could you draft a basic skeleton of the macro which recognizes metadata
and non-metadata cases, please?

Also, I would really appreciate if you could provide a sample,
demonstrating a mentioned problem (and corresponding Scheme/environment
info), so I can run it locally and ensure the final implementation won't
suffer from it.

--
Best regards,
Andrew Tropin