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

[Don]

Andrei Alexandrescu wrote:
> 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.

In BLADE, what I did was provide an error message as an alternate return 
value from the inner templates. This is then passed down through the 
higher-level functions. At the user level, instead of mixing in code to 
invoke the function, it mixes in a static assert(0, errormsg) instead. 
Then there is an error ONLY on the line of user code. You can only 
achieve these perfect error messages if you have a mixin statement in 
the user code, unfortunately.

Of course, using return values to indicate errors is so 1970's. 
Compile-time assert exception catching would be so much better...
But a simple change to the static assert handling would get us most of 
the way there.

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

There's a few cases in bugzilla about mismatched brackets. Some of them 
cause segfaults.

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