opPow, opDollar

[Chad J]

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

Does ^^ really even need to be a builtin operator to be overloadable?

I remember a discussion where we considered adding abstract operators
that have no inherent meaning in the language (not builtins), but are
overloadable to allow better exploitation of infix notation.  Things
like (+), (*), (%),  (&), [+], [*], [%], and so on.