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 UAA27505; Thu, 26 Aug 2004 20:28:35 +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 UAA13592 for ; Thu, 26 Aug 2004 20:28:34 +0200 (MET DST) Received: from postfix.evins.net (adsl-63-203-37-41.dsl.snfc21.pacbell.net [63.203.37.41]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i7QISWoM023594 for ; Thu, 26 Aug 2004 20:28:33 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.evins.net (Postfix) with ESMTP id E728035EEBA; Thu, 26 Aug 2004 11:28:30 -0700 (PDT) In-Reply-To: <71B2973D-F78A-11D8-95A4-000A27DEEC20@mac.com> References: <1093514139.15255.692.camel@pelican.wigram> <71B2973D-F78A-11D8-95A4-000A27DEEC20@mac.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: mikel evins , caml-list@inria.fr From: mikel evins Subject: Re: [Caml-list] Re: bytecode and native code at once Date: Thu, 26 Aug 2004 11:28:30 -0700 To: Paul Snively X-Mailer: Apple Mail (2.619) X-Miltered: at nez-perce with ID 412E2BD1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 stumbling:01 stab:01 objective-c:01 objective-c:01 annotations:01 ffi:01 ffi:01 expressive:01 runtime:01 extensively:01 alignment:01 gcc's:01 alignment:01 gcc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Aug 26, 2004, at 11:04 AM, Paul Snively wrote: > Finally, the one thing that's a stumbling block for most folks in our > circle when talking about O'Caml is the lack of platform bindings. > Mike Hamburg has taken a good stab at an O'Caml/Objective-C gateway. > That really needs finishing, and I had begun thinking about how to > automatically generate actual OS bindings by parsing Objective-C > headers and providing any necessary external annotations a la the > Forklift FFI, but I haven't gotten anywhere with that beyond thinking > about it. You might consider using ffigen to parse the headers and writing a simple parser in Ocaml to read its output. This is basically how the autogenerated ffi works in OpenMCL (ffigen can be hard to find; I can send you a copy of the version used with OpenMCL if you like). > > Anyway, I now take O'Caml very, very seriously. I believe it to be a > perfectly reasonable alternative to C++ for folks who want expressive > power, safety, reasonable resource consumption, and runtime > performance. Clearly there are areas in which there's still more work > to be done, cf. the conversations about floating-point representation > for high-performance 3D programming, or about memory-mapped files and > their interaction with the garbage collector. Nothing you're not > familiar with from your extensive work in Common Lisp and Mac OS X. > :-) Yep. :-) > > Your turn: what's your O'Caml story? I like languages. I like FP, always have. I've been messing with Caml and its variants for too long to remember when I started. For several years now I almost always had some small project going in Ocaml. Things heated up over the past two years as I found it possible to deploy Ocaml tools at work, and now I rely on it extensively for certain classes of project. Basically, I still think best and most fluidly in Lisp, and I explore ideas and prototype things there. If I want to deploy a compact, single-file native executable that is really fast, I rewrite it in Ocaml (which I find quite easy to do most of the time). When I absolutely need something in C, for those (rare) cases that Ocaml won't do the job, I write it first in Ocaml and then translate it to C, using Ocaml as a specification language to make it easier to write correct C code. An example of where I have to -- reluctantly -- do things in C or assembler is a virtual machine I'm doing where I really need to control register allocation, alignment, and specific bit-patterns in 64-bit words. I prototyped it in Ocaml using the Int64 library, then moved to C so that my word size was the native word size on AMD64, using GCC's extensions to control register allocation and alignment. The VM is about 30 times faster in C than in Ocaml and about one twentieth the object size, but that's specific to the nature of the project. I've also done projects in which Ocaml produced significantly faster code than GCC. Of course, if someone showed me that I could get the same results using Ocaml, I'd move right back in a heartbeat. :-) > >>> Is there some reason that asmdynlink, which is part of the Caml >>> Development Kit, doesn't address this? >> >> I don't know. All I was saying is that I knew nothing about it, >> because I had devoted no attention to the issue. >> > Right; fair enough. You can find the CDK, including asmdynlink, at > . > >>> >>> I also think that once MetaOCaml gets its native compiler done that >>> it will help answer the question as well, among others. I find >>> MetaOCaml very exciting! >> >> Yeah, I heard the same thing from Adam Megacz. I suppose I oughta >> check it out. >> > is the place. I don't know what the status > of their native-code support is, though; it's been a long time coming. Thanks for the pointers. --me ------------------- 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