On 2016-12-04 15:41, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org >> From: Clément Pit--Claudel >> Date: Sun, 4 Dec 2016 14:27:59 -0500 >> >>>> The C implementation of backtrace-frame seems to be linear in the index of the requested frame, so a Lisp implementation of backtrace would be quadratic in the depth of the stack trace. Would a new function backtrace-frames that returns all frames at once be acceptable? >>> >>> But such a backtrace-frames function would have to be implemented in >>> C, right? And you wanted to move the implementation of "backtrace" to >>> Lisp, AFAIU. So it sounds like we will be replacing one C primitive >>> with another, or did I miss something? >> >> I think you're correct. It would seem good to have the flexible primitive backtrace-frames available, and it must be in C; then we can move backtrace itself to lisp. >> >> The idea is that enumerating frames must be done in C, but printing them doesn't need to be done there. > > So would it perhaps make sense to rename 'backtrace' into something > like 'backtrace--internal', and make it accept one more argument, the > function to apply to each frame, which is now hard-coded as 'prin1'? > Would that allow you to implement 'backtrace' in Lisp and also > implement whatever application you had in mind, by calling > 'backtrace--internal' passing it your own function instead of 'prin1'? Quite possibly! Are you worried about the cost of allocating a list containing all frames? IN any case, that would be consistent with the style of maphash, for example. And a variant of backtrace taking a callback would definitely make backtrace-frames easy to implement on the lisp side :) There's no big hurry on this, anyway: it's just that we recently added a neat option to backtrace, and there were mentions of making the backtrace buffer more useful in various ways, too. Clément.