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 VAA10415; Fri, 27 Aug 2004 21:50:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA32668 for ; Fri, 27 Aug 2004 21:50:01 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from gw.orcaware.com (bdsl.66.12.233.174.gte.net [66.12.233.174]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i7RJnxgp019342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 21:50:01 +0200 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by gw.orcaware.com (8.12.8/8.12.8) with ESMTP id i7RJnokv027202; Fri, 27 Aug 2004 12:49:50 -0700 Message-ID: <412F9059.2080808@orcaware.com> Date: Fri, 27 Aug 2004 12:49:45 -0700 From: Blair Zajac User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Cannasse CC: Michal Moskal , John Goerzen , caml-list@inria.fr Subject: Re: [Caml-list] Alternative Bytecodes for OCaml References: <200408250926.28629.jgoerzen@complete.org> <20040826.071059.48814499.yoriyuki@mbg.ocn.ne.jp> <200408251909.03050.jgoerzen@complete.org> <20040826214223.GA25370@roke.freak> <004f01c48c19$9950d8e0$0100a8c0@warp> In-Reply-To: <004f01c48c19$9950d8e0$0100a8c0@warp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 412F9067.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; blair:01 zajac:01 blair:01 orcaware:01 caml-list:01 bytecodes:01 cannasse:01 ocaml's:01 compile-time:01 automaticaly:01 api:01 vice-versa:01 runtime:01 reinventing:01 gcc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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