Re: native compilation units

[Stefan Monnier]

> Currently compiling a top-level expression wrapped in
> eval-when-compile by itself leaves no residue in the compiled  output,

`eval-when-compile` has 2 effects:

1- Run the code within the compiler's process.
   E.g.  (eval-when-compile  (require 'cl-lib)).
   This is somewhat comparable to loading a gcc plugin during
   a compilation: it affects the GCC process itself, rather than the
   code it emits.

2- It replaces the (eval-when-compile ...) thingy with the value
   returned by the evaluation of this code.  So you can do (defvar
   my-str (eval-when-compile (concat "foo" "bar"))) and you know that
   the concatenation will be done during compilation.

> but I would want to make the above evaluate to an object at run-time
> where the exported symbols in the obstack are immutable.

Then it wouldn't be called `eval-when-compile` because it would do
something quite different from what `eval-when-compile` does :-)

> byte-code (or native-code) instruction arrays.  This would in turn enable
> implementing proper tail recursion as "goto with arguments".

Proper tail recursion elimination would require changing the *normal*
function call protocol.  I suspect you're thinking of a smaller-scale
version of it specifically tailored to self-recursion, kind of like
what `named-let` provides.  Note that such ad-hoc TCO tends to hit the same
semantic issues as the -O3 optimization of the native compiler.
E.g. in code like the following:

    (defun vc-foo-register (file)
      (when (some-hint-is-true)
        (load "vc-foo")
        (vc-foo-register file)))

the final call to `vc-foo-register` is in tail position but is not
a self call because loading `vc-foo` is expected to redefine
`vc-foo-register` with the real implementation.

> I'm not familiar with emacs's profiling facilities.  Is it possible to
> tell how much of the allocated space/time spent in gc is due to the
> constant vectors of lexical closures?  In particular, how much of the
> constant vectors are copied elements independent of the lexical
> environment?  That would provide some measure of any gc-related
> benefit that *might* be gained from using an explicit environment
> register for closures, instead of embedding it in the
> byte-code vector.

No, I can't think of any profiling tool we currently have that can help
with that, sorry :-(

Note that when support for native closures is added to the native
compiler, it will hopefully not be using this clunky representation
where capture vars are mixed in with the vector of constants, so that
might be a more promising direction (may be able to skip the step where
we need to change the bytecode).


        Stefan