caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Chris Hecker <checker@d6.com>
To: Xavier Leroy <Xavier.Leroy@inria.fr>,
	Jean Martos <jean.martos@wanadoo.fr>
Cc: lionel.fourquaux@wanadoo.fr, caml-list@inria.fr
Subject: Re: OCaml for Windows: a suggestion
Date: Mon, 12 Feb 2001 11:37:36 -0800	[thread overview]
Message-ID: <4.3.2.7.2.20010212110219.00c2e570@shell16.ba.best.com> (raw)
In-Reply-To: <20010211105222.B10493@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.  

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



  reply	other threads:[~2001-02-13  7:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-08 21:07 Lionel Fourquaux
2001-02-04 17:54 ` Jean Martos
2001-02-10 19:28   ` Lionel Fourquaux
2001-02-11  9:52   ` Xavier Leroy
2001-02-12 19:37     ` Chris Hecker [this message]
2001-02-12 21:27       ` Lionel Fourquaux
2001-02-14 15:32         ` [Caml-list] " Vijay Chakravarthy
2001-02-13 18:07           ` Mattias Waldau
2001-02-13 18:20           ` Gerd Stolpmann
2001-02-13  4:36 Hao-yang Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.3.2.7.2.20010212110219.00c2e570@shell16.ba.best.com \
    --to=checker@d6.com \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=jean.martos@wanadoo.fr \
    --cc=lionel.fourquaux@wanadoo.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).