opPow, opDollar

[Robert Jacques]

On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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 ^^.

Actually, if you look at Matlab, a[] = b[] ^^ 3; is well defined.

Also, given
real foo(real r) { return r*r; }
providing syntactic sugar for
a[] = foo(b[], 3); => a[] = map!foo(b[],3);
might be nice.