On 2026-04-20 18:15, Peter McGoron wrote:
> > I'm a bit confused about mixing of suite thunks and test thunks
> (run-test-thunk in the context of making suite thunk an alist).
>
> My apologies, I messed that up. I meant to refer to suite thunks throughout.
>
> > The need for suite-thunk? predicate is for discovery of top-level test
> "suites". If we have such predicate, we can find and load
> module's and project's tests relatively easy.
>
> This is very interesting, I did not know Guile had the ability to
> introspect modules like this.
>
> My concern is that the requirement to have procedure properties will
> reduce the uptake of this SRFI on systems where they are not
> implemented. This is especially important for a test suite, as it will
> run on many implementations.
>
> As far as I can tell, `suite-thunk?` is the only strictly non-portable
> part of this SRFI. So I think the SRFI should be modified to allow for a
> portable implementation.
SRFI-229 and SRFI-259 are implementing procedure tags, which are very
similiar to procedure properties. I will mention them in next SRFI
revision.
Also, you don't have to implement it via procedure properties/tags, you
can make suite-thunk create a thunk, register it in some common global
registry and return the thunk. This way (suite-thunk? ...) will use
this registry to determine if arbitrary lambda is suite-thunk or not.
This only problematic in terms of gc, as those suites won't be gced.
But for dev and test envs it should be fine.
>
> My idea:
>
> A suite thunk is *allowed* to be a procedure. It may be implemented as
> some other type. If it is a procedure, then it may be invoked with no
> arguments to run the suite. Otherwise the portable `run-suite-thunk` can
> be used to execute the suite thunk.
>
> This would allow the Guile implementation to discover thunks through the
> module system as it does currently. One could continue to use the API as
> described by the current draft if they don't care about systems without
> procedure properties. The new API (`run-suite-thunk`) can be used on
> Scheme implementations without procedure properties.
We can relax the spec a bit to allow so, not sure we really need it.
I guess 3 options above cover it. Do they?
--
Best regards,
Andrew Tropin