Re: Some questions about the Pico Lisp Interpreter
On Tue, Oct 21, 2008 at 12:28:42AM +0100, Tomas Hlavaty wrote: > http://logand.com/picoWiki/trampoline so feel free to comment on it. Beautiful! -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Some questions about the Pico Lisp Interpreter
Hi all, >> 1) Does the Interpretor do any kind of tail call optimisation, I > > No, not at all. > > As far as I can see, this is not easy to implement in an efficient way. > The interpreter would have to detect tail recursion at runtime, which > takes much more than time than simply executing the call/return. Each > function must inspect itself, just to find those (extremely few) cases > of tail recursion. > > Above that, it would violate some basic principles of picoLisp. Trying > to be clever behind the scenes, doing things the programmer did not > explicitly specify, losing simplicity and what-you-see-is-what-you-get. > > Tail recursion is nothing more than a simple loop. So we might better > write directly what we mean, using 'while', 'for', 'loop' etc. there is a way around not having tail call optimisation even though it is not very intuitive. I just put some code on http://logand.com/picoWiki/trampoline so feel free to comment on it. Thanks, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Some questions about the Pico Lisp Interpreter
Yes, you answered the questions I asked, and gave the answers I suspected. I think part of the point with Direct Threading is that you need to explicitly tell gcc to enable it when compiling the VM, and write some switch statements in a certain way. Haven't got my head around the code yet. It makes quite heavy use of Macros and not many comments. 2008/6/6 Alexander Burger <[EMAIL PROTECTED]>: > Hi Konrad, > >> 1) Does the Interpretor do any kind of tail call optimisation, I > > No, not at all. > > As far as I can see, this is not easy to implement in an efficient way. > The interpreter would have to detect tail recursion at runtime, which > takes much more than time than simply executing the call/return. Each > function must inspect itself, just to find those (extremely few) cases > of tail recursion. > > Above that, it would violate some basic principles of picoLisp. Trying > to be clever behind the scenes, doing things the programmer did not > explicitly specify, losing simplicity and what-you-see-is-what-you-get. > > Tail recursion is nothing more than a simple loop. So we might better > write directly what we mean, using 'while', 'for', 'loop' etc. > > >> 2) With the release of SquirlFish there a lot of discussion about > > You mean SquirrelFish? Actually, I've never heard about it before... > >> Direct threading and register based VM's is any of that potentially >> relevent to Pico Lisp. > > In that sense, picoLisp is also a threaded interpreter. Probably much > faster than a bytecode interpreter, though, as the elements in a thread > perform more high-level operations (e.g. complete list manipulations) > than simple byte codes (which typically do more basic operations). > > Did I get your question right? > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:[EMAIL PROTECTED] > -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Some questions about the Pico Lisp Interpreter
Hi Konrad, > 1) Does the Interpretor do any kind of tail call optimisation, I No, not at all. As far as I can see, this is not easy to implement in an efficient way. The interpreter would have to detect tail recursion at runtime, which takes much more than time than simply executing the call/return. Each function must inspect itself, just to find those (extremely few) cases of tail recursion. Above that, it would violate some basic principles of picoLisp. Trying to be clever behind the scenes, doing things the programmer did not explicitly specify, losing simplicity and what-you-see-is-what-you-get. Tail recursion is nothing more than a simple loop. So we might better write directly what we mean, using 'while', 'for', 'loop' etc. > 2) With the release of SquirlFish there a lot of discussion about You mean SquirrelFish? Actually, I've never heard about it before... > Direct threading and register based VM's is any of that potentially > relevent to Pico Lisp. In that sense, picoLisp is also a threaded interpreter. Probably much faster than a bytecode interpreter, though, as the elements in a thread perform more high-level operations (e.g. complete list manipulations) than simple byte codes (which typically do more basic operations). Did I get your question right? Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
