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 p19Kk1nM009560 for ; Wed, 9 Feb 2011 21:46:01 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGyLUk1XaqLJgWdsb2JhbAClVxYBFiIkvAKFXASPIg X-IronPort-AV: E=Sophos;i="4.60,447,1291590000"; d="scan'208";a="91001963" Received: from ka.mail.enyo.de ([87.106.162.201]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Feb 2011 21:45:55 +0100 Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1PnGvC-0004RJ-S2; Wed, 09 Feb 2011 21:45:54 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.72) (envelope-from ) id 1PnGvC-0003x8-KC; Wed, 09 Feb 2011 21:45:54 +0100 From: Florian Weimer To: Andreas Rossberg Cc: OCaml List References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> <87hbcdvx99.fsf@mid.deneb.enyo.de> <72BF43D9-1BED-4327-955E-1A7460C18CDF@mpi-sws.org> Date: Wed, 09 Feb 2011 21:45:54 +0100 In-Reply-To: <72BF43D9-1BED-4327-955E-1A7460C18CDF@mpi-sws.org> (Andreas Rossberg's message of "Wed, 9 Feb 2011 21:10:31 +0100") Message-ID: <87sjvxszr1.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? * Andreas Rossberg: > On Feb 9, 2011, at 20.11 h, Florian Weimer wrote: > >>> Scope-bound resource management is inherently broken, at least >>> without sophisticated type system support. >> >> If the environment supports communicating processes with separate >> execution pointers, it is straightforward to bypass restrictions, no >> matter how evolved the type system is. > > I don't know what scenario you have in mind with "separate execution > pointers". In principle, I'm pretty certain that you could always > define some suitable (e.g. linear) type system, if your language was > sufficiently well-behaved. If you have coroutines or threads with communication among them, you can always turn type-enforced region-based handles into open handles with an explicit close operation. >>> 2) or it is unsafe, i.e. you can access an object after its life >>> time has >>> ended, with potentially desastrous effects. >> >> This can be made safe with type-safe memory and run-time checks. I >> don't think this is a good excuse. > > True, runtime checks can deal with some of the "disastrous effects", > but they cannot make it safe in a broader sense (e.g., type-safe in an > interesting way), and AFAICS don't apply to memory itself as a > resource. Like array bounds checking, integer division or other partial functions. 8-) > You may argue that that is good enough, but then again, you can > already achieve that level of assurance using higher-order > functions. This is mostly about syntax. There is already a very convenient notation, but it has a resource leak.