Immutability of the tag?
Linas Vepstas
(07 Sep 2021 01:19 UTC)
|
Re: Immutability of the tag?
Arthur A. Gleckler
(07 Sep 2021 01:31 UTC)
|
Re: Immutability of the tag?
Shiro Kawai
(07 Sep 2021 04:59 UTC)
|
Re: Immutability of the tag?
Marc Nieper-Wißkirchen
(07 Sep 2021 05:48 UTC)
|
Re: Immutability of the tag? Linas Vepstas (08 Sep 2021 01:35 UTC)
|
Re: Immutability of the tag?
Jakub T. Jankiewicz
(07 Sep 2021 06:59 UTC)
|
Re: Immutability of the tag?
Marc Nieper-Wißkirchen
(07 Sep 2021 07:20 UTC)
|
Re: Immutability of the tag? Linas Vepstas 08 Sep 2021 01:35 UTC
Hi, On Tue, Sep 7, 2021 at 12:48 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > > 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). Please don't misunderstand me. I'm asking for the srfi itself to be clarified. As currently written, it seemed vague on this matter, suggesting that perhaps a copy would be made of the mutable data structure, and, since a copy is made, it would be private, inaccessible and therefore immutable. >> Final question: what is this good for? > > 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". This should go into the srfi. Please realize that most readers of the srfi documents are not going to be system programmers, but instead casual users glancing over them, and wondering to themselves "is this useful?" and "what can I use this for?" . Having some small, simple cookbook examples showing *obvious* utility for some task is of paramount importance. There are 229 other srfis. Spending half an hour with each becomes a major task. The eyes of the unacquainted novice glaze over. The problem with the MIT scheme example is that ... well, you now have to figure out what the heck that thing is useful for (very far from obvious), and then work backwards to figure out what srfi-229 is useful form. If the guile/kawa property lists can be emulated with this, then great! But that seems like yet another arcane example. If by "callable records" you mean some kind of object system, that would be interesting. For the things that I do, I find plain-old srfi-9 records snoringly boring, because they are too limited, constrained. Something a bit more towards to OO-side would be more interesting. I've stared at properties in the past, they never seem to solve whatever problem it is I'm having. BTW, properties in guile can be set on any "object", and not just lambdas. I'm not clear on what an "object" is. Seems to be anything that a symbol is pointing at. --linas -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us.