Re: [Caml-list] Scoped Bound Resource Management just for C++?

[Guillaume Yziquel <guillaume.yziquel@citycable.ch>]

Le Wednesday 09 Feb 2011 à 10:15:43 (-0500), orbitz@ezabel.com a écrit :
> Thanks for the answers everyone.
> 
> How does one safely write code in Ocaml that guarantees resources
> will be freed?  Guillaume mentioned the with-idiom, but even that
> doesn't seem entirely safe.

It was Dmitry Grebeniuk that mentioned it. Not me.

To me, the closest you can get is:

module type Resource = sig

	type t (* opaque type for mystuff. *)

	val v : t option ref

	val free : t -> unit

	(* Some functions manipulating type t, without storing
	 * type t values in any other structures such as lists.
	 * Should avoid anything that 'unopacifies' type t *)

end

let sbrm (x : (module Resource)) =
	let module R = (val x : Resource) in
	let do_stuff z =
		(* Write your code here *)
	in
	let Some w = !v in
	let return_value = do_stuff w in
	v := None;
	free w;
	return_value
	
let wrap_my_stuff (my_stuff : my_type) = (module struct

	type t = my_type

	let v = ref (Some my_stuff)

	(* Declarations of other functions *)

end : Resource)

Essentially, you put my_stuff into a first-class module, when calling
the sbrm function, the module is unpacked, and the type R.t is local to
the scope of the function sbrm. This forbids you to store the value in
the reference v anywhere else (excepts if you use existentialish-type stuff
like objects, first-class modules, or funky records). So you code your
do_stuff function under this typing constraints, when you're done, you
invalidate the reference v, and then free the w stuff, and then return
the value.

This code is glaringly unsatisfactory and inefficient. It's however the
only way I see of (mildly) forbiding at the type level to put the value
that is supposed to have a scope-bounded lifecycle somewhere else in the
heap that might tell the GC that it should live longer.

This also assumes that as soon as you create an object of mystuff, it is
immediately wrapped using wrap_my_stuff, and not used anywhere else.

The memory content of mystuff may live on, but it gets 'finalised' in
the scope of the sbrm function.

You still have issues with putting your stuff into existential types (I
do not think this can be avoided). And in the current state, this idiom
is error-prone. Could perhaps be lifted to a Camlp4 syntax extension
which would make it more 'robust'. Something like

opaque Resource = struct

	opaque type t = mytype

	(* manipulations of type t or of type 'mytype' that gets
	 * rewritten to 't' by Camlp4 *)

end

would generate the module type, the embedding of mytypes into
first-class modules, and the adequate sbrm function, together with an
sbrm keyword mimicking the with idiom.

Needless to say, the with- idiom is much more practical.

Otherwise you would need to refine the type system of OCaml to include
information as to whether an argument can be attached to another
datastructure inside a given function. I do not see why it could not be
done, but I do not see why it should be done.

-- 
     Guillaume Yziquel