opPow, opDollar

[dsimcha]

== Quote from Robert Jacques (sandford at jhu.edu)'s article
> On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ <kennytm at gmail.com> wrote:
> > On Nov 7, 09 18:43, Don wrote:
> >> Walter Bright wrote:
> >>> Don wrote:
> >>>> A little while ago I said I'd create a patch for ^^ as an
> >>>> exponentiation. A couple of people had requested that I make a post
> >>>> to the ng so they'd know when it happens. Here it is.
> >>>>
> >>>> This is opPow(), x ^^ y
> >>>>
> >>>> http://d.puremagic.com/issues/show_bug.cgi?id=3481
> >>>
> >>> I don't understand the rationale for an exponentiation operator. It
> >>> isn't optimization, because pow() could become an intrinsic that the
> >>> compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
> >>
> >> It's primarily about syntax sugar: pow() is so ugly. In practice, the
> >> most important case is squaring, which is an extremely common operation.
> >> pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
> >> that noone uses it: you always change it to xxx * xxx. But then, xxx
> >> gets evaluated twice.
> >>
> >
> > 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.
> >
> >> Yes, ^^ hasn't been used for exponentiation before. Fortran used **
> >> because it had such a limited character set, but it's not really a
> >> natural choice; the more mathematically-oriented languages use ^.
> >> Obviously C-family languages don't have that possibility.
> >>
> >
> Well, since D supports unicode, you can always define: alias
> reduce!("a+b") ∑;

On a more serious note, I'm starting to think that Phobos needs a specific
convenience function for sum, not because reduce!"a + b" is ugly (it isn't) or too
much typing (it isn't) but because reduce!"a + b" doesn't work on zero-length
ranges.  Obviously, the sum of a zero-length range is zero, but reduce is too
general to know this.  This bit me a few times in some code I was debugging last
week.  Rather than inserting extra checks or passing an explicit start value in
(which requires you to remember the element type of your range; is it an int or a
float?), I simply handwrote a sum function and replaced all my reduce!"a + b" with
sum.