[Caml-list] Re: javacaml

[Gerd Stolpmann <gerd@gerd-stolpmann.de>]

On Tue, 03 Apr 2001, Chris Hecker wrote:
>I assume you've seen these two things:
>http://www.dcs.ed.ac.uk/home/mlj/index.html
>http://www.dcs.ex.ac.uk/~david/en/research/previous/java/
>
>The mlj stuff seems to take it pretty far.  Is there something different
>about ocaml that makes it harder? >

No, I did not know these works (I stopped my project 1998, and did not watch
whether other people succeeded).

I had a quick look at the mlj paper, and I found many thoughts in it I had
about compiling various ML types, but the paper draws also the conclusions from
them. They are not very appealing:

- The compiler must analyze the program as a whole; no separate compilation.
  This is necessary to remove problematic cases as much as possible; for
  example the whole program is monomorphized by replicating polymorphic
  functions for each type case. Another example is that they reduce the
  number of Java classes needed for closures by sharing classes for identical
  type cases.

  The compiler is very slow, and does not support separate compilation; the
  conclusion is that projects are limited to approximately 15000 lines.

- No tail-recursions in general (although the compiler tries to transform
  tail-recursive functions to ordinary while loops)

I am a bit amuzed about the paper because there are so long sections explaining
that the compiler is nevertheless useful:

- Seperate compilation is anachronistic, so it does not matter that it isn't
  possible with the compilation scheme even if the compiler is that slow

- 15000 lines are enough for most serious applications; and it does not matter
  that the compiler itself has 60000 lines and cannot compile itself

Perhaps mlj is propaganda financed by Java-enthusiastic industry: See, the JVM
is sufficient for all. (I'm unfair.)

Don't misunderstand me: mlj is excellent work if you take it academically, but
the authors argue that it is also usable for practical purposes, and this is the
reason why I am amuzed. The better conclusion from the facts in the mlj paper
is that it is not practicable to compile ML to Java bytecode.

I think I am a being that is able to learn, and my conclusion from my Java
experiments is that it is better to go non-Java ways than to accept the JVM as
it is. There are a number of ways to do so:

- Why isn't there an O'Caml plugin for Mozilla? In many environments, you do
  not need a sandbox, e.g. within intranets, and code signing suffices.

- Why isn't there a version of the bytecode interpreter that can dynamically
  load libraries? (I know that there is a patch, but nothing official.) This
  makes it simple to distribute platform-independent bytecode, because it 
  becomes possible to provide a set of official OVMs (O'Caml Virtual Machines)
  for every platform. If you want to execute an O'Caml program, you need only
  to download the OVM from caml.inria.fr, and you are ready to make your
  experiences with this language.

These two features would be great extensions to the current O'caml system
because there are many people who want an expressive alternative to Java that
is fast enough at the same time. I think O'Caml can be an alternative if
platform-independent computing is important (e.g. servlets, or distributed
systems in heterogenous environments). I know that many people use scripting
languages in these cases if speed is not so important, but there is a field
where currently only Java fulfils the requirements.

Regarding libraries: It is not very complicated to access C libraries from
O'Caml if you use camlidl. This can do even the average programmer who has
never heard about how a garbage collector works. So every C library is
potentially accessible (however it is a bit boring to make the stubs).
See the Perl community: they have wrappers for lots of C libraries.

Regarding networking: I would like to see excellent support for various network
protocols. Again this is not difficult; most protocols are very easy. I've done
it for Sun RPC which is designed for C; I can't imagine a reason why it
shouldn't be possible to derive an RMI engine from it. The same holds for
CORBA. My vision is an open system that can communicate with most other
programming environments.

I think this is the right way, and not to integrate O'Caml into the closed Java
world.

Now that I'm writing so many lines I think you (Chris) never asked that all...
Perhaps because I can only say: No, I cannot imagine any solution for your
applet problem because I think the necessary work is not worth the effort.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr