Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!mcnc!decvax!decwrl!sun!amdcad!ames!necntc!linus!philabs!micomvax!ray
From: ray@micomvax.UUCP (Ray Dunn)
Newsgroups: comp.lang.c
Subject: Re: Power operator?
Message-ID: <882@micomvax.UUCP>
Date: 13 Jan 88 22:35:43 GMT
References: <47000029@uxe.cso.uiuc.edu> <10063@mimsy.UUCP> <646@l.cc.purdue.edu>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Information Systems Ltd., St. Laurent - Que., Canada
Lines: 42

In article <646@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>> [ description of power function rather than power operator ]
>
>I think everyone should consider this unsatisfactory. 
>
>One reason is that requiring the writing of a subroutine call is that
>this requires people to use that notation instead of writing 
>
>	x = y ** z	or x = y ! z.
>
>Similar thinking would require one to write x = sub(y, z) instead of
>x = y - z.  This is a major design flaw in all HLLs which I know.
>

Not all.  POP-2 (An AI language from Edinburgh Univ) allows (simplified):

operator <precedence> <operator name> ( <parameter list> )

as an option of

<function name> ( <parameter list> )

to allow new operators to be defined.  

This together with the fact that you could define identifier names as
combinations of signs ( e.g. *+*), was a very useful feature.


>Another is that there are _several_ power functions;

This is of course a contradiction to your statement above!  Because there
are several different versions is a very good reason to NOT have a power
function built into the language as a standard operator.  Which one should
it be!

No.  Lets add the ability to define new infix operators in C instead (:-)!

(Actually even the ability to define infixed pre-processor macros would
 add something ... just dreaming, not thinking!)

Ray Dunn.  ..philabs!micomvax!ray