From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA24203 for caml-red; Tue, 13 Feb 2001 08:14:38 +0100 (MET) 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 VAA14087 for ; Mon, 12 Feb 2001 21:24:54 +0100 (MET) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f1CKOqf25652; Mon, 12 Feb 2001 21:24:53 +0100 (MET) Received: from checkerlap.d6.com ([64.160.55.80]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G8N00IIXT18BY@mta6.snfc21.pbi.net>; Mon, 12 Feb 2001 11:34:22 -0800 (PST) Date: Mon, 12 Feb 2001 11:37:36 -0800 From: Chris Hecker Subject: Re: OCaml for Windows: a suggestion In-reply-to: <20010211105222.B10493@pauillac.inria.fr> X-Sender: def6@shell16.ba.best.com To: Xavier Leroy , Jean Martos Cc: lionel.fourquaux@wanadoo.fr, caml-list@inria.fr Message-id: <4.3.2.7.2.20010212110219.00c2e570@shell16.ba.best.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable References: <3A7D9742.16A775CB@wanadoo.fr> <000201c09213$3acd4960$d7688aa4@wfr01946> <3A7D9742.16A775CB@wanadoo.fr> Sender: weis@pauillac.inria.fr A couple of suggestions were made for the Windows OCaml port. I disagree= with both. I'll get to the details in a moment. =20 First, it's important to know what your goals are. Is the goal to make= OCaml more widely used for production code on Win32? That would be my goal= if I were running the OCaml project. Is the goal to make it more "open= source" and less dependent on commercial software? That's a fine goal as= well, but it conflicts in some ways with the former goal. 1. making the port a gcc port rather than an msvc port The reality of the situation is that almost all production programmers on= Win32 platforms use msvc. Moving the port to a gcc variant would just make= it even harder for those people to try out ocaml if they ever want to build= the compiler. It will also have a perception problem with professional= programmers, who don't take gcc on Win32 very seriously (for lots of good= reasons). And finally, if the port is done in such a way that a standalone= runtime ocaml .exe cannot be produced that doesn't depend on cygwin or= other nonstandard dlls, it would be a complete disaster and would forever= relegate ocaml to research work. 2. moving most of the runtime code into DLLs This would be fine as an option, but there has to be a way to make a= standalone exe that only depends on default installed Win32 dlls= (user32.dll, kernel32.dll, advapi32.dll, ws2_32.dll, etc.). If I have to= send a bunch of dlls along with my exe for anybody to use my program then= I'm _MUCH_ less likely to use ocaml for anything real. It just increases= my support burden. I'm actually dealing with this right now. I want to= use ocaml for doing a small OpenGL program, but both available graphics= libraries (LablTk and LablGtk) require a bunch of other dlls and= installation. It's making me think twice about using ocaml for this= program, because I either have to tell people to install those packages, or= I have to write my own quick Win32 layer (hopefully if I choose this path I= can use the Togl code and I won't have to wrap OpenGL manually). My suggestions are the following, in order of importance for the first goal= above (to make OCaml more likely to be used by professional Win32= programmers for real programs): 1. Overloading. Yes, I know, not a Win32 feature. 2. Module recursion. Ditto. 3. Generics. Ditto again. 4. A Win32 programming interface, possibly auto-generated from winuser,= wingdi, winbase, etc. I am a huge fan of cross platform development, but= it's important to face facts here: none of the cross platform gui= libraries are ready for real production work in the competitive Win32= commericial software industry. I'm sure people will argue with this and= say "our company shipped SuperMoleculeViz on Solaris with Tk and it was= great!" This is not the same thing. Those libraries are a long way from= letting me do an interface that's as tight and professional (notice I= didn't say good :) as one of the Office apps, or any other professional= Win32 app. I do not think anybody has to spend years trying to make a= beautiful OO encapsulation of Win32 (as if such a thing was possible), nor= do they have to mimic the heinosity that is MFC. Just allow me to write a= Win32 app in all its platform-specific glory if I want to. This probably= means we need to make sure you can include resource files (I wonder, would= the resource compiler just work on an ocaml .exe? hmm...). If I could= show people tight applications that act just like ones written in C to the= Win32 API, this would be a powerful thing. 5. Make dynalinking to ocaml dlls work. We have to solve the dynalink= problem at some point. Large applications need plugins and other= modularity type features, and loading ocaml code in DLLs is important. It= would be nice if this worked in every direction (ocaml exe - c dll, ocaml= exe - ocaml dll, c exe - ocaml dll). 6. More x86 code generation optimizations. A peephole optimizer would be= great for part of this. There's just a lot of register sloshing that's= unnecessary in the code I've looked at. It seems within reach to get= identical loops in C and OCaml the same speed. Not a big deal but I= thought I'd throw it in there. I'm sure there's more, but that would be a start. :) Chris