English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: JIT-compilation for OCaml?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-01-11 (09:28)
From: John Max Skaller <skaller@o...>
Subject: Re: JIT-compilation for OCaml?
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
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