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

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

Operator precedence.

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

Contents

  Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:10 -0700
    Re: Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:23 -0700
    Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-06 23:57 -0400
    Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-07 03:59 +0000
    Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 05:48 -0400
      Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 07:52 -0400
        Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 13:18 +0100
          Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 09:08 -0400
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 14:36 +0100
              Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 13:29 -0400
        Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 11:24 -0400
    Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-07 16:35 +0100
      Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-10 19:05 +0000
        Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-10 20:35 +0100
          Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 09:25 -0400
            Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 16:42 +0100
              Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 12:28 -0400
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 18:42 +0100
                  Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 15:18 -0400
                    Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:52 +0100
                      Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 18:39 -0400
                  Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:20 +0000
                    Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:28 +0000
                      Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:28 +0100
                        Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 21:45 +0000
                Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 12:11 -0700
              Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 17:37 +0100
          Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 16:24 +0100
            Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 20:14 +0100
              Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 20:56 +0100
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:21 +0100
                  Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:05 +0100
            Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-11 22:46 +0000
              Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:17 +0100
                Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-12 19:35 +0000
                  Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-12 22:39 +0100
              Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 16:07 -0700
                Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-13 19:08 +0000
                  Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-13 13:17 -0700
                    Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-14 21:06 +0000
                      Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-14 20:42 -0700
                  Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-13 23:20 +0000
        Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-10 15:24 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#20633

On 05/11/2012 05:52 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:4FAD65F5.5040605@verizon.net...
...
>> Yes, if you only consider the unary operators, it's simple. However, the
>> minute you throw in binary operators, the issue does comes up. C deals
>> with that issue by specifying a grammar that gives the postfix operators
>> (both unary and binary)
> 
> I'm not too well up on the right terminology, but wouldn't any binary
> operator just be 'infix'?

That's a reasonable point of view, but the C standard calls a[b], a(b),
a.b, a->b, and (a){b} postfix-expressions, even though they're all
binary, and the parts of those expressions that are left after you
remove 'a' and 'b' are considered by the C standard to be postfix
operators. I think that's may be because they are highly asymmetric
operators, so 'b' was considered to be part of the operator, rather than
an operand fully comparable to 'a' itself.

...
> Actually, I've made use of C-style postfix ++,-- operators in my own
> projects. They are parsed as they are in C. (But I don't any special concept 
> of precedence, and a much simpler grammar.)
> 
>> There are only two unary postfix operators, the other postfix operators
>> are all binary. According to the grammar, a++-- can only be  parsed as
>> (a++)--, not as (a--)++. It hardly matters, though: postfix ++ and --
>> both require modifiable lvalues for their left operand (6.5.3.1p2), and
>> neither one has a result which is an lvalue.
> 
> (Yes, well, I worry about lvalues in a later pass. My parser only deals
> with 'shape'.)

That's entirely appropriate - constraint violations are to be diagnosed
based upon what you have as a result of parsing; they shouldn't
influence the parsing itself (though people have argued to the contrary
with respect to function-like macros with no arguments). What "shape"
does your language consider a++-- to have?

...
> which fortunately it did. But then, I don't treat "." (or "->") as an
> operator at all; it can't be an operator because the right operand can't be 
> a conventional expression.)

The C standard considers it an operator, operating on an expression and
and identifier. Similarly, (a){b} is an operator even though 'a' has to
be a type name, not an expression.

...
> So the issue is really K&R over-simplifying matters in their operator table,
> by including constructs which are not conventional operators in syntax or
> semantics (such as "()" and "[]").

They are operators as far as the C standard is concerned, however
unconventional they might be.

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

#20613

On 2012-05-11, BartC <bc@freeuk.com> wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:4FAD3E13.7000804@verizon.net...
>> On 05/11/2012 11:42 AM, BartC wrote:
>>> in your examples. The precedence table in K&R2 suggests that a series of
>>> unary ops such as op1 op2 A op3 op4 should be calculated as op1(op2((A 
>>> op4)
>>> op3)) (with 3 and 4 interchanged). They are confusing.
>>
>> That's a rather confusing statement. Why did you write "with 3 and 4
>> interchanged" rather than simply interchanging 3 and 4?
>
> Because you might have thought it a typo otherwise. K&R says unary ops 
> associate from  right to left. So op4 first.

Right-to-left associativity only holds for the prefix unary operators.
Postfix unary operators associate from left to right.
In your example,

  op1 op2 A op4 op4

