wrote:
> That is not an answer, just an excuse. It links language operators to
> presence or absence of hardware. C is not assembly language.
> Translation is the job of something called a compiler.
>
1) You have failed to quote sufficient context -- for which Google's
broken Usenet interface is no excuse.
2) You were directed to an answer -- in the FAQ, which you should have
read *before* asking your original question.
3) This newsgroup is primarily concerned with the ISO C language as it
*is*. If you want it to be different, the proper place for such
discussions is news:comp.std.c.

Further, I recommend you do some reading on the history of the C
language, why it was created, what was its intended purpose, etc. That
may provide insight into the design decisions made.

Guest

wrote:
> C is not assembly language.

Some people would beg to differ. C evolved from B which was merely a
very high level macro assembler. C itself was developed primarily as
replacement of assembly - a better way to write low level system
software. You want something higher level, try C++ (there you can
overload whatever operater you want).

a écrit :
> wrote:
>
>>C is not assembly language.
>
>
> Some people would beg to differ. C evolved from B which was merely a
> very high level macro assembler. C itself was developed primarily as
> replacement of assembly - a better way to write low level system
> software. You want something higher level, try C++ (there you can
> overload whatever operater you want).
>

This is the old story supported by many people around here.

C is dead and everybody should move to the "higher" level, C++.

This justifies trying to deny C any evolution possibilities, and
keeping the discussion in this group as "low level" as
possible.

The OP question is a good one. Personally I do not think we need a new
exponentiation operator, and in lcc-win32 there is operator overloading,
but those are not answers to the OP question.

May I remind you that the supposedly "higher" level C++ doesn't
have an exponentiation operator EITHER ???

I think the answer is that the enormous problem of introducing a
new operator, with all the complications of the 15 levels of
precedence of C makes the introduction of an ^^ operator an
herculean task, one that nobody has attempted, and probably never
will.

Guest

> Some people would beg to differ. C evolved from B which was merely a
> very high level macro assembler. C itself was developed primarily as
> replacement of assembly - a better way to write low level system
> software. You want something higher level, try C++ (there you can
> overload whatever operater you want)

Absolutely correct, but C++ does not have an exponentiation operator
to overload. I might be off base here since I use C++ very little,
but I dont think pow(..) is in the "overloadable" list.

As regards gradual departure of C from assembly, let me note that
C99 offers a built-in complex type and associated operators.
Those are not part of any widely used assembly language
instruction set, although they can be microcoded in some
embedded systems.

"" writes:
> Some people would beg to differ. C evolved from B which was merely a
> very high level macro assembler. C itself was developed primarily as
> replacement of assembly - a better way to write low level system
> software. You want something higher level, try C++ (there you can
> overload whatever operater you want).

This exposes one of the frailties of C++. The natural exponentiation
operator, ^, has the precedence of exclusive or, which is far too low for
the operation desired. Overloading it would be a disaster waiting to
happen. You would have parens all over the place and if you forgot one
there would probably be hell to pay in faulty results.

On 2005-12-23, <> wrote:
>> Some people would beg to differ. C evolved from B which was merely a
>> very high level macro assembler. C itself was developed primarily as
>> replacement of assembly - a better way to write low level system
>> software. You want something higher level, try C++ (there you can
>> overload whatever operater you want)
>
> Absolutely correct, but C++ does not have an exponentiation operator
> to overload. I might be off base here since I use C++ very little,
> but I dont think pow(..) is in the "overloadable" list.

Jordan Abel a écrit :
> On 2005-12-23, <> wrote:
>
>>>Some people would beg to differ. C evolved from B which was merely a
>>>very high level macro assembler. C itself was developed primarily as
>>>replacement of assembly - a better way to write low level system
>>>software. You want something higher level, try C++ (there you can
>>>overload whatever operater you want)
>>
>>Absolutely correct, but C++ does not have an exponentiation operator
>>to overload. I might be off base here since I use C++ very little,
>>but I dont think pow(..) is in the "overloadable" list.
>
>
> I believe functions can also be overloaded.

a écrit :
>
> The OP I was replying to did not mention anything about exponentiation
> operator. He just said operators are linked to what is available in
> assembly.
>

God you are totally confused!!!

1) The OP (see the TITLE of this thread) asked why there isn't
an exponentiation operator in C.
2) He was redirected to the FAQ that says that there isn't since there
is no hardware support for that operator. It is the FAQ that says
it, not the OP.
3) The OP critized the FAQ, saying (rightly so in my opinion) that
C is not tied to hardware.

osmium a écrit :
> "" writes:
>
>
>>Some people would beg to differ. C evolved from B which was merely a
>>very high level macro assembler. C itself was developed primarily as
>>replacement of assembly - a better way to write low level system
>>software. You want something higher level, try C++ (there you can
>>overload whatever operater you want).
>
>
> This exposes one of the frailties of C++. The natural exponentiation
> operator, ^, has the precedence of exclusive or, which is far too low for
> the operation desired. Overloading it would be a disaster waiting to
> happen. You would have parens all over the place and if you forgot one
> there would probably be hell to pay in faulty results.
>
>

And we come to the point that I mentioned elsethread:

The 15 levels of precedence of C are so messy that nobody
has had the time to devote a man year to find out how
an exponentiation operator could be implemented.

Actually, they're not all /that/ different, conceptually speaking. One can
think of qsort as the "sort" operator, strcmp as the "string comparison"
operator, foo as the "do the foo thing" operator, and so on. A function is
just God's way of letting us specify our own operators that can do whatever
we have the skill and imagination to write.

Richard Heathfield a écrit :
> jacob navia said:
>
> <snip>
>
>>A function (overloaded or not) is not an operator!
>
>
> Actually, they're not all /that/ different, conceptually speaking. One can
> think of qsort as the "sort" operator, strcmp as the "string comparison"
> operator, foo as the "do the foo thing" operator, and so on. A function is
> just God's way of letting us specify our own operators that can do whatever
> we have the skill and imagination to write.
>

Granted, both operator overloading and function calls are the
same. The difference is syntax. In a function call even
if the function is overloaded you have a monadic (single
argument operator)

FUNCTION '(' arguments ... ')'

An operator can be monadic like above:
! arguments of the NOT operator
or DYADIC

arguments operator arguments

like

2 + 3

The purported exponentiation operator would have to be dyadic:

10 ^^ 3 --> 1000

This would be feasible but the problem is inserting it in
the precedence rules of C

10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???

There are enomous problems with this approach, and for exponentiation
I think it is just not worth the effort, unless we devise a general
rule about adding new operators.

On 2005-12-23, jacob navia <> wrote:
> Richard Heathfield a écrit :
>> jacob navia said:
>>
>> <snip>
>>
>>>A function (overloaded or not) is not an operator!
>>
>>
>> Actually, they're not all /that/ different, conceptually speaking. One can
>> think of qsort as the "sort" operator, strcmp as the "string comparison"
>> operator, foo as the "do the foo thing" operator, and so on. A function is
>> just God's way of letting us specify our own operators that can do whatever
>> we have the skill and imagination to write.
>>
>
> Granted, both operator overloading and function calls are the
> same. The difference is syntax. In a function call even
> if the function is overloaded you have a monadic (single
> argument operator)

You don't seem to see the distinction between overloading a function and
overloading the function-call operator.
> FUNCTION '(' arguments ... ')'
>
> An operator can be monadic like above:
> ! arguments of the NOT operator
> or DYADIC
>
> arguments operator arguments
>
> like
>
> 2 + 3
>
> The purported exponentiation operator would have to be dyadic:
>
> 10 ^^ 3 --> 1000

it'd probably be **, but
> 10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???
>
> There are enomous problems with this approach, and for exponentiation
> I think it is just not worth the effort, unless we devise a general
> rule about adding new operators.

jacob navia wrote:
> a écrit :
>>
>> The OP I was replying to did not mention anything about
>> exponentiation operator. He just said operators are linked to
>> what is available in assembly.
>
> God you are totally confused!!!
>
> 1) The OP (see the TITLE of this thread) asked why there isn't
> an exponentiation operator in C. 2) He was redirected to the FAQ
> that says that there isn't since there is no hardware support
> for that operator. It is the FAQ that says it, not the OP. 3)
> The OP critized the FAQ, saying (rightly so in my opinion) that
> C is not tied to hardware.

No, you are. Based on the context included in the various
messages, only your point 1) is valid. The rest was not quoted,
and thus not necessarily available to Mr. Slebetman.

The FAQ points out a perfectly valid reason for omitting any sort
of exponentiation operator. C is not alone among languages in
doing this. Exponentiation is not the most prevalent of operators,
and is normally a subroutine in almost any language.

jacob navia wrote:
> [...]
> The purported exponentiation operator would have to be dyadic:
>
> 10 ^^ 3 --> 1000
>
> This would be feasible but the problem is inserting it in
> the precedence rules of C
>
> 10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???
>
> There are enomous problems with this approach, and for exponentiation
> I think it is just not worth the effort, unless we devise a general
> rule about adding new operators.

The "enomous [sic] problems" you mention had already been
solved when I began programming thirty-nine years ago. In
FORTRAN the `**' operator means exponentiation, and binds more
tightly than multiplication and division but less tightly than
parentheses and function calls. Expressions in FORTRAN are
structurally similar to those in C, and I'm confident a similar
precedence rule could be worked out easily.

But perhaps I'm abusing you needlessly and owe an apology;
you may be referring to the problems of adding user-defined
operators on the fly and at the programmer's whim. Those would
indeed be "enomous" problems! But perhaps we need not generalize
from a question about one obviously missing operator to the issue
of accommodating every conceivable (and ill-conceived) operator
a programmer's diseased mind can imagine. If you want APL, you
know where to find it. ;-)

In article <>
Eric Sosman <> wrote:
>... In FORTRAN the `**' operator means exponentiation, and binds more
>tightly than multiplication and division but less tightly than
>parentheses and function calls.

(And, if I recall correctly, is non-associative as well: A**B**C
is an error.)
> But perhaps I'm abusing you needlessly and owe an apology;
>you may be referring to the problems of adding user-defined
>operators on the fly and at the programmer's whim. Those would
>indeed be "enomous" problems!

Although these, too, have been solved (for some definition of
"solved" anyway) in other languages.
>But perhaps we need not generalize
>from a question about one obviously missing operator to the issue
>of accommodating every conceivable (and ill-conceived) operator
>a programmer's diseased mind can imagine. If you want APL, you
>know where to find it. ;-)

It, I think, is worth noting that APL -- a language designed by a
mathematician -- avoids the whole operator binding ("precedence
and associativity") problem by defining it away. Operators are
handled strictly in textual order, right to left. For instance,

Also, as I think someone else mentioned in this thread, APL provides
sort operators (grade-up, which sorts into ascending order, and
grade-down, which sorts into descending order).

If you write pure functions (or ignore possible control flow and
"global variable" problems due to errors), the difference between
"function" and "operator" is mere syntax. A good programmer should
be comfortable with all three of these:

This does not mean you cannot *prefer* one form over another (even
Lisp programmers write fancy macros), but there is no significant
difference. The spelling does not matter as much as the semantics.
Note that, on some machines (V7-and-earlier SPARC for instance):

int i, j, result;
...
result = i * j;

compiles to a subroutine call ("call .mul"), rather than a multiply
instruction, and:

size_t size;
size = sizeof(i);

compiles to a simple assignment, despite "sizeof(i)"'s resemblance
to a call to a function.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Guest

jacob navia wrote:
> a écrit :
> >
> > The OP I was replying to did not mention anything about exponentiation
> > operator. He just said operators are linked to what is available in
> > assembly.
> >
>
> God you are totally confused!!!
>
> 1) The OP (see the TITLE of this thread) asked why there isn't
> an exponentiation operator in C.
> 2) He was redirected to the FAQ that says that there isn't since there
> is no hardware support for that operator. It is the FAQ that says
> it, not the OP.
> 3) The OP critized the FAQ, saying (rightly so in my opinion) that
> C is not tied to hardware.
>
> You mess completely!
>

OK, here's the OP's complete post:
> That is not an answer, just an excuse. It links language operators to
> presence or absence of hardware. C is not assembly language.
> Translation is the job of something called a compiler.

Apart from the title, where is the mention of the FAQ? Where is the
quote of the reply the OP was critisizing?

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!