[Caml-list] Re: javacaml

[Caml-list] Re: javacaml

[Gerd Stolpmann]

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

Re: [Caml-list] Re: javacaml

[Sven LUTHER]

On Wed, Apr 04, 2001 at 11:10:28PM +0200, Gerd Stolpmann wrote:
> 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.

For it to be really usefull (i think) you would also need that all now -custom
using libraries become trully platform independent. Xavier spoke about it some
time ago.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: javacaml

[Xavier Leroy]

> 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 agree with your conclusions, however you're perhaps slightly too
harsh with MLj: for developing applet-sized programs, for instance,
the limitations of MLj (whole-program compilation, size limitations)
are acceptable.

> - 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.

François Rouaix hacked together a Caml plugin for Netscape a few years
ago.  It sort of worked (under Unix and with Caml actually running in
a different process and communicating over a pipe), but he sort of
lost interest in it.  I have doubts on the cleanliness and stability
of the Netscape plugin API :-)  Also, the same technical tricks might
not work under Windows...

At any rate, I believe Web applets are a totally uninteresting
application area.  Most Web designers seem happy with JavaScript
hacks, and in many years of intense Web surfing, I came across an
interesting Java applet only once (Certicom's excellent tutorial on
elliptic curve cryptography).

> - 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.)       

Because I'm lazy.  And it's a somehow more subtle change than you think.  
(The patch you mention misses a number of issues.)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: javacaml

[Chris Hecker]

>I agree with your conclusions, however you're perhaps slightly too
>harsh with MLj: for developing applet-sized programs, for instance,
>the limitations of MLj (whole-program compilation, size limitations)
>are acceptable.

I agree with this.  I'd be happy with MLj-level functionality for what I want to do.  I wonder how hard it would be to use their work for ocaml.  Is this something that would be good to handle at the C-- level, or are there no types down there so it wouldn't work since the JVM wants types?  I'm not very familiar with C--...are people using it?  It seems like the asmcomp files do something with it, but they don't emit intermediate code as much as intermediate datastructures.  Do they match C-- and it's not emited as a file to save time?

> At any rate, I believe Web applets are a totally uninteresting
>application area.  Most Web designers seem happy with JavaScript
>hacks, and in many years of intense Web surfing, I came across an
>interesting Java applet only once (Certicom's excellent tutorial on
>elliptic curve cryptography).

Really?  I find tons of cool applets that are used for teaching small concepts, everything from sorting to solving PDEs.  I think of them as interactive illustrations in papers, not as full fledged applications.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: javacaml

[Gerd Stolpmann]

On Fri, 06 Apr 2001, Xavier Leroy wrote:
>> 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 agree with your conclusions, however you're perhaps slightly too
>harsh with MLj: for developing applet-sized programs, for instance,
>the limitations of MLj (whole-program compilation, size limitations)
>are acceptable.

You are right. I'm quite impressed from the techniques MLj applies, and the
thing I'm wondering is that somebody really went such a long way only to get an
alternate language for applets. Maybe these techniques are interesting
anyway, and MLj is only an example. 

>> - 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.
>
>François Rouaix hacked together a Caml plugin for Netscape a few years
>ago.  It sort of worked (under Unix and with Caml actually running in
>a different process and communicating over a pipe), but he sort of
>lost interest in it.  I have doubts on the cleanliness and stability
>of the Netscape plugin API :-)  Also, the same technical tricks might
>not work under Windows...

I never programmed with the plugin API, so I don't know anything about the
stability. The Mozilla source code is now available, and I think this makes it
much easier to work around instable parts.

>At any rate, I believe Web applets are a totally uninteresting
>application area.  Most Web designers seem happy with JavaScript
>hacks, and in many years of intense Web surfing, I came across an
>interesting Java applet only once (Certicom's excellent tutorial on
>elliptic curve cryptography).

I have already seen several interesting applets, but these are commerical
intranet applets you don't find in the internet.

I'm doing much Web development, and the current rationale is to do as much as
possible at the server side. This has several reasons:

- Every browser version has its own set of bugs, and using less features of the
  browsers makes it less likely that bugs play a role

- There are only two languages that are usually available in browsers:
  Javascript and Java. Javascript is good to better control the GUI elements
  and to write adaptors betweem several parts of the application. However, you
  cannot really write bigger programs. Java is rather heavy-weight (development
  costs; applet load time) and is only used for special tasks, e.g. complex
  visualizations.

This is of course a bit unsatisfactory. In the near future, we will have
stable browsers that can dynamically change the HTML tree (with lots of
interesting applications), but I fear the two browser languages are not very
well suited for such dynamic web apps. Javascript is too lightweight, and in
Java you would need to program many steps for every dialog event.

I think an O'Caml plugin with access to the DOM tree (and DOM events) and that
can do some own networking would be a very nice programming environment. (I
don't want an alternative to Java, but an alternative to Javascript.)

>> - 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.)       
>
>Because I'm lazy.  And it's a somehow more subtle change than you think.  
>(The patch you mention misses a number of issues.)

I know it's more than just to apply the patch.

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