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 p19KAfqw008434 for ; Wed, 9 Feb 2011 21:10:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAADeDUk2LEwExe2dsb2JhbAClVBYBFiIFH64OAY1qBYVc X-IronPort-AV: E=Sophos;i="4.60,447,1291590000"; d="scan'208";a="91000782" 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 21:10:36 +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=V28d6HBazn4xU+UtQWUQ2uIug/mC8nH090jQ7mmnQBU=; b=Q An+DidewD5w+8lpvSHOrtVDRaBaIBdNeXnNWirH6LPC/wcxbJpUp8lqpGplug5W6 EmWVBhtNir2NZsc9DRNAKJaBCdBdk4gZqtneL1988E2nTuRIxaZ7nB05ulX027HE U3Kyfaxiap8DMdvTlWdXp/EGUP/oMcwKNsz41E1DR8= Received: from infao0525.mpi-klsb.mpg.de ([139.19.1.26]:43289 helo=maniac.mpi-klsb.mpg.de) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1PnGMy-00039d-Rf; Wed, 09 Feb 2011 21:10:35 +0100 Received: from mnch-4d046580.pool.mediaways.net ([77.4.101.128]:61247 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 1PnGMy-00073I-Dn; Wed, 09 Feb 2011 21:10:32 +0100 Message-Id: <72BF43D9-1BED-4327-955E-1A7460C18CDF@mpi-sws.org> From: Andreas Rossberg To: OCaml List In-Reply-To: <87hbcdvx99.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 21:10:31 +0100 References: <50AF76A1-30E0-4735-AFB2-88BB603899CE@ezabel.com> <77df810e993b3002f8b97622102da8dd.squirrel@mail.mpi-sws.org> <87hbcdvx99.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 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. >> 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. You may argue that that is good enough, but then again, you can already achieve that level of assurance using higher-order functions. /Andreas