[Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Chris Clearwater]

    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

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Sylvain LE GALL]

Hello,

On Fri, Jul 18, 2003 at 04:21:14PM -0500, Chris Clearwater wrote:
>     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. 

Well said, you get the essence of the a powerful language, which is
ocaml.

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

I totally agree. What would be very useful will be a good tool to
compile ocaml source ( and C stubs ). But take a look at :
http://caml.inria.fr/humps/index_framed_caml.html Section Makefile

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

As gui : there is lablgtk ( binding of gtk ). As Framebuffer, there is a
binding for SDL && OpenGL && Xlib (but i am not sure of this last ).

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

Take a look at a project called cameleon, written in ocaml for ocaml...

> 10) World domination.
> 

World domination when hundred of fortran, C, C++, cobol, java programmer will
loose the castle of programmation ( not yet, and not for the 20 next
years ).

Regard
Sylvain LE GALL

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

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Richard Jones]

On Fri, Jul 18, 2003 at 04:21:14PM -0500, Chris Clearwater wrote:
> - Support on win32 could certainly be much better

Yes! OCaml works really well out of the box on my Debian GNU/Linux
machines, but it's a world of pain on Windows.

A binary mingw distribution including common packages (lablgtk!)
would help here.

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

It's possible to create compound widgets, although it's not simple and
obvious how to do it. There's a bit in my tutorial about doing
this. For creating an actual new widget I would be tempted to use a
drawing area as the basis. Not perhaps the most pure approach, but
fairly easy as the drawing area exposes all the events you need.

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

Camlimages wraps freetype, but obviously this is not cross-platform.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

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

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[William Lovas]

On Fri, Jul 18, 2003 at 04:21:14PM -0500, Chris Clearwater wrote:
> 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".
> [...]

I have to disagree with you on this idea.  I've been working recently on a
project written in SML, and one of the things i miss most about O'Caml is
its nice interaction with the standard tools (not to mention its separate
compilation strategy! *sigh*).

The one thing not standardized by the Standard ML definition is compilation
strategy, and as a result, every SML implementation has its own idea of the
"right" way to compile a project.  One can write standards-conformant code
and still have to write a bunch of specific build-scripts, each one in its
own arcane language, and quite possibly each one adhering to a vastly
different *philosophy* of compilation -- learning them all may well be a
lifetime's work.  In my humble opinion, this is a major fault of SML.

As a concrete example, SML/NJ has a built-in "Compilation Manager" module,
and to compile a project, you have start up a top-level and run the
`CM.make' function.  It was quite a shock to me not to be able to compile
something from the command line, coming from the O'Caml world, where the
compiler is mature, simple, and idiomatic (at least from a Unix user's
perspective).

For O'Caml to come up with its own incompatible compilation philosophy
seems like a step backwards.  We *already have* nice, simple ways of
interacting with the standard tools (like `make', and `ld') -- throwing all
that away smacks of "not-invented-here" syndrome.  It may be tempting to
climb up into our ivory tower and say, "We can do better than the status
quo!", but i think that attitude is better reserved for improving and
extending the language itself.

