Tools module for the Standard Lib

Tools module for the Standard Lib

[Tom Hawkins]

Recently I've been reorganizing my build process for Confluence -- it's 
a hardware design language implemented in OCaml.

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.

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:

   let my_ml = Tools.ml_of_file "my.ml" in  (* or ... *)
   let gen_ml = Tools.ml_of_string "print_string \"hello!\"" in

With such a framework, the complexity of the build process is 
encapsulated in a program.  After your process is complete, write out 
the final executable:

   Tools.output_exe some_channel my_compiled_application

Just an idea.

-Tom

Re: [Caml-list] Tools module for the Standard Lib

[Kenneth Knowles]

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.

Re: [Caml-list] Tools module for the Standard Lib

[Christian Lindig]

On Dec 5, 2004, at 6:36 PM, Tom Hawkins wrote:

> Extrapolating on this idea, it would be advantageous to have a "Tools" 
> module [..] Such a module would provide first-class ADTs for data that 
> is currently represented in files: .ml, .mli, .mll, .cmi, .cmx, etc.  
> For example:
>
>   let my_ml = Tools.ml_of_file "my.ml" in  (* or ... *)
>   let gen_ml = Tools.ml_of_string "print_string \"hello!\"" in
>
> With such a framework, the complexity of the build process is 
> encapsulated in a program.

In my experience, all serious projects have to deal with more than one 
kind of source language: besides OCaml there could be TeX for 
documentation, Troff for manual pages, input for special-purpose code 
generators like Burg, and so on. A build system must be able to deal 
with all of them. Therefore your proposal would not eliminate the need 
for a general build tool outside of OCaml,

-- Christian