From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p19I3Wt4005007
	for <caml-list@sympa-roc.inria.fr>; Wed, 9 Feb 2011 19:03:32 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmcBAO1lUk1KfVI0kGdsb2JhbACYUoxuCBYBAQEJCQwHEQQgohGMIwEFjV0BBIVclCk6
X-IronPort-AV: E=Sophos;i="4.60,446,1291590000"; 
   d="scan'208";a="90995811"
Received: from mail-ww0-f52.google.com ([74.125.82.52])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Feb 2011 19:03:27 +0100
Received: by wwd20 with SMTP id 20so445700wwd.9
        for <caml-list@inria.fr>; Wed, 09 Feb 2011 10:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=domainkey-signature:from:to:references:in-reply-to:subject:date
         :organization:message-id:mime-version:content-type
         :content-transfer-encoding:x-mailer:thread-index:content-language;
        bh=jDVD8fXf3w16x14tDuyhDiCTDEf4uukeUFaKGaceeA8=;
        b=e5iFZk/MbsuKJDt8LWzMA8BZRZejouY0fGYqt56nNt/KlnDU0KwmlFVNu+jZzk7Bhc
         Cymq6QYgU0PLWmg2e6yuPFXUky5cuur3L7uy2GY1cOHwcYcVKWEck5eXg7e1nZ4TZgCj
         fX5TN1MyGgVfmJM72tSsbhEl998JeYOhLL/P0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=from:to:references:in-reply-to:subject:date:organization:message-id
         :mime-version:content-type:content-transfer-encoding:x-mailer
         :thread-index:content-language;
        b=iFtYulSiVplxbxFluT5n2M4P/+l+XFUwKGk5d39mEkW6C+kpXVUPE+uCEV1lE3hWJ6
         poapvOivjL2SN4NfbINonfKc6R6uOf5+GnBZIGUexBjPOINYUNiEW73uTYSb3WBrjjbb
         BnHdhaWcQdxImYCEkRY4zdW92F0bbfkq8FQCo=
Received: by 10.227.155.198 with SMTP id t6mr11394588wbw.194.1297274606809;
        Wed, 09 Feb 2011 10:03:26 -0800 (PST)
Received: from WinEight (231.98.112.87.dyn.plus.net [87.112.98.231])
        by mx.google.com with ESMTPS id x1sm501394wbh.8.2011.02.09.10.03.24
        (version=SSLv3 cipher=RC4-MD5);
        Wed, 09 Feb 2011 10:03:25 -0800 (PST)
From: Jon Harrop <jonathandeanharrop@googlemail.com>
To: <orbitz@ezabel.com>, <caml-list@inria.fr>
References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com>
In-Reply-To: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com>
Date: Wed, 9 Feb 2011 18:03:11 -0000
Organization: Flying Frog Consultancy
Message-ID: <045501cbc883$9e10c040$da3240c0$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvH7AwiksQ8phs5T6OPdTwXbfg6KAAd8fUQ
Content-Language: en-gb
Subject: RE: [Caml-list] Scoped Bound Resource Management just for C++?

Orbitz wrote:
> One of the benefits, in my opinion, of C++ is SBRM.  You can reason
> about the lifetime of an object and have an give yourself guarantees
> about its clean up.  The method of initialization and clean up are
> also consistent for every object in the language.
> 
> My questions are:
> 1) Do other people in the FP world consider this to be a good strategy?

For some kinds of resources under some circumstances, yes.

> 2) Can this be done in a sane way in a GCd language?

Yes, of course. You just use a higher order function to factor out the
pattern of initializing and cleaning up the resource. For example, the
following "file" function opens a file, applies the given function "f" to
the resulting channel and then closes the channel:

  let file name f =
    let ch = open_in name in
    try
      let x = f ch in
      close_in ch;
      x
    with e ->
      close_in ch
      raise e

The OOP equivalent is called the command pattern. On the .NET platform, this
pattern is provided by the IDisposable interface and languages like C# and
F# even include syntactic support for it. This is used to handle resources
that benefit from deterministic cleanup, like file handles.

> 3) What are the alternatives in a language like Ocaml?

The most obvious alternative is to leave clean up to the garbage collector
by using a finalizer. When the resource is either memory or equivalent to
memory, this works extremely well in practice and is simpler than manual
memory management. For example, I once used the garbage collector to clean
up OpenGL display lists. However, this is not generally advised for
non-memory resources because they tend to be much more precious and,
therefore, prone to being exhausted.

Cheers,
Jon.