Why plists? John Cowan (17 Aug 2020 16:09 UTC)
Re: Why plists? Marc Nieper-Wißkirchen (17 Aug 2020 19:27 UTC)
Re: Why plists? Marc Nieper-Wißkirchen (17 Aug 2020 20:42 UTC)
Re: Why plists? hga@xxxxxx (17 Aug 2020 19:37 UTC)
Re: Why plists? hga@xxxxxx (17 Aug 2020 21:10 UTC)
Re: Why plists? Marc Nieper-Wißkirchen (18 Aug 2020 05:45 UTC)
Re: Why plists? hga@xxxxxx (18 Aug 2020 09:25 UTC)
Re: Why plists? Marc Nieper-Wißkirchen (18 Aug 2020 09:51 UTC)
Re: Why plists? John Cowan (18 Aug 2020 19:18 UTC)
Re: Why plists? Marc Nieper-Wißkirchen (18 Aug 2020 20:00 UTC)
Re: Why plists? John Cowan (18 Aug 2020 20:16 UTC)

Re: Why plists? Marc Nieper-Wißkirchen 17 Aug 2020 19:27 UTC

Am Mo., 17. Aug. 2020 um 18:10 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

[snipped]

> So if I _must_ make an executive decision (and I hope not to have to) it will be to do plists.  If someone will hack out the implementation of <https://github.com/johnwcowan/r7rs-work/blob/master/PropListAPI.md> we can get it in the SRFI pipeline.

I've done so, I meaning having hacked out an implementation to
contribute to a plist SRFI. (This does not necessarily mean that I
agree to the all [snipped] arguments from Reddit.)

Before a first SRFI draft of your API is written, I have one question:
The procedure you propose mutate the argument (at least in the
"normal" case) so that the same plist can be returned. However, aren't
plists often entered as literal lists, in which case such a mutation
is not allowed?

Besides that, a typical idiom using the API will be (set! plist
(plist-frobnicate! plist ...)). I am wondering whether we should and
can simplify this.

Marc