should be calculated as

  op1 (op2 ((A op4) op3))

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

#20614

On 2012-05-11, Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2012-05-11, BartC <bc@freeuk.com> wrote:
>> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
>> news:4FAD3E13.7000804@verizon.net...
>>> On 05/11/2012 11:42 AM, BartC wrote:
>>>> in your examples. The precedence table in K&R2 suggests that a series of
>>>> unary ops such as op1 op2 A op3 op4 should be calculated as op1(op2((A 
>>>> op4)
>>>> op3)) (with 3 and 4 interchanged). They are confusing.
>>>
>>> That's a rather confusing statement. Why did you write "with 3 and 4
>>> interchanged" rather than simply interchanging 3 and 4?
>>
>> Because you might have thought it a typo otherwise. K&R says unary ops 
>> associate from  right to left. So op4 first.
>
> Right-to-left associativity only holds for the prefix unary operators.
> Postfix unary operators associate from left to right.
> In your example,
>
>   op1 op2 A op4 op4
>
> should be calculated as
>
>   op1 (op2 ((A op4) op3))

Sorry for adding to the confusion, that should, of course, be

   op1 op2 A op3 op4

and

   op1 (op2 ((A op3) op4))

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

#20629

"Ike Naar" <ike@sverige.freeshell.org> wrote in message
news:slrn3vfsjqqq2q.kv6.ike@sverige.freeshell.org...
> On 2012-05-11, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2012-05-11, BartC <bc@freeuk.com> wrote:
>>> "James Kuyper" <jameskuyper@verizon.net> wrote in message
>>> news:4FAD3E13.7000804@verizon.net...
>>>> On 05/11/2012 11:42 AM, BartC wrote:
>>>>> in your examples. The precedence table in K&R2 suggests that a series
>>>>> of
>>>>> unary ops such as op1 op2 A op3 op4 should be calculated as op1(op2((A
>>>>> op4)
>>>>> op3)) (with 3 and 4 interchanged). They are confusing.
>>>>
>>>> That's a rather confusing statement. Why did you write "with 3 and 4
>>>> interchanged" rather than simply interchanging 3 and 4?
>>>
>>> Because you might have thought it a typo otherwise. K&R says unary ops
>>> associate from  right to left. So op4 first.
>>
>> Right-to-left associativity only holds for the prefix unary operators.
>> Postfix unary operators associate from left to right.

So my book is wrong (K&R2 p. 53); it says *all* unary operators associate
right to left.

>> In your example,

>   op1 op2 A op3 op4
>
[should be]
>
>   op1 (op2 ((A op3) op4))
>

So, all the ones on the right first, innermost first out, then all those on
the left, also innermost first?

-- 
Bartc 

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

#20630

On 2012-05-11, BartC <bc@freeuk.com> wrote:
> So my book is wrong (K&R2 p. 53); it says *all* unary operators associate
> right to left.

Perhaps it's a matter of terminology.
I don't have K&R2 available to check it, but perhaps
the term "unary operator" does not apply to postfix ++ and postfix --.

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

#20655

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Not all of the choices made for operator precedence were good ones;
> IIRC, Ritchie himself acknowledged that fact. In a new language where
> backwards compatibility was not an issue, they should be done
> differently. But I don't think that fewer precedence levels is the way
> to go.

Here's what Dennis Ritchie said about it in net.lang.c, this group's
predecessor, on 1982-10-22, Message-ID: <bnews.research.310>:

    The priorities of && || vs. == etc. came about in the following way.
    Early C had no separate operators for & and && or | and ||.  (Got
    that?)  Instead it used the notion (inherited from B and BCPL) of
    "truth-value context": where a Boolean value was expected, after
    "if" and "while" and so forth, the & and | operators were
    interpreted as && and || are now; in ordinary expressions, the
    bitwise interpretations were used.  It worked out pretty well, but
    was hard to explain.  (There was the notion of "top-level operators"
    in a truth-value context.)

    The precedence of & and | were as they are now.

    Primarily at the urging of Alan Snyder, the && and || operators were
    added. This successfully separated the concepts of bitwise
    operations and short-circuit Boolean evaluation.  However, I had
    cold feet about the precedence problems.  For example, there were
    lots of programs with things like
            if (a==b & c==d) ...
    In retrospect it would have been better to go ahead and change the
    precedence of & to higher than ==, but it seemed safer just to split
    & and && without moving & past an existing operator. (After all, we
    had several hundred kilobytes of source code, and maybe 3
    installations....)
            Dennis Ritchie

