Previous week Up Next week


Here is the latest Caml Weekly News, for the week of November 09 to 16, 2010.

  1. Type Safety comes to the iPad
  2. MLbrot: Mandelbrot Set in OCaml
  3. ocamlclean : an OCaml bytecode cleaner
  4. Generalized Algebraic Datatypes branch is ready for testing
  5. F# open sourced
  6. Other Caml News

Type Safety comes to the iPad


Jonathan Kimmitt announced:
I thought you might be interested to know that my new OCAML App for the iPad
was published on the iTunes Store yesterday. I believe this is a significant
achievement given the notorious reluctance of Apple to embrace languages other
than C/obj-C/C++ and I would hope it would promote wider dissemination of type

The real win would be if the new paradigm was accepted for teaching the new
generation of students etc, which would require greater acceptance by
potential employers which is a bit of a chicken/egg scenario.

Anyway I am inordinately proud of my new publication and if you know anybody
who has an iPad, please let them know about it.
Later on, Jonathan Kimmitt added:
Perhaps a further explanation is necessary. What I have done is ported the
interpreter ocamlrun to the iPad and added a gui based on Graphics.cma and
bound ancillary libraries such as Num.cma into the executable. The ocaml
interpreter itself is written in ocaml and is identical to the workstation
version of the same release. This means you can drop a compiled library into
iTunes and then load it immediately in iPad (provided it does not use shared
objects which are not bound into the signed app.

So you could say the app is written in ocaml. I have called it 'OcamlExample'
with the intention that users will substitute their own code making use of
#use or #load statements

The alternative option to use ocaml's own native code generator seems to me a
bit pointless because the app is then hard-wired to a given function. But if
anyone wants to write a type-safe game or something, this would be an
interesting. You could use the standalone codesign function of xcode perhaps

The other thing you will have gathered is it allows creative activity on the
iPad, without becoming a developer.

With this version you cannot compile to a file on the iPad, but you can #use
source files which then get compiled into memory in a sense. But the ability
to exchange compiled bytecode with the host running iTunes means this is not
too much of a limitation in my view.
Later on, Jonathan Kimmitt added again:
The application itself is written in Xcode. You need to be a member of the
development program at £59/$99 or equivalent per year to get access to the
signing keys if you need to modify 'extern' functions (native C code of the

You don't need anything apart from iTunes to download (using document sharing)
source code in .ml files to the iPad and execute in the App

Or you can type in ocaml statements directly into the interpreter for example
draw_rect 100 100 200 200;; will draw a box immediately because the default
startup open the graphics library.

There are some irritations, for example itunes does not allow a document with
the name .ocamlinit to be selected for download, so I provide an 'ocamlinit'
instead to execute if it exists. If it doesn't exist then the default startup
is executed that comes with the App

The built-in keyboard is not ideal for ocaml with its dearth of easily
accessible symbols. An external keyboard is recommended if you want to do real
work. Another issue is the lack of a decent editor suited to programming -
perhaps someone could port chamo to the iPad ?

I envisage a typical program would be developed on the workstation, compiled
to a .cma file and then downloaded to the iPad. However I have not tried this
route to see if it works. you need to make sure the ocaml version is

There is no dynamic loading allowed - all the standard library that was
relevant is linked in statically
Daniel Bünzli then added:
There are a few instructions here [1].




MLbrot: Mandelbrot Set in OCaml


Continuing the thread from last week, Goswin von Brederlow asked and Daniel de Rauglaudre replied:
> Only looked at the pictures so far but they do look good. I'm missing
> some screenshots though. How does the interface look like? I assume you
> have some way to select a part of the image to zoom?

When clicking with left button, you zoom (twice) centered to that
point. Middle button: recenter. Right button: unzoom. And the keys
'z' and 'x' zoom and unzoom, 'Z' and 'X' do it 10 times.

> It would also be nice to know a bit more about what drawing methods you
> support. Do you just compute every pixel or do you support guessing,
> boundary trace, tesseracting?

I compute every pixel. I searched on the Internet for faster algorithms
but I did not find. What are guessing, boundary trace and tesseracting ?
Well, I am going to google these terms :-)

> Also do you have a coloring mode using distance estimation?
> E.g. color all points < 0.5 pixels distance from the M-Set white.

No. I see that I have many things to learn... :-)

> Can you zoom and refine the image like xaos does?

I did not know xaos, so I installed it, and tested it a little. Well, it
is very fast indeed! Yes, I refine the image (you mean around Mandelbrot
islands ?) by extending the number of iterations some times.

> Do you support the single orbital iteration method? That puts a 3x3
> points grid over the image plus 4 control points. Points of the image
> are aproximated from the 9 grid points. The 13 points are iterated a few
> iterations as long as the 4 reference points are close to approximating
> the same points. If the error becomes to great you go back an iteration,
> subdivide the grid into 4 parts, approximate the missing point and
> repeat for each subgrid. Esspecially on dep zooms this can speed up
> calculations by magnitudes since the first few thousand iterations of
> each point will be done by calculating only 14 points and approximating.

