On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
On Monday, 11 July 2016 at 14:36:22 UTC, Andrew Godfrey wrote:
On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote:
On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote:
Btw here's a thread from 2014 that touches on the idea of a "tailrec" annotation. At the time, Walter viewed the optimization as the compiler's business and not something he'd elevate to a language feature:


I find it odd that something like tail recursions that actually makes certain things possible that wouldn't be otherwise is seen as only an optimization, when things like inlining which really is only an optimization is seen as important enough to have a pragma.

I agree. Maybe Walter has reconsidered since then. He did also say, though, that he thinks D supports enough different programming styles already.

Would you be satisfied with a pragma? I'd intuited (but could be wrong) that the focus of your proposal was to get a compiler error if someone makes a change to a recursive function, that causes the compiler to be unable to apply the TCO optimization. If that is your focus, it has heavy implications and the feature can't just be a pragma.

Pragma does not seem enough, at least current pragmas can be ignored by the compilers (http://dlang.org/spec/pragma.html#predefined-pragmas), but if it's required for tco it can make it.

Ola addressed the "bounded stack" idea. TCO is hard enough, I'll stick to that:

When people say "it should be a pragma", I think they particularly are saying, "it should be ignorable by the compiler". That is a different feature. I think you need to lay out *exactly* what you want it to do - because doing so will raise the questions that need to be answered.

I'll take a stab, but this may not be the direction you're pushing in. This is a straw man to illustrate the difficulties I see:

* It must not be ignorable by the compiler.

* It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO.

One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable.

If you additionally want to make it portable, then you need to specify the conditions under which *any valid compiler* must be able to apply the TCO. Also, you need to make the feature generate a compiler error if it is used under other conditions. This all seems rather difficult; at any rate, I don't see any hints in the current proposal about what these rules would be. (Even a rule as simple as "the call must be to the same function" could be tricky.)

P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated.

Reply via email to