3 ms·

Handle it the same way as a return I think. Evaluate the temporaries, move / copy into the right place, run destructors, jump? Copy elision might be hard to pul

by im3w1l 6y ago

Handle it the same way as a return I think. Evaluate the temporaries, move / copy into the right place, run destructors, jump? Copy elision might be hard to pull off I suppose. Edit: Hmm there is an issue in handling the stack space I suppose, because there are live old parameter objects already in the place you want to put your new parameters. An ugly but possibly workable way of handling it is to have two areas for parameters. One used for odd recursion depths and another used for even ones.

yakubin 6y ago
Then you changed the semantics of the code. Now a program that e.g. prints a message in its destructor, which gives this output: Message 1 Message 2 Message 3 Will give this output: Message 3 Message 2 Message 1 Your odd/even fix also won't work, because a function may push an argument to a list, and pass the list in another argument, making the original temporary accessible from any recursion level. A call to a destructor is a normal call. If you need to call destructors, then it means your tail call is a call to a destructor and not what you're seeing in the code. It's a fundamental semantical problem. You can't have "make the last call in this function be an implicit call to some function" and "make the last call be the explicit call to this other function" at the same time.
- syrrim 6y ago
  If it's a different syntax, then you can expect people to know that it's semantically different. That's the whole point of using a different syntax, I think.
  - yakubin 6y ago
    I thought that the point of this syntax was to make the compiler warn you when, what you think is a tail call, in fact isn't one, and demand that the compiler optimizes it; not introduce a completely new control flow construct.
- im3w1l 6y ago
  > push an argument to a list, and pass the list in another argument, making the original temporary accessible from any recursion level. Either you push a copy of the object to the list, in which case it is fine. Or you push a pointer/reference to the object, in which case it becomes dangling.
  - yakubin 6y ago
    Exactly. It wouldn't be dangling without the transformation you proposed.

by im3w1l 6y ago

yakubin 6y ago

Then you changed the semantics of the code. Now a program that e.g. prints a message in its destructor, which gives this output: Message 1 Message 2 Message 3 Will give this output: Message 3 Message 2 Message 1 Your odd/even fix also won't work, because a function may push an argument to a list, and pass the list in another argument, making the original temporary accessible from any recursion level. A call to a destructor is a normal call. If you need to call destructors, then it means your tail call is a call to a destructor and not what you're seeing in the code. It's a fundamental semantical problem. You can't have "make the last call in this function be an implicit call to some function" and "make the last call be the explicit call to this other function" at the same time.

syrrim 6y ago
If it's a different syntax, then you can expect people to know that it's semantically different. That's the whole point of using a different syntax, I think.
- yakubin 6y ago
  I thought that the point of this syntax was to make the compiler warn you when, what you think is a tail call, in fact isn't one, and demand that the compiler optimizes it; not introduce a completely new control flow construct.
im3w1l 6y ago
> push an argument to a list, and pass the list in another argument, making the original temporary accessible from any recursion level. Either you push a copy of the object to the list, in which case it is fine. Or you push a pointer/reference to the object, in which case it becomes dangling.
- yakubin 6y ago
  Exactly. It wouldn't be dangling without the transformation you proposed.