Hi Zhu,

> In your SRFI-279, you specify that 'inspect-properties' return a
> non-dotted alist which contains all available properties.
>
> However, I wonder whether it will work or not in practice. In your SRFI,
> you also specify many "conversion properties" such as list->vector,
> list->string, etc. Computing these properties will be very expansive --
> an N-length list will require O(n) time to compute its 'list->vector'.
> What's worse, these properties will be computed unconditionally even
> user don't them!

I think that performance is an issue of implementation and not
representation. But I heard you! I now lean towards removing the
conversion procedures except when absolutely necessary (utf8->string,)
because they usually don’t add much to the inspector.

> Therefore, I suggest that (inspect-properties OBJ) return an abstract
> "inspector" object that holds a reference to OBJ for inspection and
> provides the following API:
>
> (inspector-properties INSPECTOR): Return all available properties of
> INSPECTOR.
>
> (inspector-get-property INSPECTOR PROP): Return the value of PROP of
> INSPECTOR.
>
> The key point of this change is that the value of the property
> corresponding to PROP is calculated only when the user calls
> inspector-get-property on their expected property. And user can also use
> inspector-properties to query the available properties (which may be
> used to implement inspect-describe).

This is a good API and the point of on-demand computation (raised by
Peter McGoron too) is a good one still. However, I’m hesitant of going
in this direction. Alists are much easier to manipulate programmatically
and (mostly) preserve read-write invariance, which I consider really
important for SRFI 279 (and in general.) So, unless there’s more
arguments for inspector object, I want to retain the alists in the spec.

In any way, thanks for this email!

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