Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162618 > unrolled thread

C precedence - relative comparisons before equality operators

Back to article view | Back to comp.lang.c

Contents

  C precedence - relative comparisons before equality operators James Harris <james.harris.1@gmail.com> - 2021-09-05 18:49 +0100
    Re: C precedence - relative comparisons before equality operators Siri Cruise <chine.bleu@yahoo.com> - 2021-09-05 13:11 -0700
    Re: C precedence - relative comparisons before equality operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-05 21:12 +0100
      Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 09:09 +0200
    Re: C precedence - relative comparisons before equality operators gazelle@shell.xmission.com (Kenny McCormack) - 2021-09-05 20:19 +0000
      Re: C precedence - relative comparisons before equality operators Richard Damon <Richard@Damon-Family.org> - 2021-09-05 17:52 -0400
        Re: C precedence - relative comparisons before equality operators Bart <bc@freeuk.com> - 2021-09-06 00:09 +0100
          Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 09:15 +0200
            Re: C precedence - relative comparisons before equality operators Bart <bc@freeuk.com> - 2021-09-06 11:10 +0100
              Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 13:01 +0200
                Re: C precedence - relative comparisons before equality operators Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-09-06 04:20 -0700
      Re: C precedence - relative comparisons before equality operators John Bode <jfbode1029@gmail.com> - 2021-09-07 09:27 -0500
        Re: C precedence - relative comparisons before equality operators Bart <bc@freeuk.com> - 2021-09-08 00:20 +0100
          Re: C precedence - relative comparisons before equality operators John Bode <jfbode1029@gmail.com> - 2021-09-08 14:18 -0500
    Re: C precedence - relative comparisons before equality operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 02:01 +0100
      Re: C precedence - relative comparisons before equality operators James Harris <james.harris.1@gmail.com> - 2021-09-06 09:39 +0100
        Re: C precedence - relative comparisons before equality operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 10:46 +0100
          Re: C precedence - relative comparisons before equality operators Richard Damon <Richard@Damon-Family.org> - 2021-09-06 10:09 -0400
            Re: C precedence - relative comparisons before equality operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 16:05 +0100
    Re: C precedence - relative comparisons before equality operators James Harris <james.harris.1@gmail.com> - 2021-09-06 09:27 +0100
      Re: C precedence - relative comparisons before equality operators James Harris <james.harris.1@gmail.com> - 2021-09-06 12:18 +0100
        Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 13:44 +0200
          Re: C precedence - relative comparisons before equality operators James Harris <james.harris.1@gmail.com> - 2021-09-06 13:38 +0100
            Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 18:12 +0200
          Re: C precedence - relative comparisons before equality operators tth <tth@none.invalid> - 2021-09-06 18:20 +0200
            Re: C precedence - relative comparisons before equality operators David Brown <david.brown@hesbynett.no> - 2021-09-06 23:40 +0200
        Re: C precedence - relative comparisons before equality operators Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-06 17:20 -0700
      Re: C precedence - relative comparisons before equality operators Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-06 13:44 +0100
      Re: C precedence - relative comparisons before equality operators Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-06 17:23 -0700
    Re: C precedence - relative comparisons before equality operators James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-09-06 23:07 -0400

Page 1 of 2  [1] 2  Next page →

#162618 — C precedence - relative comparisons before equality operators

According to

   https://en.cppreference.com/w/c/language/operator_precedence

and other references C applies relative comparisons (<, <=, >=, >) 
before equality comparisons (==, !=) rather than giving them all the 
same priority.

Anyone know why the precedences were designed that way?

Are there certain idioms in which that arrangement is useful?


-- 
James Harris

[toc] | [next] | [standalone]

#162621

In article <sh2vvh$oir$1@dont-email.me>,
 James Harris <james.harris.1@gmail.com> wrote:

> According to
> 
>    https://en.cppreference.com/w/c/language/operator_precedence
> 
> and other references C applies relative comparisons (<, <=, >=, >) 
> before equality comparisons (==, !=) rather than giving them all the 
> same priority.

