Assorted comments Peter McGoron (13 Apr 2026 23:51 UTC)
Re: Assorted comments Andrew Tropin (14 Apr 2026 03:21 UTC)
Re: Assorted comments Peter McGoron (20 Apr 2026 22:16 UTC)
Re: Assorted comments Andrew Tropin (21 Apr 2026 09:00 UTC)
Re: Assorted comments Peter McGoron (21 Apr 2026 11:45 UTC)
Re: Assorted comments Andrew Tropin (21 Apr 2026 13:21 UTC)

Re: Assorted comments Andrew Tropin 21 Apr 2026 09:00 UTC
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