Hi, Linas,

thanks for the feedback.

Am Di., 7. Sept. 2021 um 03:19 Uhr schrieb Linas Vepstas <xxxxxx@gmail.com>:

As I read through this, the examples seem to suggest that the tag is immutable, but this is not clear.

As SRFI 229 does not offer any procedures or syntax to "set!" the tag, so its binding is immutable as far as SRFI 229 goes.
 
What I have in mind is that a tag might be a hash table, and that I would want to add/remove entries over time. Perhaps a dictionary (such as srfi-225) ... could a tag be a srfi-225 dictionary?

Yes, your tag can be a hash table or some other mutable data structure.  You won't be able to rebind the hash table tag, but you can change the entries of the hash table (which amounts to changing some locations in the store).
 
Another question: why lambda/tag and not define/tag ? I guess I can emulate define/tag with lambda/tag ... but also, the other way around!?

define/tag would just be syntactic sugar of lambda/tag, and it is not clear to me whether it would really show up often in real code.  Some future SRFI can deal with such syntactic sugar.

In Scheme, procedures are first-class objects and don't need a special form of define, so I always consider the lambda form the more primitive than the define form.
 
Final question: what is this good for? Rationale mentions MIT/GNU application hook, but it is not clear what application hooks are good for, at least, not without an example. I guess its supposed to be kind-of-like a C callback. But without examples, I find it hard to stretch my mind in that direction.

The SRFI does not want to promote application hooks, so there is no example on application hooks.  Instead, that application hooks (which are at least interesting to MIT/GNU Scheme) can be implemented in terms of SRFI 229, is a demonstration for the capabilities of SRFI 229.

Other examples are the implementation of property lists (see the other threads), the implementation of procedure identity for R6RS systems (see the SRFI text), and, for example, the implementation of callable "records".

Marc