[Caml-list] Complex Numbers

[Caml-list] Complex Numbers

[David McClain]

"One of the articles by William Kahan (www.cs.berkeley.edu/~wkahan/)
"How JAVA's Floating-Point Hurts Everyone Everywhere" discusses
(among other things) some traps in complex number implementations,
including those in Fortran.
"

My NML, written in OCaml, paid particular attention to these issues after I
read everything I could from Kahan. To my knowledge, aside from Common Lisp
(perhaps), it is the only proper implementation of complex arithmetic
available.

In particular, Kahan's demo of "Borda's Pipe", shows that stream lines are
incorrectly computed in every language I have tried: Mathematica, RSI/IDL,
Fortran, C/C++, Basic, with the possible exception of Common Lisp. Only NML
has passed demonstrably passed this test.

The difficulty stems from the fact that, to paraphrase Kahan, "a tuple
representation of complex numbers is insufficient, given the Riemann
surfaces of common transcendental functions". There are two zeros defined in
the IEEE Floating Point Standard: 0+, and 0-.  Arithmetic in the floating
point domain do not obey classical algrebraic relations with respect to
conventional identity elements.

I sweated out two solid weeks in gaining a full understanding of his rather
cryptic statement. NML represents my final victory over this issue and I can
thank OCaml and the INRIA team for their wonderful implementation language
that made it all so readily possible.

- DM


Borda NML code follows:

--------------------------------------------------
(* borda.nml -- test of complex arithmetic in NML *)
(* DM/MCFA  09/99 *)

let g z = z^2 + z*sqrt(z^2+1)
let f z = 1 + g(z) + log(g z)

let ls =
  let ptor r theta =
    complex (r*cos theta) (r*sin theta)
  in
  let t = tan(pi/2*[0, 0.001, .. 1]) in
    map (fun ang ->
    ptor t ang)
      (lis (pi * [-0.5, -0.45, .. 0.5]))

let rec pshow (l, ... as args) =
  let clip x =
    x #< 400 #> -400
  in
  let z = f(l) in
    oplot(clip(re z), clip(im z) | args @ [clip: true])

let borda() =
  let s = 5 in
    axes(xrange: [-s,s], yrange: [-s,s],
 title: "The Correct Borda!");
    pshow(hd ls, color: red, thick: 2);
    app pshow (tl ls)

let _ = borda()



-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] OCaml, where art thou?

[Anjayan Puvananathan]

Hello,

It is a great pleasure to participate in this list. I'm
returning to Caml after using having used it on my XT back in
high school. I remember trying to stretch 640k for all it was 
worth in those days. I'm glad to see all the work that has gone
into it. Keep up the excellent work!

There have been questions raised about threading in Caml under
BeOS, but however no one has responded with authority to these.
I have a few more pragmatic questions related to this. BeOS
treats threads and sockets in a fundamentally different
(better?) way than POSIX. I would like to use Caml purely as
code generator and interface the native BeOS libraries via C.
Can I be safe is assuming that the GC facilities and in general
Caml runtime are thread-safe. What would be required to ensure
thread safety, since building with -with-pthread is not an
option on BeOS? Could I, if desperate enough, initialize
separate Caml runtimes by calling caml_main in different threads
from a C main program to avoid synchronization issues? Ideally
I'd like to strip any extraneous code in Caml that is associated
with a UNIX view of the world. If OCaml is not a option, how
about Caml Light? The language itself is worth the tradeoff in
execution speed.

I hope you can help.

Once more, many thanks to the researchers at INRIA. With all
these discussions about libraries and the such, I hope you keep
the system code clean and simple as it is right now. Less is
more, although this email seems to be the antithesis of this.

Anjayan
--
Hire a talented student for a summer internship.
http://www.student.math.uwaterloo.ca/~apuvanan/

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] OCaml, where art thou?

[Xavier Leroy]

> There have been questions raised about threading in Caml under
> BeOS, but however no one has responded with authority to these.

I'm trying to catch up with my mail, but every time I respond on
caml-list some more replies pop in :-)

> I have a few more pragmatic questions related to this. BeOS
> treats threads and sockets in a fundamentally different
> (better?) way than POSIX.

I wouldn't say that the differences are fundamental -- just
significant enough to be annoying.  As much sympathy I have for BeOS,
I regret that they stopped short of providing full POSIX
compatibility.  That would make it much easier to get free software
ported to it.

> I would like to use Caml purely as
> code generator and interface the native BeOS libraries via C.
> Can I be safe is assuming that the GC facilities and in general
> Caml runtime are thread-safe.

No, neither the GC nor most of the runtime system are thread safe.

> What would be required to ensure
> thread safety, since building with -with-pthread is not an
> option on BeOS?

The "system threads" OCaml library addresses this issue by having one
global master lock that must be acquired in order to run Caml code or
call most run-time facilities, including the allocator and the GC.
This lock is released when calling C from OCaml (allowing other
threads to execute Caml code) and reacquired again before resuming
execution of Caml code.

> Could I, if desperate enough, initialize
> separate Caml runtimes by calling caml_main in different threads
> from a C main program to avoid synchronization issues?

Disaster would ensue very quickly.

> Ideally I'd like to strip any extraneous code in Caml that is associated
> with a UNIX view of the world. If OCaml is not a option, how
> about Caml Light? The language itself is worth the tradeoff in
> execution speed.

The core runtime system is ANSI C, however the threading library
(module Threads) and the OS interface (module Unix) are
system-specific.  We have implementations of these for Unix and
Windows, and as Sylvain Kerjean said volunteers are trying to build an
implementation for BeOS.

You can of course change the OCaml APIs and have BeOS-specific
BeThreads and BeSystem modules (although you'd then lose source-level
compatibility with the other systems, which I would advise against).
However, for threading, you'd still have to use the same mechanisms as
in the "system threads" library to ensure single-threadedness in the
OCaml runtime system.

Hope this clarifies the issues.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] OCaml, where art thou?

[David Fox]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> The "system threads" OCaml library addresses this issue by having one
> global master lock that must be acquired in order to run Caml code or
> call most run-time facilities, including the allocator and the GC.
> This lock is released when calling C from OCaml (allowing other
> threads to execute Caml code) and reacquired again before resuming
> execution of Caml code.

How good or bad an arrangement is this?  I've been asked about the
threading facilities of ocaml, but I don't know enough to compare and
contrast, say, ocaml and Java.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Using HTML as a standard GUI for Ocaml

[Mattias Waldau]

- Is the idea below good or bad?
- I am looking for ideas how to implement the idea below.
- Making some kind of JSP/ASP-package for Ocaml could be a solution,
but code likes that gets very messy.
- What has been done? Unpublished code?
- Alternatives?

Using HTML for GUIs
===================

Today there exists two flavors of gui for Ocaml based on Tcl or GTK.
Tcl is portable, and GTK is becoming portable.

What about using HTML-interfaces
instead of standard GUIs like Tcl and GTK?

The architecture is
that you start some kind of HTTP-based server and than you
start the browser and go to a local adress like
http://localhost:8989/start.html.

The advantages are
- Portable
- Much nicer looking GUI's, it is easier to add pictures, fonts etc
  to a HTML-gui, than to a Tcl/GTK-based
- Many GUI-operations are easier to do in HTML than in a standard
  GUI-tool, for example HTML-tables are easier to create the
  listboxes with columns.
- Easy to create server-based solutions out of client-applications.
  Only need to handle state in a general and scalable way.
- Smaller executables, for example including GTK statically into
  Unison increases the size from 700Kb to 2400Kb on Windows.
- Easier to integrate with other applikations, since two
  applications can merged on the HTML-page

The disadvantages are
- slower
- difficult to set focus correctly if the whole page is updated
  after each input (bugs i IE). This can be solved by being
  XML-based and talk XML from the browser to the server (which
  only works on IE>=5 and Netscape 6).
- browser incompabilities. (for example HTC in IE makes event
  very easy to handle, but incompatible with active sheet on Netscape,
  which is buggy)

/mattias

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Fergus Henderson]

On 31-Mar-2001, Mattias Waldau <mattias.waldau@abc.se> wrote:
> What about using HTML-interfaces
> instead of standard GUIs like Tcl and GTK?
...
> - What has been done? Unpublished code?

Zoltan Somogyi and Thomas Conway, who have been implementing a new
profiler for Mercury, have been using this technique.  The code is not
officially released, and at this point I suspect it is very much a
prototype, and probably not well documented, but it is available from
the Mercury CVS repository (on the `deep2' branch; the code for the CGI
interface is in the `deep' directory).  I saw a public demo that Tom
gave here at the University of Melbourne about a month ago.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Sven LUTHER]

On Sat, Mar 31, 2001 at 11:31:43AM +0200, Mattias Waldau wrote:
> - Is the idea below good or bad?
> - I am looking for ideas how to implement the idea below.
> - Making some kind of JSP/ASP-package for Ocaml could be a solution,
> but code likes that gets very messy.
> - What has been done? Unpublished code?
> - Alternatives?
> 
> Using HTML for GUIs
> ===================

can be a good idea, depending on your use.
> 
> Today there exists two flavors of gui for Ocaml based on Tcl or GTK.
> Tcl is portable, and GTK is becoming portable.

Gtk is portable, it works at least on X, windows, the linux framebuffer device
(soon) and possibly some others.

> What about using HTML-interfaces
> instead of standard GUIs like Tcl and GTK?

Well, i think this may be a good idea (sun is doing this) if you need to run
your code remotely and for system configuration and administration.

But, ...

Most web browser are huge beast, running slowly and ressource hungry. Also i
think you can do less things with html than you can do with modern toolkits.

Also there is the question of bandwith.

> The architecture is
> that you start some kind of HTTP-based server and than you
> start the browser and go to a local adress like
> http://localhost:8989/start.html.

Sun is doing this for their system/wbe server administration, but then i guess
everyone using this has fast web connection and quick boxes wiht loads of
memory

> The advantages are
> - Portable

Sure, ...

But i think you don't envision to run it on a text based browser like lynx ?

> - Much nicer looking GUI's, it is easier to add pictures, fonts etc
>   to a HTML-gui, than to a Tcl/GTK-based

Erm, ...

i don't think much people will be of the same opinion as you.

It may be easier for simple tasks, but there is much less things you can do
with HTML.

Also i hope you don't try to do OpenGL stuff and other such, i don't think it
will work.

> - Many GUI-operations are easier to do in HTML than in a standard
>   GUI-tool, for example HTML-tables are easier to create the
>   listboxes with columns.

But you have less control wit them, as well as one the callbacks you can add
to them. Also i am not html specialist but from what i know, the event loop
handling is really slow on a browser + server thing than what you can do with
even the slow tcl/tk toolkit.

> - Easy to create server-based solutions out of client-applications.
>   Only need to handle state in a general and scalable way.

This has nothing to do with GUIs, ...

> - Smaller executables, for example including GTK statically into
>   Unison increases the size from 700Kb to 2400Kb on Windows.

But you need the 20Mb + of mozilla/whatever installed.

> - Easier to integrate with other applikations, since two
>   applications can merged on the HTML-page

mmm, ...

i don't know about this, but i think you will launch a cgi to generate the
html page. if you have 2 pages, you would need to launch 2 cgis and merge
them, or have one of them call 2 other and do the merging.

I think it trully depends on what you want to do. Please provide a more
detailed context, and we could discuss it in more details.

> The disadvantages are
> - slower

much slower, and ressource hungry, yes ...

> - difficult to set focus correctly if the whole page is updated
>   after each input (bugs i IE). This can be solved by being

And naturally, don't forget that IE is not the only browser around.

>   XML-based and talk XML from the browser to the server (which
>   only works on IE>=5 and Netscape 6).
Sure, and XML is the solution to all your problems ... :)))

I am not that convinced, but then i am no XML expert.

> - browser incompabilities. (for example HTC in IE makes event
>   very easy to handle, but incompatible with active sheet on Netscape,
>   which is buggy)

Just use Standard html and forget about all the private extensions of the ones
and the others.

All in all, i think using html as guis is a solution only for the most
specialized of case, where having it running remotely is a requirement, like
in the sun case, but mostly it is simply to cumbersome and ugly to be of any
help for more advanced GUIs. I would not do it.

That said, in the ocaml oreilly book, you will find a chapter on how to write
a web server in ocaml, and some stuff that could lead to some of the things
you may want to do, please read it.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Bruce Hoult]

At 10:11 PM +0200 4/1/01, Sven LUTHER wrote:
>  > What about using HTML-interfaces
>>  instead of standard GUIs like Tcl and GTK?
>
>Well, i think this may be a good idea (sun is doing this) if you need to run
>your code remotely and for system configuration and administration.
>
>But, ...
>
>Most web browser are huge beast, running slowly and ressource hungry. Also i
>think you can do less things with html than you can do with modern toolkits.
>
>Also there is the question of bandwith.

I think cvsweb is a good example.

I'm sitting here in New Zealand on a 56k modem, doing development 
work on Gwydion Dylan, with the cvs server being in Germany.  If I 
want to see, say, the change log for the CREDITS file then I have two 
choices.  I can type [1]...

   cvs -d :pserver:anoncvs@berlin.ccc.de:/home/cvsroot log src/CREDITS

... which takes just over five seconds to fetch the results, or I can 
enter into my browser the URL...

   http://www.ccc.de/cgi-bin/cvsweb/gd/src/CREDITS

...which takes about two seconds, is prettier, and is more functional 
in that I am then only a click (and two more seconds) away from 
seeing the source of any version I want, doing diffs between 
versions, getting source annotated with who last changed each line 
etc.

It's just not obvious that HTML is slower than the alternatives.

-- Bruce

[1] no, of course I don't type all that -- I'm more likely to hit 
"C-x v l" in emacs (because Eric Raymond taught emacs how to do 
that), and emacs could equally easily be taught how to fire up a 
Netscape window with the cvsweb page. (actually, I taught MPW Shell 
to do that for me, because I know how to customize it better than I 
know how to customize emacs)
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Sven LUTHER]

On Mon, Apr 02, 2001 at 08:35:14AM +1200, Bruce Hoult wrote:
> At 10:11 PM +0200 4/1/01, Sven LUTHER wrote:
> >  > What about using HTML-interfaces
> >>  instead of standard GUIs like Tcl and GTK?
> >
> >Well, i think this may be a good idea (sun is doing this) if you need to run
> >your code remotely and for system configuration and administration.
> >
> >But, ...
> >
> >Most web browser are huge beast, running slowly and ressource hungry. Also i
> >think you can do less things with html than you can do with modern toolkits.
> >
> >Also there is the question of bandwith.
> 
> I think cvsweb is a good example.
> 
> I'm sitting here in New Zealand on a 56k modem, doing development 
> work on Gwydion Dylan, with the cvs server being in Germany.  If I 
> want to see, say, the change log for the CREDITS file then I have two 
> choices.  I can type [1]...
> 
>    cvs -d :pserver:anoncvs@berlin.ccc.de:/home/cvsroot log src/CREDITS
> 
> ... which takes just over five seconds to fetch the results, or I can 
> enter into my browser the URL...
> 
>    http://www.ccc.de/cgi-bin/cvsweb/gd/src/CREDITS
> 
> ...which takes about two seconds, is prettier, and is more functional 
> in that I am then only a click (and two more seconds) away from 
> seeing the source of any version I want, doing diffs between 
> versions, getting source annotated with who last changed each line 
> etc.
> 
> It's just not obvious that HTML is slower than the alternatives.

Sure, but guess what you would have used if you wanted to update your Xfree86
source tree to the latest cvs HEAD version ?

Again, like i said, there are a few uses where using html for guis make sense,
but in the generic case, using gtk+ or some other toolkit makes more sense.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[CREGUT Pierre FTRD/DTL/LAN]

That's the way I program GUI now. I found I lost too much time with GUI 
that were supposed to be the standard way with CAML (do you remember 
Daniel's (de Rauglaudre) RT lib ?  the various versions of Tk libs, etc.).

Nowadays there is a browser (Netscape or IE) on any machine and most of the
time it is running anyway. This gives you distributed, multi user interfaces,
may be not for free but at least you will not have to rethink everything when
you need it. Furthermore you really get more independance between the 
contents and its presentation than with a regular GUI (unless you are
careful to design your application as two separate sub applications). XML
will improve the situation further.

HTML GUI has weaknesses (handling the back button, old contexts, etc.) but
they are relatively small. For bandwidth : I do not program video games. 

So I use a modified version of Daniel de Rauglaudre wserver using threads
instead of fork and a home brew
library for HTML where text is basically a stream of string but HTML
constructs are hided behind functions.
The major task of the library is to hide URLs behind a notion of callbacks 
with arguments and maintain notions of contexts (lifetime of a user
interaction).
Drawings are done with Thomas Boutel gd library sometimes with some DHTML
code for layering. Another solution for very dynamic parts is to use
a socket with a  java applet (a  generic graphics applet would be nice).

Pierre Crégut

PS> Another solution for the HTTP server is to use Jserv and program
an interface between CAML and Apache replacing the Java integration.
This is not difficult but I only experimented it briefly.
The major advantage is that you get all the apache modules for free (for
example so far I only have basic authentification with my server).

-- 
Pierre Cregut - pierre.cregut@rd.francetelecom.fr - +33 2 96 05 16 28
FTR&D - DTL/MSV - 2 avenue Pierre Marzin - 22307 Lannion Cedex - France
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Gerd Stolpmann]

