From Newsgroup: comp.lang.ada

John J Herro wrote in 1996: #--------------------------------------------------------------------------# #"dewar@merv.cs.nyu.edu (Robert Dewar) writes: #

Ask an Ada expert what is the value of #
-5 mod 3 # Almost anyone [gets it wrong] ... the default # parenthesiztion of this expression is -(5 mod 3). #

# # #This brings us to a coding style rule that I wish everyone would follow. # #Use parentheses unless the order of evaluaton is VERY OBVIOUS. A person # #reading your code should _never_ have to go to the RM to look up the # #precedence of operators, and certainly you should never refer to that # #section when writing code; use parentheses instead. #
# # #I'm not saying that the code #
# #
# if X**2 + 3.0*X + 2.0 < 100.0 then ... #
# # #should be cluttered with unnecessary parentheses. Everyone knows that # #"**" comes before "*" and "/", which come before binary "+" and "-", and # #everyone knows that the relational operators have a low precedence. It's # #also arguable that "everyone" knows that "and" comes before "or". But I'd# #say in almost every other case, unless the order of evaluation is very # #obvious, use parentheses! #
# # #Even Ada has some pitfalls. If everyone followed this rule, one of them # #would be no problem. #
# #
#- John Herro # #Software Innovations Technology # #http://members.aol.com/AdaTutor # #ftp://members.aol.com/AdaTutor" # #--------------------------------------------------------------------------#

Matthew Heaney wrote in 1996: |---------------------------------------------------------------------------| |"In article <54snn6$8j5@newsbf02.news.aol.com>, johnherro@aol.com (John | |Herro) wrote: |
| | |>It's also arguable that "everyone" knows that "and" comes before "or". |
| | |Are you sure? My understanding is that "and" and "or" have equal | |precedence, and that Ada *requires* the use of parens to force to | |programmer to state his intent. |
| | |The Ada 83 explains that because we've all been taught algebraic logic | |since we were young whipper-snappers, the precedence of "+" and "*" is | |well-kwown. But because we haven't all been taught relational logic that | |long, there's some potential ambiguity. So Ada eliminates it once and for | |all by forcing the use parens. |
| | |The thing I'd like to add, however, is to admonish programmers to not to | |write complicated predicates! If you're writing a predicate that requires | |the use of "a lot of" parens, then try to re-think your solution. As has | |been noted in this group before, one of the largest sources of errors | |(perhaps _the_ largest) is predicates, especially getting loop termination | |correct. |
| | |Please, please, if you need to leave a loop early, then use "exit when..." | |or return. I've often seen code (even in software engineering texts that | |use Ada examples) that sets a loop flag to false, that in turn gets tested | |at the top of the (while) loop. This is clearly a misuse of the language | |and a violation of all the principles of programming as a _human_ activity,| |as you've just doubled the number of states you have to test! |
| | |-------------------------------------------------------------------- | |Matthew Heaney | |Software Development Consultant | |mheaney@ni.net | |(818) 985-1271" | |---------------------------------------------------------------------------|

Use parentheses!

A publication by the Association of C & C++ Users reveals that survey answerers at a conference of the Association of C & C++ Users have not
known that multiplication or dvision takes precedence over binary addition
or subtraction! Old persons can forget things which they had been taught
when they used to be young whipper-snappers.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Wed, 7 Jan 2026 13:01:53 +0100, Nioclás Pól Caileán de Ghloucester
wrote:

John J Herro wrote in 1996:

#This brings us to a coding style rule that I wish everyone would
#follow. Use parentheses unless the order of evaluaton is VERY
#OBVIOUS. A person reading your code should _never_ have to go to
#the RM to look up the precedence of operators, and certainly you
#should never refer to that # section when writing code; use
#parentheses instead.

I wonder why we bother to have operator precedence rules, then? Give
all operators the same precedence, and make the grouping parentheses
mandatory.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

#This brings us to a coding style rule that I wish everyone would
#follow. Use parentheses unless the order of evaluaton is VERY
#OBVIOUS. A person reading your code should _never_ have to go to
#the RM to look up the precedence of operators, and certainly you
#should never refer to that # section when writing code; use
#parentheses instead.

I wonder why we bother to have operator precedence rules, then? Give
all operators the same precedence, and make the grouping parentheses >mandatory.

+1

After bugs this is now a Linux kernel rule. Took Linux longer than it should
to specify best practice though.
--
Regards, Kc
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Sat, 10 Jan 2026 10:07:26 -0000 (UTC), Kevin Chadwick wrote:

On Wed, 7 Jan 2026 20:27:12 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Wed, 7 Jan 2026 13:01:53 +0100, Nioclás Pól Caileán de
Ghloucester wrote:

John J Herro wrote in 1996:

#This brings us to a coding style rule that I wish everyone would
#follow. Use parentheses unless the order of evaluaton is VERY
#OBVIOUS. A person reading your code should _never_ have to go to
#the RM to look up the precedence of operators, and certainly you
#should never refer to that # section when writing code; use
#parentheses instead.

I wonder why we bother to have operator precedence rules, then?
Give all operators the same precedence, and make the grouping
parentheses mandatory.

+1

In which case, why bother with infix operators at all? Why not
construct all your expressions out of function calls, à la Lisp?

So instead of

2 + (3 × 5)

or

(2 + 3) × 5

you could have

(+ 2 (× 3 5))

or

(× (+ 2 3) 5)

respectively. Bye-bye precedence issues!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

In article <10juemk$3eijl$6@dont-email.me>,
Lawrence D�Oliveiro <ldo@nz.invalid> wrote:

So instead of
2 + (3 × 5)
or
(2 + 3) × 5

you could have
(+ 2 (× 3 5))
or
(× (+ 2 3) 5)

respectively. Bye-bye precedence issues!

Brings back fond memories of the HP calculators with RPN (Reverse Polish Notation)...

https://www.hpmuseum.org/rpn.htm
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Sun, 11 Jan 2026 18:29:13 -0000 (UTC), Dirk Craeynest wrote:

On Wed, 7 Jan 2026 20:27:12 -0000 (UTC), Lawrence D’Oliveiro wrote:

So instead of

2 + (3 × 5)

or

(2 + 3) × 5

you could have

(+ 2 (× 3 5))

or

(× (+ 2 3) 5)

respectively. Bye-bye precedence issues!

Brings back fond memories of the HP calculators with RPN ...

What I posted is “PN” -- “RPN” without the “R”.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On Sun, 11 Jan 2026 18:29:13 -0000 (UTC), Dirk Craeynest wrote:

Brings back fond memories of the HP calculators with RPN ...

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

What I posted is 'PN' -- 'RPN' without the 'R'.

Sure. Nevertheless, your post brought back those memories... ;-)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 11 Jan 2026, Dirk Craeynest wrote
(in article <10k0q5p$3oia$1@dont-email.me>):

Brings back fond memories of the HP calculators with RPN (Reverse Polish Notation)...

A computer that used an RPN instruction set was the English Electric KDF9.

You can see snippets of KDF9 assembler here: <http://www.findlayw.plus.com/KDF9/#PSK>

That code was generated by a 21st century KDF9 Pascal cross-compiler
called paskal, and can be executed by a KDF9 emulator called ee9.

Both paskal and ee9 are written in ... Ada 2012.

You can find them here: <http://www.findlayw.plus.com/KDF9/emulation/emulator.html#Download>
--
Bill Findlay


--- Synchronet 3.21a-Linux NewsLink 1.2