You are not logged in

The compile-file/load functionality is important to me also,
so I wanted to weigh in here with another use case. I rely on
this for updating running applications which operate uninterrupted
for months at a time. The updates are non-interactive, and the
way the application is sandboxed, firing off a shell to run a
compilation is undesirable at best (at worst, impossible).

I appreciate the arguments for the batch compilation approach,
but doing this to the exclusion of compile-file/load would be
a serious loss.

I'm using Kawa from within Emacs which some glue
code for smoother interaction between Emacs and
Kawa.

I typically compile files (buffers) with a key
combination C-c C-k which compiles the file and
loads the jar file into the running JVM process.
It doesn't create a new JVM instance just to
compile a file.

Warnings/Errors are annotated in the source
buffer. To do that my glue code can't use
compile-file directly; it uses the lower level
functions instead but it's conceptually the same
as compile-file.

If the second argument of compile-file is a jar
filename it seems to generate a jar file. I'm
not sure though, might just be a zip file with a
different extension. But the -C command line
switch compiles to a ton of class files instead
of a single jar which is another reason why I
rather use
kawa -e '(compile-file \"x.scm\" \"x.jar\")'.

As far as interaction goes, I'd like to associate
an Emacs buffer/file with a (runtime) module. It
would be nice if there were a way to evaluate
expressions in the "toplevel environment" of such
modules. In that environment the toplevel macros
and toplevel functions of the module should be
callable even if not exported (in addition to
imported bindings). It would also be nice to be
able to reload/relink/hotswap those modules with
newer versions of the module.

So Emacs could have a command like C-x C-e which
evaluates the expression before point in the
environment associated with the current
file/module. Of course, it should also be
possible to compile modules without loading them
just to see compiler warnings.

Except for the relinking part, I think that such
a model isn't unreasonably inefficient. And
relinking will probably be easy with
invokedynamic.

In terms of a REPL, there could be something
analogous to the "cd" command but instead of
changing the directory it would switch the
current module. Something like Scheme48's ",in"
command.

Yes, for now it is better to use Kawa as batch compiler from the system shell. But it might make sense to have a new "compile" procedure that takes various (keyword?) parameters specifying what files to compile, where to put them, where to report errors and warnings, and which options to apply. I haven't felt much need for that myself, but I'm on Unix/Gnu/Linux, where I have reasonable shells and 'make'; some people might prefer scripting in Scheme. That's a topic I'm interested in exploring (see the old http://per.bothner.com/software/Q/Qshell.html), but the general topic will have to wait.

I believe compile-file does show errors - just not warnings.
However, it shows errors by throwing an exception, rather than by printing to a port. Printing the exception reports the errors.

I feel uncomfortable with having a "tool" like compile-file write to the current output (or error) port. That makes it harder to invoke the tool programmatically. Yes, it is possible to change the current output port, but it seems ugly.

I'm also concerned about duplicate error message. Your patch prints the errors and warnings, then if there is an error, we throw an exception, which gets reported - by printing the exception.

Finally, compile-file is not really recommended these days. It creates a zip file, which you then need to load. Load interacts badly with lexical scoping, compile-time analysis, and hence performance and error checking. I strong discourage use of load, and hence also of compile-file.