On Fri, Mar 7, 2008 at 9:10 AM, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:
>  1- Change the specs of caml_register_global_root() to prohibit
>  in-place updates to the value contained in the registered value
>  pointer.  If programmers need to do this, they must un-register the
>  value pointer, update its contents, then re-register it.
>  How much existing code would that break?  I don't know.

I have just looked at a fairly large number of bindings.  Only a few
actually register global roots, and those that do would be perfectly
safe - with the exception of LablGTK it seems.  I'm a bit wary of
changing the semantics of global root registration in a way that could
seriously break existing libraries even though almost all of them seem
fine.

>  2- Keep the current API for backward compatibility and add a
>  caml_register_global_immutable_root() function that would implement
>  generational scanning of global roots, in exchange for the
>  programmer's guarantee that the values contained in those roots are
>  never changed.  Then, convince authors of Caml-C bindings to use the
>  new API.

After having given it some thought, I think I prefer this approach.
As a maintainer of some C-bindings that would be affected by this
change, I'd be perfectly happy to upgrade them, which seems like
extremely little work.

I also second Berke Durak's proposal to add some kind of modification
macro/function.  Concerning the naming we should maybe avoid the name
"immutable" then, because one can obviously update the value, but has
to do so explicitly.  How about "caml_(un)register_generational_root"
and "caml_modify_generational_root"?

> I'm willing to implement any of these 2 approaches, but it is not a
> transparent change in either case.

Thanks a lot, this would be great!

Best regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com