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.
