Re: [Caml-list] about OcamIL

[ben kuin <benkuin@gmail.com>]

> Isn't this precisely the aim of Jon's hlvm
> (www.ffconsultancy.com/ocaml/hlvm/)?

that's an interesting question, Here are a few thoughts:

technical:
- in .NET everything is easy (from the surface): you have your source
file (hello.cs) you take your compiler (cs.exe) and compile it to a
msil bytecode file (hello.dll). You can run reflection tools to
hello.dll or link it to a exe or generate back to source.  This
bytecodefile is your friend. You can run it on a bunch of runtimes
like .net clr, or on mono, or rotor, or dotgnu. You can register
libraries in a container to prevent versioning problems with future
releases. I couldn't figure out those equivalents int hlvm or llvm.

- with HLVM things are complex (for me): What is the role of the big
underlying llvm infrastructure. Why do even need hlvm if we have llvm
plus ocaml bindings. Does hlvm has its own bytecode? If yes where is
it specified? Is hlvm a ocaml library or is it a free standing vm?
etc.

Maybe for you these a trivial questions, but I still dont get it,
while with .net I never had problem to get the idea.


licensing:
Hlvm is driven by a company and its landing page is on a companies
website and one of its protagonists is smart *and* business savvy.
What if hlvm would really take off, could they set it free and move
the homepage to sourceforge ? Right now it's bsd licensed, maybe
tomorow it's dual licenced like Qi? Or maybe the license some (future)
killer features under a closed license?
This is just guessing - I don't want to spread fud. But as a former
.net developer I followed mono from the beginning and I'm very
disappointed that mono is still not considered as a friendly linux
citicen. All because of some half-clear license issues.

But sure hlvm is impressive and could be the solution.