From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,38fc011071df5a27
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-05-31 12:25:06 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal12.airnews.net!usenet
From: "John R. Strohm" <strohm@airmail.net>
Newsgroups: comp.lang.ada
Subject: Re: Ideas for Ada 200X
Date: Sat, 31 May 2003 14:18:52 -0500
Organization: Airnews.net! at Internet America
Message-ID: <bbavc7$ns8@library1.airnews.net>
References: <6a90b886.0305262344.1d558079@posting.google.com>
 <3ED46E07.4340CABC@0.0> <3ED4F3FD.A0EF7079@alfred-hilscher.de>
 <xIeBa.1017346$3D1.597085@sccrnsc01>
 <bebbba07.0305292326.75f5fbef@posting.google.com> <u4r3co12f.fsf@nasa.gov>
 <bebbba07.0305301649.45b78d8c@posting.google.com> <uvfvrobrb.fsf@wanadoo.fr>
 <bb9vp8$7bkb8$3@ID-77047.news.dfncis.de> <uisrrnxzk.fsf@wanadoo.fr>
 <BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk> <bbai5n$6hm@library1.airnews.net>
 <BAFE9115.2EDC%yaldnifw@blueyonder.co.uk>
Xref: archiver1.google.com comp.lang.ada:38238
Date: 2003-05-31T14:18:52-05:00
List-Id: <comp.lang.ada>

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 14:21:44 -0500 (CDT)
NNTP-Posting-Host: !aga/1k-VNTCkL\ (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BAFE9115.2EDC%yaldnifw@blueyonder.co.uk...
> On 31/5/03 16:31, in article bbai5n$6hm@library1.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> > Bletch.
> > Part of the problem is that you insist on the assignment statement
paradigm.
> > The problem with your proposed "idem" construct is that it creates
> > opportunity for error.
> > Consider: I := idem + 1; vs. I := item + 1; vs. I := idep + 1;
>
> Consider: item := item  + 1;  vs. item := iter + 1;
> Why are your examples any more of a problem?
>
> Anyway, 'idem' is just a placeholder. The alternative syntaxes I suggested
> are not subject to these (rather trivial) errors, so I can't take this
> objection very seriously.
>
> > Now consider the equivalent Oberon:  INC(I);
> > The programmer's intention in Oberon is unmistakable.
>
> Really? FSVO 'unmistakable' perhaps.
> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
> 'unmistakable'?

Empirically, those operations do not happen nearly as often as the canonical
I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca. 1970,
and various follow-on papers in the decades since.

> > FURTHERMORE, under your "idem" proposal, the semantic interpretation of
the
> > RHS is *UNKNOWN* until the LHS is parsed and translated.  Consider:
> > p.all.left.all.right.next.refcnt := idem + 1;
>
> Why is that a disadvantage?

Preference, to a fair extent.  If I have to change

<some_lvalue_expr> := idem op expr;

to

shadow := idem op expr;
<some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device
drivers.

I'd rather not have to worry about the implications of not doing fetch *AND*
store on the device register.  I've gotten burned on this kind of thing
enough times to be wary.