Backward compatibility is not a new problem.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20599

"BartC" <bc@freeuk.com> writes:
<snip>
> ...    And if I read the table properly, then a & b == c & d actually
> means a & (b==c) & d; that obviously doesn't look right, not for
> bitwise & anyway.

Yes, that's a well-known "mistake" -- one that DMR has commented on so
we have the explanation of how it came about from the horse's mouth:

http://www.lysator.liu.se/c/dmr-on-or.html

<snip>
-- 
Ben.

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

#20588

"BartC" <bc@freeuk.com> writes:
<snip Fortran operators>
> Well they don't look like C. And I'm not sure why unary ops are
> included in that lot. And whether they are logical or not, too many
> precedences are difficult to remember. I tend to use a pattern like
> this:
>
> 6 LOGICAL OR
> 5 LOGICAL AND
> 4 COMPARE/LOGICAL XOR [not sure what this one is doing here]
> 3 ADD/SUB/BITWISE AND/OR/XOR
> 2 MUL/DIV/MOD/SHIFT
> 1 POWER (right-to-left)
>
> Since C doesn't have a power op, that leaves just 5 levels; only two
> of which are needed for normal arithmetic. A bit easier or not?

At least one component of "easier" is "logical" so it may help to look
at C's operators in that light.

Because of the strong mathematical the connection between &/| and */+ it
is natural to separate these pairs by precedence.  Since C also has
&&/|| that gives us 6 levels right away.  You could argue that these
need not all be distinct, but logical connections (&& and ||) are often
made between arithmetic and bit-wise expressions and almost never the
other way round, and although the case for separating &/| from */+ is
more pragmatic it still strong.

Order relationships are most often made between arithmetic expressions
and they are often joined by logical connectives, so another level seems
natural for these.  This gives us 7 levels.

Likewise, assignment should allow almost anything to be assigned without
parentheses, but sequencing (,) should allow assignment without any
because it's main purpose, after all, is to permit a explicit
side-effect, to occur in sequence.  That takes us to up to 9.

Unary operators need a 10th level just to be consistent with normal
mathematical notation, but because C has postfix unary operators as well
we should ask if they can share the level with their prefix cousins.
Expressions like -a[10] and *f(0) are common, so it seems impractical to
require parentheses for them and, because the expected meaning is not
easily expressed using associativity, this leads to an 11th level.

C has 15 levels -- the other 4 coming from bit-wise XOR, the shift
operators, the conditional operator, and from separating equality from
the other comparison operators.

Once you have 11, it seems to me you may as well have 15.  Putting ^ in
with, say, |; or putting the shift operators in with * would probably be
as confusing as giving them their own level.  And separating == and !=
from < and friends has strong arguments in its favour, which there is no
reason to ignore once you already have so many levels.

In short, I don't think C would be logical with fewer than 11 levels,
and once you have 11, does it matter if the distinctions between
operators are emphasized by having 15?  Would the degree of
arbitrariness required to reduce the number eliminate the benefit of
having fewer?

-- 
Ben.

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

#20611

[Repost of lost message. Hopefully this won't contradict that one if it ever
turns up..]

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

> In short, I don't think C would be logical with fewer than 11 levels,
> and once you have 11, does it matter if the distinctions between
> operators are emphasized by having 15?  Would the degree of
> arbitrariness required to reduce the number eliminate the benefit of
> having fewer?

You've got it wrong; you need more arbitrariness to increase the number of
levels. You need to justify one operator having a higher or lower precedence
than another. At the same level, there is little to decide!

The difference between add/subtract, and multiple/divide, most people know
about. That's two. There's a few more levels that are obvious (compare, and
logical and/or). But none of the rest have an obvious precedence, or no
reason to for them to have their own dedicated precedence level.

(In a UK general discussion forum, the value of 48÷2(9+3) was recently
discussed. After 2500 posts, there was still no agreement! And a poll showed
that 55% thought the answer was 2, and 45% thought it was 288. Someone even
posted this explanation: http://www.youtube.com/watch?v=bwpWw-iVKHc.

So a lot of people have trouble even dealing with just two precedence
levels. And C has a dozen more! Admittedly that was a not technical forum.)

