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.
Yes you can actually "get" an exc trace for "uncaught exceptions" only
using debug mode which greatly increase the size of bytecode files. In
Neko you can get the exc trace at anytime after you catched an exception
and you can get all the current callstack (at anytime too).
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.
Introspection is useful in order to do "funny" things such as TopLevel
console. It also have a lot of cases where you want to "bind" some data
to a database, or generate polymorphicaly XML from any value.... In
general, everytime you want to interact with the outside dynamicly typed
world.
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 ?
Actually it does none of theses.
The whole program is typed + compile at one time. Since there is no
interfaces right now, you're always recompiling all - which is pretty
fast - and you're sure then that everything is correctly typed.
Of course NekoML first generates to Neko that "loose" all the NekoML
types. And in the VM all the usual checks needed to run a Neko program
are done as well.
Also, the introspection stuff can be done on top of an untyped
bytecode, which then allow both static and (more) dynamic languages.
That's exactly the point here.
If you want to get the output from a normal Neko program using NekoML
then you have to be able to introspect this value (actually it could be
as well a NekoML program that was dynamicly loaded and that you don't
know anything about it).
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.
There two things here :
a) can an invalid bytecode program crash the system
b) can types can be checked at runtime against a signature
For the sandboxing you need (a) but not (b). For Marshalling you need
(b) but not (a). It means that in the case of sandboxing, it's "ok" to
have the program behave badly in case of wrong input, as long at it
doesn't crash or can be exploited.
While for marshalling, you just want to check that the things you're
deserializing have an equivalent type to the one you're expecting.
While I agree that sandboxing does not only need a safe VM, I think that
together with Neko Loaders (see the VM specs docs) it is enough to get it.
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.
Actually in OCaml each module and CMI have a MD5, and you also store a
MD5 of the interfaces you're using, so at linking time the whole checks
are performed (or at runtime if you're using Dynlink). It's a strict
equality check so the interface really need to be the same. If you
inverse the order of two functions it might have different MD5 for
instance. It would be nice to store a little more complexe structure in
order to be able to check more things and be a little more permisive.
That's at least what I will do when I will add interfaces to NekoML.
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.
Want to try mod_neko ? :)
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.
Yes the type system is ML type system with type inference.
It doesn't have the following "advanced" features provided by OCaml :
- labels
- polymorphic variants
- objects
- (sub)modules
- functors
But one nice feature I like is the ability to print any time at runtime
polymorphicaly so the following :
print [(1,None);(2,Some "help")]
is printed as : "(1,None) :: (2, Some help) :: []"
... it saves a lot of time when you're printf-debugging.
But it's really enough to program large systems :)
The speed is nowhere near the one of OCaml native executables since
we're currently running it on top of a dynamicly typed VM but it's
actually already pretty good right now and will improve with the time
(JIT, a better GC, ...)
Nicolas
---
Neko : One VM to run them all
