A few questions and comments:

-- The SRFI explicitly states that only procedures can be tagged, and
not non-procedure objects. Why?  It is potentially interesting to tag
non-procedure objects. If I put on my s-expression glasses, and forget
that I am working with scheme, this tells me that, given the
expression (a (b c)) I can tag a and b but not c. This feels like an
artificial limitation: a and b have parenthesis that come before them,
but not c. I can work around this with a Hintikka constant, and write
(a (b (c))) instead, but having to Hintikka-ize everything seems
awkward.

As I read through section "6 Implementation" I think I discover the
limitation: it is easy to tag procedures, but hard to tag arbitrary
objects. Is that what this boils down to?

-- The section 5.1 on equivalence states: "Note that in an R7RS
system, all procedures are conceptually tagged with a storage
location" !? What is a "storage location"? Storage where? in RAM? In a
file? in the cloud?

I'm left confused about equivalence.  Suppose I write (define x
(lambda (f g h) (a b c)))   and also much later (define y (lambda (f g
h) (a b c))) then what will I get if I say (eqv? x y)  Is it #f or #t?
If it is #t, this suggests that if I tag x  and then later look at the
tag on y, I will find whatever was placed on x. That implies that
(lambda (f g h) (a b c)) is globally unique for the currently running
scheme instance. Is that correct?  I suspect the answer is
"undefined".

The reason for writing the above paragraph is that, with this srfi, it
is apparently the case that I can never discover the tag, if I have
lost the handle to the procedure. It is hard to tell if this is an
oversight in the SRFI, or if it is an intentional design feature.  So,
for example, say I write

(lambda/tag 42 (f g h) (a b c))

Is there a way to write

(procedure-tag (f g h) (a b c))

and get back 42? For the SRFI as written, the answer seems to be "no",
but I can't tell if this is an oversight, or intentional.  If I look
at section "6 implementation" it seems like it might be possible to
write an alternative implementation that included a
(find-tagged-proceedure formals body) that looped over the
*tagged-procedures* list, fished out matching formals and body, and
then returned the corresponding tag (or tags, if there are more). OK,
yes, you'd need some modifications to the *tagged-procedures* list to
allow this.

In case my questions above sound confusing, and I haven't been
transparent enough: when I look at section 6 implementation, what I
see is a database called *tagged-proceedures* and I can see that
procedure/tag? is a woefully inefficient O(N) database search, and
that make-procedure/tag is a clever setter, allowing the getter
procedure/tag to run in O(1) time. Having O(1) getters is a good thing
for databases.

Because what I see appears to be a database, and I'm just idly
thinking "hey, let's go all the way" -- store the formals, store the
body, store objects in general. Enable lookup by content, rather than
lookup by reference.  But perhaps this is wayyy too far away, and a
distraction, and so half of what I wrote above is kind of irrelevant
to the nuts and bolts of this srfi.

-- linas

On Sun, Nov 7, 2021 at 9:31 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> I've just published draft #2 of SRFI 229. It was submitted by Marc Nieper-Wißkirchen, author of the SRFI.
>
> Marc has asked me to announce last call for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.
>
> In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.
>
> If you're interested in this SRFI, please give your feedback via the SRFI 229 mailing list before 2021-11-15. After that, assuming that no major revisions are required, we will declare it final. It is important that we get your feedback before 2021-11-15. If that deadline is too soon for you, but you would like to contribute, please let me know so that I can extend the last-call period.
>
> Here is the commit summary:
>
> Add more acknowledgements.
> Fix example (reported by Göran Weinholt).
> Add comment about immutability per Linas Vepstas' request.
> Add a few more explanations that have so far been only on the mailing list.
> Publish second draft.
>
> Here's the diff:
>
> https://github.com/scheme-requests-for-implementation/srfi-229/compare/draft-1..draft-2
>
> Regards,
>
>
> SRFI Editor

--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.