home bbs files messages ]

Just a sample of the Echomail archive

COMPOSVM:

<< oldest | < older | list | newer > | newest >> ]

 Message 263,008 of 264,034 
 =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Simon Clubley 
 Re: extending MySQL on VMS 
 18 Aug 25 15:21:07 
 
From: arne@vajhoej.dk

On 8/18/2025 8:14 AM, Simon Clubley wrote:
> On 2025-08-16, Arne Vajhøj  wrote:
>> On 8/15/2025 6:42 PM, Lawrence D?Oliveiro wrote:
>>> On Fri, 15 Aug 2025 09:55:17 -0400, Arne Vajhøj wrote:
>>>> But I believe most curly bracket languages inherited from C in this
>>>> regard.
>>>
>>> Python took over the C operator hierarchy, with one subtle little
>>> twist. It slightly tweaked the precedence of the bitwise operators
>>> relative to the comparisons, so you don?t need parentheses in
>>> expressions like
>>>
>>>       (C)       («val» & «bitmask») == «testvalue»
>>>       (Python)  «val» & «bitmask» == «testvalue»
>>>
>>> I have asked on comp.lang.c whether any existing C code could be
>>> broken by making the same change in that language. In principle it
>>> could, but nobody could come up with any real-world examples.
>>
>> What about:
>>
>> if(reperr & sys$put(&rab, 0, 0) != RMS$_NORMAL)
>> {
>>       printf("Houston we have a problem\n");
>> }
>>
>
> And it's crap like that which means I tend to ignore operator precedence
> and place all subexpressions in brackets (nested if needed).
>
> It avoids stuff like this and makes it _extremely_ clear in the code
> what the intention is (and makes it easier to read BTW).

There are two separate questions.

Should one use parentheses to specify evaluation explicit
instead of relying on operator precedence?

I do think so. The above is not good code.

I like the Java Coding Convention section 10.5.1:


10.5.1 Parentheses
It is generally a good idea to use parentheses liberally in expressions
involving mixed operators
to avoid operator precedence problems. Even if the operator precedence
seems clear to you, it
might not be to others—you shouldn’t assume that other programmers know
precedence as
well as you do.
if (a == b && c == d) // AVOID!
if ((a == b) && (c == d)) // RIGHT


Is it OK for a language to change operator precedence, because the
change would only make a difference for code not following good
style?

I don't think so.

Changing behavior of existing code is not acceptable. Not even
for bad style code.

I know a few languages has made such changes (changing behavior of
existing code - not specifically changing operator precedence).

But I still don't like it.

Arne

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)

<< oldest | < older | list | newer > | newest >> ]


(c) 1994,  bbs@darkrealms.ca