Re: java/kawa hello world example

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2010-08-21 20:19] writes:

> On 08/21/2010 12:55 PM, Helmut Eller wrote:
>
>>Well, no.  It's the same protocol.
>
> I read "Emacs then automatically connects to Lisp with a TCP socket"
> at http://www.cliki.net/SLIME-HOWTO which suggests to me there is more
> going on than just starting up a REPL.

Well, the REPL in the *inferior-lisp* buffer is used to tell Kawa to
start a TCP server, then Emacs connects to that server, after that all
communication runs on the TCP socket.  swank-kawa.scm does exactly that.
You can also start the Kawa server "manually" (e.g. on a remote machine)
and use M-x slime-connect.  But it's the same protocol.

>> The real problem is that "interactive programming" is not on Kawa's
>> priority list and it's supposed to be used as batch compiler.
>
> Interactive programming is definitely on Kawa's priority list.
> It uses compilation-on-the-fly heavily, of course, for repls,
> eval, and the web-server support.

For me, interactive programming includes that it's possible to compile a
file and load the compiled code into the running Lisp.  I want to use
the same file, with the same module imports/exports as I would for a
batch compiler.  Then I want to make a small fix to the file, compile it
and load it again.  And the (existing) bindings should be updated in
some sensible way.  Yes, updatable bindings are obviously a problem for
compile-time analysis.

(Ideally I only want to recompile a single function because compiling a
big file is quite slow; but I have given up all hopes on that already.)

I think this is quite different from typing some small snippet in a REPL
(which is of course also important).  And it seems that Kawa prefers to
do more compile-time analysis instead of making interactive programming
easier.

> What is not as high a priority is heavy use of eval and dynamic
> scoping.  (Rather: I tend to discourage it, because people
> tend to over-use it - at least that is my impression.)

Implementing the condition system properly is also low on the priority
list.  I guess it will never be fixed.  Unwinding the stack is not
helpful for debugging.  Ever heard of gdb automatically unwinding the
stack when it detects a SIGSEGV?  Of course not, because very valuable
debug information is right on top of the stack and it would be
self-defeating to throw it away.

>
> (Though I just checked in some major changes to the
> dynamic variable support to make it work better in a multi-threaded
> environment even if you just use raw Java threads, rather than
> Kawa futures.)
>
> One feature that would require more than simple REPL I/O is
> M-. - if you're in a Lisp/Scheme buffer, that should take you
> to the definition.  To do that robustly needs compiler help
> - at least the compiler needs to emit the appropriate mapping
> tables.  Doubly nice if M-. in a Kawa buffer can take you
> to the definition in a Java source file.

swank-kawa does it this way: it evaluates the name, then takes the
function object to figure out which class/bytecode corresponds to it and
uses JDI to get the source location form the line number table.  It also
can bring you to Java source files (even the ones in src.zip of the
JDK).  

Evaluation, obviously, doesn't work for non-exported bindings.  And
people shouldn't use eval anyway, right?

There are some of cases, I think those defined with define-procedure,
where it's almost impossible to find out which bytecode method it
actually calls. (Nothing to be ashamed of, though: even the disassembler
can't handle those.)

Kawa also emits relative filenames; so if swank-kawa doesn't know where
look for it can't find the source file.

Helmut