From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 2D6F7BC37 for ; Tue, 9 Feb 2010 04:38:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN5ncEuFBoIF/2dsb2JhbADJT414AQSCQ4IRgxQ X-IronPort-AV: E=Sophos;i="4.49,434,1262559600"; d="scan'208";a="43986853" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Feb 2010 04:38:19 +0100 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id ECF76B63B; Tue, 9 Feb 2010 12:38:15 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (camel-172 [172.16.254.4]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 914AE88A9; Tue, 9 Feb 2010 12:38:15 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= date:message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=alpha; bh=kK8QDC9H4kIN/ahG+421kLBDQh8=; b=yDv+F13h6NUC56jBmRR/IxuM1Aiz nei380QF6Ye7x1b1hryZNIaGvGmpCJjH9bi1Piv6Peu6yMie2qCiTk5/I+UuxY+y rR4KdqLmJ7e7L6U09iqwG9TzqXSYjOMqn4aA47pyHJIcoaffXOV2Ku3Im65nIsy2 ei7N7qbo176m68s= DomainKey-Signature: a=rsa-sha1; h=Received:Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; b=GkaRFzcOJrsdnhX1D3k7y+qG6Oc9+OKlXCto6urZEl+wn9DTvb9lwf7pul/fiQWi6vce5OVr6Kjn9y0Zpx6qhIl7j8KubZ4cP6VOX+1O+zRLg73vXzAGDdQXCZh9ysOpRHgCqeSJq9i+ZsmKmAPEKp7EDBjOmhEeO1gg9H3fhvg=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from localhost (millas [172.16.30.29]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 73E0288A8; Tue, 9 Feb 2010 12:38:15 +0900 (JST) Date: Tue, 09 Feb 2010 12:38:13 +0900 (JST) Message-Id: <20100209.123813.39168535.garrigue@math.nagoya-u.ac.jp> To: rich.neswold@gmail.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Preventing values from escaping a context From: Jacques Garrigue In-Reply-To: <14cf844b1002081907y2900c313q97ae0cb6f4c92394@mail.gmail.com> References: <14cf844b1002081907y2900c313q97ae0cb6f4c92394@mail.gmail.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; val:01 compiler:01 ocaml:01 runtime:01 caml-list:01 functions:01 functions:01 expressive:01 short:01 data:02 parameter:02 parameter:02 ctx:02 ctx:02 garrigue:03 From: Rich Neswold > Most of the functions in my library take a parameter that describes the > current environment. I call this data type, "context". The context is passed > to a function which will then use other functions in the library to get its > job done. The signature of the function that starts all this is: > > val usingContext : (context -> 'a) -> 'a [...] > My question is this: Is there a way to make the compiler reject a function > parameter from returning the context parameter? For instance, the identity > function should be disallowed since the context is invalid outside the scope > of 'usingContext'. It's true that a returned context would be unusable, > since its resources are gone, but it would be nice to prevent contexts from > escaping the 'usingContext' function entirely. The short answer is no. Types are not sufficient to prevent values from escaping. In ocaml, you have both functions and references. So you can always plug a function of type [unit -> unit] into a reference, and the function is allowed to access the full context available when it was created. let r = ref (fun () -> ()) let f ctx = r := (fun () -> chgCtx ctx) (* later on *) List.hd !r () The language is just too expressive... You should rather look into adding a dynamic flag to your context, causing a runtime error if you use it later. Jacques Garrigue