I'm using OCaml as the target language of my compiler of a custom
language, because the OCaml compiler has good quality and the OCaml
language has appropriate runtime characteristics for my language
(regarding side effects, modules, recursion, memory management etc.).

1. Is it possible to setup a custom handler / printer of exceptions
   raised at the toplevel? The language defines how to convert objects
   to strings but of cource OCaml doesn't know that when printing
   exceptions.

   I can ignore the problem. I can also let my compiler wrap each
   toplevel binding which can fail. But perhaps it can be done easier.

2. Why ocamlc & ocamlopt are compiled to bytecode and ocamlc.opt &
   ocamlopt.opt have these names instead of being the default?

   I understand that the native code compiler is not as portable as the
   bytecode compiler. What should be a good policy for using one of the
   four versions of the compiler? I think the -O switch of my compiler
   will change from ocamlc/ocamlc.opt to ocamlopt/ocamlopt.opt,
   with some unknown yet way to choose between * and *.opt - probably
   a configuration file which sets program names (commandline switch
   is not good, I don't need makefiles for my language - the compiler
   manages dependencies itself).

3. I will want to have an interactive interpreter for my language,
   in addition to a compiler of standalone executables.

   I think it should be possible to start ocaml (or a custom toplevel)
   in a subprocess and talk with it through a pipe, giving it
   declarations compiled on the fly. How to suppress printing the
   prompt and the resulting value and type?

   Is there a better way? This one probably won't work on Windows.

4. Am I right that modules are executed exactly in the order provided
   during linking, and that the only requirement is that each module
   is listed after those it depends on?

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr