caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: Dave Berry <dave@kal.com>
Cc: Markus Mottl <mottl@miss.wu-wien.ac.at>, OCAML <caml-list@inria.fr>
Subject: Re: JIT-compilation for OCaml?
Date: Thu, 11 Jan 2001 17:38:13 +1100	[thread overview]
Message-ID: <3A5D54D5.A19704BD@ozemail.com.au> (raw)
In-Reply-To: <3145774E67D8D111BE6E00C0DF418B663A7C76@nt.kal.com>

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



  parent reply	other threads:[~2001-01-11  9:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-09 17:09 Dave Berry
2001-01-10  9:12 ` XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?) Mattias Waldau
2001-01-11  6:38 ` John Max Skaller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-11 12:45 JIT-compilation for OCaml? Dave Berry
2001-01-12  8:23 ` John Max Skaller
2001-01-09 17:18 Dave Berry
2001-01-11  7:00 ` John Max Skaller
2001-01-11 10:01   ` Alain Frisch
2001-01-12  7:55     ` John Max Skaller
2001-01-03 15:24 Jerry Jackson
2001-01-04 14:12 ` Alan Schmitt
2001-01-02 16:07 Markus Mottl
2001-01-02 18:16 ` Mattias Waldau
2001-01-02 19:30   ` Markus Mottl
2001-01-03 12:15     ` Alain Frisch
2001-01-04  8:37       ` Fabrice Le Fessant
2001-01-04  9:04         ` Alain Frisch
2001-01-03 13:23     ` Mattias Waldau
2001-01-03 14:25       ` Markus Mottl
2001-01-03 14:40       ` STARYNKEVITCH Basile
2001-01-03 15:51     ` John Max Skaller
2001-01-03 17:50       ` Markus Mottl
2001-01-05  0:30         ` Michael Hicks
2001-01-08  9:59           ` Xavier Leroy
2001-01-09  6:40         ` John Max Skaller
2001-01-03 17:49     ` Joseph R. Kiniry
2001-01-03 18:19       ` Markus Mottl
2001-01-03 18:38         ` Joseph R. Kiniry
2001-01-03 18:58           ` Markus Mottl
2001-01-03 19:06             ` Joseph R. Kiniry
2001-01-04 22:32               ` Jonathan Coupe
2001-01-07  0:16                 ` Chris Hecker
2001-01-05 12:52               ` Sven LUTHER
2001-01-05 20:08                 ` Joseph R. Kiniry
2001-01-09  7:14             ` John Max Skaller
2001-01-09  6:50         ` John Max Skaller
2001-01-05 12:39   ` Sven LUTHER
2001-01-05  5:48 ` Vitaly Lugovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A5D54D5.A19704BD@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=caml-list@inria.fr \
    --cc=dave@kal.com \
    --cc=mottl@miss.wu-wien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).