From ... From: Erik Naggum Subject: Re: General Lisp questions... Date: 1998/05/01 Message-ID: <3103054423888634@naggum.no>#1/1 X-Deja-AN: 349459210 References: <6id1qg$dee@senator-bedfellow.MIT.EDU> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * David Bakhash | here are some things that I couldn't gather from Steele's book: you'll doubtless get numerous answers, so I'll try a shot, too... | 1) temporarily, let's forget about macrolet. Suppose I have a function | in which I'd like to define a local function (with `flet' or with | `labels'). And also, suppose that I want that function to be inlined | inside the main function. So it looks like this: the first question that occurs to me is "why do you want to inline it?" the second question is "why do you think you have tell the compiler so explicitly?" | so I want to know where the declaration *should* go so that the function | is inlined. evaluate (EXPLAIN-COMPILER-SETTINGS), as suggested when you start Allegro and in the User Guide. the optimization setting affecting whether to try and _automatically_ inline function calls is ;; COMPILER:GENERATE-INLINE-CALL-TESTS-SWITCH T this is actually a variable, whose values is #= SPACE @ #x2683e2> indicating that if your optimization declarations satisfy this condition, the compiler will try to inline calls. you can learn more about this: (DECLAIM (:EXPLAIN :CALLS)) will tell you about each call the compiler has to generate code for. (note: it quickly gets verbose.) | 2) can someone explain the difference between `labels' and `flet' ? I | can't understand it :-( the scope of an FLET function binding is the _body_ of the FLET form. the scope of a LABELS function binding is the _whole_ LABELS form. | 3) in Allegro CL, after you've verified that your program is really | clean and bug-free, you compile it with all the best compiler | options. then you get a .fasl file which you can load at an time, | and you can run a program that way. But is that the fastest way? is | there a way to turn your program into a binary executable that will | run even faster? when finalizing some software for packaging as a product, you build an image that is essentially a stand-alone program just like the Allegro CL image is. you will replace the top-level loop with your own, and will probably not have the editor interface and all that included. building such images can save you a lot of size, but probably not much in speed. #:Erik -- Support organized crime: use Microsoft products!