RE: Obsoleting end-user-functions [was: turn-on-* type functions]

[Stephen J. Turnbull]

Drew Adams writes:

 > > > A harder, invasive idea: get rid of explicit byte-compilation,
 > > > by default.
 > 
 > What do you mean "by default"? 

I mean that you should not ever need to run byte-compile-file in the
normal use of Emacs, even if you code a lot of Lisp.

 > > > If Emacs always byte-compiles out-of-date 
 > > > libraries at load time, the warnings would be generated.
 > 
 > If load implies byte-compile, then, again, what did you mean by "by default"?

To be precise, "load" wouldn't imply byte-compile.  It would be a
cache fetch, which would check for freshness, and if not, regenerate
the bytecode for the library.

 > When would non-compiled code be used - just by explicit eval (e.g. `C-x C-e')
 > instead of load?

I said nothing about eval.  As Daniel pointed out, some Lisps have
never had a Lisp interpreter, they always (byte-)compile.  Python (and
IIRC, Perl) use a similar strategy of executing only compiled code.

Code would be interpreted directly only when byte-compiling was
inhibited, by binding an appropriate variable (and if so, there would
presumably be a command-line flag to allow either global
interpretation or interpretation of the uncompiled user code only).

 > > I've been using byte-code-cache.el for years. It reimplements
 > > load in lisp, byte-compiling files and automatically caching the
 > > results.
 >
 > Maybe I'm misunderstanding... Are you suggesting that every load
 > would load byte-compiled code?

Unless explicitly inhibited, and maybe even that would be disallowed.

 > So to use the debugger I would need to explicitly eval stuff
 > (e.g. whole libraries)? Surely you don't mean for users to debug
 > using byte-compiled code?

Why not?  Making that transparent is why I characterized this as
"harder" (a small understatement) and "invasive".  But it's not that
hard.  Python does it fine.  You need to remember that there are
bytecodes for only a very small (< 256) number of functions, and that
variable references are by symbol, not by address.  That means that in
most cases it is fairly easy to unambiguously reconstruct the source.
Only in the case of compiled (and therefore pre-expanded) macros would
there be a problem.  But in that case it should be possible to use the
same source-level debuggers and other techniques we use today.