|
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
Andrew Tropin
(13 Aug 2026 06:12 UTC)
|
|
Re: Some initial comments
Andrew Tropin
(13 Aug 2026 06:03 UTC)
|
|
Re: Some initial comments
Daphne Preston-Kendal
(19 Aug 2026 06:49 UTC)
|
|
Re: Some initial comments
Andrew Tropin
(02 Sep 2026 12:17 UTC)
|
|
Re: Some initial comments
Daphne Preston-Kendal
(07 Sep 2026 08:18 UTC)
|
|
Re: Some initial comments
Andrew Tropin
(09 Sep 2026 11:04 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>