Re: [Caml-list] Dynamically evaluating OCaml code

[Brian Hurt <bhurt@spnz.org>]

On Thu, 3 Jan 2002, Issac Trotts wrote:

> That being so, how would you use OCaml as an extension language for a C
> program?  
> 

I would use C as an extension language for Ocaml.

This isn't meant to be a snarky answer.  Ocaml is an applications
language- you should write the bulk of the code in Ocaml, and drop to C in
places where you need to.  If you're looking for a language to embed, you
might try looking at one designed to be embeeded, like Lua.  Or a Lisp
variant.  But that isn't what Ocaml is designed for.

Nor would it be a good language for that.  Consider the complexity of the
Ocaml 'eval' function.  On my system (Redhat 9, x86, Ocaml 3.07) Ocamlc is
920K in size, and ocamlrun another 144K.  You'd have to replicate the
majority of that in the eval function- so you're talking north of a
megabyte of code.  As an application, that's small.  As a library, that's
huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
small, simple language.  Although this might not be so bad- libperl.so on 
my machine weighs in at 3.2M.

As a side note, I don't see Ocaml as a science project.  It's a pragmatic
language, in that it doesn't automatically assume it knows what's best,
but instead provides the programmer the tools he needs to get the job
done.  As reflected in it's design decisions, the people designing Ocaml
were designing a production language to be used by real programmers on
real problems.  Science projects, especially computer science projects,
tend towards an extreme aesthetic, for two reasons.  First is that they're
designed to push a a specific idea or set of ideas.  Second, generality
requires extra effort, which isn't worth it if all you're doing is an
experiment.

Two examples of this in action.  First, consider the different ways you 
can run Ocaml code.  You can interpret it (like Perl or Lisp, although 
Ocaml doesn't provide eval), you can compile it to native (like Fortran or 
C/C++), or you can use a virtual machine (like P-system Pascal or Java).  
The Ocaml writters didn't assume that one way was the "right" way and just 
implement that, they implemented all three.  Better yet, the same code 
runs in all three, just with slightly different performance 
characteristics.  Whichever solution is best for my particular case, I can 
do.

Second, consider the different paradigms Ocaml embodies.  Yes, functional 
is the default mode.  But Ocaml supports both OO and imperitive/procedural 
programming as well.  If those paradigms allow you to express a better 
algorithm or express the same algorithm better, use them!

The fact that it didn't include some things (like an eval() function) 
means it did include others.  I'll fault Perl, Python, Lisp, and the rest 
for not having a good static type system.

Wandering into the arena of suspect analogy, if C and C++ are the blue
collar assembly line workers, tightening bolts by hand, than Ocaml is the
robot repairman maintaining the whole factory of robots.  He's every bit
as blue collar and about getting real work done, but more educated and a
heck of lot more productive.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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