-- 
Bartc 

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

#20616

"BartC" <bc@freeuk.com> writes:

> [Repost of lost message. Hopefully this won't contradict that one if it ever
> turns up..]
>
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>
>> In short, I don't think C would be logical with fewer than 11 levels,
>> and once you have 11, does it matter if the distinctions between
>> operators are emphasized by having 15?  Would the degree of
>> arbitrariness required to reduce the number eliminate the benefit of
>> having fewer?
>
> You've got it wrong; you need more arbitrariness to increase the number of
> levels. You need to justify one operator having a higher or lower precedence
> than another. At the same level, there is little to decide!

Most of my post did try to explain why it's not arbitrary!

> The difference between add/subtract, and multiple/divide, most people know
> about. That's two. There's a few more levels that are obvious (compare, and
> logical and/or). But none of the rest have an obvious precedence, or no
> reason to for them to have their own dedicated precedence level.

I don't want = and , to share precedence with any of these.

> (In a UK general discussion forum, the value of 48÷2(9+3) was recently
> discussed. After 2500 posts, there was still no agreement! And a poll showed
> that 55% thought the answer was 2, and 45% thought it was 288. Someone even
> posted this explanation: http://www.youtube.com/watch?v=bwpWw-iVKHc.
>
> So a lot of people have trouble even dealing with just two precedence
> levels. And C has a dozen more! Admittedly that was a not technical
> forum.)

I can't see what the number of precedence levels has to do with this
example.  The only possible ambiguity (as evidenced by the two answers
you give) is about associativity, not precedence.

-- 
Ben.

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

#20628

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.b12cce1ec5f25bcfb767.20120511205606BST.8762c2wkyx.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> You've got it wrong; you need more arbitrariness to increase the number 
>> of
>> levels.

> Most of my post did try to explain why it's not arbitrary!

You tried to justify why every new operator seems to need it's own 
precedence level. But OK:

> Because of the strong mathematical the connection between &/| and */+ it
> is natural to separate these pairs by precedence.

It also makes it natural to group them together.

> Once you have 11, it seems to me you may as well have 15.

Now you seem to be saying there are so many, that you need to keep a table 
to hand anyway, so it doesn't matter how many levels there are!

>  Putting ^ in
> with, say, |; or putting the shift operators in with * would probably be
> as confusing as giving them their own level.

Shift operators effectively multiply and divide; so why *not* lump them with 
* and /? As it as, some are obliged to use parentheses as they will not know 
off-hand where they actually are in the hierarchy.

>  And separating == and !=
> from < and friends has strong arguments in its favour, which there is no
> reason to ignore once you already have so many levels.

Again, adding levels for it's own sake. And, should be == be higher then >, 
or the other way? And, what are the arguments for not having the same level 
for all of them? I can't see a reason to favour (a==b)<c over a==(b<c) or 
vice versa.

>> The difference between add/subtract, and multiple/divide, most people 
>> know
>> about. That's two. There's a few more levels ...

> I don't want = and , to share precedence with any of these.

Well, OK, in C, "=" is classed as an operator, although a low priority one. 
So actually when you take out the obvious ones, such as "=" and ".", there's 
a bit less than 15 to remember. But still too many..

>> (In a UK general discussion forum, the value of 48÷2(9+3) was recently
>> discussed. After 2500 posts, there was still no agreement!

> I can't see what the number of precedence levels has to do with this
> example.  The only possible ambiguity (as evidenced by the two answers
> you give) is about associativity, not precedence.

That's true; I tend to lump the two together. Ultimately what's being 
decided is order of evaluation**. The point was, the general public seem to 
have a real problem with this stuff; I can fare a bit better, but still have 
trouble remembering beyond about six levels (and that only because they are 
in two groups: arithmetic, and compare/logical).

Did the designers of C actually seek to minimise precedence levels? Did they 
think that having many of them would be better than having too few? Having 
too few levels means extra parentheses. Having too many also means extra 
parentheses when you can't remember the priorities!

(** And yes I know the right terminology is a bit different. Sometimes there 
is a choice of evaluation order without affecting the result.)

-- 
Bartc 

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

#20635

"BartC" <bc@freeuk.com> writes:
<snip>

I think we're likely to continue to disagree here so I'll just answer
your question:

> Again, adding levels for it's own sake. And, should be == be higher
> then >, or the other way? And, what are the arguments for not having
> the same level for all of them? I can't see a reason to favour
> (a==b)<c over a==(b<c) or vice versa.

All of these operators produce 0 or 1.  The < and <= relation between
such values crop up very must less often than == and != do.  For example

  a < 0 == b < 0

asserts that a and b have the same sign.  != is logical XOR.

I am not saying that this will convince you that another precedence
level is needed, but it might persuade you that it's not pointless (as
you seemed to be suggesting).

