On 22 February 2010 22:20, Mark Evenson evenson@panix.com wrote:
First of all, an excellent explanation for the implementation choices. Thanks!
I am a "if the function doesn't fit into one 80x25 Emacs buffer it should be split" kinda guy", but the ABCL codebase violates that maxim at so many points (q.v. compiler-pass2.lisp) that I don't try to
The violation is cruft in our codebase, and is something we are semi-actively gettind rid of. I've been trying to shorten things wherever I touch, Closure.java being the prime example of such work. compiler-pass2 is actually another example. Note that both pass2 and Closure still have long functions in places, but we have cut a lot of that cruft into better abstractions whenever time has allowed.
religously follow that principle here. I'd be happy to do such splitting, but would have thought that you of all people would have jumped on my back about the penalty for a further push to the stack. My
Oh, not at all - I expect the compiler to inline the calls to the (hopefully forthcoming) two helper functions. I prefer readability to micro-optimizations any given day. :) I prefer readability to even _real_ optimizations.
splitting is worth it. But for functions like LIST-DIRECTORY, we should keep it all in one method call for efficiency. For what its worth, I
That would sound like a premature optimization to me. Having LIST-DIRECTORY as
if (jar) { listJar(); } else { listDir(); }
should be just fine, if the separate helper functions are private. As I said, I expect the compiler to inline such calls.