Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.awk
Subject: Re: Operator precedence
Date: Thu, 30 May 2024 07:26:11 +0200
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <v392lk$1ideb$1@dont-email.me>
References: <v2nium$1pl8f$1@dont-email.me> <20240523092856.646@kylheku.com>
 <87sey8movv.fsf@axel-reichert.de> <v2okuh$1vrvh$1@dont-email.me>
 <v2ouo9$2547f$1@dont-email.me> <20240523210755.307@kylheku.com>
 <87zfsektvi.fsf@axel-reichert.de> <v2tlbf$320cq$1@dont-email.me>
 <v2tn6n$32bqt$1@dont-email.me> <slrnv55129.2osd.naddy@lorvorc.mips.inka.de>
 <20240525185349.904@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 30 May 2024 07:26:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dad9d5c6c1a55d13d3f139bd7c0ae403";
	logging-data="1652171"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DH5dROeEEcP6JfpUeJDqn"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:mTM+O/etbzt1MHcPGfiGD+GzPYg=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <20240525185349.904@kylheku.com>
Bytes: 4233

On 26.05.2024 04:06, Kaz Kylheku wrote:
> On 2024-05-26, Christian Weisgerber <naddy@mips.inka.de> wrote:
>> On 2024-05-25, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> People should be anyway aware of the operator precedences in the
>>> various programming languages since there are obviously yet worse
>>> definitions than the one we've been discussing here.
>>
>> Which is why BSD has had an operator(7) man page about "C operator
>> precedence and order of evaluation" since 1990.
> 
> This discussion has convinced me that unary operators must not be
> clumped together and put into a single precedence level.

That's the way it goes. With proceeding discussion and studies of
yet more literature sources I came exactly to a different result,
and confidence in my (initially not that strong) view.

> For instance, if we have the C-like expression
> 
>   -*p/*q
> 
> it should ideally be
> 
>   -(*p/*q)
> 
> and not as it is now:
> 
>   (-*p)/(*q)
> 
> due the unary minus being clumped with dereference.

I won't comment on the dereferencing operator in C; it's a low
level construct of a low level language that you don't find in
Algol (the language mentioned as reference) or Awk (the language
this NG is dedicated to), nor in 'bc' or spreadsheets, I suppose,
which have also been mentioned.

A note on the upthread also mentioned Ksh (which also shows this
precedence). Earlier versions of Ksh did not support '**' in
arithmetic expressions, it was added later. And (as opposed to
C's misplaced &, |, and ^ operators) they deliberately inserted
it between dyadic and monadic '-', which makes me confident that
they thought well about the appropriate place where to insert it.
(But this is of course just a detail, not a formal reasoning.)

> 
> Unary minus should not be a distinct operator from binary minus.

This is a statement I really find scary.

> Unary minus should denote the elision of an identity element term,
> so that - X not only means the same as 0 - X, but is considered
> to be the same notation, just with the additive identity element not
> show. We could correctly parse it as a binary minus by putting the
> element back in.

But this reasoning is just artificial. Only because we can use
transformations  0-X  or -1*X  for -X  that doesn't mean that a
subtraction is the same as a negation.

We have dedicated syntax trees for monadic and dyadic operations.

> 
> This can make a difference easily. Consider that the unsigned types
> in C have a definition for unary minus. If *p is of type unsigned
> int, and its value is 1, then (-*p) is UINT_MAX. *q is 4 then
> we get UINT_MAX / 4.  Under the proposedd rule, we would get
> something else: 1/4 producing 0, and that negating to 0.

(Again low level C.)

Janis