== serves as scalar equality and logical equivalence.

Parentheses are easy to type.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#162622

James Harris <james.harris.1@gmail.com> writes:

> According to
>
>   https://en.cppreference.com/w/c/language/operator_precedence
>
> and other references C applies relative comparisons (<, <=, >=, >)
> before equality comparisons (==, !=) rather than giving them all the
> same priority.
>
> Anyone know why the precedences were designed that way?
>
> Are there certain idioms in which that arrangement is useful?

I'm curious now too.  I don't know of any, but then I've not see a
particularly large quantity of C code.

There is one that uses arithmetic between comparisons to get a -1, 0, +1
result where such a thing is required:

  (a >= b) - (b >= a)

but that, of course, /needs/ the parentheses.

As to why it's like this, I suspect that DMR just liked lots of
precedence levels to avoid ()s in as many cases as possible.  If you do
decide to separate the groups, one has to be higher than the other and,
though not common or idiomatic, equality and non-equality of comparisons
seem to make more sense than comparisons of equality and non-equality.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#162628

On 05/09/2021 22:12, Ben Bacarisse wrote:
> James Harris <james.harris.1@gmail.com> writes:
> 
>> According to
>>
>>   https://en.cppreference.com/w/c/language/operator_precedence
>>
>> and other references C applies relative comparisons (<, <=, >=, >)
>> before equality comparisons (==, !=) rather than giving them all the
>> same priority.
>>
>> Anyone know why the precedences were designed that way?
>>
>> Are there certain idioms in which that arrangement is useful?
> 
> I'm curious now too.  I don't know of any, but then I've not see a
> particularly large quantity of C code.
> 
> There is one that uses arithmetic between comparisons to get a -1, 0, +1
> result where such a thing is required:
> 
>   (a >= b) - (b >= a)
> 
> but that, of course, /needs/ the parentheses.
> 
> As to why it's like this, I suspect that DMR just liked lots of
> precedence levels to avoid ()s in as many cases as possible.  If you do
> decide to separate the groups, one has to be higher than the other and,
> though not common or idiomatic, equality and non-equality of comparisons
> seem to make more sense than comparisons of equality and non-equality.
> 

The relational operators and equality operators can be applied to
different things (there are more possibilities for equality comparison).
 I guess that meant it made sense to consider them as separate operator
groups.  And since each group has to fit at a different spot in the list
of precedences, it was either relational operators before equality
operators, or vice versa.

[toc] | [prev] | [next] | [standalone]

#162623

In article <sh2vvh$oir$1@dont-email.me>,
James Harris  <james.harris.1@gmail.com> wrote:
>According to
>
>   https://en.cppreference.com/w/c/language/operator_precedence
>
>and other references C applies relative comparisons (<, <=, >=, >) 
>before equality comparisons (==, !=) rather than giving them all the 
>same priority.
>
>Anyone know why the precedences were designed that way?
>
>Are there certain idioms in which that arrangement is useful?

I think it makes sense.  If I see:

    if (a < b == c < d)

I would expect it to mean:

    if ((a < b) == (c < d))

That's got to be more useful than:

    if ((a < (b == c)) < d)

-- 
You know politics has really been turned upside down when you have someone in the
government with a last name of Cheney (Liz, Senator from Wyoming) who is the voice of
reason.

[toc] | [prev] | [next] | [standalone]

#162624

On 9/5/21 4:19 PM, Kenny McCormack wrote:
> In article <sh2vvh$oir$1@dont-email.me>,
> James Harris  <james.harris.1@gmail.com> wrote:
>> According to
>>
>>   https://en.cppreference.com/w/c/language/operator_precedence
>>
>> and other references C applies relative comparisons (<, <=, >=, >) 
>> before equality comparisons (==, !=) rather than giving them all the 
>> same priority.
>>
>> Anyone know why the precedences were designed that way?
>>
>> Are there certain idioms in which that arrangement is useful?
> 
> I think it makes sense.  If I see:
> 
>     if (a < b == c < d)
> 
> I would expect it to mean:
> 
>     if ((a < b) == (c < d))
> 
> That's got to be more useful than:
> 
>     if ((a < (b == c)) < d)
> 

