From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p190mJjf022484 for ; Wed, 9 Feb 2011 01:48:20 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAB5zUU3RVaA2kGdsb2JhbACXJY4VCBUBAQEBCQkMBxEEIKJ/jCOEaYkIAQEDBYVVBIR5hnGDL26EEjqBDg X-IronPort-AV: E=Sophos;i="4.60,444,1291590000"; d="scan'208";a="87688364" Received: from mail-pw0-f54.google.com ([209.85.160.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Feb 2011 01:48:16 +0100 Received: by pwi10 with SMTP id 10so8419pwi.27 for ; Tue, 08 Feb 2011 16:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=KQdPtRVjIs1zRsd9GU/5NM48b9cgiqdGRBQmeT1R8JY=; b=JMP84JEi4+GOB2fOLwoEefXIq8LOAewSQ2WWKYQNbKV8jOa61znoFxpSY3U39QW4o+ Lsq271ts7/9VZHOe3tFWdkAbbCwm57f4Nk7P2PBD6nHvIHgO6YVoe+LovwlGSCMqFPH9 CtsTwaWTCP70dQpPxlIW9fVAhsAxwyumUNUro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=wri//1nHEnyUHGJQHrVyyBOtVusRQEb8glpjOtf9BD6zsLt4byRsdvqUVxOeQDQwEy E4uUwJkWhLiy4OP/02RVFYue10u9qJc1uj4A8bhMzwbuW+/93CWGKwsm7GfQGRNs1PyA 6IlQbfm7+kffssD9649JRR5c4XhXQqMHtl/XE= Received: by 10.142.221.1 with SMTP id t1mr636280wfg.168.1297212494308; Tue, 08 Feb 2011 16:48:14 -0800 (PST) Received: from [192.168.1.212] (nat-10-0.math.nagoya-u.ac.jp [133.6.130.80]) by mx.google.com with ESMTPS id y42sm280236wfd.10.2011.02.08.16.48.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Feb 2011 16:48:13 -0800 (PST) Sender: Jacques Garrigue Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jacques Garrigue In-Reply-To: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> Date: Wed, 9 Feb 2011 09:48:15 +0900 Cc: caml-list@inria.fr Message-Id: References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> To: orbitz@ezabel.com X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p190mJjf022484 Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? On 2011/02/09, at 8:57, orbitz@ezabel.com 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? > 2) Can this be done in a sane way in a GCd language? > 3) What are the alternatives in a language like Ocaml? It is difficult to compare a manually managed language to a GCd language, a fortiori a functional one. One first answer is that if your language is GCd you don't care about lifetime: the GC will clean up when needed anyway. You may be concerned by when finalization occurs, but if your language is functional finalization cannot be observed, so you really don't care. So I would say that you really don't think about these problems in most situations. The only exceptions I see are: * Memory leaks: have to be careful that you are not referencing dead data, preventing the GC from freeing it. This is a well known problem in Haskell, where you have lots of closure which can refer to huge amounts of data. This is much less a problem in ocaml, where most data structures do not contain closures, so you just have to be careful to design your data structures properly (you have to in any language...) * Interaction with external world: explicitly managing objects outside of the ocaml heap. This is going to occur when you interface with a database, or with any external library or entity that manages large states. A good example is communicating with a GUI library. The GC API allows you to free data structures when they are no longer referenced by ocaml, but this may be too late (your application may not be calling the GC often enough, or you may have lurking references around) This is a situation where you might want to reason about object lifetime, but I'm not aware of tools to do that in ocaml. I don't know if SBRM (whatever it is) would help there. Jacques Garrigue