John Cowan <xxxxxx@mercury.ccil.org> writes:

> 1) Add SRFI 69 hash tables to R6RS hashtables as a supported type.
> The only difference for SRFI 123 purposes is the spelling of the procedure
> names.

From what I can tell, SRFI-69 is obsoleted by the R6RS hashtable API.
There is even an (r6rs hashtables) library for R7RS (which bases itself
on SRFI-69 if that's available) so I see no reason to support SRFI-69
directly in new code and specifications.

The really stubborn people can just use 'register-getter-with-setter!',
but this should probably be discouraged.  After all, R6RS hashtables
make concrete improvements over SRFI-69 (in terms of specification) as
was pointed out by Will Clinger on the scheme-reports-wg2 mailing list.
Given that, and the existence of the portable (r6rs hashtables) library,
I see no reason to support SRFI-69.

Am I wrong?

> 2) I think you should say "it is an error" rather than "an error is raised"
> in the definition of `ref` (in two places).  That allows implementations
> to support SRFI 123 in unsafe mode as well.

Done.

> 3) The first comma in the paragraph marked "Warning:" should be dropped.

Done.

> 4) Change "reference implementation" to "sample implementation".  A reference
> implementation is one used as a specification, which SRFI implementations
> are not.

Done.

> Define-record-type should not be overridden if the R6RS, ERR5RS, or SRFI 99
> implementations of inspection are available, as determined by cond-expand.
> They already have the capability of taking a non-opaque record and determining
> its field names, as well as accessing and mutating fields by their names.
> This should be added to the implementation and to the "Considerations when
> using as a library" section.

Done but needs some testing.  I'll see what R7RS + R6RS-records Scheme
implementations I can use to test this.  Maybe Larceny.

Changes pushed so far (but no pull-request made yet).

Thanks for the feedback!
Taylan