On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
> Hi everyone (=
>
> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>
> The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it.
>
>
> The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6)
>
> --
> Dietrich

In the future I'd recommend to delay announcing DIP until it get to the point of being merged into the queue (I'd do it myself at that point). Right now there are quite some boring technical details to be fleshed out before it becomes a complete proposal - asking for community feedback is likely to be time-inefficient.

And sorry for some of the inadequate responses you got here. D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored. In the end only thing that should matter is a good technical document to be merged into the queue.

On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
> Hi everyone (=
>
> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>
> The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it.
>
>
> The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6)
>
> --
> Dietrich

Oh no, another consequence of the wilzaback. He has announced everywhere that it's possible to make DIPs on github...what a surpise to see that. So...Dietrich, do you use D a bit at least ? Or do you come because you read r/programming or hackernews ?

On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
> Hi everyone (=
>
> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>
> The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it.
>
>
> The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6)
>
> --
> Dietrich

Would something like Clojure's recur and trampoline do what you want?

http://www.clojure.org/about/functional_programming#_recursive_looping

A number of Common Lisp programmers like to use those functions because TCO is then guaranteed, and unlike Common Lisp where you don't know for sure what will happen, it is explicit.

On Monday, 11 July 2016 at 12:29:33 UTC, Basile B. wrote:
> On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
>> Hi everyone (=
>>
>> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>>
>> The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it.
>>
>>
>> The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6)
>>
>> --
>> Dietrich
>
> Oh no, another consequence of the wilzaback. He has announced everywhere that it's possible to make DIPs on github...what a surpise to see that.

I am happy to learn why posting the announcement to reddit was a mistake. The reception was entirely positive and as Dicebot pointed out, having a formal process about language changes is a must-have criteria for many companies and thus a blocker for further adaption of D. On the contrary I think it was a wake-up call for people being frustrated with some deficits of D.
Moreover I am not sure why you keep misspelling my lastname. If eight letter are to difficult to memorize for you, you might want to stop complaining about deficit's of other people.

> So...Dietrich, do you use D a bit at least ? Or do you come because you read r/programming or hackernews ?

Did you take the time to look at the DIP before making your offenses?
Dietrich has already published D modules on Github which you would have seen if you be generally interested and not trolling.

As other people already have stated the DIP is not trivial and the only thing that was sub-optimal was it's announcement in News before being fleshed out, but to be fair Dietrich just followed the new DIP process protocol, which still needs fine-tuning in its details. However without motivated alpha warriors like Dietrich such fine-tuning can't happen, so you should be more thankful to him.

@Dietrich: Don't let yourself distract by trolls. Keep on improving your DIP and making it great & convincing!

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:
>>
>>
>> http://forum.dlang.org/post/lqp6pu$1kkv$1@digitalmars.com
>
> 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.

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:
>>>
>>>
>>> http://forum.dlang.org/post/lqp6pu$1kkv$1@digitalmars.com
>>
>> 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.


I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me.
The complement, @unboundedStack, might be better, as it would explicitly mark the functions that might cause stack overflows so they drag required attention and would also force the compiler to do TCO where required.
Focusing on  stack size, rather than directly on TCO might even allow to guarantee that many D programs do not crash due to a stack overflow, which is a nice guarantee that not many languages, allow to express.
I'd like thoughts on this change of perspective.


BTW, I'm glad that discussion has arised, as it can only make the propossal better.

On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
> I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me.

Just keep in mind that a @tco constraint is much easier to implement than @boundedStack. I don't do tail calls much, but I think you have the right idea for a system level language: specify the constraints you want to hold rather than explicitly laying out everything manually. That's what I expect from a modern system level language.

I have previously argued in favour of something similar like @boundedStack, but there is quite a bit of resistance against  (and lack of interest in) solid static analysis in the D community.

You probably will save yourself some trouble by reading one of the numerous threads touching on stack handling in D. Here is one:

http://forum.dlang.org/post/logpgo$2k1d$1@digitalmars.com

On Monday, 11 July 2016 at 15:48:08 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
>> I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as @boundedStack is something that bothers me.
>
> Just keep in mind that a @tco constraint is much easier to implement than @boundedStack. I don't do tail calls much, but I think you have the right idea for a system level language: specify the constraints you want to hold rather than explicitly laying out everything manually. That's what I expect from a modern system level language.
>
> I have previously argued in favour of something similar like @boundedStack, but there is quite a bit of resistance against  (and lack of interest in) solid static analysis in the D community.
>
> You probably will save yourself some trouble by reading one of the numerous threads touching on stack handling in D. Here is one:
>
> http://forum.dlang.org/post/logpgo$2k1d$1@digitalmars.com


Previous discussion seems to favour @unboundedStack as it can become a requirement to go beyond the stack-size-safe operations effectibly tracking where stack overflow may happen and encourage detailed review of those functions.

Walter's concern is that a great amount of the D runtime library would make this unpractical. Maybe another attribute to promise bounded stack without a proof might be required to make the idea viable.
I really think that this kinds of proofs are somewhat natural in D, as it follows ideas like contracts, and safe/trusted attributes.

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:
>>>>
>>>>
>>>> http://forum.dlang.org/post/lqp6pu$1kkv$1@digitalmars.com
>>>
>>> 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.

On Monday, 11 July 2016 at 16:18:47 UTC, Dietrich Daroch wrote:
> Previous discussion seems to favour @unboundedStack as it can become a requirement to go beyond the stack-size-safe operations effectibly tracking where stack overflow may happen and encourage detailed review of those functions.

I would favour it, but I am not a DMD developer ;-)

> Walter's concern is that a great amount of the D runtime library would make this unpractical. Maybe another attribute to promise bounded stack without a proof might be required to make the idea viable.
> I really think that this kinds of proofs are somewhat natural in D, as it follows ideas like contracts, and safe/trusted attributes.

Yes. Although keep in mind that DMD does not have a shared intermediate representation, so each backend probably might have to implement it over a low level SSA which may or may not be suitable. So, if they have to implement 3 different versions of it for DMD, LDC and GDC what are then the chances that this will pass?

Contrast this to a language like Whiley which has an intermediate representation geared towards theorem-proving.

Would D benefit from a shared intermediate representation suitable for static analysis? Sure. But you probably need more than a single feature-request to get there.