I think that is probably about as good of an arguement as any will find.

Since the grammer doesn't easily support what some later langagues did
to make a < b < c to mean (a < b) && (b < c) which can be handy being
able to say something like a < b == b < c at least lets you test if 3
numbers are in sequence without parenthesis.

Also, it puts less operators at any give level of the grammer which
might be useful. You end up with more levels of grammer, but each one is
simpler.

[toc] | [prev] | [next] | [standalone]

#162626

On 05/09/2021 22:52, Richard Damon wrote:
> On 9/5/21 4:19 PM, Kenny McCormack wrote:
>> In article <sh2vvh$oir$1@dont-email.me>,
>> James Harris  <james.harris.1@gmail.com> wrote:
>>> According to
>>>
>>>    https://en.cppreference.com/w/c/language/operator_precedence
>>>
>>> and other references C applies relative comparisons (<, <=, >=, >)
>>> before equality comparisons (==, !=) rather than giving them all the
>>> same priority.
>>>
>>> Anyone know why the precedences were designed that way?
>>>
>>> Are there certain idioms in which that arrangement is useful?
>>
>> I think it makes sense.  If I see:
>>
>>      if (a < b == c < d)
>>
>> I would expect it to mean:
>>
>>      if ((a < b) == (c < d))
>>
>> That's got to be more useful than:
>>
>>      if ((a < (b == c)) < d)
>>
> 
> I think that is probably about as good of an arguement as any will find.

I think given some of the other crazy decisions, it's probably 
accidental if this particular one has any benefit.

> 
> Since the grammer doesn't easily support what some later langagues did
> to make a < b < c to mean (a < b) && (b < c) which can be handy being
> able to say something like a < b == b < c at least lets you test if 3
> numbers are in sequence without parenthesis.

In sequence maybe, but it doesn't distinguish between ascending or 
descending as a < b < c would do in properly chained comparisons.

I think the OP is thinking of implementing chained comparisons, and may 
be gauging what would be lost if moving away from the C model.

Personally I wouldn't care about that; Python has chained comparisons so 
it doesn't care about compatibility with C expressions either.

(I have them too, but I can emulate whatever C does by adding parentheses.)



> Also, it puts less operators at any give level of the grammer which
> might be useful. You end up with more levels of grammer, but each one is
> simpler.

I dispute it's that useful; but it is certainly harder to remember all 
the different levels. You can also can't assume that everyone will know 
them as well as you.

[toc] | [prev] | [next] | [standalone]

#162629

On 06/09/2021 01:09, Bart wrote:
> On 05/09/2021 22:52, Richard Damon wrote:
> 
>> Also, it puts less operators at any give level of the grammer which
>> might be useful. You end up with more levels of grammer, but each one is
>> simpler.

I think that is a very likely reason.

> 
> I dispute it's that useful; but it is certainly harder to remember all
> the different levels. You can also can't assume that everyone will know
> them as well as you.

You don't need to remember all the different levels.  You need to
remember the common ones, and they are all pretty obvious - no one is
going to be in doubt about the meaning of "a = b * c + d;".

Beyond that, you can always add parenthesis or split the expression into
sub-expressions - whatever makes the code clearer and more maintainable.

You might need to be able to understand other people's code written with
fewer parenthesis than you might personally like, but usually it's clear
what they meant unless they were deliberately writing smart-arse code.

[toc] | [prev] | [next] | [standalone]

#162633

