Re: [Caml-list] PostgreSQL and Ocaml

[Chris Hecker <checker@d6.com>]

>If nobody has, would anyone like to join me in the project of writing an 
>add-in for PostgreSQL supporting Ocaml stored procedures? I have little 
>experience in this, but it should not be too difficult: it should be a 
>matter of writing a C dll which, upon initialization, starts a bytecode 
>compiler and interpreter, and has callbacks through with which the server 
>can request the compilation of a text string or the execution of a 
>bytecode cmo blob.

I have no time to help you with this, but I have a suggestion.  I would 
write this dll in caml and use the asmdynlink library (which, 
unfortunately, is bound rather tightly into the apparently-moribund cdk at 
this point, but it still appears to work).  I'm planning on using 
asymdynlink for some of my game work, and it appears to be just the trick 
for using caml as a dynamic scripting language (you can eval strings, load 
cmo files, the loaded caml can call native caml code transparently, 
etc.).  This would allow you to write 90% of the dll in native mode caml, 
and still dynaload programs.

There are two main issues I've found that I will probably try to solve:

1.  You need to have all the cmi files around, which is annoying and a 
logistical nightmare.  This is true of the toplevel and the regular 
bytecode dynlink library too, and it sucks.  The optimal solution would be 
to bind in all the cmis as data resources into the program.  Slightly less 
optimal but still better than nothing would be to use the -pack option, get 
a single big .cmi, and use that.  I think you'd have to -pack the whole 
standard library first, and then link with that because the modules will 
now be nested in the pack module.

2.  The asmdynlink interpreter is supposedly fairly slow (I haven't done 
any timings yet).  This is not that big of a deal for what I'm going to use 
it for, but if I find it is too slow, there are a couple options.  First, 
Fabrice has a mostly-finished JIT in the cdk version.  It's x86 only I 
think, but it might be useful.  [As an aside to Fabrice and/or Xavier, why 
didn't the JIT generate Cmm code instead of x86, and then link in the 
compiler backend from the current platform, and that way it would be 
cross-platform?  That would work, right?]  The other option is to rewrite 
the interpreter by porting the C interpreter over the the asmdynlink 
environment...that should be fairly easy and should run at the same speed 
as the regular bytecode interpreter.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners