Moving from caml Light to CSL

Guy.Cousineau@ens.fr
Wed, 14 Feb 96 10:23:44 +0100

From: Guy.Cousineau@ens.fr
Date: Wed, 14 Feb 96 10:23:44 +0100
Message-Id: <9602140923.AA00449@aubepine.ens.fr>
To: caml-list@pauillac.inria.fr
Subject: Moving from caml Light to CSL

Hi!

this is to report on my experience about moving from caml Light to CSL
and ask for advices on how to do that.

First, let me express my enthusiasm about the native code compiler
(clsopt).
I have translated to CSL the MLgraph library and tested it on some
programs involving heavy geometry computations.

At first, I have been disappointed by the byte code execution times
which were exactly the same than in Caml Light. This is certainly
partly due to my translation (see below) but mainly due to the
fact that my examples involve heavy complex numbers computations
(therefore essentially floating point computation) and output
of big PostScript files (again mainly involving printing floating
point numbers).

On the other hand, when I compiled my modules with cslopt,
I noticed a speedup factor of 12 for the computations
and of 4-5 for the output. This is very impressive.

Now, about the translation from Caml Light to CSL. I was faced
with a dilemna. I could either perform a deep translation which
could fully benefit from the CSL module constructs or a surface
translation which could enable me to keep a source code that
would remain (almost) compatible with Caml Light.

I chose the latter because I do not want to have to maintain
2 sets of different source files for MLgraph. I guess that many
people who devellop applications with Caml will have the
same problem. At some point, we shall make a decisive move
to CSL but it is to early to do that.

Now, if we try to keep a unique set of souce files for both languages,
we have to add 2 compatibility files butit is not enough.

Some preprocessing is required for instance because
#open "geometry";; in Caml light
should become
open Geometry;; in CSL

In fact, it might be the only problem assuming that compatibility
files eliminate lexical problems. For instance, if you use
characters, you have to add a variable definition for each
explicitly used character:
let space_char = ` ` ;; for Caml Light
let space_char = ' ' ;; for CSL

So, my question is: should we each write our compatibilty files
and preprocessors or should the community adopt common
format for compatibility files and preprocessor?

Anyway, thanks a lot for making CSL available.

--Guy Cousineau