DIP: Tail call optimization

Dietrich Daroch via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Mon Jul 11 19:55:44 PDT 2016


On Tuesday, 12 July 2016 at 01:42:13 UTC, Andrew Godfrey wrote:
> On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote:
>> On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:
>>> [...]
>>>
>>> * 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.
>>
>> I think that noticing problems while porting it it's better 
>> than having it crash unexpectedly as it would currently happen.
>
> Sure, non-portability that causes a guaranteed compiler error, 
> is better than other kinds of non-portability. But it's still 
> non-portable. That is distasteful enough that you probably need 
> to make a more compelling case; factorial is a "toy" function 
> that's not enough - on its own - to justify adding a feature.
>
> I personally feel like it is a neat idea, and it may enable 
> some programming styles that I'm not familiar with so I can't 
> say they definitively they have no value. The reason I'm not 
> familiar with them could be that I've never had this feature in 
> a language I've used a lot. So there could be something here, 
> BUT I also think it would need to be a portable feature, which 
> implies much more rigorous rules that all compilers would have 
> to follow. (They could still do TCO for more complicated 
> situations, but those wouldn't interact with this feature; to 
> make use of this feature you'd have to conform to the more 
> rigorous rules).

I've thought about using pragmas and they would allow for an 
easier implementation if ignored pragmas raise warnings (and 
errors with strict flags) when a pragma was ignored.

Under that setup, people who need the errors can enable the 
flags, while people who doesn't care about this can just 
ignore/disable the warnings and keep their programs without need 
for rewrite.

Also, using pragmas requires no change on the grammar, nor adding 
new attributes that most people really dislike (I still don't get 
why, probably the text editors should take care to make them less 
distracting or even hiding them).


More information about the Digitalmars-d-announce mailing list