> 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.

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.

-- Peter McGoron