On Sat, 31 Mar 2001, Mattias Waldau wrote:
>- Is the idea below good or bad?
>- I am looking for ideas how to implement the idea below.
>- Making some kind of JSP/ASP-package for Ocaml could be a solution,
>but code likes that gets very messy.
>- What has been done? Unpublished code?
>- Alternatives?

I'm doing a lot of professional development for web applications. These are
typically intranet applications, and many companies like such apps because
there is no need of client installations (which are very expensive to maintain).

So I think I can answer these questions.


>Using HTML for GUIs
>===================
>
>Today there exists two flavors of gui for Ocaml based on Tcl or GTK.
>Tcl is portable, and GTK is becoming portable.
>
>What about using HTML-interfaces
>instead of standard GUIs like Tcl and GTK?
>
>The architecture is
>that you start some kind of HTTP-based server and than you
>start the browser and go to a local adress like
>http://localhost:8989/start.html.
>
>The advantages are
>- Portable

This is only true for HTML 3.2 because all current browsers support this
standard. HTML 4.0 + Ecmascript + DOM + CSS could become portable in the
future, but this is not yet the case. 

In the moment, I am developing an application which must run under both
Netscape 4.x and IE 5.0 browsers, and this is a nightmare if you begin to use
features beyond HTML 3.2. The point is that the customer/user already has
installed some type(s) of browsers on the clients, and that the server must
cope with that. Otherwise one of the main goals (reduce client costs) of such
installations cannot be achieved.

>- Much nicer looking GUI's, it is easier to add pictures, fonts etc
>  to a HTML-gui, than to a Tcl/GTK-based

Agreed. However, nice GUIs are also possible with Tk or GTK, and I think there
are also HTML renderers for these toolkits.

>- Many GUI-operations are easier to do in HTML than in a standard
>  GUI-tool, for example HTML-tables are easier to create the
>  listboxes with columns.

Only "display operations" are easier. Input operations are very restricted in
HTML. 

On the other hand, it is much more complicated to program the dialogue control
for web applications, because you have the strict request/response scheme of
the underlying protocol.

>- Easy to create server-based solutions out of client-applications.
>  Only need to handle state in a general and scalable way.

Yes, and this is not simple, even with toolkit support (see below).

>- Smaller executables, for example including GTK statically into
>  Unison increases the size from 700Kb to 2400Kb on Windows.

This does not count, because libraries can be shared between executables. So
if you have ten different executables for GTK, the GTK library is only loaded
_once_. Statistically, GTK has shrunken to the size of 1700K/10 = 170K. This is
hard to beat.

Let us compare that with the resource usage of web applications. There are two
widely used architectures:

- CGI: Every request creates a new process. This has the _big_big_big_
  advantage of unbeaten stability because requests cannot interfer. However,
  many initializations of the application have to be done for every request,
  e.g. opening database connections. Because of this, CGI applications cause a
  high server load (Note: For web services, one CGI request per second is
  already regarded as high load).

- Application servers: The same process can accept multiple requests, and 
  performs them either serially or in a multi-threaded way. This reduces the
  load (usually) dramatically, but for this architecture the app must be coded
  much more carefully because the requests share implicitly state. (E.g. you
  must close all files otherwise you get out of file descriptors after a
  while.)

I recently developed a mixture of both: An application server that forks for
every request; it was quite successful.

You see (as a rule of thumb): Either you have a simple architecture and high
loads, or a complex architecture and low loads. Perhaps it is possible to find
a simpler solution for one-user applications (i.e. every user has its own
server); this could be comparable to the requirements of "traditional"
toolkits. But then the implicit multi-user accessibility of web applications
goes away.

>- Easier to integrate with other applikations, since two
>  applications can merged on the HTML-page

This is one of the big advantages of HTML-based apps.

>The disadvantages are
>- slower
>- difficult to set focus correctly if the whole page is updated
>  after each input (bugs i IE). This can be solved by being
>  XML-based and talk XML from the browser to the server (which
>  only works on IE>=5 and Netscape 6).

