Re: defun vs lambda

[pjb@informatimago.com (Pascal J. Bourguignon)]

weber <hugows@gmail.com> writes:

> I did wanted to generate code at run-time, similar to the way like
> defstruct generates helper functions.

"Times" are a little complicated matter in lisp.

There is a read-time, a macro-expansion time, a compilation-time, a
load-time and a run-time.  In emacs lisp, things are a little
simplier, since there's no customizable reader macros, there's no way
to have user code executing at read-time.  Nonetheless, there are
means to have code evaluated during each of four other times.

The problem is that more than "times" they are "phases", and they can
occur intermixed one with the other.

When at run-time, (eg in the scratch buffer you run the
eval-last-expression (C-x C-e) command to evaluate the form you just
typed), this form is first read; during this read-time, a lisp object
is built according the syntax of the characters that are "read".  Then
the read object (which must be a form), is evaluated; during this
run-time, it may be noted that we must interpret a macro.  We will
call corresponding macro-function, and we get the body of the macro
executed during this macro expansion time.  The macro may build a new
function and call byte-compile to include a compiled function in the
returned form, so we will have a compilation-time, which further may
include macro-expansion times, etc. At compilation-time it is possible
to set things up to be evaluated at load-time, only when you use load
on the .elc file (see the load-time-value macro in (require 'cl)).

If you compile the file (byte-compile-file), then you go to the
compilation-time, it reads the source (read-time), then macroexpands
the macros (macro-expansion time), then generate the byte code.  You
will later load it (load-time), and then you may execute it
(run-time).  If your program generate *at run-time* new functions, it
may compile them (compilation-time, macro-expansion-time), and then
execute them (back at run-time). etc...


defstruct is a macro.  You may use it in different circumstances,
let's consider the three following cases:

- You directly evaluate (defstruct point x y).

- You put (defstruct point x y) in a source file, 
  and then evaluate (byte-compile-file "point.el"),

- You put it in a function, such as:

     (defun example ()
        (defstruct point x y))

  and you evaluate this form (which defines the function example),
  or you have this function in a file, and you byte-compile-file it.
  Then  you load the file and you call the function (example).


Let's consider the second case.  The compiler will read the defstruct
form, will notice that the symbol defstruct is defined as a macro, and
the will call the corresponding macro-function.  Now at macroexpansion
time, defstruct can work, and generate the accessor functions needed
from the arguments (a list of fields).  Notice that the macro
generates the functions at macro-expansion time, not at run-time.  It
returns a progn form containing defun forms amongst others.  The
compiler then compile that form, including the function definitions,
and generate the byte-code of these functions in a file, along with
the byte-code  needed to _define_ these functions, that is, to
associate the compiled function byte code to the symbol that name the
function.

Later you will load this byte-code file, and will have the function
definition loaded in your emacs lisp image.  No run-time has occured,
yet your functions are already defined.


In the third case, when compiling the defun form, the compiler will
macroexpand the defstruct form, and will generate the body of the
example function, which contain only the instructions needed to
_define_ these function, that is, to associate the compiled function
byte code to the symbol that name the function.

Then you call (example), and at run-time, the accessors of the
structure (which have been generated at macro-expansion time during
compilation of the function example), will be _defined_, that is
associated to the symbol that name the accessor function.  Still, no
code has been generated at run-time.


In the first case, you might have the impression that defstruct
generate code at run-time but as the above explications, and
particularly the third case, may lead you to understand, when
evaluating the defstruct form, there's a macroexpansion time during
which the functions are generated, and then what is executed at
run-time, is only the binding of these functions to their name (when
executing the defun forms).  Even without a compilation time, when
interpreting code, the function generation done by macros is not
exactly done at run-time.


The reason why it is not the case, and why it is not needed to
generate the code at run-time, is that all the information needed to
generate these defstruct accessor functions is known before run-time:
none of the arguments of the defstruct macro are evaluated (at
run-time). They're taken literally, and known at compilation-time.
The macro just returns the accessor function definition, it doesn't
need to return forms that would evaluate the arguments (at run-time)
and generate the functions (at run-time), since it has all the
information to do it itself at macro-expansion time.


Therefore since your sentence is contradictory, I still don't know
when you want to generate your functions...

-- 
__Pascal Bourguignon__