RE: [ObjectWeb architecture] just an idea for (Java) native compilation

["dominique.devito" <dominique.devito@xxxxxxxxxxxxxxx>]

>===== Original Message From "Christophe Ney" <christophe.ney@xxxxxxxxxxxxx> 
=====
>Hi Dominique,
>
>This is something we should definitively explore. Will you
>get the chance to attend our meeting this Friday? If so we
>will be very happy to learn more from your effort then.
>
>Thanks,
>Christophe
>
>Christophe Ney
>President of the Executive Committee
>ObjectWeb Consortium

Hi,

* detailled points about Java and OCaml
---------------------------------------

I have just noticed different facts :

- CGJ seems to move slowly,

- INRIA has an outstanding compiler technology (the Cristal project is a 
great 
team),

- Java still needs a native compiler.

- Here are the OCaml features :
  * OCaml has native-code compilation (ocamlopt),
  * OCaml permits to define primitive types, classes, mutable data structures,
  * OCaml offers exceptions (try-catch-throw with different names, same as 
Java : the exception Invalid_argument is raised if the access is out of 
bounds...)
  * OCaml permits to interface C with Objective Caml,
  * OCaml libraries includes a threads library, the graphics library, the 
dynlink library (dynamic loading and linking of object files)...
  * The GC of OCaml is one of the top GCs I know,
  * OCaml permits already to define parametrized types, functions... just as 
Java in JDK 1.5...
  * OCaml enables to define enumerations just as Java in JDK 1.5.
  * etc.

So, as said before, at first thoughts, one could imagine the way 
Java->OCaml->native code for compiling to Java to native code. If we think 
only in a OO perspective, one could imagine a one-to-one mapping on Java and 
OCaml features.


* Possible problem(s) :

  - I don't think that OCaml includes the unicode support. A solution may be 
to design a specific OCaml class for supporting unicode characters. But it 
would not permit to use operator symbolic shortcuts for manipulating 
new-unicode-strings in OCaml.

  - I don't think that OCaml includes the reflection support. A solution may 
be to support Java-like reflection through (hash)tables generated during the 
Java->OCaml generation.

  - other problems ?


* Ideas for the Java->OCaml generation
--------------------------------------

My first just-of-the-brain idea was to imagine a generator Java->Ocaml driven 
by template transformations : one Java instruction would be transformed into 
a 
code portion in OCaml.

We have, here, to cross the gap Java->OCaml. In fact, if needed, one could 
imagine to generate code, not for OCaml, but for OCaml-2 (a syntax-simplified 
OCaml language, simplified for generation purposes). Look at 
<http://caml.inria.fr/camlp4/index.html> : this page is devoted to Camlp4 : 
"Camlp4 is a Pre-Processor-Pretty-Printer for Objective Caml. It offers tools 
for syntax (grammars) and the ability to modify the concrete syntax of the 
language (quotations, syntax extensions)." So, if needed, one could imagine 
the way Java->OCaml-2->OCaml->native code. May be, it will be simpler.

Let's enter into more details.

If the template approach works (it has, yet, to be validated), I imagine a 
generator with 2 phases : 
(1) parsing the Java code and create a typed-code representation-hierarchy
(2) cross the representation-hierarchy (top-down) and apply template-rules in 
order to replace Java code into OCaml code.

One could imagine during phase (2) using templates :

* templates defined in XML

* template defined with 3 parts : pre-template, core template, and 
post-template. Just think about class definition :
  - pre-template : class XXX {-like
  - core template : member and method definitions
  - post-template : }-like

  For generating class in OCaml, one start to write the pre-template, then 
the 
core and after the post-template.

* predefined variables to use in templates, like :
  - $type in template for member class,
  - $name in template for class,
  - $return-type, &argument-type[i] in template for method,
  - ...

* correspondance tables into template file for basic conversion (like, for 
example, for converting the string 'int' into 'integer').

* correspondance tables into template file for mapping Java instructions to 
OCaml instructions. Let's imagine one OCaml specific class is defined to map 
unicode String class in Java. The String Java-class has to be mapped to this 
String OCaml-class and this mapping may be done through some XML coding into 
the template file.

* ...

Just my 2 cents : this is a somewhat naive first draft, so be lenient :-)

I will send an email to a guy of the INRIA Cristal projet to see what he 
think 
about it.


* the future of Java and OCaml
------------------------------

There is also the F# language (a son of C#) from Microsoft research teams. 
The 
aim of F# is to combine the safety and productivity of ML and Caml with the 
libraries, tools and cross-language working of .NET. See 
<http://research.microsoft.com/projects/ilx/fsharp.aspx>.

I have heard that the F# features are driving the future C# features. That 
could be the way followed by Microsoft as I imagine that Microsoft is 
searching new features to add new valuable features to C# in order to 
distinguish C# from Java ! And as Java is driven by features-libraries of C# 
(see generic types and WebForms-Microsoft and then, the emerging response 
into 
the Java world : JavaServerFaces), one could imagine that in some future, 
Java 
will include OCaml features...


* Future meeting
----------------

Well, I have not planned to go to the meeting.
In fact, these ideas above are just-of-the-brain ideas (I have no PPT, no 
slides...).

Note that, even if I am working in a Thales subsidiary, I am not talking here 
from the Thales point of view. Just my own point of view.

Unfortunately, I am not (directly) funded by Thales to work with ObjectWeb...


Dominique


>
>mailto:christophe.ney@xxxxxxxxxxxxx
>http://www.objectweb.org
>phone +33 4 76 61 54 87
>mobile +33 6 87 76 96 14
>> -----Original Message-----
>> From: dominique.devito@xxxxxxxxxxxxxxx
>> [mailto:dominique.devito@xxxxxxxxxxxxxxx]
>> Sent: Wednesday, September 24, 2003 10:00 PM
>> To: architecture@xxxxxxxxxxxxx
>> Subject: [ObjectWeb architecture] just an idea for (Java) native
>> compilation
>>
>>
>>
>> Hi,
>>
>> This is just an idea for (Java) native compilation.
>>
>> INRIA has an outstanding knowledge about native compiler
>> technology. To be more precise, INRIA has developped a native
>> compiler for the "Objective Caml" language. Caml is a
>> strongly-typed functional programming language from the ML
>> family. OCaml (Objective Caml) and Caml Light are two open
>> source implementations of Caml developed at INRIA
>> Rocquencourt, projet Cristal. See <http://caml.inria.fr/> and
>> <http://caml.inria.fr/ocaml/>.
>>
>> INRIA has started at January 2001 the Caml consortium (like
>> the ObjectWeb consortium) : the Caml consortium federates the
>> design and development of the Caml language and its
>> programming environment. The Objective Caml (OCaml) compiler
>> is released by the Caml Consortium and performs very well :
>> Objective Caml ranks 2nd on speed (between C and C++) on Doug
>> Bagley's computer language shootout ! See
>> <http://www.bagley.org/~doug/shootout/>.
>>
>> So, why not joining Caml & ObjectWeb consortiums strengths
>> for developping a Java compiler ? One way could/would be to
>> develop a bridge Java->OCaml as OCaml's object-oriented
>> features are similar to Java's object-oriented features
>> (Ocaml also includes functional features, module features...).
>>
>> What do you think about this idea ? Silly idea :-) ? Good idea ?
>>
>> Best regards,
>> Dominique
>>
>>