Don't know. I never wanted to set the focus for web apps.

>- browser incompabilities. (for example HTC in IE makes event
>  very easy to handle, but incompatible with active sheet on Netscape,
>  which is buggy)

Yes, a nightmare.

By the way, I have a web toolkit for Caml. It allows the programmer to describe
the application in an XML document, and to add callbacks to the interesting
events. The toolkit solves the details of keeping the state of the application
instance, and provides a way to form HTML pages from fragments. I'm using it for
many of my professional developments. However, it has one major drawback: My
boss owns it, and not me. There is a realistic chance to make it available
under the GPL (yes, GPL, such that nobody else can use it for commercial
projects).

The application uses persistent objects that "survive" between request/response
cycles. In an XML document these objects can be declared, e.g.

<ui:object name="whatever">
  <ui:variable name="x" type="string"/>
  <ui:variable name="y" type="enumerated"/>
  ...
</ui:object>

There is always one main object which typically reflects the current dialogue
state of the session. (Instance) variables contain dynamically created contents
of a page, or serve as target for input elements. What is sent to the
browser is a view of the main object computed by expanding a mixture of HTML
elements and toolkit elements (these have the prefix ui:). E.g.:

<ui:page>
  <html>
    <body>
      <h1>This is a sample page!</h1>
      The value of variable x: <ui:dynamic variable="x"/>.  
        <!-- ui:dynamic: insert dynamically generated contents -->
      Please enter variable y: 
      <ui:form>
        <ui:text variable="y"/>        <!-- ui:text: make a text input box -->
        <ui:button name="b" label="OK"/>
      </ui:form>
    </body>
  </html>
</ui:page>

When an event happens (button is pressed, or a hyperlink) the toolkit calls
back a user-supplied function or method, and the system can react on the event.

Complex HTML pages can be formed by instantiating templates. A template is an
HTML fragment containing free identifiers (using dollar notation):

- Abstraction:

<ui:template name="t">
  <ui:expectparam name="p1"/>
  <ui:expectparam name="p2"/>
  This is <b>$p1</b> and that is <i>$p2</i>.
</ui:template>

- Application:

<ui:use template="t">
  <ui:param name="p1">one parameter</ui:param>
  <ui:param name="p2">another parameter</ui:param>
</ui:use>

Note that this is not a lambda calculus because abstractions must be done at
top level. 

The resulting application normally separates strictly HTML parts (the layout)
and the programmed code (for the callbacks). The toolkit enforces a clear
concept for the application getting better maintainability.

If anybody is interested in such a toolkit, I can package a version 0.0 tarball
with very incomplete documentation (and perhaps only bytecode and no sources),
and only a few samples one can learn from.


Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Using HTML as a standard GUI for Ocaml

[Mattias Waldau]

There are at least two implementations of using "HTML as GUI".

I would be very interesting to see these solutions, so
please make then available. GPL isn't a problem.

/mattias

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Threads in OCaml

[Xavier Leroy]

> [OCaml's "master lock"]
> How good or bad an arrangement is this?  I've been asked about the
> threading facilities of ocaml, but I don't know enough to compare and
> contrast, say, ocaml and Java.

On a multiprocessor machine, the "master lock" scheme is really bad,
since it prevents OCaml code from running on more than one processor
at once.

On a single-processor machine, it's OK, but not great.  Since there is
only one processor, it's not that bad to serialize execution of all
OCaml code -- execution of all threads is eventually serialized on the
processor.  However, the extra locking performed at the level of the
OCaml code can make thread scheduling a bit less smooth.  This depends
a lot on the fairness characteristics of the underlying system threads
library.

As compared with Java, threads in OCaml are a late addition to the
library and implementation, while the Java language, libraries and
implementations were designed from the very beginning with threads.

So one can expect Java threading to be somehow more mature; it is
certainly true for the libraries, not so true for the implementations
(e.g. Sun's JDK implementation sucks, w.r.t. threads as well as
w.r.t. everything else :-).

On the other hand, a thread-aware runtime system and library such as
Java's pays a significant execution penalty for single-threaded code.
In a way, you're paying all the time for hypothetical speedups on
less-and-less-common multiprocessor machines.  I'll let you decide if
this is a reasonable deal or not...

- Xavier Leroy




-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr