Version française
Home     About     Download     Resources     Contact us    
Browse thread
Tools module for the Standard Lib
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kenneth Knowles <kknowles@s...>
Subject: Re: [Caml-list] Tools module for the Standard Lib
On Sun, Dec 05, 2004 at 11:36:05AM -0600, Tom Hawkins wrote:
> A few days ago a Confluence user made an interesting suggestion: why not 
> use OCaml to build OCaml applications?  He then proceeded to write an 
> OCaml script to generate the lexers and parsers, compile the interfaces 
> and implementations, then link everything together.

I did a similar thing with ocamlconf (currently don't have time to maintain it,
though), except it generates a Makefile from a high-level spec.  I think getting
the "make" logic into O'Caml is the right way to go, and it'll make it easier to
experiment with different build strategies, such as the fixpoint iteration
Skaller has brought up, or some constraint->action (a la Dijkstra's guarded
commands) approach that would subsume fixpoint and traditional make.
 
> Extrapolating on this idea, it would be advantageous to have a "Tools" module
> in the standard library to provide an interface to ocamlc, 
> ocamlopt, ocamllex, ocamlyacc, ocamldep, and all the other tools.  Such 
> a module would provide first-class ADTs for data that is currently 
> represented in files: .ml, .mli, .mll, .cmi, .cmx, etc.  For example:

Sounds like a polyvalent program:
http://www.catb.org/~esr/writings/taoup/html/ch11s07.html#id2960228

I think this is an admirably flexible way to design tools of all sorts, but it
might force too much stability on the compiler's internals.  A user could
implement this module using tempfiles and storing whole file contents in
memory.. actually I guess there'd be a problem parsing reasonable exceptions
from the error messages...

- Kenn

p.s. As far as the details, I think "*_of_filename" functions are misguided, and
"*_of_channel" is more appropriate.