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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,10444cff97404845
X-Google-Attributes: gid103376,public
From: lrk@pobox.com (Lance Kibblewhite)
Subject: Re: C like op= proposal
Date: 1999/08/19
Message-ID: 
 <94F5B195547AECE1.B6FE2B3CA516CAD6.3C04D9FA19124F16@lp.airnews.net>#1/1
X-Deja-AN: 514696012
Content-Transfer-Encoding: 7bit
References: <7pefco$v7o$1@nnrp1.deja.com>
 <Pine.SUN.3.91-FP.990818113007.5192A-100000@cap1.capaccess.org>
 <yeck8qsev4d.fsf@king.cts.com> <37BBA5E1.13FBF70E@kvaerner.com>
X-Orig-Message-ID: <37bc10a0.56047201@library.airnews.net>
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Time: Thu Aug 19 09:26:39 1999
Organization: None.
NNTP-Proxy-Relay: library2.airnews.net
Mime-Version: 1.0
Abuse-Reports-To: abuse at airmail.net to report improper postings
Newsgroups: comp.lang.ada
Date: 1999-08-19T00:00:00+00:00
List-Id: <comp.lang.ada>

Tarjei T. Jensen wrote:

>Keith Thompson wrote:
>> I'm well aware that there's little or no chance of this being added to
>> some future version of Ada (which makes this whole thread somewhat
>> off-topic, I suppose).  I'm just saying that I like the idea, and I
>> wouldn't mind seeing it in some future language.
>
>So would I. I don't care much for [+-*/]= as I too think it is ugly.
>However using @ or a functional equivalent seems to be worthwhile. It
>may make some code much more readable than it would otherwise be. I
>don't know if safety critical applications would want to use it, but it
>would be simple to expand the @s before using the source.
>
>So count me in on those who prefer a := @ + 1; over a += 1;

Since we are counting :-), count me out.

There are two issues.

1) Indication of modification of the LHS, as opposed to replacement.

For this, I do prefer the '+=' approach.

2) A shorthand for reducing the possibility of error in duplicating
complex expressions.

For this, consider this situation:

   declare
      Exp1 : <whatever> renames <first complicated expression>
      Exp2 : <whatever> renames <second complicated expression>
   begin
      Exp1 := Exp2 - Exp1 / Exp2 + 1;
   end;

'Renames' is much more versatile. The use of a 'special' notation to
reflect the LHS only seems too specialized.