From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA04414 for caml-red; Wed, 10 Jan 2001 09:25:40 +0100 (MET) 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 SAA28832 for ; Tue, 9 Jan 2001 18:05:31 +0100 (MET) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f09H5UP16087 for ; Tue, 9 Jan 2001 18:05:30 +0100 (MET) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_0045_3a5b_4554_8ebb; Tue, 09 Jan 2001 17:07:32 +0000 Received: from somewhere by smtpxd Message-ID: <3145774E67D8D111BE6E00C0DF418B663A7C76@nt.kal.com> From: Dave Berry To: John Max Skaller , Markus Mottl Cc: OCAML Subject: RE: JIT-compilation for OCaml? Date: Tue, 9 Jan 2001 17:09:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr Dynamic libraries would be useful, but there are other areas where OCaml (and most if not all other FLs) falls short. See below. Regarding C/C++ interfacing, this should be do-able, it's just a lot of work. What might be useful would be if all the implementors of advanced programming languages (OCaml, SML, Dylan,...) got together and wrote a tool for generating IDL from C/C++ header files. Then each implementor could write a language-specific IDL translator. I know the Dylan community made some headway with parsing header files. Here are some application areas to consider: 1. Huge numbers of commercial programs are simple UIs on top of simple databases. Hence the success of VB. A UI builder and simple DB interface would meet this need. (This is easier said than done). 2. A smaller number of commercial programs are complex UIs on top of complex databases. Here a UI builder is less important, but a UI toolkit and a sophisticated DB interface are essential. 3. Web programs require interfacing to web browsers. Perhaps someone could add the OCaml VM to Mozilla? 4. A growing number of commercial offerrings are based on component technology (ActiveX controls or Javabeans). Support for these (or perhaps a native equivalent) would be very useful. (Again, this is easier said than done). 5. There are many embedded programs out there. These are tricky to write with a GC. Dave. -----Original Message----- From: John Max Skaller [mailto:skaller@ozemail.com.au] Sent: Tuesday, January 09, 2001 6:40 To: Markus Mottl Cc: Mattias Waldau; OCAML Subject: Re: JIT-compilation for OCaml? Markus Mottl wrote: > > If Ocaml had a decent GUI API that worked on just X- and MS- Windows > > systems, it would be a killer. > I expected that people would mention GUI-libraries, but I don't write > GUIs. Is this really everything people are missing? Actually, no, there are some other significant problems (apart from education) with Ocaml. 1. The lack of dynamic loading virtually wipes it out as a serious commercial language (IMHO). This can probably be fixed. 2. The difficulty of interfacing to existing C/C++ code. This probably cannot be fixed. [For example, consider the sheer volume of work required to map GTK to Ocaml] There are, of course, many other problems, such as the lack of intermodule recursion, but all languages have various difficulties which can usually either be fixed or worked around. But clearly the biggest problem is one of education, both of the virtues of functional programming, and the details of the ocaml syntax/semantics (much of which escapes me, after several years usage). -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net