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 WAA11131; Fri, 27 Aug 2004 22:47:17 +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 WAA11539 for ; Fri, 27 Aug 2004 22:47:16 +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 i7RKlG7R019097 for ; Fri, 27 Aug 2004 22:47:16 +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 53291C023; Sat, 28 Aug 2004 00:42:40 +0200 (CEST) Message-ID: <008501c48c77$27ffaa00$0100a8c0@warp> From: "Nicolas Cannasse" To: "John Goerzen" Cc: "Michal Moskal" , References: <200408250926.28629.jgoerzen@complete.org> <20040826214223.GA25370@roke.freak> <004f01c48c19$9950d8e0$0100a8c0@warp> <200408270809.28272.jgoerzen@complete.org> Subject: Re: [Caml-list] Alternative Bytecodes for OCaml Date: Fri, 27 Aug 2004 22:48:06 +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 412F9DD4.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 prey:99 interfacing:01 seamlessly:01 focusing:01 runtime:01 runtime:01 nativecode:01 api:01 camlp:01 lacking:01 generic:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > I agree with you here, the main problems OCaml and other functionnal > > languages targeting CLR faces here are interoperability and > > performances. > > No arguments here, but I would like to expand a but on the performance > issue. I have every reason to believe you are right about it, but one > important thing to remember is that it may not matter to many. In > other words, let's not fall prey to premature optimization. I agree. I was talking of performances as one of the advanges coming from technology leverage. But that's true it's not the best one : accessing to many libraries or interfacing seamlessly with other languages are much more powerful features that we can get when focusing on a particular runtime system. However, my point was that current (to-be-)mainstream runtime systems (.NET CLR and JVM) are not offering the best executation environements for functional languages and we are then loosing some of the advanges the OO languages are getting with no cost because theses VMs have been designed with OO in mind. In the long term, that might be quite a big handicap for functional languages not to be able to keep up in terms of performances or easiness of interoperability when compared to OO languages. > > 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 > > I'm not 100% certain what you're talking about here, but I'll guess and > try to share my thoughts along those lines :-) > > There is a lot of great stuff in camlp4. It is, in my opinion, the > single most powerful and unique part of OCaml. I've dabbled with it > myself, but there's a lot that's lacking, too. Despite the tutorial > and reference, the learning curve is quite steep due in part to the > syntax and available parsers/lexers, and in part to the academic rather > than how-to nature of the documents. > > Then there's a whole other part of OCaml that is untapped. For > instance, the OCaml source includes everything necessary to write, in > OCaml, the toplevel interpreter. However, the OCaml modules installed > on the system don't provide enough for someone to embed an OCaml > interpreter (aside from the interactive kind) or generic printer in > their own code. I think part of the problem could be solved simply by > installing more bits of the OCaml distribution on people's systems. That was part of my thinking. A lot of technologies that are available in the OCaml compiler sources are not made accessible to the OCaml programmer. I would like for instance be able to create on the fly Lambda OCaml AST, generate corresponding ocaml bytecode, and execute it : such a feature would be great for DSL since it will remove the need to implement an efficient runtime system (ocaml one will be used in place). 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