I have to admit that it is true that also "we" make mistakes when it
comes to the linear-update procedures. The test code of SRFI 113 assumes
that linear-update procedures modify their argument, see e.g. here:
https://github.com/scheme-requests-for-implementation/srfi-113/blob/master/sets/sets-test.scm#L153.
Some volunteer should correct the test cases (or take the SRFI 113 tests
from SRFI 146, where I had to fix it because the linear-update
procedures from the SRFI 146 sample implementation do not change their
argument).

I would like to suggest to take the following steps to make the Scheme
world a bit safer again:

1) The definition of linear update procedures in SRFI 146 should be
stricter by adding the following error conditions explicitly: "It is an
error to reference a (mapping) parameter after a linear-update procedure
has been invoked. It is an error not to reference the result of invoking
a linear-update procedure in its continuation."

2) The same will be applied to SRFI 1 and SRFI 113 (and possibly other
SRFISs).

3) A future SRFI add a new Scheme values, <undefined>, which may be
stored in a location. It is an error to reference a location holding
this value. Using this, the first error condition for linear-update
procedures can be implemented. Also, a future SRFI adds a way to flag a
location. The flag is reset when the location is read. It is an error if
a location is garbage-collected when the flag is still set. Using this,
the second error condition for linear-update procedures can be implemented.

4) A Scheme-compiler could use 3) and code analysis to statically check
at compile-time whether a inear-update procedure is invoked correctly.

5) Someone should think of a type-extension to Scheme that has at least
the power of Rust's type system (including linear and affine types).

Marc

P.S.: Of course, I can only implement 1) when it comes to the current SRFI.

Am 22.05.2017 um 19:58 schrieb Per Bothner:
> On 05/22/2017 07:30 AM, John Cowan wrote:
>>
>> On Mon, May 22, 2017 at 4:59 AM, Alex Shinn <xxxxxx@gmail.com
>> <mailto:xxxxxx@gmail.com>> wrote:
>>
>>     The only cause for confusion seems to be with the use of ! for
>> naming, and the fact that many conventional languages perform similar
>> operations as in-place mutations.
>>
>>
>> I think that blurring the line between "must mutate" and "may mutate"
>> was actually a !!! move by Olin in the game of standards chess.  By
>> looking at the return type, unspecified vs. specified, we always know
>> which kind of procedure we are dealing with, and the ! just gives a
>> general warning: "beware the mutant lurking in the underbrush".
>>
>> So I'm for keeping linear-update exactly as is, ! and all.
>
> There are certain ideas in programming-language design that are
> unquestionable powerful and elegant, but whose benefit may be outweighed
> by their propensity for errors.
>
> One is local variables being able to shadow other local variables.
> Even Olin Shivers create a bug because of this, that was uncaught for
> 16 years:
> http://srfi-email.schemers.org/srfi-1/msg/5710983
> This misfeature is too late to fix for Scheme [*], but Java got it right.
>
> (A classic mis-feature common to newbie language designers is not
> distinguishing
> definition and assignment.)
>
> I believe linear update is potentially in the same category:
> * It's a useful feature, but very prone to accidental bugs.
> * It is easy to misunderstand by non-experts.
> * Bugs are very hard to catch and easy to overlook, at least without
> compiler support.
>
> On 05/22/2017 07:30 AM, John Cowan wrote:
>> I think that blurring the line between "must mutate" and "may mutate"
>> was actually a !!! move by Olin in the game of standards chess.
>
> Not disagreeing - but it is very dangerous, so it needs a more
> descriptive name.
>
>> By looking at the return type, unspecified vs. specified, we always
>> know which kind of procedure we are dealing with,
>
> "We" do, but we're not typical programmers - and even "we" forget or
> make mistakes.
> "Normal" programmers do not read specifications or understand
> documentation nuances.
>
> [*] Thought Kawa has a new match operator"
>   (! PATTERN EXPERSSION)
> This extends define to patterns, but any identifiers introduced by
> PATTERN
> cannot shadow another variable of the same name.