Re: ocaml?? why??

[Vincent Hanquez <vincent.hanquez@eu.citrix.com>]

John Levon wrote:
>> OCaml has been great to use. Programming the same functional tree store 
>> with advanced transaction merging capability in the C version would have 
>> been a major pain, compared to how (almost) easy it was in OCaml.
>>     
>
> So, I'm interested: why?
>   
The initial reason was getting rid of the on-disk database that also 
work as the mechanism for transaction  merging (a language with a GC is 
good for that). However it became quite clear, that we could also solve 
the problem of transaction stalling through the immutable tree and also 
making transactions cheap (the tree representation is shared over all 
transactions) compare to copying the whole database over filesystem of 
the C version.

at this point, making the transaction cheap is almost a given because of 
the language good GC (not referenced base !). the merging mechanism is 
something like 50 lines at this point too, with minimum code 
modifications on operations since that's the normal tree operations. 
(the C version has the same "normal operation" policy by  copying the 
whole database and just changing which database is actually being 
referenced)

So now the reason, why not to modify the C version .. first getting rid 
of disk database to the memory, is quite annoying to do (but relatively 
easy so far) .. then you need to solve the problem of transaction stalling.
there's lots of ways i guess, but i haven't imagine a solution where the 
same thing that the ocaml code does become trivial in C. either you need 
to modify every operation to understand some kind of modification list 
so that the tree get modified only at commit time (compare to now, at 
every operations), or you need to implement some kind of immutable tree 
(careful the C language doesn't prevent you for modifying it) which 
*requires* a GC that you need to implement too (or take one of those 
implementation from somewhere ..).

there's lots of other small reasons too, like the static type system 
that protect a lot during development phase (xenstored is very annoying 
to test, since it requires for full testing, to reboot the machine), and 
it's still an asset when i need to prove that no unexpected type are 
going to appears somehow (try to do the same thing in python and have 
fun :).

But surely xenstored could be implemented in any language, but I 
certainly wouldn't want to be the one fixing the C one, or implementing 
a python xenstored !

-- 
Vincent