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.
