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 KAA09423 for caml-red; Thu, 11 Jan 2001 10:28:46 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA13724 for ; Thu, 11 Jan 2001 07:40:12 +0100 (MET) Received: from localhost.localdomain (cartman21.zip.com.au [61.8.20.149]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f0B6e8T28498 for ; Thu, 11 Jan 2001 07:40:09 +0100 (MET) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id RAA03479; Thu, 11 Jan 2001 17:38:13 +1100 Message-ID: <3A5D54D5.A19704BD@ozemail.com.au> Date: Thu, 11 Jan 2001 17:38:13 +1100 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Berry CC: Markus Mottl , OCAML Subject: Re: JIT-compilation for OCaml? References: <3145774E67D8D111BE6E00C0DF418B663A7C76@nt.kal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr Dave Berry wrote: > 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). I actually don't believe in UI builders. I have an alternate idea, I'd just love to implement in Ocaml. (I have done it in Tcl, oTcl, and Python). I call the system HWM, for Heirachical Window Manager. The idea is to use a tree widget instead of a linear panel. Each (application level) window is a node in the tree. The user can: 1. Move, iconise, and delete whole subtrees. 2. Spawn new applications as children of some other window (usually a container) 3. Dynamically change the type of a container What this means is that instead of building a huge, monolithic, integrated GUI application, configuration/placement/ organisation/style of windows is up to the user. This means you don't need a UI builder to build a client interface: HWM is the UI builder, and it is used by the client. For example: the otherwise excellent OcamlBrowser has a fixed, and, for me, quite broken, method of organising its windows (they come in the wrong places, and the scroll boxes are always the wrong size: it takes one click to spawn a new window showing some module used in another, and ten clicks and drags to get the size right). With HWM, I, as the client, would have complete control over where those new windows went. [The actual impetus for the design was an IDE for a Literate Programming Tool, which must handle edit/compilation/make/test of the software, as well as providing views of the 'book' text. The complexity required when dynamically displaying both kinds of information with various aspects of the structure (such as index of indentifiers, and index of words in the documentation) is far beyond conventional organisational techniques.] > 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). I guess these things have the wrong kinds of 'component'. Ocaml already has the 'right' kind of component: the module. What is needed is to dynamically load them (i.e. some module conforming to some statically specified interface). > 5. There are many embedded programs out there. These are tricky to write > with a GC. Perhaps the Ocaml GC is too heavyweight for microcontrollers. But I don't know: Java was designed to program a toaster wasn't it? :-) -- 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