If you want a better `make', then write a better `make' -- but keep it
general purpose, and keep the O'Caml compiler's interface simple enough to
interact with *either* `make'.

cheers,
William

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

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Eray Ozkural]

On Monday 21 July 2003 18:18, William Lovas wrote:
> If you want a better `make', then write a better `make' -- but keep it
> general purpose, and keep the O'Caml compiler's interface simple enough to
> interact with *either* `make'.

I have a makefile library called "justmake" that uses some recent features in 
GNU make. I think it can cope with complex ocaml sources easily as it 
implements most interesting features you can only have with automake. If I 
make such a hack, I'll post it here.

Cheers,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

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

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Stefano Zacchiroli]

On Thu, Jul 24, 2003 at 07:40:48PM +0300, Eray Ozkural wrote:
> I have a makefile library called "justmake" that uses some recent features in 
> GNU make. I think it can cope with complex ocaml sources easily as it 
> implements most interesting features you can only have with automake. If I 
> make such a hack, I'll post it here.

Could you briefly list which features implements justmake?

TIA,
Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

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

Re: [Caml-list] Roadplan for world domination

[Warren Harris]

[-- Attachment #1: Type: text/plain, Size: 10488 bytes --]

Chris Clearwater - chris@sharkzone.com wrote:

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

I agree that ocaml is a beautiful language and first-class 
implementation, and I sincerely hope that it sees its way to world 
domination. I too am a relative newcomer to ocaml, so I've been 
reluctant to throw in my comments and criticism of the language/system 
until I had a little more experience with it, but your message has 
prompted me to resurrect this message that I began composing some time 
ago in response to the thread "OCaml popularity (long)". Please take it 
as a constructive criticism.

Warren


[Caml-list] OCaml popularity (long)

I know this is an old thread, but I can't help but throw in my 2 cents 
on ocaml's popularity. I'm relatively new to ocaml, but I have 
experience with many other languages, and think that I have a good sense 
for the new-comer's perspective. Here's my take:

1. I agree that the major factor is lack of industry backing. Java is 
successful because of Sun's marketing muscle. Same goes for C#/Microsoft.

2. Lack of university backing. Although there is a lot more support for 
ocaml at universities, there's still a large degree of fragmentation in 
terms of languages used for teaching: java, scheme, haskell, etc. Lack 
of knowledgeable students leads to a lack of demand for ocaml by 
industry people.

3. Difficulty to learn. I don't really think ocaml is that difficult to 
learn, but there are two main factors:

    (a) it's "different enough" from most languages that people are 
familiar with and many people are too lazy or impatient to wade through 
the differences to make it to the rewards, and

    (b) often the introductory treatments have an academic slant rather 
than a get-things-done approach (already mentioned in this thread -- 
need for "cookbook"). Ocaml is really much better than other "academic" 
languages in this regard (I find the O'Reilly book very pragmatic and 
not sure why so many people seem to love to hate it). I mean at least 
you don't need to understand monads to get useful work done in ocaml.

4. Tools. Lack of proper tools is the downfall of many languages. 
Although ocaml is really quite good in this dept, the major flaws are 
lack of a debugger on win32, and lack of an IDE (yes, there's emacs, and 
some integration with VC6, but it's far from what your typical Visual 
Studio guy is looking for).

About the debugger:

First I'll say that the debugger isn't nearly as necessary in ocaml for 
several reasons:

    (a) There's a read-eval-print loop (REPL) that can be used for 
interactive testing and development. This allows programs to be built 
from the bottom-up, verifying the smallest pieces first before building 
things that depend on them. This is the same as 
lisp/scheme/python/perl/js, and in stark contrast to C++/Java/C# where 
you often need to write a large part of the program (and lots of 
boilerplate) to get to the point where you can test anything.

    (b) The fact that in the REPL you don't need to specify types 
further lends itself to interactive development (again, in contrast to 
Java).

    (c) All data types can be used as literals, and printed to the 
console further aids interactive development.

    (d) Pretty-printing and the formatter are great tools, make things 
easier to read, and are very easy to use.

The reason for the lack of the debugger on Windows is the lack of 
fork/exec primitives, and these are used to implement checkpoints 
(ability to roll back to a previous debugger state). Although this is a 
nice feature, I for one don't find it that useful -- primarily because 
with every other debugger I've used I get used to putting breakpoints in 
places where I need to begin paying attention, or at least, I can 
restart the computationfrom the beginning to get back to an earlier 
point. I think most programmers would agree with this.

    (I'm not sure if there isn't a slight anti-Windows bias in the ocaml 
community, but I think there are two potentially conflicting goals for 
ocaml: (1) promoting an alternative to the dominant platform by offering 
ocaml as a better tool/language for Linux and open source development, 
or (2) promoting wide-scale adoption of ocaml language in general, which 
means making it work well on the dominant platform.)

5. Learning the language. Here's where I'll list what I think is 
"different enough" about the language that keeps people from using it:

    (a) Syntax of types -- in particular use of * and ->. I know where 
they come from, why they're good, etc, but I know they put some people 
off. This is compounded by type variables prepended with apostrophes and 
postfix type functions. Also currying is foreign to most people -- the 
fact that functions return functions that take more arguments. On the 
surface this must seem useless, and inefficient (although once you 
understand the power you'll wonder how you lived without them).

At the very least, I think ocaml type expressions would benefit from the 
ability to label arguments with symbolic names. This would aid in 
understanding. E.g.

    val assoc : 'a -> ('a * 'b) list -> 'b

might be expressed as:

    val assoc(key:'a) : fun(l: list(key:'a, value:'b)) : (value:'b)

(Just a suggestion -- I know this is more verbose, but if it makes the 
language easier to learn it might be a good thing.)

    (b) Constructors, patterns and values. This is no doubt one of the 
great things about ocaml -- the fact that these three things are 
expressed uniformly, i.e. that I can construct one by saying Foo(x), 
match and destructure by saying Foo(x), or return a value and see it 
print out as Foo(x). But to the beginner these three distinct things 
might be confused. People are very used to seeing "new" in front of 
constructors, and pulling apart nested structures one dereference at a 
time. So I believe this is one reason why ocaml is different/hard to learn.

    (c) Union types. (Or do you call them sums?) It's probably also lost 
on many newcomers how great unions are in ocaml -- the fact that the 
compiler will tell you all the functions that need to handle a new 
constructor of the union when it's introduced (as long as you don't add 
catch-all patterns), and how the pattern-matching cases are checked 
exhaustively. Unions seem to suffice for 99% of the things that people 
use OOP for (representing cases as disjunctive function clauses rather 
than methods on classes) -- but without all the boilerplate. Unions are 
great, but foreign to newcomers, and unwelcome to those that think they 
only want OOP.

    (Perhaps some sort of document is in order that shows exactly the 
class of problems that requires overloaded methods, distinguishing this 
from the cases where choosing ocaml's object system over union types is 
simply a matter of taste to the programmer. Or better yet, a document 
that describes how numerous problems expressed in Java or C++ can be 
better (more concisely and efficiently) expressed with unions.)

    (d) Heavy reliance on recursion. Although ocaml provides some 
iterative constructs, for many things you still need to write recursive 
functions. Fortunately, due to tail recursion elimination and a very 
good compiler, recursion is very efficient in ocaml, but nonetheless it 
requires programmers to contort their normal way of thinking about 
common program idioms. Higher-order functional library routines also 
fill the gap when iterative constructs are often used, but for whatever 
reason, most people don't think in terms of List.map or Array.iter. I 
think ocaml would benefit from a little more syntactic sugar in this dept:

    for x in l do e       == List.iter (fun x -> e) l
    for x in l collect e  == List.map (fun x -> e) l

    (e) Assignment and mutability. The first hurdle is that people often 
think ocaml is a "functional language," doesn't have assignment, and 
consequently isn't practical. If they get past this, they may find that 
refs require some change in the way you think about assignment. 
Programmers are used to dealing with references and dereferencing when 
pointers are involved, but for ordinary data types like int, bool and 
char they think of variables being mutable or "const". Although ocaml's 
treatment of references is more consistent, it presents a slight 
rethinking. Also, ocaml's mutable record fields further confounds the 
problem because unlike ordinary lexical variables, they can be modified. 
Perhaps ocaml should consider adding mutable local variables:

    let sum_until n =
      let mutable sum = 0 in
        for i = 0 to n-1 do
          sum <- sum + i
        done;
        sum

    (f) Type-checker error messages. When something fails to type check 
in ocaml, the error messages can be uninformative or confusing. Often 
times the source of a type constraint is far removed from the location 
where the problem is reported. Showing the source of the constraint 
would be very helpful. Also, often times the type conflict that's 
reported fails to narrow down the conflict sufficiently. It would be 
very helpful if the expected and actual type expressions were unified in 
some way to pinpoint the exact discrepancy.

    (g) Module system. Once you become proficient in the base language, 
you move on to the module system, with it's own learning curve. For 
instance, the beginner may wonder why they need to redefine all the 
types in the mli file again in the corresponding ml file (not something 
you have to do with import/include file in Java/C++). They may also be 
confused by the difference between a a functor that takes a type as a 
parameter, and a module struct specialized by a 'with' type constraint 
(ok, maybe I'm the only one confused by the difference here).



[-- Attachment #2: Type: text/html, Size: 11919 bytes --]

Re: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities)

[Eray Ozkural]

On Saturday 26 July 2003 10:36, Stefano Zacchiroli wrote:
> On Thu, Jul 24, 2003 at 07:40:48PM +0300, Eray Ozkural wrote:
> > I have a makefile library called "justmake" that uses some recent
> > features in GNU make. I think it can cope with complex ocaml sources
> > easily as it implements most interesting features you can only have with
> > automake. If I make such a hack, I'll post it here.
>
> Could you briefly list which features implements justmake?
>

Well, I was using a kludge for an eval function in GNU make, then Paul as he 
promised made it into the latest release. That's the method I use in 
implementation of justmake.

What justmake implements is a neat automake like build system in which you 
indicate what you want to build, what sources there are and everything else 
is done automatically including dependency analysis and recursive 
compilation. No nasty preprocessing!

It's basically a makefile library. All you have to do is to include the 
library header and define a few vars. A big advantage over automake is you 
can use make expressions anywhere.

The interface is very similar to automake.
Here is an example entry file

PACKAGE = sma
SUBDIRS = data
VERSION = 0.1.1
BUILDARCH = i686
# valid build configs : dbg, opt, optdbg
BUILD = dbg

include justmake/Makefile.justmake

And here a flavor of file definitions

# Executable files
PROGRAMS = bin2ascii check-session-db sequence-gen ....
# Library files
LIBRARIES = sma sma++ stock-db sequence-c generic
...
bin2ascii_CFILES = $(wildcard src/bin2ascii/*.c)
bin2ascii_INCFILES = $(wildcard src/bin2ascii/*.h)
bin2ascii_LIBS = -lsma
...

The system doesn't enforce recursive makes, which I think sucks most of the 
time but you can still use them (as in SUBDIRS above). You can indicate 
source files anywhere in the source directory.

Also visible above is the build configuration support. Every temporary file is 
created in a build dir, no files are created in the source directory, which I 
think is a great win. Also you get to have as many build configs as you like 
which you can define (well at least I've got debug and optimized configs :P)

It has also a lot of extra functionality that I developed over years, but 
still clean and sensible :)

I've noticed that automake started implementing some features that I had for a 
long time in justmake but it's still superior ;) [I think that's because 
we're working on the same problem]

BTW, it only supports libtool for handling library builds but I guess it's OK 
for the most part.

I'll try to bring together a first release soon. I'll let you know.

Cheers,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

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

Re: [Caml-list] Roadplan for world domination

[Guillaume Marceau]

On Sat, 2003-07-26 at 16:14, Warren Harris wrote:

>     (f) Type-checker error messages. When something fails to type check 
> in ocaml, the error messages can be uninformative or confusing. Often 
> times the source of a type constraint is far removed from the location 
> where the problem is reported. Showing the source of the constraint 
> would be very helpful. Also, often times the type conflict that's 
> reported fails to narrow down the conflict sufficiently. It would be 
> very helpful if the expected and actual type expressions were unified in 
> some way to pinpoint the exact discrepancy.

Myself and a handful of other researcher are working on this problem. As
you said, the two incompatible type constraints are often far removed to
one another. In fact, most of the times, the mistake is somewhere in
between, along the statements that connect the two constraints together.

I have a prototype solution for a toy version of ocaml which is embedded
in the Drscheme environment. My code takes an error involving a large
amount of code and break it down into small layer. Ideally, each layer
in each layer is small enough that you can be understand it by itself.

Once I am done building the prototype, I intent to port it to David
Goldber's Dromedary, "A CAML-like dialect of ML that works in the
DrScheme environment." and then to ocaml.
   http://www.cs.utah.edu/~goldberg/


Matthias Neubauer and Peter Thiemann at the Universität Freiburg seem to
have gotten good results on the same problem using a form of data flow
analysis. They will be presenting a paper on the subject at icfp 2003
titled "Discriminative sum types locate the source of type errors"

   http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp03.pdf


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

Re: [Caml-list] Roadplan for world domination

[Damien Doligez]

On Saturday, Jul 26, 2003, at 22:14 Europe/Paris, Warren Harris wrote:

>     val assoc : 'a -> ('a * 'b) list -> 'b
>
> might be expressed as:
>
>     val assoc(key:'a) : fun(l: list(key:'a, value:'b)) : (value:'b)

You can already write:

   val assoc : 'key -> ('key * 'value) list -> 'value


-- Damien

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