I understand the rationale but explicit TOC is, IMHO, nasty. How about a VM-wide switch instead? Then I've made it explicit that I accept the consequences of the optimisation. I can then develop on the small without TOC and execute on the large with it. It also means the code is technically portable to other implementations.
Of course were an explicit call required, I'd probably use it anyway and implement it on other platforms as a stub :/ On Dec 25, 3:21 am, evanphx <[email protected]> wrote: > Hi Simon, > > On Dec 24, 2:19 am, Simon Harris <[email protected]> wrote: > > > Does rubinius perform any kind of TOC or are there any plans? > > We currently do not do any tail call optimizations. One big reason is > that tail call optimizations typically destroy proper backtrace > information. I consider that an unacceptable side-effect for any kind > of automatic tail call detection. > > I might consider some explicit tail call tagging, where the user > understands that using it means confusing backtraces. > > A simple syntax like: > > return Rubinius.tailcall obj.method(....) > > would maybe be acceptable. > > - Evan -- --- !ruby/object:MailingList name: rubinius-dev view: http://groups.google.com/group/rubinius-dev?hl=en post: [email protected] unsubscribe: [email protected]
