> You're confusing whole programs with libraries.
> A program can be
> distributed as a statically-linked executable . . .

Ideally, I'd like to confuse them as much as possible.  From
the libtool manual: "libraries are programs with multiple
entry points, and
more formally defined interfaces."

I think a good rule of thumb for a rational developer
prospectively looking at using a new language is "How easy
is <insert here> compared to C?"  Insert your favorite term
[package management/system integration/dynamic library
futzing].  I claim our choice in package management should
make sense to a good but non-ocaml-indoctrinated programmer.
Right now I don't think the proposals fall along those
lines.

Ideally, multiple ocaml libraries loaded into the same
process could do all the same things as C:

- share (ocaml) runtimes
- call each other
- be loaded and unloaded
- call and be called by other languages without much
programmer effort

and at build time:

- if no interfaces are changed rebuild only one shared lib
and rebuild only that.  (In fact newer Linux can even reload
such a recompiled lib while the process is still running,
hence you can upgrade libc while still running, etc.)

Currently, certain tools to make this so are missing.  (For
example both forward and reverse stub generators smarter
than camlidl and camoflage.)  But we should not make package
management design choices that preclude these possibilities
unless there's a good reason to.

> This is a strawman argument in many respects:
>
> - The OCaml distribution is 100 KLOC and recompiles in a
few minutes
>   on a 1000 EUR machine.  So, 2MLOC takes less than one
hour, not two
> days.  . . .

I am admittedly offering arbitrary unchecked numbers.  But I
don't think the argument changes, it's analagous to an order
of growth argument.  If build times don't matter, then why
does "make" exist?  I for one am quite impatient to build
caml on MPW with a broken make tool (or makefiles? I haven't
quite taken the time to understand.) which recompile the
world upon one file touch.  I heard Gerry Sussman (scheme
coinventor) quip something once along the lines of "Software
is like some funny kind of gas.  It takes up all the space
you give it."  I think this applies to build times as well
as run times.

> > To change the subject slightly, there seem to
> be some other
> > dangerous related "purity before progress" idea bugs
> > floating around, like
>
> And there seems to be some dangerous "let's hack
> something before
> thinking over the consequences" ideas in your message.

Admittedly.  I would probably think differently if I
everything were up to me, but since I know there are enough
people of the opposite thinking to keep me in check, I feel
it's most useful for me to err on this side.  In groups with
abundance of hacker mentality I am quite happy to play the
other role.  Sorry if anyone is offended.

Regards,


Jeff Henrikson





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