Hello Peter,

> 1. It might be good to have (inspect-property object property-name) so
> that one can access a specific property without having to compute
> things like the representation. This is nice for things like procedure
> introspection, where there isn't a way to access that information
> otherwise.

This might be a good API indeed! One of the lost drafts of this SRFI
actually included a requirement that all the properties should have a
matching exported accessor procedure, but I forgot to include it in this
version. inspect-property sounds better! Though it certainly might
complicate the implementation. Oh well.

One potential problem with it though: properties are supposed to be
implementation-specific and the properties listed in the SRFI are merely
suggestions. So maybe relying on property names instead of general
inspect-properties return value is too non-portable. Not sure if that
should be formalized in any way.

> 2. Type information vs object information. Many of the property lists
> (but the numbers one in particular) emit information about the type of
> the object and not really the object itself. Stuff like the
> smallest/largest representable value should really be in the
> properties of the *type* of the object, not really the object itself.

Yes, right. I’m hesitant to include them into type properties
though—types are not portable, while values of these types are. That’s
why I include type-specific information into properties of its
instances.

> 3. How does 0..n work for circular lists?

Oh, it is under-specified indeed! I’m thinking of including this
phrasing:

“In case the list is circular, only the elements that precede the
circular tail are included.”

> 4. Symbols are not exported from libraries, identifiers are. Symbols
> wouldn't carry this type of information: (inspect-properties 'car)
> would have no way of knowing that that "car" is from (scheme base) as
> opposed to any other object.

Right, this is my Common Lisp background exposed—in CL, symbols have
packages, and packages are bags of symbols with values bound to
them. I’ll remove that part.

Thank you for this feedback, I really appreciate that!

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