opPow, opDollar

[Andrei Alexandrescu]

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?

In order for everyone to air an informed opinion, a related question is: 
will loop fusion be allowed with function calls?

Loop fusion currently only works with operators, and adding ^^ would allow:

a[] = b[] ^^ 3;

But with pow you can't do that:

a[] = pow(b[], 3);


Andrei

P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for 
automatic loop fusion that would tilt my opinion in disfavor of ^^, and 
if not, it would tilt my opinion in favor of ^^.