Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 08 Jun 2021 17:40 UTC

I'm replying without the CC to srfi-discuss, since this is mostly
SRFI 224-specific.

On 2021-06-08 08:18 +0200, Marc Nieper-Wißkirchen wrote:
> Am Di., 8. Juni 2021 um 00:17 Uhr schrieb Wolfgang Corcoran-Mathe
>
> > I'd also like to get this right, but, if the solution involves
> > revising at least two finalized SRFIs, this will take a while.
> > I'd prefer to make most of the changes Shiro suggested to SRFI 224
> > and finalize it, rather than asking Arthur to wait an indeterminate
> > amount of time.
>
> Can you word the changes in a way so that they only refer to the
> well-defined terms of Scheme's semantics described in the RnRS?

I'd like to do this, if possible.  How can we rephrase Olin's
"live references" in terms consistent with the RnRS?

Contrary to Marc's claim, the phrase "shared structure" appears in
both R7RS and R5RS (e.g. in the 'append' spec), so I think it's
clear to state something like "... the programmer should ensure
that no object shares structure with an imapping passed to as
argument to a linear-update procedure".

> In any case, I am wondering whether anyone would benefit from finalizing
> SRFI 224. When SRFI 113 and SRFI 146 are updated, SRFI 224 would have to
> updated as well (so that it remains in line with the other two SRFIs). So
> the current SRFI 224 spec seems to be preliminary to me.

The current SRFI 224 spec seems consistent with all related SRFIs
to me, and it's just about done in its current form.  Again, if a
number of final SRFIs are going to be revised, this is just one
more.  I don't think it's consistent with the SRFI process to leave
224 in limbo; if I decide that it's fatally flawed, I'll simply
withdraw it.  But since its flaws are shared with a number of
well-known SRFIs, some standardized in R7RS-large, I see no reason
to take drastic action.

> Speaking of the "i"-prefix: Are there any chances to change SRFI 224's
> i-prefix into something different? Both SRFI 116 and SRFI 134 (both being
> part of R7RS-large) use the "i" prefix to denote immutability.

Agreed; this is an issue that I'm concerned about.  SRFI 217
similarly uses the name 'iset' for integer sets, and this SRFI
inherited the prefix.  What name would be preferable?  Some that
come to mind are

* integer-mapping
* int-mapping
* intmap or intmapping

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Everything is vague to a degree you do not realize till you have
tried to make it precise." --Bertrand Russell