Re: [Caml-list] Dynamically evaluating OCaml code

[Brian Hurt <bhurt@spnz.org>]

On Thu, 8 Apr 2004, John Goerzen wrote:

> On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> > 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.
> 
> Indeed, and in fact:
> 
> -rw-r--r--    1 root     root      1073392 Feb 24 02:34 /usr/lib/libpython2.3.so.1.0
> 
> Python is often used as an embedded extension language as well.

I think I've talked myself into that Ocaml, at least the VM part, should 
be embeddable.

> 
> > 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
> 
> Careful; that sounds like you're describing Perl :-)

I've heard that used to describe Perl, C++, and Java, in different ways.  
As such, I'm using it as a benchmark for what a "usable" language is.

> > 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.
> 
> I agree with most of your analogy here.  I'm still relatively new to
> OCaml, having been using it for only a couple of months, but you've
> touched on one of my pet peeves: the OCaml standard library is really
> sub-par for doing real work.  

Heh.  It's orders of magnitude better than the C or C++ standard
libraries.  Which explains why those languages never went anywhere :-).  
Note that POSIX is an add-on layer, not gaurenteed to be there.  So all
socket communication is optional and non-standard.  As is all database
connectivity, GUI handling, etc.  The thing is, almost no one actually
programs the "standard" C/C++ environment.  Every C/C++ environment comes 
with a whole collection of add-on libraries- POSIX at a minimum.  
Generally a whole lot more.

I think the problem here isn't technical, it's social- marketing, to be 
specific.  Having a language with a very minimialistic standard library 
isn't the problem- the problem is have a standard development environment 
with a minimialistic library.  The "core" language and libraries 
distribution should be, if not hidden, then at least not obvious.  
Instead, the "default" Ocaml distribution should be something more like 
CDK (is that project still alive?).  There shouldn't be links from the 
home page to the core, the home page should link to CDK *only*.  And we 
need to get the Linux distros up to speed and distributing CDK instead of 
only Ocaml-core.

While we're kvetching, here's my list of desires to be in the default 
development environment (note that I don't think any of these belong in 
the standard libraries):
	- OUnit
	- ExtLib (OK, this should perhaps become part of the standard)
	- BLAS/LAPACK, GMP, and MPI bindings
	- Regular expressions
	- ocamlexc
	- Camllisp (or similiar)
	- compression, encryption, etc. filters for I/O

Certain things can be moved out of the standard distribution and moved 
into the development environment in this case- pcaml, ocamldoc, ocamlex, 
ocamlyacc, etc.

Of course, the other advantage that the standard distribution has, in 
addition to being the default, is coherent documentation.  There is one 
book, and everything in the standard distribution is more or less equally 
well documented (ocamllex and ocamlyacc could use some help).  The same 
thing should be true for the development environment.


> Similar complaints exist for working with subsets of lists; it's really
> too hard to say "replace elements 4 through 9 with this", "delete
> elements 4 through 9", "return elements 4 through 9", etc.  (While we're
> at it, I think it's silly that there is a list and an array type).  Yes,
> I could write functions to do all of this, but my point is that I
> shouldn't have to.

They aren't hard to write, the problem is that they're O(N).  To replace 
element 9 in a list, you also end up replacing elements 0-8 as well.  I 
would argue that if you're wanting to do this routinely and efficiently, 
you shouldn't be using lists.  I'd recommend Map or Set myself.

> One other thing to mention is that installing libraries is much more
> difficult than it should be, and writing library build systems (and even
> app build systems) is much more complex than it should be.  Part of this
> is due to a lack of a standardized build system (think Perl's MakeMaker
> or Python's setup.py).  Part of it is due to the complex array of OCaml
> options -- for instance, some platforms do not support ocamlopt, so
> while a library might normally build both native and byte-code versions,
> it has to not try to if ocamlopt is missing.  (Something which, I have
> found, many OCaml authors fail to consider.)  I've been toying with the
> idea of writing a generic build system for OCaml to address this point
> though.

There have been several swings taken at this already- the relevent 
developers should be letting you know about them.

If you're regularly having to install more than one or two libraries for 
your development environment, that's a problem.  I mean, think about it.  
You install Linux, how many libraries do you generally need to add to do 
C/C++ programming?  Or Visual Studio?  You don't realize how much of the 
stuff is "optional" because it's all installed automatically.

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