Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts <ijtrotts@ucdavis.edu>]

On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> 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.

It may still be good for it even if it wasn't designed for it.  At any
rate, it bothers me to write code in languages lacking OCaml's type
safety.  Maybe the solution is to graft Hindley-Milner type inference
onto Scheme or Python.  Some people at CMU did something like this with
R4RS Scheme, but I don't know if they released the code.  

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

If I didn't know about OCaml I would say you are right, but OCaml is
robust and easy to modify (hence its complexity is not such a problem
for me), and easy on system resources (hence its code size is not such a
problem for me either).  So I would be very happy if I could use
OCaml to do experimental, bottom-up programming within a graphical
environment constructed in C.  

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

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