Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Graphmanipulation in Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Diego Olivier Fernandez Pons <Diego.FERNANDEZ_PONS@e...>
Subject: Re: [Caml-list] Graphmanipulation in Ocaml

> Does anyone have experience porting Sml code to Caml ? I would
> expect everything is fairly mechanic, or can there be differences
> which require non-trivial effort to resolve ?

I have some experience porting from Haskell (Edison, Parsec), SML
(parts of SML/NJ standard library, parts of MLKit standard library,
some code from Erwig FGL and some code from Nikolaj Bjorner which
seems to have been used in the stanford temporal prover).

Porting is easy and fast. Redesigning is hard and slow.

example : SML has (or had) two kind of polymorphic variables 'a and
''a because of the polymorphic comparison problem. The first time you
port SML code you just don't care since the resulting Caml code seems
to be working fine (the first time I didn't even notice it since I
never type-checked the SML code).

The problem is that not having a correct polymorphic comparison will
lead to several work around according to who wrote the SML code :
functors, functions with a comparison function argument, records
saving a generic comparison function, etc. And this will give to the
whole library a specific 'style' (even if the original problem -
whatever it may be - was solved in a next version of the language)

There is a very old discussion on the Caml list when the first Set
module was released by Xavier Leroy
( which gives you an idea
of the problems one can face :
- 'a ->'a -> int comparison or Smaller | Equal | Greater
- functors, polymorphic data structures, objects or records ?
- generic or specific ?
- public or private constructors ?
- dirty imperative but fast tricks or pure and beautiful functional ?

And since you are working in Caml you will want your library to have
more caracteristic Caml style. There begins the hard part.

Conclusion : no really difficult points from SML to Caml (most of the
time you just guess what is happening and what to do). You may look at
SML vs. Caml ( which
is a bit out of date with respect to the Caml part (I have asked
Andreas Rossberg several times to update it but he does not seem to
want to).

        Diego Olivier

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: