opPow, opDollar

[Don]

Walter Bright wrote:
> KennyTM~ wrote:
>> Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's 
>> primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In 
>> practice, the most important case is the sum from 1 to n, which is an 
>> extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly 
>> ugly for something so fundamental. It's so ugly that noone uses it: 
>> you always change it to n*(n+1)/2. But then, n gets evaluated twice.
> 
> As amply illustrated, one can make this argument pro and con about any 
> builtin operator. The waterfront real estate of builtin operators is 
> extremely limited, so we need to be very parsimonious in allocating it. 
> Candidates for builtin operators need to have a very high bar.
> 
> The question is, does ^^ clear that bar or not?

Yes, that's exactly the question. From an old post by Bill Baxter, 
here's a list of languages with an exponentiation operator:

# x ↑ y:  Algol,  Commodore BASIC
# x ^ y: BASIC, J, Matlab, R, Microsoft Excel, TeX (and its
derivatives), Haskell (for non-negative integer exponents), and most 
computer algebra systems
# x ^^ y: Haskell (for integer exponents)
# x ** y: Ada, Bash, Fortran, FoxPro, Perl, Python, Ruby, SAS, ABAP,
Haskell (for floating-point exponents), Turing
# x * y: APL

None of the languages derived from C and Pascal include exponentiation. 
(I suspect that if it had been included in C, there would be very few 
languages without it: since Algol and Fortran both had it).

Note that D currently has <>, <>=, !<>, !<>=, !>=, !<=, !>, !<, which 
would have to be lower down the list than exponentiation. As one of the 
very few users who actually uses them, I'd happily sacrifice them in 
exchange for exponentiation.

And BTW, there is another issue with pow(), relating to implicit conversion.
Given an int x, x * x is also an int. But pow(x, 2) is a double, so they 
are not at all equivalent. (and pow() definitely needs to return float 
for general  exponents). The recently introduced integer range tracking 
for implicit conversions could fix this nicely.