On 06/09/2021 08:15, David Brown wrote:
> On 06/09/2021 01:09, Bart wrote:
>> On 05/09/2021 22:52, Richard Damon wrote:
>>
>>> Also, it puts less operators at any give level of the grammer which
>>> might be useful. You end up with more levels of grammer, but each one is
>>> simpler.
> 
> I think that is a very likely reason.
> 
>>
>> I dispute it's that useful; but it is certainly harder to remember all
>> the different levels. You can also can't assume that everyone will know
>> them as well as you.
> 
> You don't need to remember all the different levels.  You need to
> remember the common ones, and they are all pretty obvious - no one is
> going to be in doubt about the meaning of "a = b * c + d;".
> 
> Beyond that, you can always add parenthesis or split the expression into
> sub-expressions - whatever makes the code clearer and more maintainable.
> 
> You might need to be able to understand other people's code written with
> fewer parenthesis than you might personally like, but usually it's clear
> what they meant unless they were deliberately writing smart-arse code.

If everybody was trusted to do that, or expected to, then what was the 
point of having so many precedence levels?!

(How many can list the precedence levels of &, | and ^, or can explain 
why any one is ranked higher than another?)

C has twice as many as I do for the same set of operators.

Specifically, I parse a<<8 + b the same way as a*256 + b, for obvious 
reasons. In C, one is a<<(8+b), the other is (a*256)+b.

[toc] | [prev] | [next] | [standalone]

#162634

On 06/09/2021 12:10, Bart wrote:
> On 06/09/2021 08:15, David Brown wrote:
>> On 06/09/2021 01:09, Bart wrote:
>>> On 05/09/2021 22:52, Richard Damon wrote:
>>>
>>>> Also, it puts less operators at any give level of the grammer which
>>>> might be useful. You end up with more levels of grammer, but each
>>>> one is
>>>> simpler.
>>
>> I think that is a very likely reason.
>>
>>>
>>> I dispute it's that useful; but it is certainly harder to remember all
>>> the different levels. You can also can't assume that everyone will know
>>> them as well as you.
>>
>> You don't need to remember all the different levels.  You need to
>> remember the common ones, and they are all pretty obvious - no one is
>> going to be in doubt about the meaning of "a = b * c + d;".
>>
>> Beyond that, you can always add parenthesis or split the expression into
>> sub-expressions - whatever makes the code clearer and more maintainable.
>>
>> You might need to be able to understand other people's code written with
>> fewer parenthesis than you might personally like, but usually it's clear
>> what they meant unless they were deliberately writing smart-arse code.
> 
> If everybody was trusted to do that, or expected to, then what was the
> point of having so many precedence levels?!

As has been discussed, it simplifies the grammar and language
specification if operators are divided into groups based on the type of
operands allowed, and then having these groups given different precedence.

> 
> (How many can list the precedence levels of &, | and ^, or can explain
> why any one is ranked higher than another?)

For "and" and "or" operations, it is standard mathematical convention to
treat "and" as higher precedence than "or".  The operations are even
written as "." and "+" in many cases.  Where exclusive or fits in is a
different matter.

> 
> C has twice as many as I do for the same set of operators.
> 

Do you actually have a formal grammar and language specification?

> Specifically, I parse a<<8 + b the same way as a*256 + b, for obvious
> reasons. In C, one is a<<(8+b), the other is (a*256)+b.
> 

I assume you are thinking of shifts as a kind of multiplication or
division, and therefore it should be a higher precedence than addition
and subtraction.  Looking at things purely objectively, I'd be inclined
to agree.  I am generous with parenthesis when using shift operators.

[toc] | [prev] | [next] | [standalone]

#162636

On Monday, 6 September 2021 at 12:01:55 UTC+1, David Brown wrote:
> 
> > (How many can list the precedence levels of &, | and ^, or can explain 
> > why any one is ranked higher than another?)
> For "and" and "or" operations, it is standard mathematical convention to 
> treat "and" as higher precedence than "or". The operations are even 
> written as "." and "+" in many cases. Where exclusive or fits in is a 
> different matter.
>
And is similar to multiplication. If half of the children are boys and a third
have ice creams, then the number who are boys and have ice creams should
be 1/2 * 1/3 = 1/6.
Or is similar to addition. If 1 in ten thousand have the dreaded lurgy, and 1
in ten thousand are hypochondriacs who think they have the dreaded lurgy,
the proportion of people in your clinic will be 1/10000 + 1/10000 =
1/5000 (the number of hypochondriacs with genuine dreaded lurgy is
so small it can be ignored).

[toc] | [prev] | [next] | [standalone]

#162656

On 9/5/21 3:19 PM, Kenny McCormack wrote:
> In article <sh2vvh$oir$1@dont-email.me>,
> James Harris  <james.harris.1@gmail.com> wrote:
>> According to
>>
>>    https://en.cppreference.com/w/c/language/operator_precedence
>>
>> and other references C applies relative comparisons (<, <=, >=, >)
>> before equality comparisons (==, !=) rather than giving them all the
>> same priority.
>>
>> Anyone know why the precedences were designed that way?
>>
>> Are there certain idioms in which that arrangement is useful?
> 
> I think it makes sense.  If I see:
> 
>      if (a < b == c < d)
> 
> I would expect it to mean:
> 
>      if ((a < b) == (c < d))
> 
> That's got to be more useful than:
> 
>      if ((a < (b == c)) < d)
> 

That's exactly the example given in footnote 108 of N1570:

   108) Because of the precedences, a<b == c<d is 1 whenever a<b and c<d
        have the same truth-value

It's the same rationale as expecting "a + b == c + d" to be parsed as
"(a + b) == (c + d)".  You want to see if two relational expressions
are equivalent, and the way to enable that without having to use
explicit parentheses everywhere is to make == and != lower precedence
than <, >, <=, and >=.

[toc] | [prev] | [next] | [standalone]

#162662

On 07/09/2021 15:27, John Bode wrote:
> On 9/5/21 3:19 PM, Kenny McCormack wrote:
>> In article <sh2vvh$oir$1@dont-email.me>,
>> James Harris  <james.harris.1@gmail.com> wrote:
>>> According to
>>>
>>>    https://en.cppreference.com/w/c/language/operator_precedence
>>>
>>> and other references C applies relative comparisons (<, <=, >=, >)
>>> before equality comparisons (==, !=) rather than giving them all the
>>> same priority.
>>>
>>> Anyone know why the precedences were designed that way?
>>>
>>> Are there certain idioms in which that arrangement is useful?
>>
>> I think it makes sense.  If I see:
>>
>>      if (a < b == c < d)
>>
>> I would expect it to mean:
>>
>>      if ((a < b) == (c < d))
>>
>> That's got to be more useful than:
>>
>>      if ((a < (b == c)) < d)
>>
> 
> That's exactly the example given in footnote 108 of N1570:
> 
>    108) Because of the precedences, a<b == c<d is 1 whenever a<b and c<d
>         have the same truth-value
> 
> It's the same rationale as expecting "a + b == c + d" to be parsed as
> "(a + b) == (c + d)".  You want to see if two relational expressions
> are equivalent, and the way to enable that without having to use
> explicit parentheses everywhere is to make == and != lower precedence
> than <, >, <=, and >=.

But has anyone ever seen that in real code? And if they have, why 
wouldn't they also, at some point, have seen:

   (a == b) == (c == d)

Without parentheses, that becomes ((a==b)==c)==d).

It seems like they desperately wanted to find any excuse for justifying 
an extra, gratuitous precedence level for everyone to remember, when 
dropping one level would probably have had a greater net benefit.

[toc] | [prev] | [next] | [standalone]

#162678

On 9/7/21 6:20 PM, Bart wrote:
> On 07/09/2021 15:27, John Bode wrote:
>> On 9/5/21 3:19 PM, Kenny McCormack wrote:
>>> In article <sh2vvh$oir$1@dont-email.me>,
>>> James Harris  <james.harris.1@gmail.com> wrote:
>>>> According to
>>>>
>>>>    https://en.cppreference.com/w/c/language/operator_precedence
>>>>
>>>> and other references C applies relative comparisons (<, <=, >=, >)
>>>> before equality comparisons (==, !=) rather than giving them all the
>>>> same priority.
>>>>
>>>> Anyone know why the precedences were designed that way?
>>>>
>>>> Are there certain idioms in which that arrangement is useful?
>>>
>>> I think it makes sense.  If I see:
>>>
>>>      if (a < b == c < d)
>>>
>>> I would expect it to mean:
>>>
>>>      if ((a < b) == (c < d))
>>>
>>> That's got to be more useful than:
>>>
>>>      if ((a < (b == c)) < d)
>>>
>>
>> That's exactly the example given in footnote 108 of N1570:
>>
>>    108) Because of the precedences, a<b == c<d is 1 whenever a<b and c<d
>>         have the same truth-value
>>
>> It's the same rationale as expecting "a + b == c + d" to be parsed as
>> "(a + b) == (c + d)".  You want to see if two relational expressions
>> are equivalent, and the way to enable that without having to use
>> explicit parentheses everywhere is to make == and != lower precedence
>> than <, >, <=, and >=.
> 
> But has anyone ever seen that in real code? And if they have, why 
> wouldn't they also, at some point, have seen:
> 
>    (a == b) == (c == d)
> 
> Without parentheses, that becomes ((a==b)==c)==d).
> 
> It seems like they desperately wanted to find any excuse for justifying 
> an extra, gratuitous precedence level for everyone to remember, when 
> dropping one level would probably have had a greater net benefit.
> 

As pointed out in another subthread, that split was already present in B
- Thompson decided it was worth doing for whatever reason. Perhaps he
hit the a<b == c<d case a lot more than most of us.  Or maybe he just
though "hey, this could be useful".

C's expression grammar is set up to do mostly what you expect without
having to explicitly group operators and operands.  "*p" works to
dereference a pointer object, and you can substitute "p" with any
postfix expression and it will still work as you expect - "*ap[i]",
"*fp()", "*s.p", etc.  You don't have to write "*(ap[i])", "*(fp())",
etc.

Comparing the results of any two expressions is just a matter of
writing "expr == expr" or "expr != expr", and it works for  almost
any expression - arithmetic, postfix, or relational.

You don't have to explicitly remember 16 levels of precedence; most of
the time you don't have to think about it at all.  You only have to know
when the default precedence *doesn't* work for what you're trying to do.

[toc] | [prev] | [next] | [standalone]

#162627

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> James Harris <james.harris.1@gmail.com> writes:
>>Anyone know why the precedences were designed that way?
>
>   The precedence of > < <= >= over == != was already
>   present in B.

Ah.  But not in BCPL, so Thompson thought it worth splitting them.

Mind you, BCPL permits expressions  like a < b < c and a < b = 0 with
the usual "mathematical" meaning.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#162631

On 06/09/2021 02:01, Ben Bacarisse wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
>> James Harris <james.harris.1@gmail.com> writes:
>>> Anyone know why the precedences were designed that way?
>>
>>    The precedence of > < <= >= over == != was already
>>    present in B.
> 
> Ah.  But not in BCPL, so Thompson thought it worth splitting them.
> 
> Mind you, BCPL permits expressions  like a < b < c and a < b = 0 with
> the usual "mathematical" meaning.
> 

I guess that's the meaning of "The result of evaluating an extended 
relation is true if and only if all the individual relations are true." in

   https://www.bell-labs.com/usr/dmr/www/bcpl.pdf

That document also appears to back up what you say about relative 
precedences. It says "The relational operators are less binding than the 
arithmetic operators."

And, subsequently, "the shift operators are less binding than the 
relations on the left and more binding on the right." - which means 
something or other...!


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#162632

James Harris <james.harris.1@gmail.com> writes:

