Email list hosting service & mailing list manager

Editorial nits; define-record-type John Cowan (02 Sep 2015 20:27 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 12:05 UTC)
Re: Editorial nits; define-record-type John Cowan (03 Sep 2015 13:33 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 15:01 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 15:31 UTC)

Editorial nits; define-record-type John Cowan 02 Sep 2015 20:27 UTC

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.

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.

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

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

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.

--
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.