Oops, I have to read that again, that seems interesting but at the
first reading, I don't understand everything.

> You say you are using OpenGL, so where are the 3D images?


I was just looking for a graphic toolkit instead of mine (olibrt,
which is old and works only on X Window). Many people here (Inria)
use OpenGL, to indeed doing 3D, so I tested, but only in 2D. Well,
actually, I tested it on a mini-small-tiny-mplayer I wrote in OCaml:
OpenGL is interesting because of Direct Rendering which accelerate the

So, I tested OpenGL in Mlbrot, after having separated the graphic
toolkit from the rest of the program. Perhaps, that makes it work
under Mac and Windows? I don't know. And a few days ago, I tested
with Gtk, which appears to be the good solution and I continue
programming with it.

Perhaps I try out the 3D feature of the Mandelbrot Set one day. I just
looked at a couple of sites talkint about it.

> I've converted some 20 year old code into ocaml a while back that
> generates 3D images. Putting the height map into OpenGL and render it
> through that would probably improve the quality:

Interesting, but I would prefer something more 3D, like cauliflowers.

ocamlclean : an OCaml bytecode cleaner


Philippe Wang announced:
ocamlclean is now available in a separate package so that you don't have to
get the whole ocapic distribution just to try ocamlclean.

More information:
ocamlclean takes a bytecode executable (which are generally but not
necessarily produced by "ocamlc" compiler) and reduces its size by eliminating
some dead code. Dead code is discriminated statically. (It's impossible to
eliminate all dead code, but in some cases it can reduce bytecode executables
tremendously) It is meant to be compatible with standard bytecode such as
produced by ocamlc. (DBUG section is currently not supported and is removed
during the cleaning process. Other unsupported sections are left untouched.)

Web site:

Benoît Vaugon
Julien Signoles asked and Philippe Wang replied:
> Is ocamlclean compatible with dynamic loading? That is code potentially used 
> by some unknown dynamically-loaded code must be kept.

ocamlclean removes code to which there is no possible path. For instance, this
program :
 let plop = succ [1;2;3];;
uses module List (for map) and module Pervasives (for succ) but doesn't use a
lot of functions of List or Pervasives (e.g., List.iter, List.fold_left,
Pervasives.print_endline). So most functions of modules Pervasives and List
are removed from the bytecode executable.

If one dynamically loads some bytecode, for instance the previous program
 let plop = succ [1;2;3];;
 let _ = Dynlink.load "stuff.cmo";;
then stuff.cmo should not reference anything that may not exist, such as
Pervasives.(@) since it has been removed by ocamlclean. And we are not
supposed to know at compile-time what stuff.cmo needs from stdlib. Hence I
guess everything should be kept and ocamlclean not used.

On the other hand, if we statically know what is in stuff.cmo, then why load
it dynamically? (I guess the answer can be "just for fun" but I'm not so sure
it's such a good answer :-)

Though, I'm not very familiar with Dynlink, and I'm not sure what
"Dynlink.allow_only" really does...

I haven't tested using dynlink to load a self-sufficient module. I might work,
but I don't really see how it can be usefull anyway...

Generalized Algebraic Datatypes branch is ready for testing


Jacques Le Normand announced:
I am pleased to announce that the GADT extension to O'Caml is now complete,
apart from camlp4, and ready for testing:

svn checkout

You can find more information here:

F# open sourced


Mihamina Rakotomandimby announced:
Manao ahoana, Hello, Bonjour,

Good thing? Bad one? 

(Just "Friday discussion" :-)) 

Misaotra, Thanks, Merci. 
Yoann Padioleau asked and Laurent Le Brun replied:
> I thought it was already open source ... What is new with this announcement ?
> When I downloaded F# a few months ago the source of the compiler 
> were already in the package.

The source was available, but it was not under an open-source license
(it was Microsoft Research Shared Source license). There were a few
restrictions (i.e. on its redistribution). It's now an Apache 2.0

> Does it work with mono ?

Yes. The last F# release is a bug-fix for Mono. Unix users might be
interested by the packages:
Also, since the license change, the Mono team plans to distribute F#
as part of Mono for both OSX and Linux.
Yoann Padioleau then said and Laurent Le Brun replied:
> I've downloaded mono and the fsharp package for the Mac and 'fsharpi' seems to work. 
> Where are located the header files of the standard library ? (the equivalent of list.mli for instance). 
> There is only .dll files in /usr/lib/fsharp/ 

Source code is not included in these packages. You can get the .fsi 
files from the zip release at, or from the full source code 
at However, you'll get a more complete 
documentation online (see for links). 

F# developers often rely on their editor for completion and 
exploration. Monodevelop plugin for F# will be released in a few days 
(and I'm working on F# Intellisense support in Emacs). 

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at

ocaml-sphinx 0.0.1:

MLBrot 1.00:

Developing the Mirage networking stack on UNIX:

A First-Principles DNS Client:

Source code layout:

Subgroups are equalizers, constructively?:

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt