Re: Backtrace with 'trail' and 'up' (64-bit)
On Fri, Nov 16, 2012 at 10:24:44PM +0100, Axel Svensson wrote: Perhaps the interpreter could push the call to the global variable? That way, the global variable would hold a list of the calls currently on stack. ... Would it be a contained change of the C code, or spread out everywhere? Also, would this imply severe performance costs? I feel so. The only reason why PicoLisp didn't support a more extensive backtrace (until now) was the cost involved, compared to its relatively unimportant gain. In normal runtime operation, the backtrace information isn't needed, and each and every call to a Lisp function triggers otherwise unnecessary stack operations. But these operations involve just a push and a pop. Using a list instead of the stack would explode that cost, causing periodic runs of the garbage collector. This is surely not worth the gain. Then it would be much more efficient to extend the C stack binding structures. Still I don't think it is worth the effort. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Backtrace with 'trail' and 'up' (64-bit)
for the 64-bit version at last we have a long-missed feature: A substantial backtrace mechanism. Great! - a new function 'trail', which returns the complete backtrace as a list. Staying with the hype-terminology, we may call this a first class backtrace ... OK, just kidding, no big thing :) If the first class backtrace would be modifiable programmatically, it would allow for a whole new range of control structures, in some aspect possibly going beyond what's implementable by call/cc. That would be a big thing. - an extension to 'up' which returns the current expressions (or the nth expression if a numeric argument is passed) Note that 'up' now allows to implement things which were until now only possible in FSUBRs (i.e. on assembly level), because the CAR of the expression (the function or method) are not passed to EXPRs or FEXPRs. I proposed this feature on Jan 26, 2012, so at least for me this is also a long-missed feature. This will among other things allow redefinition of the message passing (or method execution) function, and a 'defmacro' that is cleaner than my example from a week ago. Question: How hard would it be to extend 'up' the same way in pil32? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Backtrace with 'trail' and 'up' (64-bit)
Hi all, for the 64-bit version at last we have a long-missed feature: A substantial backtrace mechanism. Until now, the runtime stack didn't store enough information to make this possible. Now there is - a new function 'trail', which returns the complete backtrace as a list. Staying with the hype-terminology, we may call this a first class backtrace ... OK, just kidding, no big thing :) - an extension to 'up' which returns the current expressions (or the nth expression if a numeric argument is passed) Note that 'up' now allows to implement things which were until now only possible in FSUBRs (i.e. on assembly level), because the CAR of the expression (the function or method) are not passed to EXPRs or FEXPRs. It is trivial to pretty-print the 'trail' list (for an example, see the reference), and store such a mechanism in e.g. '*Err'. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
