Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] build tools - good vs. fast, both cheap
On Sat, 2004-04-17 at 04:46, John Goerzen wrote:
> On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> > On Sat, 2004-04-17 at 02:06, Kenneth Knowles wrote:
> > 
> > To understand interscript .. what does it do?
> 
> You keep bringing that up, so I have to ask: why is that relevant as
> part of a discussion of *OCaml* build tools?
> 

Interscript is language independent and general purpose.
Language dependent tools are limited.
Because systems generally aren't uniform.

EG: you build a system (like Felix) which uses
Ocaml .. and C++ .. and Felix codes .. can you
use Ocamldep to document it? Of course not,
it only works for Ocaml. Interscript works
for ALL three languages. As well as every other
language you care to use or invent (provided
it is a linear text file kind of language :D
heck, ocamldoc doesn't even work with camlp4!

In addition, interscript uses some different
techniques such as literate programming
with executable script, has a new build
concept based on convergence to a fixpoint,
and generally speaking is so far in advance of
make and autoconf I don't even consider
those tools to provide any kind of model for
any part of a build process anymore.

The logic embodied in those tools is still
needed, but it should be represented
by library modules, not executables.
EG: topological sort is a useful module.
EG: getfiletime is a useful function!
EG: (dependency) graph is a useful module.
And given them you can write 'make'
in 10 lines of Ocaml .. well i exaggerate
but you get the idea.

Yes yes, bash is a (lame) general purpose
language and Unix commands are just library
modules... of an archaic programming system,
not a modern one.

Anyhow, hope that answers your question:
I have spent something like 5 years building
a tool that handles much the same set
of problem we're discussing, or at least
could handle them if so programmed,
and ended up with something quite different
from the spagetti the C world uses.
I really don't want to see Ocaml go down the
spagetti route :D

So far it hasn't: for example no lame preprocessor!
Yeah, Ocaml does finally have one, camlp4.
But a preprocessor that can extend the grammar,
and involves arbitrary executable caml code ..
that isn't even marginally lame .. its a completely
radical and worthy tool: perhaps not perfect,
but I'm so glad the Ocaml team resisted a spagetti
solution.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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