Some initial comments Daphne Preston-Kendal (04 Apr 2026 10:01 UTC)
Re: Some initial comments Andrew Tropin (07 Apr 2026 11:29 UTC)
Re: Some initial comments Daphne Preston-Kendal (29 Jul 2026 20:17 UTC)
Re: Some initial comments Vincent Manis (he/him) (29 Jul 2026 21:03 UTC)
Re: Some initial comments Wolfgang Corcoran-Mathe (01 Aug 2026 16:16 UTC)

Re: Some initial comments Wolfgang Corcoran-Mathe 01 Aug 2026 16:16 UTC

Andrew & Ramin,

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

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.

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.

Regards,

Wolfgang

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>