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,1d321b3a6b8bcab2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-25 22:24:54 PST Path: pad-thai.cam.ov.com!bloom-beacon.mit.edu!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!Starbase.NeoSoft.COM!not-for-mail From: smize@Starbase.NeoSoft.COM (Samuel Mize) Newsgroups: comp.lang.ada Subject: Re: "Subtract C, add Ada" Date: 25 Jan 1995 23:07:26 -0600 Organization: NeoSoft Internet Services +1 713 684 5969 Message-ID: <3g7ame$5d8@Starbase.NeoSoft.COM> References: <3fo2ot$su2@miranda.gmrc.gecm.com> <3fode9$dap@soleil.uvsq.fr> NNTP-Posting-Host: starbase.neosoft.com Date: 1995-01-25T23:07:26-06:00 List-Id: The attached discussion of "self-referencing assignments" (I like the term -- is it a standard term?) raises some points for me. Yes, there should be a clearer method for self-referencing assignments. The usual argument (that I've seen) for the C operators +=, *=, etc., is that the code won't have to do the same dereference/index/etc. series twice. This is dumb; this is what the optimizer should do. BUT your point about readability is very true. The action "modify this value somehow" is a common task. Of course, the C operators are prone to typos. Also, you can only do a simple calculation (one multiply, one add...). It seems to me that something more general would be useful, along the lines (NOT THIS SYNTAX, THIS IDEA): foo( bar( zot( element + 1))) := * ( + 3 ); Question for the net: how much were self-referencing assignment operators, and and algebraic ifs (the ?: operator pair) considered for Ada83 and Ada95 (1). Are they discussed in the Rationales, or where would I find discussion of the reason for their omission from Ada? (I'll be looking through the Rationales for this, but if you know where to look it will help me.) Samuel Mize - smize@starbase.neosoft.com (1) YES! THAT'S RIGHT! NINETY-*FIVE*! I GOT THE RIGHT NUMBER THIS TIME, OK? :-) =8-p In article , N. Mellor wrote: >In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes: ... >>... On the other hand what do you think about the operators += *= ... >>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a. >>So don't you think that these construct have their place in Ada. > >This seems a valid point to me, particularly because += >simplifies and clarifies expressions, particularly complex ones. I >don't think there'd be much disagreement over this one, for example: > >foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1; > >foo( bar( zot(element + 1))) += 1; > >The second clearly saves on mistakes and makes the whole line more readable. >To check the first, you need to do a mechanical, lexeme by lexeme comparison >of the two array references to check that they're the same-- not a great score >in the readability stakes. This is a clear example of C shorthand being >superior, in some situations, in some respects, to Ada's straightforwardness. >It isn't the whole story, of course. > >BUT...self-referencing assignments are a very common idiom in just about any >language, and it's only right that we should at least discuss ways of >expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, >I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can >usefully reduce complexity in very busy and convoluted bits of code. > >Of course, there are other good reasons for not having these goodies. >One is that they're not essential, and too many operators can increase the >complexity of the language disastrously. One of the problems with C is its >plethora of operators and the consequent complexity of the operator precedence >rules. Add to that C's blurring of the distinction between statements and >expressions and you have serious readability problems, whether for novices or >experts. > >The bottom line is that it's simple to write an Ada procedure which safely >adds or subtracts its second argument from its first, which can be defined as >an in out parameter: > >procedure self-add(in out var, in expression) is > var := var + expression; >end self-add; > >and use it as in > >self-add( foo( bar( zot( element + 1))) , 1); > > >Any other thoughts? > >Nick Mellor >Leeds