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 08:39: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 10:31:40 -0500
Organization: Airnews.net! at Internet America
Message-ID: <bbai5n$6hm@library1.airnews.net>
References: <6a90b886.0305262344.1d558079@posting.google.com>
 <3ED41344.7090105@spam.com> <3ED46D81.FF62C34F@0.0> <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>
Xref: archiver1.google.com comp.lang.ada:38220
Date: 2003-05-31T10:31:40-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 10:36:23 -0500 (CDT)
NNTP-Posting-Host: !ZEsB1k-XZg.PFo (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:BAFE6FC5.2ECD%yaldnifw@blueyonder.co.uk...
> On 31/5/03 12:42, in article uisrrnxzk.fsf@wanadoo.fr, "Pascal Obry"
> <p.obry@wanadoo.fr> wrote:
> >
> > Right! I must be a bit tired to forget that :) So I think it could be
> > /:= *:= +:= and -:= (operators before the :=).
>
> What about and, or, xor, rem and mod? "mod:=" ? I hope not!
>
> I find this proliferation of special notations revolting.
>
> An "idem" feature, meaning, "the same as the destination" and used thus:
>
> 1.  I := (idem + 1);  -- or perhaps: (<> + 1); or maybe: (all + 1);
>
> 2.  I := (1 - idem);  -- N.B. not possible using any ?:= operator
>
> 3.  X := 0.5*(idem + a/idem);
>
> gives a lot more expressive power than update-in-place operations, but
> allows the latter to be implemented very easily in most cases that
> significant efficiency gains are possible (though not, admittedly,
> arithmetic operations overloaded on matrices and other structures for
which
> conventional, if slightly heavier, procedural notations remain).
>
> The idem notation also documents the programmer's intention more clearly
in
> the cases (such as 3) in which the RHS subexpression is necessarily the
same
> as the LHS, but which do not fit the limitations of a ?:= operation.

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;

Now consider the equivalent Oberon:  INC(I);

The programmer's intention in Oberon is unmistakable.

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;