On 2026-09-09 18:04, Andrew Tropin wrote:

> 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.

Hi Daphne.

A gentle ping here.

I think the metadata syntax is the last potential issue that blocks
finalization.

Could you provide a small reproducer exercising it, please?

--
Best regards,
Andrew Tropin