ocaml: demand-driven compilation?

ocaml: demand-driven compilation?

[William Chesters]

Are there plans to extend the separate compilation system of ocaml to
take over some of the functions of make, as the Java compiler does?
The Java compiler not only checks sources against the precompiled
signatures of the modules it refers to, as ocamlc/ocamlopt do; it also
checks the existence and modtime of the bytecode file against the
source and (re)compiles if necessary.  With a little hack to get any
necessary standard libraries included in the link command
automagically, we wouldn't need makefiles at all.  For me it would
even be nice to able to specify the C files implementing the external
functions needed by each source _in the source itself_.

I think it would be quite easy to hack something together to do this,
since [Env.find_pers_struct] very nearly constitutes the necessary
hook.  (Mind you it would be even easier if the compiler was free of
naughty global variables---I don't think it's safe to invoke it
recursively?)

It would also be possible to do it (approximately) without touching
the compiler, say using ocamldep, but it would get messy.

Re: ocaml: demand-driven compilation?

[Ian T Zimmerman]

In message <6086.199709131752@venus> (message from William Chesters on Sat,
	13 Sep 1997 18:52:43 +0100),
you <williamc@dai.ed.ac.uk> write:
>  Are there plans to extend the separate compilation system of ocaml
> to take over some of the functions of make, as the Java compiler
> does?  The Java compiler not only checks sources against the
> precompiled signatures of the modules it refers to, as
> ocamlc/ocamlopt do; it also checks the existence and modtime of the
> bytecode file against the source and (re)compiles if necessary.
> With a little hack to get any necessary standard libraries included
> in the link command automagically, we wouldn't need makefiles at
> all.  For me it would even be nice to able to specify the C files
> implementing the external functions needed by each source _in the
> source itself_.

IMO things like this don't belong to the language or compiler.  It is
a _disadvantage_ of Java that it tries to be a `complete environment',
and I bet the reasons why it is packaged that way has a lot to do with
marketing b*s*t.  Apart from the general reasons of going against the
toolkit philosophy (if you try to have a program do too much, it stops
cooperating nicely with the rest of the system), in a compiler there's
another reason: depending on the file system in nontrivial ways would
make it harder or impossible to verify that the language has a sound
semantics and that the compiler implements the semantics correctly.

>  It would also be possible to do it (approximately) without touching
> the compiler, say using ocamldep, but it would get messy.

Yes, it would definitely be possible to beef up ocamldep.  The result
would be a reimplementation of make in ocaml.  Why reinvent the wheel?
And why do you dislike makefiles anyways?  They are the right tool for
the job.

Just my penny worth.

-- 
Ian T Zimmerman                        <itz@rahul.net>
The dilemma is that when you model something 
completely on efficiency, a lot of people get hurt.
Dr. Leonard Duhl of UC Berkeley, discussing `managed medical care'.

Re: ocaml: demand-driven compilation?

[William Chesters]

Ian T Zimmerman writes:
 > Yes, it would definitely be possible to beef up ocamldep.  The result
 > would be a reimplementation of make in ocaml.  Why reinvent the wheel?
 > And why do you dislike makefiles anyways?  They are the right tool for
 > the job.

There are three things to know in building an executable: what modules
are needed; are they up to date; what commands are needed to
compile/link them?

`make' addresses the second (trivial) point and provides a framework
for going *some* way to help with the third.  You have to bridge the
remaining gap yourself.  In ocaml (as in Java) this means duplicating
information: the compiler has already used your sources to find out
what modules are needed.  Furthermore the task of inferring what ocaml
and native libraries were needed for the link is easy for the
compiler, but a bit annoying for me.

That's why I dislike makefiles.  make comes in at the wrong level, or
at least, at a level which was only ever right because C had no module
system worth the name.

Re: ocaml: demand-driven compilation?

[Ian T Zimmerman]

In message <11948.199709171652@jupiter> (message from William Chesters on
	Wed, 17 Sep 1997 17:52:59 +0100),
you <williamc@dai.ed.ac.uk> write:
>  Ian T Zimmerman writes:
>  > Yes, it would definitely be possible to beef up ocamldep.  The
>  > result would be a reimplementation of make in ocaml.  Why
>  > reinvent the wheel?  And why do you dislike makefiles anyways?
>  > They are the right tool for the job.
>  There are three things to know in building an executable: what
> modules are needed; are they up to date; what commands are needed to
> compile/link them?
>  `make' addresses the second (trivial) point and provides a
> framework for going *some* way to help with the third.  You have to
> bridge the remaining gap yourself.  In ocaml (as in Java) this means
> duplicating information: the compiler has already used your sources
> to find out what modules are needed.  Furthermore the task of
> inferring what ocaml and native libraries were needed for the link
> is easy for the compiler, but a bit annoying for me.
>  That's why I dislike makefiles.  make comes in at the wrong level,
> or at least, at a level which was only ever right because C had no
> module system worth the name.

I disagree.  Your argument would be valid if ocaml was the only tool I
used in building a program.  But what of ocamlyacc and ocamllex?  The
build process for ocaml itself generates ML files by passing them
through the C preprocessor, of all things.  Myself, I'd use m4 for
that purpose.  You could code knowledge of all these file types into
ocaml (eeek!) but guess what, I'm considering writing a tree pattern
matcher generator, call it ocamlburg.  It will obsolete your code
immediately.

As soon as ocaml is mixed cooperatively with other tools, _all_ of
your 3 points become nontrivial and require something close to full
make functionality.

-- 
Ian T Zimmerman                        <itz@rahul.net>
The dilemma is that when you model something 
completely on efficiency, a lot of people get hurt.
Dr. Leonard Duhl of UC Berkeley, discussing `managed medical care'.