On 2026-06-25 08:27, Wolfgang Corcoran-Mathe wrote:

> The SRFI says:
>
>> (suite-loader? obj) → boolean
>>
>> Returns #t if obj is a suite loader produced by 'suite-loader' or
>> define-suite.  Implementations can mark suite loaders with a procedure
>> property or somehow else; ordinary lambdas do not satisfy this
>> predicate.
>
> The latter part is non-portable, since neither R6 nor R7 define
> procedure properties.  Do suite loaders really need to be disjoint from
> other procedures?  I can't see a compelling reason.

Yes, it's needed for "discovery" functionality.  Current implementation
in suitbl loads all the modules ending with `-test` suffix and fetch all
suite-loaders from them.

I was able to make a portable implementation with SRFI-229.

https://git.sr.ht/~abcdw/guile-ares-rs/tree/d549104b/src/guile/srfi/srfi-269-draft.scm#L4

>
> If there *is* a good reason (and there may be--I just woke up), then
> I'd prefer the usual solution: make suite loaders "objects of a
> disjoint type" and provide a simple 'suite-loader-load' procedure.

They should be procedures for UX purpose.

1. While IDE support can be cool and we can provide separate hotkeys for
loading suites and running tests, we want to keep it possible to easily
load them in REPL just by calling the corresponding procedure.

2. When we compose suites, it looks pretty straightforward as it doesn't
require any extra function/wrapper:

(define-suite (my-suite1)
  ...)

(define-suite (my-suite2)
  ...)

(define-suite (super-suite)
  (my-suite1)
  (my-suite2))

Otherwise it would be:

(define-suite (super-suite)
  (suite-loader-load my-suite1)
  (suite-loader-load my-suite2))

More explicit, but more noisy and less readable at the same time.

--
Best regards,
Andrew Tropin