Hi Zhu,

> 1. 'boolean->integer' may be named 'boolean->bits', to emphasize that it's
> the bit representation of a boolean.

As mentioned in the SRFI itself, BASIC represents true as -1 (minus
one.) So naming the property as “bits” is confusing, as bits kinda imply
unsignedness. “integer” is more generic and accommodates more
implementation choices.

> 2. 'char->integer' may be named 'char-code-point', and specify it to
> return the Unicode code point of a character. However, given that some
> implementations may support characters other than Unicode, this is open
> to debate.

Yes, again, “integer” is a more neutral choice. And, to add to that,
“char->integer” is an existing procedure in R7RS, so having a property
like that is most conventional and reliable.

> 3. 'utf8->string' should specify that it interprets the bytevector under
> the UTF-8 encoding, and also consider adding utf16->string,
> utf32->string properties.

I should probably refer to the standard procedure in this part. I don’t
think that UTF-16 and UTF-32 are good properties, as they have domains
beyond bytevectors—16 and 32 bits instead of 8 bits.

> 4. This SRFI doesn't specify how record inspector properties interact
> with the "opaque" record in R6RS, which is prohibits any level of
> inspection in principle. Perhaps the SRFI should note that "if a record
> is an opaque record, the record properties specified in this SRFI may
> not be available."

I didn’t know of opaque records, thanks for mentioning them! While these
are implicitly covered by the part of “In case the implementation has no
information for a given property, this property should be omitted,” I’ll
amend the document.

Thank you for the comments!

Best of love,
--
Artyom Bologov
https://aartaka.me