On 2026-06-13 21:43, Wolfgang Corcoran-Mathe wrote:

> Hello Andrew & Ramin,
>
> Thanks for your work on this SRFI.  I like the idea of separating test
> description and execution very much.  It may be a battle to get
> Schemers to use anything other than SRFI 64 (and the like), but I hope
> SRFI 269 will succeed.

Hi Wolfgang!

Sorry for delayed reply, the message ended up flagged as spam for some
reason, so I only found it via web interface.

>
> A few questions & comments:
>
> 1. Why is the parameter called 'test-runner*' and not 'test-runner'?

No particular reason, it's just a naming convention in guile-ares-rs
project (where reference implementation of the suitbl testing library is
developed) to make dynamically scoped variables stand out.  I derived it
from clojure's style of `*dynamic-var*`, but without prefix asterisk.  I
know it conflicts with let* and alike.  Also, somebody already mentioned
and suggest current-test-runner.

I have no preference here for SRFI.  Any sensible option would work fine
for me.  If you have preference/reasoning, please suggest.

>
> 2. There is currently no assertion support for multiple values.  The
> "general" form of 'is' is thus not general enough, and the "predicate"
> form conflicts badly with multiple-value syntax ('let-values',
> 'call-with-values', etc.).  I'll have to study the protocol in greater
> depth to come up with a suggestion of how to solve this, but it really
> must be solved: multiple values are common in Scheme.  In several
> places the SRFI also refers to "the value" returned by a user-provided
> expression (which may return zero or more values).  In those places,
> read "values".

Yeah, I'm not even sure if I thought about it.  Thanks for bringing it
up!

I gave it a brief thought and it still seems general enough (I will
address issue with predicate form replying to the #3).  The design of
SRFI-269 is heavily relies on shifting as much as possible to test
runner and focusing only on definition semantics, not execusion.  So,
it's the responsibility of test runner to decide what asserting means.

As for test runner in suitbl, we just inherit semantics of `if`.  For
Guile it's following (I just checked it a few minutes ago): If
there are 0 values, it's exception, if more than zero the first value is
checked for truethness.

If you have in mind something else for the multiple-value use case for
assertion macro, please let me know :)

>
> 3. Setting the multiple-value issue aside for the moment, I'd add that
> 'is' should not analyze the test expression.  One of my favorite of
> Herman & Van Horn's macro-design principles[1] is "treat subterms as
> atomic".  At the moment, the "general" and "predicate" forms of 'is'
> overlap, with potentially surprising results.  (You can't tell, in
> general, whether the first identifier of a Scheme expression denotes a
> procedure or something else.)  If you want to capture the operator of a
> procedure application, make it an additional macro argument.

You are very right!  It was bothering me from the very first days of the
development.  After that I faced a few issues while using the library, I
also documented one of them with doc test:

https://git.sr.ht/~abcdw/guile-ares-rs/tree/d549104b/tests/guile/ares/suitbl/definitions-test.scm#L231

Thanks for noticing it and bringing it up.  I guess we need to sacrifice
the fancy reporting of evaled predicate arguments for the sake of
reliability and simplicity.

Let's keep only general form?

>
> In short, the form of assertions needs work.
>
> That's what I have at the moment.  I'll keep studying the SRFI.

My great pleasure to read your thoughtful feedback!  Please share more
ideas, when you get them.  The plan is to finalize SRFI by the end of
June, so we have a bit of time to introduce changes.

--
Best regards,
Andrew Tropin