Here’s an interim report on my experience with
ocamlnat, which is an OCaml toplevel that runs native code rather than bytecode.
I’m very grateful to @dbuenzli for getting
ocamlnat working and for explaining how to use packages with it in this thread and in individual help that he’s given to me. dbuenzli was kind enough to file an issue for the Owl package to help get it running with ocamlanat. (I am almost able to get Owl fully loaded into ocamlnat, but couldn’t have identified what was more was needed as well as dbuenzli did.)
I’ve worked on getting Core loaded into ocamlnat, but I’m giving up for now. It might be doable, but it’s a pretty big job–for me, at least. I’ve made some progress, but there are many components and many dependencies. One has to load each by hand as a cmxs file, in the right order of course. Not all of the module names map in obvious ways to filenames and directories. I have figured out some of the mappings, but have failed with others. I don’t think that all of the modules referenced are part of Core; that’s another complication. This detective job might be easier for more experienced OCaml folks, but still would require a bit of work. I think that there are cmxs files that one would need but that don’t actually exist, but I am not sure! (In any event, the fact that I could try to do this at all is due to dbuenzli’s help.)
Batteries doesn’t automatically build any cmxs files, but the list of its components in
lib/batteries/META is a lot shorter than the list for Core, so it might be easier to get it working with
ocamlnat once one has cmxs files.
Summary: At the moment, one can’t use Batteries or Core in ocamlnat, but the traditional Standard library is available. An option would be to rewrite bits of code or add one’s own definitions for functions provided by Batteries or Core that the Standard library doesn’t provide, obviously.
I’ll investigate making cmxs files for Batteries myself, and will submit issues for Batteries and Core to ask for better support for ocamlnat. I dont’ think this is a high priority for the community, but I do think that in the long run better support for a native-code toplevel would a good thing, particularly for scientific work. Thanks again to dbuenzli and everyone who commented on the original thread.