From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA13893; Fri, 27 Aug 2004 11:37:35 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA14360 for ; Fri, 27 Aug 2004 11:37:34 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i7R9bX0l026848 for ; Fri, 27 Aug 2004 11:37:33 +0200 Received: from warp (chateaudeau-4-82-225-176-25.fbx.proxad.net [82.225.176.25]) by postfix3-2.free.fr (Postfix) with SMTP id C6A62C140; Fri, 27 Aug 2004 13:32:56 +0200 (CEST) Message-ID: <004f01c48c19$9950d8e0$0100a8c0@warp> From: "Nicolas Cannasse" To: "Michal Moskal" , "John Goerzen" Cc: References: <200408250926.28629.jgoerzen@complete.org> <20040826.071059.48814499.yoriyuki@mbg.ocn.ne.jp> <200408251909.03050.jgoerzen@complete.org> <20040826214223.GA25370@roke.freak> Subject: Re: [Caml-list] Alternative Bytecodes for OCaml Date: Fri, 27 Aug 2004 11:38:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Miltered: at concorde with ID 412F00DD.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; cannasse:01 warplayer:01 caml-list:01 bytecodes:01 ocaml's:01 compile-time:01 automaticaly:01 api:01 vice-versa:01 runtime:01 reinventing:01 gcc:01 nativecode:01 api:01 endorsement:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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