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 p19LCxAC010982 for ; Wed, 9 Feb 2011 22:12:59 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAHWSUk2LEwExe2dsb2JhbAClWhYBFiIFH61uAY1uBYVc X-IronPort-AV: E=Sophos;i="4.60,447,1291590000"; d="scan'208";a="91002954" Received: from hera.mpi-sb.mpg.de ([139.19.1.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Feb 2011 22:12:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Subject:Mime-Version:Date: References; bh=j6/AmIs6Bk4rMYW2P8cgdp1yo+ooKCwE4GHRmf3WxFw=; b=O MI72WoqLLU1uEa3dl3iqbT6aAGjNmXNiVilbQNE+dys3sNUOAPeo9GxCqciRoR9p x6wM1lQNbLAx3WcTKzIYrZqRjHsDlvX3ViSarMjQFKNZE89HtWoXHgNparZJd+Uz rSy3hKfxnfvmrBvI2dBj44t6AE7GuzQviqv0SqT6bg= Received: from maniac.mpi-klsb.mpg.de ([139.19.1.26]:35839) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1PnHLH-0007SL-1u; Wed, 09 Feb 2011 22:12:53 +0100 Received: from mnch-4d046580.pool.mediaways.net ([77.4.101.128]:61371 helo=[192.168.178.21]) by maniac.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) id 1PnHLG-0007IC-Hk; Wed, 09 Feb 2011 22:12:50 +0100 Message-Id: <8DECBDB1-84C6-4609-9C2A-8C9AEDE337A1@mpi-sws.org> From: Andreas Rossberg To: OCaml List In-Reply-To: <87sjvxszr1.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Feb 2011 22:12:49 +0100 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> <87sjvxszr1.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] Scoped Bound Resource Management just for C++? On Feb 9, 2011, at 21.45 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. I still don't know what you are talking about. Why should a suitable type system not be able to make such an operation ill-typed? >>>> 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-) Right. But these are examples of collateral damage of useful features, while the one under discussion is just the damage, with no new expressiveness to justify it. ;) /Andreas