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.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/