Usability problems with ocamlmktop / toplevels

[Richard Jones <rich@annexia.org>]

I'm experimenting with building a custom toplevel, but have run across
some problems.

(1) I want to have some modules 'open' already in the toplevel - we
have lots and lots of modules, some with long names, and most of these
should be opened by default.  The partial solution is to add lots of
'open' statements to a .ocamlinit file in the current directory, but
this assumes that you know what the current directory is, and that you
only need to use one type of toplevel in that directory.

(2) Toplevels don't work the same way as 'ocaml'.  The difference is
that our custom toplevel ignores any command line arguments passed to
it, whereas 'ocaml foo.ml' runs 'foo.ml'.  This means that we can't
use our toplevel to write scripts:

  #!./adwords

(or variations we've tried) doesn't work.

(3) Some libraries are linked into the toplevel, but apparently can't
be accessed.  For instance, Calendar ExtLib must be linked into the
toplevel because our main code relies on them; however no symbols from
either are visible:

$ ./adwords
        Objective Caml version 3.08.2

# Date.today ();;
Unbound value Date.today
# open Date;;
Unbound module Date
# ExtString.String.split;;
Unbound value ExtString.String.split

Rich.

PS. This is how we build the toplevel:

ocamlfind ocamlmktop -custom -package pxp-lex-iso88591,pxp-engine,netclient,netstring,extlib,pcre,calendar -I ../ocsoap -I ../csv -linkpkg ../ocsoap/oCSoap.cmo ../csv/csv.cma adwords.cma -o adwords

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com