Nicolas Cannasse wrote:

>>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.
>  
>

I haven't looked at Parrot too closely, but where does that fit into 
this?  Would that not be considered a VM here?  Wouldn't Parrot be 
pretty good because it supports Python and Perl which have more 
functional aspects in them than C, C++ and Java?

Regards,
Blair

-------------------
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