Groups | Search | Server Info | Login | Register


Groups > comp.lang.awk > #9775

Re: Operator precedence

From Axel Reichert <mail@axel-reichert.de>
Newsgroups comp.lang.awk
Subject Re: Operator precedence
Date 2024-06-01 09:11 +0200
Organization A noiseless patient Spider
Message-ID <878qzpuoh6.fsf@axel-reichert.de> (permalink)
References (1 earlier) <20240523092856.646@kylheku.com> <87sey8movv.fsf@axel-reichert.de> <v2okuh$1vrvh$1@dont-email.me> <87ikyvk933.fsf@axel-reichert.de> <v3crcn$29n7m$1@dont-email.me>

Show all headers | View raw


Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 30.05.2024 10:17, Axel Reichert wrote:
>> 1. Unary and binary minus, while not identical operators, at least
>> visually are identical. Hence it reduces the cognitive load on the
>> reader of source code, who does not need to remember that unary minus
>> and binary minus are "on opposite sides of the 'exponentiation fence'".
>
> I sort this "argument" (quotes borrowed from your text) into the same
> category as "[old] mathematical convention". IMO it doesn't withstand
> the slightest analysis. To explain I'm going back to "Computer Science
> 101" as taught in the 1980's (and probably even before)...
> You model expressions with Kantorovic trees (using a homonym '-' here)
>   a     b    c
>    \   /     |
>     '-'     '-'
> but what I depicted are different operations, as can obviously be seen.
> Their evaluation in a stack automaton will happen like
>   push(a); push(b); subtract()  and  push(c); negate()  respectively.
> If there wouldn't be a distinction and we had, say, a single 'minus()'
> operation there'd be no indication to reduce that part of expression.

How does the low-level computational model of a stack automaton
invalidate my claim about the reduced cognitive load? When reading
source code (in an supposedly infix language), I certainly think neither
about Kantorovic trees nor about an Forth-like (RPN) evaluation model.

> Deviation from conventions makes sense when appropriate.

Sure. If you can agree with the summary that the disagreement is about
"conventions copied from the domain modelled, in this case maths (awk,
...) versus consistency (Algol, ksh)", than we can end this (very
interesting!) discussion.

By the way, of the latter (consistency), I am a big fan, hence some
programming language's syntax excessions drive me crazy: "Was it
'foo(bar)' or 'bar.foo()' or 'foo bar'?" Which is why I have a weak spot
for Lisps and Forth/Factor. No more earmarks in books with operator
tables.  (-:

> I'm glad that the "Burning Witches" convention has been superseded,
> and that "Newton" got fixed by Relativity and Quantum Mechanics. :-)

I know what you mean, but rest asured that Newton has NEITHER been
wronged NOR superseded in the domain relevant to daily life. I would
have used the wording "extended" rather than "fixed", but can live with
your choice.   (-:

Thanks and best regards!

Axel

Back to comp.lang.awk | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-23 16:13 +0200
  Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-23 16:49 +0000
    Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-23 19:14 +0200
      Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-24 01:53 +0200
        Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-24 04:41 +0200
          Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-24 04:32 +0000
            Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-25 13:34 +0200
              Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-25 23:31 +0200
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-26 00:03 +0200
                Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-25 22:26 +0000
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-30 06:59 +0200
                Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-30 10:24 +0200
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-31 17:08 +0200
                Re: Operator precedence Christian Weisgerber <naddy@mips.inka.de> - 2024-05-26 00:37 +0000
                Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 02:06 +0000
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-30 07:26 +0200
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-30 07:06 +0200
                Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-30 10:22 +0200
                Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-31 17:16 +0200
            Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-25 23:31 +0200
              Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 01:29 +0000
        Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-30 10:17 +0200
          Re: Operator precedence Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-05-31 17:46 +0200
            Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-06-01 09:11 +0200
      Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-24 03:45 +0000
        Re: Operator precedence Axel Reichert <mail@axel-reichert.de> - 2024-05-25 13:09 +0200
          Re: Operator precedence Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-25 22:20 +0000

csiph-web