RE: JIT-compilation for OCaml?

RE: JIT-compilation for OCaml?

[Dave Berry]

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

XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)

[Mattias Waldau]

> Dave Berry wrote

> 3.  Web programs require interfacing to web browsers.  Perhaps someone
>     could add the OCaml VM to Mozilla?

I don't believe we need Ocaml as a VM, I am not even sure that Java will
exist as a VM in the future. Most advanced WEB-clients today are coded using
Javascript (or sometimes VBscript).

Thin clients is a good approach! By implementing the Ocaml-program as a
multithreaded HTTP-server which exports its functions using XML or SOAP
(typed rpc over HTTP encoded by XML), very advanced interfaces can be done
easily.

The client consists of a Javascript program, or stylesheets or some of the
newer XML-technologies.

If you restrict yourselves to modern browser (ie 5, netscape 6), there are
good nice way reducing the amount of javascript coding. One example is HTC.

These kinds of interfaces can both be used locally (http://localhost) or
over the internet. Performance is very good locally, I know from practical
experience.

Creating a table using HTML is very often much easier than creating a user
interface with a listbox with columns and filling it.

/mattias

Re: JIT-compilation for OCaml?

[John Max Skaller]

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

RE: XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)

[Dave Berry]

Here at KAL we do develop many of our applications using scripting languages
in IE, as you describe.  But within this we embed ActiveX controls or
Javabeans that provide significant functionality (e.g. business logic or
device control).  The script handles the events generated by the embedded
components.  So this is an example of advanced web programming that does
require explicit language support, and if you wanted the same program to run
on different architectures you would need a VM (or multiple
architecture-specific installations).

-----Original Message-----
From: Mattias Waldau [mailto:mattias.waldau@abc.se]
Sent: Wednesday, January 10, 2001 9:12
To: Dave Berry; John Max Skaller; Markus Mottl
Cc: OCAML
Subject: XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)


> Dave Berry wrote

> 3.  Web programs require interfacing to web browsers.  Perhaps someone
>     could add the OCaml VM to Mozilla?

I don't believe we need Ocaml as a VM, I am not even sure that Java will
exist as a VM in the future. Most advanced WEB-clients today are coded using
Javascript (or sometimes VBscript).

Thin clients is a good approach! By implementing the Ocaml-program as a
multithreaded HTTP-server which exports its functions using XML or SOAP
(typed rpc over HTTP encoded by XML), very advanced interfaces can be done
easily.

The client consists of a Javascript program, or stylesheets or some of the
newer XML-technologies.

If you restrict yourselves to modern browser (ie 5, netscape 6), there are
good nice way reducing the amount of javascript coding. One example is HTC.

These kinds of interfaces can both be used locally (http://localhost) or
over the internet. Performance is very good locally, I know from practical
experience.

Creating a table using HTML is very often much easier than creating a user
interface with a listbox with columns and filling it.

/mattias