From: Sylvain Le Gall <sylvain@le-gall.net>
To: caml-list@inria.fr
Subject: Re: A C to OCaml helper ?
Date: Mon, 17 Mar 2008 20:33:43 +0000 (UTC) [thread overview]
Message-ID: <slrnfttld7.tll.sylvain@gallu.homelinux.org> (raw)
In-Reply-To: <200803171507.10069.ober.14@osu.edu>
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
readable".
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)
Results:
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
code.
Regards,
Sylvain Le Gall
next prev parent reply other threads:[~2008-03-17 20:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 19:42 Fabrice Marchant
2008-03-12 20:51 ` [Caml-list] " Richard Jones
2008-03-12 21:03 ` Basile STARYNKEVITCH
2008-03-12 21:09 ` Fabrice Marchant
2008-03-13 6:41 ` Basile STARYNKEVITCH
2008-03-17 19:07 ` Kuba Ober
2008-03-17 20:33 ` Sylvain Le Gall [this message]
2008-03-13 1:56 ` Christopher L Conway
2008-03-13 3:14 ` Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=slrnfttld7.tll.sylvain@gallu.homelinux.org \
--to=sylvain@le-gall.net \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox