Thanks for the fast answer, I actually understand the interest of re-building things from scratch, you can change a few things, and it's probably a lot of fun. I also understand that some application (more or less dynamically typed languages) require a typed bytecode, so OCaml wasn't good for that. So I see the point with Neko.
Two minor things on which I don't agree, exception traces are something possible in OCaml (OCAMLRUNPARAM=b gives the trace when using bytecode compiled with -g) and I believe that OCaml can be forked, I think they had a few arguments with Debian maintainers, but it's now in debian/free, so can be forked. I actually don't like very much the introspection thing, at least I believe it should be hidden from the user, cause leads to uncontrollable semantics, breaks the interest of the static typing. How is it in NekoML ? Do you use runtime typecheck on module loading only and then rely on the static typechecking ? Is it possible that some module is loaded a while after startup and you detect only at that point that the interface (types of exported values) is wrong ? Also, the introspection stuff can be done on top of an untyped bytecode, which then allow both static and (more) dynamic languages. > [...] means that OCamlVM is inheritanly unsafe so you cannot embed it for > example in a browser plugin that will run on the client side. It has no > sandbox either, and you need often to recompile a lot of different > bytecode files if you modify only one. I don't see why it couldn't run on client side. Of course, it cannot with the current standards. But I think there was a crazy guy who wrote a browser able to load caml applets. I don't know if he did something about sandboxing. Anyway, the fact that you cannot check the type of the module you loaded is not a show-stopper as far as I can see, since dynamic type-checking is anyway not enough for avoiding sandboxing and other precautions, errors can come from so many things. On the other hand, I feel I miss something here, since so much people are looking for a parly dynamic typing in MLs, for transmission of typed values over network. I don't know much about it, but hope it doesn't require the full bytecode to be typed. Little precision: you need to recompile if you change the interface of a module, which is normal since module consistency is done at compilation time. The compilation process for OCaml is quite a constraint. I'm wondering if the static check is worth it. > I would say that OCaml VM is very good for what it's doing : runnning > OCaml bytecode. But I don't think it's suitable to do more than that. > Some people managed to run a mod_ocaml on Apache but that's very hard > due to the fact that modules are not garbaged when no longer used (while > they are in Neko) so it eat up your memory everytime you modify a script. Nice point... I'm just wondering how useful it is. > I really like OCaml (apart from the syntax) but the only reason I'm > still using it is that it can produce very fast native executables, and > that's the only thing missing to NekoML + NekoVM to replace it for the > usages I'm making of it. Do you have a safe type-system ? type inference ? same object typing ? I'm sure Caml has more than speed compared to NekoML ;) But I agree with you, the syntax makes it a bit boring. It could be nicer to the user on typing error reports, too. Cheers. -- David --- Neko : One VM to run them all