> On 06/09/2021 02:01, Ben Bacarisse wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> 
>>> James Harris <james.harris.1@gmail.com> writes:
>>>> Anyone know why the precedences were designed that way?
>>>
>>>    The precedence of > < <= >= over == != was already
>>>    present in B.
>>
>> Ah.  But not in BCPL, so Thompson thought it worth splitting them.
>> Mind you, BCPL permits expressions  like a < b < c and a < b = 0 with
>> the usual "mathematical" meaning. 
>
> I guess that's the meaning of "The result of evaluating an extended
> relation is true if and only if all the individual relations are
> true." in
>
>   https://www.bell-labs.com/usr/dmr/www/bcpl.pdf

Later documents are much clearer on this point.  The above document is
a technical note and not really a user manual.

> That document also appears to back up what you say about relative
> precedences. It says "The relational operators are less binding than
> the arithmetic operators."
>
> And, subsequently, "the shift operators are less binding than the
> relations on the left and more binding on the right." - which means
> something or other...!

It was trendy to have asymmetric precedence at one time (exponentiation
was the most common example, I think), but that seems to have been
dropped in later manuals.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#162646

On 9/6/21 5:46 AM, Ben Bacarisse wrote:
> It was trendy to have asymmetric precedence at one time (exponentiation
> was the most common example, I think), but that seems to have been
> dropped in later manuals.

When "Operator precedence" isn't described in terms of actual operator
precedence, but a grammar production rule, it is easy to create the
asymmetric cases.

I wonder if the issue is that more modern systems go to a less grammar
and more descriptive way to describe expressions, which makes this sort
of asymmetry harder to describe and thus undesirable.

It may also be related to how we write parsers, a grammar based parser
will tend to be bigger, as you need separate code (at least somewhat)
for each level of the grammar, while a precedence based parser while
somewhat more complicated that a single grammar rule, is smaller as the
repetition of rules becomes a table of operators and precedence.

[toc] | [prev] | [next] | [standalone]

#162647

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/6/21 5:46 AM, Ben Bacarisse wrote:
>> It was trendy to have asymmetric precedence at one time (exponentiation
>> was the most common example, I think), but that seems to have been
>> dropped in later manuals.
>
> When "Operator precedence" isn't described in terms of actual operator
> precedence, but a grammar production rule, it is easy to create the
> asymmetric cases.
>
> I wonder if the issue is that more modern systems go to a less grammar
> and more descriptive way to describe expressions, which makes this sort
> of asymmetry harder to describe and thus undesirable.
>
> It may also be related to how we write parsers, a grammar based parser
> will tend to be bigger, as you need separate code (at least somewhat)
> for each level of the grammar, while a precedence based parser while
> somewhat more complicated that a single grammar rule, is smaller as the
> repetition of rules becomes a table of operators and precedence.

The "usual" expression parser can handle asymmetric cases just fine.
You pass in the precedence (starting with, say, 0) and the parse is
driven by a table giving associativity along with left and right
precedences to pass down when parsing sub-expressions.

I suspect tools like yacc might have played a role in its dying out.
While you can write a suitable grammar in yacc, it also has a built in
way to parse expressions simply by giving one precedence.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#162630

On 05/09/2021 23:29, Stefan Ram wrote:
> James Harris <james.harris.1@gmail.com> writes:
>> Anyone know why the precedences were designed that way?
> 
>    The precedence of > < <= >= over == != was already
>    present in B.

Was that in just some versions of B? It looks as though relational and 
equality comparisons are at the same level in

   https://www.thinkage.ca/gcos/expl/b/manu/manu.html#AppendixB

Of course, that may not be right but I wonder if Thompson changed from 
one set of precedence levels to the other, and why.

> 
>    Kernighan/Ritchie wrote:
> 
> |The == (equal to) and the != (not equal to) operators are
> |analogous to the relational operators except for their lower
> |precedence. (Thus a<b == c<d is 1 whenever a<b and c<d have
> |the same truth-value.)

Do you have a link to the source of that?


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web