On 13 Aug 2026, at 08:02, Andrew Tropin <xxxxxx@trop.in> wrote:

> On 2026-07-29 21:16, Daphne Preston-Kendal wrote:
>
>> 1. It is not possible to implement current-test-runner /
>> set-current-test-runner! in portable Scheme
>>
>> In R7RS there is no way to set the value of a parameter object apart
>> from its default value (given at make-parameter time) and local
>> rebinding with parameterize. Either set-current-test-runner! cannot
>> exist, or current-test-runner is not a parameter object.
>>
>> The recommendation ‘Libraries that provide a test runner should call
>> set-current-test-runner! upon loading so that end users need not
>> configure it manually’ which appears to be the raison d’être for
>> set-current-test-runner! is ill advised in any case. Loading a library
>> should not, in general, affect global state in a way that could lead
>> to conflicts depending on the order of library instantiation, because
>> the order of library instantiation is unspecified in Scheme.
>>
>> I would simply delete the set-current-test-runner! procedure.
>
> Hi Daphne!
>
> I think it's still implementable in r7rs:
>
> https://git.sr.ht/~abcdw/guile-ares-rs/commit/bfd84fa09a06f1dc884419e4187284fc2272b0ba

Ah, interesting. This does imply somewhat different semantics than those which the current draft (and indeed the name set-current-test-runner!) seems to prescribe. If you call set-current-test-runner! in a block where current-test-runner is already set by parameterize, the set-current-test-runner! operation will have no effect until the dynamic extent of the parameterize block is left.

That could be fixed by better specification (and ideally changing the name to ‘set-default-test-runner!’).

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.

Using set-current-test-runner! in the recommended way will not work on Chez Scheme, for example. (Vide Zhu Zihao’s proposed erratum to the R6RS, which corrects an example which is broken for the same reason <https://codeberg.org/scheme/r6rs/issues/27>)

> I've considered all those options and re-evaluated them again after your
> message.
>
> 1. At the first glance, 'metadata is implementable in r7rs syntax-rules:
> https://git.sr.ht/~abcdw/guile-ares-rs/tree/4d34ad857a7219476f6ff1bf9282da48d7c06851/item/src/guile/srfi/srfi-269-draft.scm#L112
>
> Not sure how "canonical" guile's syntax-rules is, but I hope it is.

This is either not what is implied by the use of ‘quote’ in the defined syntax, or is wrong. If there is a local binding called ‘metadata’, then this will never match. You are depending on a semantic which is fickle and which really should not exist.

> I consider the visual clarity is more important than general "idiomatic"
> syntax, thus my final ranking of the options:
>
> 1.
> 'metadata
> `((a . ,b))
>
> 2.
> (metadata
> `((a . ,b)))
>
> 3. test-with-metadata/suite-with-metadata
>
> 'metadat is most clean and uncluttered and scales much better with the
> amount of written tests

This argument makes no sense. I appreciate that option 3 is worse from the point of view of future extensibility, but 1 and 2 are barely distinguishable.

> The primary difference between alists and records are open world
> assumption vs closed world.

No, records are also open world as long as you allow inheritance.

There is no inheritance in R7RS small, admittedly, but R6RS has inheritance, R7RS large will almost certainly have it, and every implementation in actual use I’m aware of has it in some form.

The combination of a free ‘metadata’ field and inheritance would be sufficient. You also haven’t answered why metadata has to be an alist, which is probably a sharper point of criticism for me, being an unjustified restriction on users.

Daphne