Hi all,

I'm forwarding this thread to the SRFI 224 mailing list, since I
accidentally sent the original message to a dummy local address.

Unless there are objections, I'm planning to remove the linear
update forms.

----- Forwarded message from Marc Nieper-Wißkirchen <xxxxxx@gmail.com> -----

Date: Thu, 10 Jun 2021 07:27:53 +0200
From: Marc Nieper-Wißkirchen <xxxxxx@gmail.com>
To: Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
Cc: Shiro Kawai <xxxxxx@gmail.com>
Subject: Re: Get rid of linear update!

Has this gone through? I got a reply like: "521 5.1.2 Domain does not
exist: 'hecuba.sigwinch.xyz".

Thanks,

Marc

Am Mi., 9. Juni 2021 um 19:47 Uhr schrieb Marc Nieper-Wißkirchen <
xxxxxx@nieper-wisskirchen.de>:

> Hi Wolfgang,
>
> yes, this sounds like a very compelling solution.
>
> The only thing that may have to be considered are naming conventions with
> respect to future changes of SRFI 113 and SRFI 146 and hypothetical future
> extension of SRFI 224 with linear update procedures.
>
> If we go, for SRFI 113 and SRFI 146, the route Shiro and I have come with,
> the only part of the functional part that may change would be the naming of
> the constructors. This is the only thing that we have to foresee now.
>
> Marc
>
> Am Mi., 9. Juni 2021 um 19:43 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
>> Hi all,
>>
>> A more radical solution to the issues surrounding linear update
>> forms (see thread beginning with [1]), at least with respect to
>> SRFI 224, is to eliminate them.  That is, we don't make this hand-wavy
>> attempt to provide an imperative finite mapping interface (which
>> can be provided by the various hash-table librares, after all), and
>> focus on providing a single, simple functional interface.
>>
>> I believe that there are several advantages to this:
>>
>> (1) Simplicity.  There's no need for implementers to consider the
>> tricky details of mixing side-effecting and "pure" forms.  The
>> semantics of the spec become much, much simpler.
>>
>> (2) Correctness.  As Olin notes, using linear update forms requires
>> great care, and Scheme provides no help in ensuring that they're
>> used correctly.  Getting rid of them means fewer bugs.
>>
>> (3) Performance.  Shiro notes that current SRFIs make it nearly
>> impossible to provide both efficient linear update and efficient
>> functional forms.  Without linear update, there's only one
>> paradigm to worry about, so we can focus our optimization efforts
>> there.  There's no efficiency "balancing act".
>>
>> I don't propose this as a general solution, of course; I'm
>> specifically talking about SRFI 224.
>>
>> Are there any particular arguments against this, aside from
>> that it's contrary to some SRFI precedent?  I find it very appealing
>> in its simplicity.
>>
>> [1] https://srfi-email.schemers.org/srfi-discuss/msg/16764346/
>>
>> --
>> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>>
>> "The usual way in which we plan today for tomorrow is in
>> yesterday's vocabulary." --Edsger W. Dijkstra
>>
>

----- End forwarded message -----

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

"Scientific theories are judged by the coherence they lend to our
natural experience and the simplicity with which they do so.
The grand principle of the heavens balances on the razor's edge
of truth." --Commissioner Pravin Lal (Sid Meier's Alpha Centauri)