English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
A C to OCaml helper ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-03-17 (20:34)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: A C to OCaml helper ?
On 17-03-2008, Kuba Ober <ober.14@osu.edu> wrote:
> On Thursday 13 March 2008, Basile STARYNKEVITCH wrote:
>> Fabrice Marchant wrote:
>> > On Wed, 12 Mar 2008 22:03:51 +0100
>> >
>> > Basile STARYNKEVITCH <basile@starynkevitch.net> wrote:
>> >> Fabrice Marchant wrote:
>> >>> Please does it exist some tool that could do at least the very
>> >>> mechanical first parts of the translation of a C source to OCaml ?
>> >>
>> >> Why do you want to do that?
>> >
> I disagree somewhat. A good starting point is to have mechanically-translated
> code that works, and then work on refactoring it to utilize what OCaml has to
> offer.
> In fact, C++ may provide much better translation results than C, since, if
> properly written, the C++ sources will utilize higher-level primitives that
> look better in OCaml. C is a really primitive language, by OCaml's 
> standards ;)

In my former work i have been able to see (and to participate) to some
kind of langage rewrite (PLI -> C++ for example). This is interesting,
because it "mechanically work" but it is far from being "humand

Just to give you a couple of example:
* integer arithmetic are most of the time not what you think (i.e.
 COBOL/PLI doesn't have the same integer representation, C play with bit
 arithmetic, a lot of people like i++ on pointer...)
* float arithmetic is a nightmare (less than integer because you cannot
 do a lot of tricky stuff with it)
* with 99% of the tools you will find, you will loose your comments
* you will get a lot more lines than the initial program (because most
 of the tools do a local rewrite translating one token in langage SRC to
 many token in langage DST)

You will get a BIG program without any comments, containing tricky
behavior in one langage translated to buggy source code in OCaml (i let
you think about the pointer/pointer arithmetic problem).

BUT i am not saying this is not possible... It is always possible, you
will just get a pile of junk that works more or less... But don't think
you will be able to dig into a huge amount of code autogenerated without
comments and anything like that.

(just for fun: imagine all C macro expanded everywhere in your program
and then translated to ocaml -- take a look at stdlib.h to see how many
macros it uses ;-)

Conclusion of my former work: it works, but soure need to be near
destination language (e.g. COBOL MVS -> COBOL MicroFocus -- which is
already a nightmare).

IMHO, the real good way: define piece of code that will stay in C,
translate other parts, by hand, into OCaml, link both. When you feel
this or that part can be rewritten, remove the C stub and replace it.
And use the former C part for regression testing against the new OCaml

Sylvain Le Gall