Some of Guile built-in types allow or require for "name hints" to be
associated with specific object of the class. I understand the intent
of this is to aid debugging.
[...]
PROPOSAL
(0) Drop name hints for variables. Rationale: It is analogous to all
types provided by R4RS Scheme.
(1) Make arbiter and record type name hint OPTIONAL and
discourage/prohibit its use in Guile. Rationale: It is analogous to
all types provided by R4RS Scheme, but optional name hint is provided
for compatibility with Slib.
This is true for RECORD (which follows the proposal for R5RS), but not
arbiters.
(2) Introduce OPTIONAL "name hint" mechanism applicable to ALL Guile
objects. Rationale: Debugging aid. Vectors and closures deserve an
optional name hint no less than record-types or arbiters.
PROPOSAL OF A SPECIFIC MECHANISM IN (2)
Macro: `debug-name OBJECT NAME-HINT'
inserts the NAME-HINT for the OBJECT into the system-wide debugging
hashtable when processed in debugging mode, and expands to nothing
otherwise (default: debugging mode ON).
The debugger shall use global debugging hashtable to access the name
hint (if supplied) instead of acquiring it from within the object
itself.
This is a very interesting idea. Would name-hints be used for other
purposes than the printing of expressions?
The debugging hash table shall not be part of Guile API, but the
`debug-name' macro should be.
PROS
Universal useability of the "name hint" feature for any object.
Consistency of "name hint" feature implementation for all types.
You do mean *all* types, yes? The burden of checking every CONS-pair
may necessitate a very fast access method like perfect hash tables.
Some resource savings when debugging switched off. (Probably
not significant.)
CONS
Change to current specification and implementation of Guile.
When debugging, current slot fetch is replaced by hashtable
lookup when `#<...>' debugging representation of an object is
being constructed. (Probably not significant.)
I'd appreciate comments on my proposal.
Thanks.
-- Petr Adamek