login signup
Some initial comments Daphne Preston-Kendal (04 Apr 2026 10:01 UTC)
Re: Some initial comments Andrew Tropin (07 Apr 2026 11:29 UTC)
Re: Some initial comments Daphne Preston-Kendal (29 Jul 2026 20:17 UTC)
Re: Some initial comments Vincent Manis (he/him) (29 Jul 2026 21:03 UTC)
Re: Some initial comments Wolfgang Corcoran-Mathe (01 Aug 2026 16:16 UTC)
Re: Some initial comments Andrew Tropin (13 Aug 2026 06:12 UTC)
Re: Some initial comments Andrew Tropin (13 Aug 2026 06:03 UTC)
Re: Some initial comments Daphne Preston-Kendal (19 Aug 2026 06:49 UTC)
Re: Some initial comments Andrew Tropin 13 Aug 2026 06:02 UTC

Show/hide attachments 
On 2026-07-29 21:16, Daphne Preston-Kendal wrote:

> Hiya,
>
> As promised, albeit somewhat belated, some further comments – now on the latest draft:
>
> 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

>
> 2. The 'metadata syntax is insensible and also seems not implementable in R7RS small
>
> It is hard to tell at a glance what the intention of the 'metadata
> syntax used in ‘test’ and ‘suite’ is. On inspection, it appears that
> it must be recognized at the syntactic level, not at run time;
> otherwise ‘test’ and ‘suite’ could not have bodies (they could not
> begin with definitions). However the use of ‘quote’ only makes sense
> in an expression context where the quoted datum could be the return
> value of an expression evaluation.
>
> The use of ‘quote’ implies somehow that the keyword ‘metadata’ should
> be matched by its symbolic name, but syntax-rules – the only macro
> system in R7RS small – is not capable of doing this.
>
> No other syntax in Scheme works this way, so it’s hard for me to tell
> what the intention of the spec authors is here in terms of how the
> 'metadata ‘keyword’ is supposed to be recognized by the
> implementation.
>
> The best solution in my view would be to have separate exported names
> for ‘test’ and ‘suite’ with and without metadata, rather than combine
> them into two forms. So there might be, omitting for simplicity the
> case of an empty context:
>
> (test <<description>> (<<context>>) <<body>>)
> (test-with-metadata <<description>> (<<context>>) <<metadata>> <<body>>)
>
> (suite <<description>> <<body>>)
> (suite-with-metadata <<description>> <<metadata>> <<body>>)
>
> [where <<metadata>> is an expression which evaluates to the metadata
> to be used – incidentally, the 'quote issue is likely only the most
> obvious symptom of a thoroughgoing flaw in this SRFI’s spec text,
> which is the failure to distinguish syntactic forms from the values
> they evaluate to as expressions, a vital distinction when new syntax
> is defined. consider adopting the report style of consecutive sections
> on Syntax and Semantics]
>
> Another option would be to export a ‘metadata’ auxiliary syntactic
> keyword, which *can* be matched by binding by syntax-rules. The
> precedent of R6RS define-record-type then says that the syntax should
> be e.g.
>
> (test <<description>> (<<context>>) <<body>>)
> (test <<description>> (<<context>>) (metadata <<metadata expression>>) <<body>>)
>
> or even for the latter
>
> (test <<description>> (context <<context expression>>) (metadata <<metadata expression>>) <<body>>)
>
> where either clause could be optional.

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.

2.  Many libraries are used onece in eternity and should be explicit,
verbose and easy to understand.  However, it's probably not the case for
a test definition syntax.

For each function under test there can be a few tests, a couple of
suites and dozens of assertions. So in big projects the amounts of
testing code is huge.  Which means it should be minimally verbose and
easy to skim.

Also, testing code, its shape, syntax and paradigms will be the same
between modules and projects and consequently well-known (even if the
syntax is slightly quirky/unusual).

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.

>
> 3. Ad hoc alists where records should maybe be used
>
> I am less sure about this one. There can be good reasons to stick to
> using the basic Scheme datum types instead of requiring (imported)
> access to a particular record type, mainly that it is the only way in
> R7RS small Scheme to create a protocol in which different components
> can interact without having to import a common library which defines
> and exports a record type. (R6RS has nongenerative record types for
> this, which is a preferable solution where available.)
>
> But in general, I get icky feelings about alists with specifically
> defined symbolic keys. This is what records are for. (There also seems
> to be no reason to limit the type of user-defined ‘metadata’ to an
> alist, for that matter – why not let users supply any arbitrary object
> as their metadata?)
>
> If you intend test suites and runner implementations to be able to
> interact without actually importing (srfi :269), there is a good
> excuse for using alists. Otherwise, records are type safe unlike
> alists, faster than alists, use less memory than alists, and are
> generally cleaner.
>

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

In our case open world works better. E.g. when test runner load a test
it can add test/id, test/suite-path for implementing scheduling,
fixtures and other functionality.

Those key of course can be put to extra-data field of the record, but I
consider them first class citizens and they should be conviniently
available.

Also, alist make a uniform access to fields and doesn't require to
create and export/rexport tons of getters.

Of course, there are some downsides to alist, but IMHO they fit pretty
well in this case.

>
> I may yet find some more things to complain about ;-), but those are
> the ones that I spotted on a quick skim of this latest
> draft. (Apologies for not flagging those earlier that were there right
> from the start.)
>
>
> Daphne
>

Thank you for the valuable feedback, appreciate it!

--
Best regards,
Andrew Tropin