From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA00497; Thu, 5 Apr 2001 19:43:18 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA00943 for caml-list@pauillac.inria.fr; Thu, 5 Apr 2001 19:43:17 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA18810 for ; Thu, 5 Apr 2001 00:36:40 +0200 (MET DST) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f34Macr01745 for ; Thu, 5 Apr 2001 00:36:38 +0200 (MET DST) Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14kvtG-0008Rs-00; Thu, 5 Apr 2001 00:36:38 +0200 Received: from drms-3e35781a.pool.mediaways.net ([62.53.120.26] helo=ice.gerd-stolpmann.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 14kvtD-0001Ei-00; Thu, 5 Apr 2001 00:36:35 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id AAA31593; Thu, 5 Apr 2001 00:35:45 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: Chris Hecker , caml-list@inria.fr Subject: [Caml-list] Re: javacaml Date: Wed, 4 Apr 2001 23:10:28 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200103292240.OAA22134@smtp5-cm.mail.eni.net> <4.3.2.7.2.20010403142051.032a0a70@shell16.ba.best.com> In-Reply-To: <4.3.2.7.2.20010403142051.032a0a70@shell16.ba.best.com> MIME-Version: 1.0 Message-Id: <01040500354406.00489@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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