From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2CG5MOe013168 for ; Mon, 12 Mar 2012 17:05:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoCAE4eXk9KfVM2kGdsb2JhbABDpAg0iB8BiHIIIgEBAQEJCQ0HFAQjggkBAQEDARICLAEbEgsBAwELBgULGiEiAREBBQEKEgYTEgcBCIdjBQueTQqLeIJxhQM/iHQBBQuKJQWGTASCXpJuiUmEfD2CVYEwgVMI X-IronPort-AV: E=Sophos;i="4.73,570,1325458800"; d="scan'208";a="148884552" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Mar 2012 17:05:26 +0100 Received: by eekd17 with SMTP id d17so1542331eek.27 for ; Mon, 12 Mar 2012 09:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5sQqT5sEVlXmmAL+QvlodUGv3PadfazMVL1LxoCVDAQ=; b=cAl1TeObxpqCvnOa6Ml0IZo6YBacUZh5M9TyZQr++OBh42Ncq8FGkAg+pyA0JIU7N/ i4fXQTuhCTlCl3C+3y8gjO/KA55TT4igtwnMSnCI2z10J59mlaYtCzPs/beWLiX5nJHK MYHK3i0XD+BlGuS2Lh5EXvTmNzd8ufkx0/iJ1ySk7y8MiGMruJokUnfk5v2gi1jWAu5L uNmuIrlwTT3KAej5WVeCny0dZL635aZrz5tH3uCdEfZNkLWEj1lomcT1FLMqsa4+ke/b YyZrqFkcjNWJBdynfpXcz6LfYqqGy2Si7r2pqmoq4B85FWy92beefolFoOAIdvrsJ1EB bSUA== Received: by 10.52.65.134 with SMTP id x6mr14811109vds.60.1331568326338; Mon, 12 Mar 2012 09:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.201 with HTTP; Mon, 12 Mar 2012 09:05:06 -0700 (PDT) In-Reply-To: <051FF700-7AB2-43CE-A917-53461BB3EEE6@x9c.fr> References: <4F5A41C6.10505@inria.fr> <051FF700-7AB2-43CE-A917-53461BB3EEE6@x9c.fr> From: Philippe Veber Date: Mon, 12 Mar 2012 17:05:06 +0100 Message-ID: To: "forum@x9c.fr" Cc: caml users Content-Type: multipart/alternative; boundary=bcaec5015f3f15e92a04bb0de986 X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] A js_of_ocaml equivalent for the JVM? --bcaec5015f3f15e92a04bb0de986 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Xavier and Johan for the replies. 2012/3/9 forum@x9c.fr > > Le 9 mars 2012 =E0 18:45, Johan Grande a =E9crit : > > > Le 09/03/2012 18:12, Philippe Veber a =E9crit : > >> Dear camlers, > >> I used js_of_ocaml several times and was really stunned of how clever > >> (notably because writing interfaces boils down to writing types) and > >> efficient this approach is. Would a similar thing work for the JVM, th= at > >> is a compiler from ocaml bytecode to java bytecode? > > It is not easy to envision such a tool on the JVM, because of the current > restrictions imposed on Java bytecode. As an example, the size of a method > is currently limited to 64Ko, which is clearly way too small for non > trivial > programs. I see the point. It sure is a problem to reuse the same compilation scheme than in js_of_ocaml. > > > >> I guess it wouldn't > >> provide a full interoperability with java, in the sense that creating = or > >> extending classes may not be possible (well, why not after all?). > >> However, being able to run an ocaml program on the JVM reusing existing > >> java libraries would be so useful already! > > I am currently working on this for OCaml-Java (see below). > I must admit one of the most exciting feature of js_of_ocaml (beside efficiency) is the way ocaml interfaces with javascript. I remember the procedure was much heavier with nickel. In another thread ( http://www.mail-archive.com/caml-list@inria.fr/msg02094.html) you said that this has changed in the version you're currently developing. I look forward to see how it works (I'm in if you need alpha testers). > > > >> Are there known obstacles to this? Has anyone tried something in this > >> direction? > > Well, no real obstacle as OCaml-Java showed. > However, OCaml-Java 1.x is still a bare proof of concept due to both > poor design choices and JVM limitations. But then came Java 1.7 and > some limitations were removed (e. g. a garbage collector better suited > to functional languages, and an implementation of method handles). > OCaml-Java has been largely rewritten and now exhibit acceptable > performances. > This is really great. > > > >> Would there be a chance to support multicore programming that > >> way? > > Yes, it is actually working. But not released yet. > Starting from vanilla OCaml, you "only" need two things: > 1/ have a reentrant runtime; > 2/ have a parallel garbage collector. > OCaml-Java implements the former, while all modern JVMs provide the latte= r. > So, basically, it just works. itou > The great difficulty is then to provide the good > abstractions to make the life of the programmer as easy as possible. > I mean: who would like to program with locks? > Well I'm not much into multicore programming myself, but at least for advertisement purposes, it cannot hurt ;o). > > > >> I hope these are not silly questions (sorry if they are!) > > > > http://ocamljava.x9c.fr > > Thanks for the plug. However, OCaml-Java is quite different and provides > two tools: > - an equivalent of ocamlrun written in Java (meaning you can interpret > OCaml bytecode inside a JVM); > - an equivalent of ocamlc/ocamlopt for Java (meaning you can compile > OCaml sources to Java jar files to be executed by a JVM). > Thanks for the news and clarifications! > > > Kind regards, > > Xavier Clerc > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --bcaec5015f3f15e92a04bb0de986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Xavier and Johan for the replies.

2012/3/9 forum@x9c.fr <forum@x9c.fr>

Le 9 mars 2012 =E0 18:45, Johan Grande a =E9crit :

> Le 09/03/2012 18:12, Philippe Veber a =E9crit :
>> Dear camlers,
>> I used js_of_ocaml several times and was really stunned of how cle= ver
>> (notably because writing interfaces boils down to writing types) a= nd
>> efficient this approach is. Would a similar thing work for the JVM= , that
>> is a compiler from ocaml bytecode to java bytecode?

It is not easy to envision such a tool on the JVM, because of the cur= rent
restrictions imposed on Java bytecode. As an example, the size of a method<= br> is currently limited to 64Ko, which is clearly way too small for non trivia= l
programs.I see the point. It sure is a problem to reuse the sa= me compilation scheme than in js_of_ocaml.

=A0


>> I guess it wouldn't
>> provide a full interoperability with java, in the sense that creat= ing or
>> extending classes may not be possible (well, why not after all?).<= br> >> However, being able to run an ocaml program on the JVM reusing exi= sting
>> java libraries would be so useful already!

I am currently working on this for OCaml-Java (see below).
I must admit one of the most exciting feature of js_of_ocaml (be= side efficiency) is the way ocaml interfaces with javascript. I remember th= e procedure was much heavier with nickel. In another thread (http://www.mail-= archive.com/caml-list@inria.fr/msg02094.html) you said that this has ch= anged in the version you're currently developing. I look forward to see= how it works (I'm in if you need alpha testers).
=A0


>> Are there known obstacles to this? Has anyone tried something in t= his
>> direction?

Well, no real obstacle as OCaml-Java showed.
However, OCaml-Java 1.x is still a bare proof of concept due to both
poor design choices and JVM limitations. But then came Java 1.7 and
some limitations were removed (e. g. a garbage collector better suited
to functional languages, and an implementation of method handles).
OCaml-Java has been largely rewritten and now exhibit acceptable
performances.
This is really great.
=A0


>> Would there be a chance to support multicore programming that
>> way?

Yes, it is actually working. But not released yet.
Starting from vanilla OCaml, you "only" need two things:
=A01/ have a reentrant runtime;
=A02/ have a parallel garbage collector.
OCaml-Java implements the former, while all modern JVMs provide the latter.=
So, basically, it just works.
itou
=A0
The great difficulty is then to= provide the good
abstractions to make the life of the programmer as easy as possible.
I mean: who would like to program with locks?
Well I&#= 39;m not much into multicore programming myself, but at least for advertise= ment purposes, it cannot hurt ;o).

=A0


>> I hope these are not silly questions (sorry if they are!)
>
> http://ocamljava= .x9c.fr

Thanks for the plug. However, OCaml-Java is quite different and provi= des two tools:
=A0- an equivalent of ocamlrun written in Java (meaning you can interpret<= br> =A0 =A0OCaml bytecode inside a JVM);
=A0- an equivalent of ocamlc/ocamlopt for Java (meaning you can compile
=A0 =A0OCaml sources to Java jar files to be executed by a JVM).

Thanks for the news and clarifications!
=A0


Kind regards,

Xavier Clerc



--
Caml-list mailing list. =A0Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--bcaec5015f3f15e92a04bb0de986--