Re: [Caml-list] Alternative Bytecodes for OCaml

["Nicolas Cannasse" <warplayer@free.fr>]

> It's probably possible to implement OCaml's objects using .NET
> objects, using one interface per method, or casting everything down
> to System.Object, but this doesn't seem a) pretty, b) fast nor c)
> interoperable.  And c) is one of the main reasons .NET exists.
> You would at least have to add .NET-like classes and interfaces to OCaml
> to make using .NET libraries possible. And if you want to write
> libraries in such OCaml.NET, you would be restricted to these types at
> the edges. And this in turn means you have to have very good support
> for these features, and this turns out not to be so easy -- after one
> year of development we still don't have full support for this stuff in
> Nemerle.

I agree with you here, the main problems OCaml and other functionnal
languages targeting CLR faces here are interoperability and performances.

There is two kind of VM : typeless ones (such as OCaml one) which bytecode
does not contains any RTTI - since all checks are done at compile-time, and
typed VMs (such as .NET CLR and the JVM). Typed VMs are a lot
ObjectOriented, and all performances (for instance GC) are tuned for an OO
type system. This is a real problem for the future of functionnal languages
: if the mainstream technology becomes .NET CLR in the next five years, yes
there will be an open source alternative in Mono but it will still be a pain
and have a performance cost to run a functional language on such an OO VM .
And even if it runs, what about interoperability ? How to expose correctly
(and automaticaly) a functional style API to an OO language, and vice-versa
? Since the type system on the language is directly embedded into the VM,
one need to "forget" functionnal style when generating bytecode.

There is several attempts to fix this problem (LLVM might be one), but none
from Sun or Microsoft. That's why the functionnal languages community should
focus on interoperating its languages in a single runtime system. If we
don't, we might loose to the leverage that the CLR provides. There is
already a big set of languages (Nemerle among them) that are targeting the
CLR because they don't want to get through reinventing the well and writing
a native code generator, an other set of languages (such as Felix) are
generating C code in order to leverage on GCC.

Ocaml is great for writing DSL, and have both very efficient bytecode and
nativecode compilers. However theses two technologies are right now reserved
to OCaml itself.  If they were more "opened" (means : documented, provide
API and tools to ease code generation, ...) , it would enable DSL writters
to leverage on theses great technologies of OCaml and might interest as well
other languages writters. However that goal might require some endorsement
and active support from OCaml team since I guess it will need modifications
in order to support other languages.

Remarks anyone ?

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners