Email list hosting service & mailing list manager

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.