On 2026-08-01 12:16, Wolfgang Corcoran-Mathe wrote:

> Andrew & Ramin,
>
> (I'm using Daphne's comments as a template for my own, but this is
> addressed to you guys.)

Hi Wolfgang,

thanks for the comments!

>
> On 2026-07-29 21:16 +0100, Daphne Preston-Kendal wrote:
>> 1. It is not possible to implement current-test-runner /
>> set-current-test-runner! in portable Scheme
>
> I'm also confused by 'set-current-test-runner!'.  Is the idea to allow
> a test to conditionally change the test runner for other tests?  That
> would be confusing, so I've probably misunderstood.  A rationale
> paragraph would help.

The idea is to make it possible to set a "default" test runner, so all
interactive invocations (in REPL or IDE) of is/test/suite forms change
their behavior accordingly.

>
> Mutable parameter objects seem like a very bad idea in general, since
> they mix two strategies for dynamically changing a name's binding.
> I'm not sure I fully understand their semantic implications, either.
>
>> 2. The 'metadata syntax is insensible and also seems not implementable
>> in R7RS small
>
> Yes, once again, the quote must go.  The (context) vs. () syntax is
> also awkward; I don't think there's any well-known Scheme form that
> uses this syntax for an optional keyword.  Daphne's alternative seems
> good, at least as a starting point for fixing the current form.
>
>> 3. Ad hoc alists where records should maybe be used
>
> After reading the current draft in light of this comment, I believe
> records should work for all of the alist cases in SRFI 269.  The SRFI
> specifies the components of each message and entity type, and that
> makes record types a good implementation for them.  Just having
> standard predicates (the kind you get for free from
> 'define-record-type') for distinguishing between message types would
> make the system much more robust, since an object could easily report
> receiving an invalid message.
>
> An alist or other dictionary type is good when the set of allowed keys
> is so open-ended that any collection of well-known or user-defined keys
> can be used.  This doesn't seem to be the case in SRFI 269.  If you
> want to allow custom data to be included in a message, you could simply
> add a 'user-data' field with unspecified contents.

Answered those two in reply to Daphne.

--
Best regards,
Andrew Tropin