here are some things that I couldn't gather from Steele's book:

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:

(defun test ()
  (declaim (inline f)) ;; #### does the declaim line belong here??? ####
  (flet ((f (x)
            (declaim (inline f) ;; #### or does it belong here??? ####
            (* x x))))
    (blah...)
    (+ (f 2) (f 3))))

so I want to know where the declaration *should* go so that the function
is inlined.

2) can someone explain the difference between `labels' and `flet' ?  I
   can't understand it :-(

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?

In article <6id1qg$...@senator-bedfellow.MIT.EDU>,
David Bakhash  <ca...@mit.edu> wrote:

    A declare at the beginning of a body effects that body. So to inline
    into the body of test you'd wish to say it here.
    Not that Lisp really "has to" do it.  The environment can ignore
    you at its discretion.

    However,   F hasn't been defined yet.....  so this probably isn't a
    good place to put this declaration...

          Again DECLARE.   DECLAIM/PROCLAIM to effect the global environment
          (and generally used outside the body of functions et. al. ).
          DECLARE to effect the body of a function/let/etc.
          The declaration would only effect the body of F. Not where F is
          utilized.

  The closest body to the place where you wish to inline is that of the
  FLET.  That would be where you would want to put the inline declaration.

    (flet ( (f ()
                ... )  )
      (declare (inline f ))
      ..... )

  As mentioned above... the environment doesn't "have to" inline.

  However, .....

      (flet ( ... fcn defs .... )  
          ... flet's body.. )

    Whereas the functions defined by the beginning of a LABELS can be
    seen both in the body and in definitions part...

    Examples:

         (flet  ( (f (x)  (g (1+ x )) )
                     (g (x)  (* x 10)) )

               (f 10))

     Or even

         (flet  ( (f (x)  (cond ((= x 0 ) 'all-done)
                                ( t (f (1- x ))))) )
            (f 10 ) )

     Will "die" a horrible death.  The function F knows nothing of the
     function g or of itself. Where:

            (labels  ( (f (x)  (g (1+ x )) )
                     (g (x)  (* x 10)) )

               (f 10))

      works.

    In some sense, FLET and LABELS are to functions what  LET and LET*
    are to local variables. It isn't a precise analogy but close.

  You can peek under the hood...

   (disassemble  #'car )   ;; or one of your compiled functions...

  should reveal the associated opcodes for your processor if compiled.

  Somewhat related to the above question...
  You can develop (with the proper tools) as standalone application that
  doesn't return you to "start up" the lisp environment to run. You can
  forego the startup overhead of the development environment and it would
  be faster from start to finish ( for instance, if you developed some filter
  that read some data, transformed it, and then quit).  But besides the
  development environment start up /close down overhead.... your code would
  execute no faster.

--

* 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

#<Function SPEED >= 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.

        Paul
        (eagerly awaiting ACL 5.0, and hoping they'll
         release it for Linux as well)

---

;; Here's an example, using this file:

(defun counter (n)
  (declare (fixnum n))  
  (let ((x 0))
    (declare (fixnum x))
    (loop
        for i from 1 to n do
          (incf x i))
    x))

In article <hckg1ispfmy....@eto.ericsson.se>,
Raymond Wiker  <eto...@eto.ericsson.se> wrote:

    The temporary variable will be evaluated twice when this LET is
    evaluated.  But that isn't the original expression (which may
    have associated side effects, which is evaluated once).
    Evaluating a variable has no side effects.  

--

ly...@cc.gatech.edu (Lyman S. Taylor) writes:

In article <sfwbttfkera....@world.std.com>,
Kent M Pitman  <pit...@world.std.com> wrote:

 It would seem that a reasonable compiler would manage not to add
 too much overhead if the LET was always used. That renders the
 symbol macro "problem" moot. [ Not that I'd ever seen one before...***]

 What's that Knuth quote...  :-)

   "Premature optimization is the root of all evil ... "

*** Are symbol macros new to ANSI CL??  I can't seem to find anything in
      CLtL2.  Of course it could be in there somewhere... just hard to
      find.  Seems like a weird concept to bind general expressions
      to a symbol...   which makes landmines like the one mentioned
      here...

--

In article <6ijjnj$...@pravda.cc.gatech.edu>,
Lyman S. Taylor <ly...@cc.gatech.edu> wrote:
...

* Lyman S. Taylor
| Are symbol macros new to ANSI CL??  I can't seem to find anything in
| CLtL2.

  why look in CLtL2 if you want to find out about ANSI X3.226-1994?
  see http://www.harlequin.com/books/HyperSpec/ for the Real Thing¹.

Have fun,

-Eric "Don't tell the EPA I've dumped lisp in the past." Dahlman