RE: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Drew Adams <drew.adams@oracle.com>]

[Caveat: I haven't read the doc and am not familiar
 with native compilation.  Just commenting on what
 I see written here (which is without context).  If
 what I say helps, good; if not, please ignore.]

> >  "Native-Compilation is implemented as a side
> >  effect of byte-compilation"

That says that IF you byte-compile THEN, as a side
effect of byte-compiling, native-compiling also
happens.

Actually, that statement doesn't really say that
so definitively.  It could be that the side effect
doesn't _always_ take place during byte-compiling,
but that it does sometimes, i.e., conditionally.

But a casual reading will likely assume that
native compilation occurs each time a file is
byte-compiled.

IOW, byte-compile => native compile.

The statement _could_ also be read (by assuming
that's the _only_ native-compile implementation)
as saying that IF you native-compile THEN
byte-compiling also happens - i.e., that you
can't native-compile without also byte-compiling.

IOW: native-compile => byte-compile.

It would probably be a good idea to _spell out_
exactly the relationship.  The statement as is
tries to pack too much into the few words "is
implemented as a side effect of".

> It goes on by saying
> 
>   Thus, compiling Lisp code natively always
>   produces its byte code as well

(See above.  That's the "_could_ also be read"
bit, made explicit.)

If byte-compiling always native-compiles, say so.

If the only way to native-compile is to byte-compile
(i.e., that's the _only_ implementation of native
compilation, so you can't native compile without
also byte-compiling), then say so.

> So the above has nothing to do with _when_ does native compilation
> happen.  It just says _how_ it works: by launching a byte-compilation
> and using its by-products internally to produce native code.

It doesn't really say all of that.  (Maybe some of
the rest of the doc does, but not just the snippets
shown here out of context.)  It certainly doesn't
say that you initiate the compilations (both byte
and native) by "launching a byte-compilation".  And
it says nothing about needing to use some by-products
of byte-compilation to produce native code.

Based on your last statement, a guess would be this:

Byte-compilation produces, as a side effect, some
things that can (separately) be used to perform a
native compilation.

Does a user initiate that separate native compilation?
Or does it happen automatically when you byte-compile?
(This is the first question above: does byte-compile
imply native-compile?)

Are there other ways to native-compile, besides
launching a byte-compile?

> if the above would load a .eln file instead, how would
> a Lisp program be able to force Emacs to load a .elc file?
> 
> Therefore, when you specify an explicit extension, be it .el or .elc,
> Emacs loads that specific file, nothing more, nothing less.  Exactly
> like '(load "foo.el")' in previous versions of Emacs always loaded the
> .el file, even if the .elc file was available.

This was Stefan's remark also.  It's very important.

It fits what Emacs has always done (with *.el and
*.elc), and is perfectly logical.  It should be
pointed out explicitly in the text about native
compilation and byte-compilation and loading.

HTH.