Packaging, and GUIs

Simon Peyton-Jones simonpj@microsoft.com
Wed, 23 Jul 2003 08:27:22 +0100


Dear Haskell library and GUI folk,

Here's an interesting message from the Caml mailing list, largely
focusing on
	a) packaging
	b) GUIs

Interestingly, the very two topics on which we have active groups
working!  I wonder if it'd be a good time for a status report from both
efforts?  Both have been very quiet of late, but I see that Daan and
Krasimir have both published new GUI libraries recently, so GUI stuff is
still going on. =20

Simon


-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Clearwater
Sent: 18 July 2003 22:21
To: caml-list@inria.fr
Subject: [Caml-list] Roadplan for world domination (or constructive
criticism of ocaml facilities)

    I have come across the Ocaml language several months ago and after
much
investigation and trial coding I have come to several conclusions. Most
importantly I think Ocaml is a wonderful language to program in. It has
all
the features I would expect from a modern language and on top of that
it's
compiled native code appears to rival that of C in many areas. It truly
is
the language of the future. Now that I have expressed how much I am
growing
to love Ocaml I would like to share with you my initial experiences as a
new
user. First I would like to single out some issues that I believe
threaten
Ocaml from being taken seriously and then i would like to offer some
solutions that would improve the usability of ocaml greatly.

- Support on win32 could certainly be much better
- Compiling and distributing Ocaml source is a very delicate process
- There exists much fragmentation among usage of different GUI toolkits
  and they are limited to C/C++ conventions. (Is it possible to create
your
  own custom GTK widgets within ocaml?)

And without further ado I present to you 10 steps to world domination:

1) Support for Ocaml on win32 (both as a development and target
enviroment) is
very crucial for the adoption and practicality of Ocaml. For example,
look at
the trouble some developers must go through to get their application
running
under win32: http://groups.yahoo.com/group/unison-hackers/message/31.
Forutnately this doesn't have to be the case. The mingw32 toolset allow
compilation and linking to be done very similarily to how it is done on
Unix.
Also, it enables one to develop win32 apps without shelling out hundeds
of
dollars to Microsoft:
http://msdn.microsoft.com/visualc/howtobuy/pricing.aspx
I propose mingw32 be made the default compiler/linker for native win32
binaries
(or even drop MSVC support entirely).

2) Take the idea of ocamlmklib further to generalize the compilation of
both
Ocaml programs and libraries into a module called "Ocamlmake". Also
create a
binary of ocamlmake which makes use of the module for command line
compiling
and include these in the standard distribution on all platforms.

3) Now that we have a easy cross-platform way to compile ocaml
applications we
can just distibute our code with Makefiles that call ocamlmake! WRONG.
Makefiles suck. Now we standardize on the idea of an Ocaml "package".
Each
package would include in it's toplevel directory a file called setup.ml
(This
is starting to resemble python's distutils indeed). setup.ml would make
use of
the Ocamlmake module by building a record and passing it to
Ocamlmake.setup.
This record might be static or it might be created by
self-configuration.
For example, the ocamlsdl package would call sdl-config to retrieve some
compilation flags. You _would_ rather configure in ocaml than "portable
shell
script", right? Then to build the application you would execute
"ocamlrun
setup.ml build" and "ocamlrun setup.ml install" to install it. Also the
record
would contain meta-information such as the author, copyright, etc.

4) Change the ocaml distribution to compile using Ocamlmake :) (except
for
bootstrapping if you dont already have a previous version of ocaml
installed)

5) Create a module called Framebuffer which parallels the primtives
found in
OpenGL/DirectX. The Graphics module is close, but the design doesn't
match
well with these two APIs (We want hardware acceleration). Implement for
each
platform a Framebuffer module (DirectX or OpenGL where available, Xlib
or
other native graphics system otherwise). Include this in the standard
distribution.

6) Create a cross-platform Event module. Include this in the standard
distribution.

7) Create a cross-platform Font module (wrap freetype or create an Ocaml
implementation). Include this in the standard distribution.

8) Create a GUI on top of the Framebuffer, Event, and Font modules,
implemented in Ocaml :) Include this in the standard distribution.

9) Now the big payoff, we write a standard Ocaml IDE, to be included
with the
Ocaml distribution. It would be well integrated with the distribution.
Ocamlmake
module for compiling, the ocaml lexer for syntax highlighting, exporting
packages
(setup.ml). This would make it incredably easy to get started creating
cross-platform libraries and modules. Realating to point #1, now a win32
user
need only grab the mingw32 and Ocaml distributions and they are set.
They can
even easily export their code to a ocaml package for distribution.
Obviously the
benefit extends to all other platforms as well.

10) World domination.

I would greatly appreciate any feedback.

-------------------
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