<snip>
-- 
Ben.

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

#20634

In article <0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>Once you have 11, it seems to me you may as well have 15.

They have structure:

    function call
    arithmetic
	power root (**)
	multiply divide
	plus minus
    bitwise
	not
	and
	or
	compare
    logical
	not
	and
	or
	compare (.EQV.)
    assignment

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

#20636

jgk@panix.com (Joe keane) writes:

> In article <0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>>Once you have 11, it seems to me you may as well have 15.
>
> They have structure:
>
>     function call
>     arithmetic
> 	power root (**)
> 	multiply divide
> 	plus minus
>     bitwise
> 	not
> 	and
> 	or
> 	compare
>     logical
> 	not
> 	and
> 	or
> 	compare (.EQV.)
>     assignment

To what are you referring?  This is not C and it's not Fortran (as
.EQV. might suggest).

-- 
Ben.

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

#20656

In article <0.38da0585be4c06b336ce.20120512001744BST.871umqux2f.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>To what are you referring?

programming languages

I know BASIC, Pascal, Java, and they're all pretty much the same.

Why doesn't C have a '**' operator?
Well it just doesn't.
Why doesn't C have a '^^' operator?
Well it just doesn't.

I can work with Lisp or HP-41 but, obviously a lot of people thought it
useful to AFAP copy math notation (translating formulas).

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

#20658

"Joe keane" <jgk@panix.com> wrote in message 
news:jome15$6c$1@reader1.panix.com...
> In article 
> <0.38da0585be4c06b336ce.20120512001744BST.871umqux2f.fsf@bsb.me.uk>,

> Why doesn't C have a '**' operator?
> Well it just doesn't.

It has a pow() function that does almost the same thing (with fewer 
overloading possibilities).

> Why doesn't C have a '^^' operator?
> Well it just doesn't.

What is ^^ supposed to be? Up-arrow notation?

-- 
Bartc  

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

#20664

jgk@panix.com (Joe keane) writes:
> In article <0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk>,
> Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>>Once you have 11, it seems to me you may as well have 15.
>
> They have structure:
>
>     function call
>     arithmetic
> 	power root (**)
> 	multiply divide
> 	plus minus
>     bitwise
> 	not
> 	and
> 	or
> 	compare
>     logical
> 	not
> 	and
> 	or
> 	compare (.EQV.)
>     assignment

As you've been asked several times before, what language are you talking
about?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20688

In article <lnd369m20l.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>As you've been asked several times before, what language are you
>talking about?

a language that has operator precedence

Although you may find languages without operator precedence,
the ones that do have it are more similar than different.

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

#20690

jgk@panix.com (Joe keane) writes:
> In article <lnd369m20l.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>As you've been asked several times before, what language are you
>>talking about?
>
> a language that has operator precedence
>
> Although you may find languages without operator precedence,
> the ones that do have it are more similar than different.

So it's not any specific language?  You've been posting very specific
information about something that doesn't actually exist -- when
there are *plenty* of examples of real-world languages with well
defined operator precedence rules that would have made perfectly
good examples.

And you didn't feel the need to tell us what you were doing.

Please consider making some additional effort to let people know
what you're talking about rather than wasting our time.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#20722

In article <ln4nrjn8e0.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:

>You've been posting very specific information about something that
>doesn't actually exist -- when there are *plenty* of examples of
>real-world languages with well defined operator precedence rules that
>would have made perfectly good examples.

The conversation was about some hypothetical language that is like C
but has less [or more] levels of precendence.

Bartc suggested six [or five] levels, and asked whether this would be easier.  James Kuyper and Ben Bacarisse suggested that it would not, and that
arguably C has about the right number of levels.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web