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>