ch-ch-update: series, closed-form series, and strides

[Andrei Alexandrescu]

Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
> Nice! :-)
> 
> I showed the Fibonacci example to a friend of mine and he said "that 
> string stuff scares me a little". The same happens to me.
> 
> What kind of error do you get if you mistype something in that string 
> expression?

Let me see. Say I made the mistake of using "b":

auto fib = series!("a[n-1] + b[n]")(1, 1);

std/functional.d(185): static assert  "Bad binary function: a[n] + 
b[n-1] for types Cycle!(int[]) and uint. You need to use an expression 
using symbols a and n."

Heck, that's even better than compiler's own error messages. 
Unfortunately, the line where the actual instantiation was invoked is 
not shown. I think that's entirely doable though.

Say I forget to close a bracket:

auto fib = series!("a[n] + a[n-1")(1, 1);

The compiler penalizes that by never finishing compiling. That's a bug.

> Can you pass a delegate instead of a string? Something like:
> 
> auto fib = series!((Range a, int n) { return a[n-1] + a[n]; })(1, 1);

Not right now because delegate literals can't be templates. But I talked 
about that with Walter and he'll make it work.

> That seems much safe and will probably give a reasonable error if you 
> mistype something. I know, it's longer than the previous one. But it 
> would be nice if D had the following rule (or something similar to it): 
> "if a delegate doesn't return, the last statement is converted to a 
> return" (and you can ommit the semicolon). So now you can write:
> 
> auto fib = series!((Range a, int n) { a[n-1] + a[n] })(1, 1);
> 
> And if you could just ommit the types in the delegate...
> 
> auto fib = series!((a, n) { a[n-1] + a[n] })(1, 1);
> 
> Still a little longer than the original, but you get all the benefits of 
> not using a string.

Incidentally, I was talking to Walter about the shorter delegate form 
and he convinced me that it's too risky to have semantics depend on only 
one semicolon. But omitting the type names from a literal delegate is 
something we're mulling over.

The truth is, the reasons against using strings for short functions are 
shrinking. I mean, you don't want to not use strings just to not use 
strings, right? I hope I convinced you that strings are unbeatable for 
short functions that don't need access to local state, their efficiency 
is exemplary, and their error messages are not half bad.


Andrei