From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=AWL,DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id E5B8EBB84 for ; Thu, 30 Oct 2008 20:59:04 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtICAFuvCUnAXQIngWdsb2JhbACTTT4BARYirXiKUwEDAQODToIE X-IronPort-AV: E=Sophos;i="4.33,517,1220220000"; d="scan'208";a="30948980" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2008 20:58:59 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9UJwxPS012299 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 30 Oct 2008 20:58:59 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAAHCuCUlA6ba5kGdsb2JhbACTTT4BAQEBCQkMBxEDrWyKUwEDAQODToIE X-IronPort-AV: E=Sophos;i="4.33,517,1220220000"; d="scan'208";a="18696254" Received: from nf-out-0910.google.com ([64.233.182.185]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Oct 2008 20:58:58 +0100 Received: by nf-out-0910.google.com with SMTP id d3so455305nfc.7 for ; Thu, 30 Oct 2008 12:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=9dv7tsnkcwsHZU8s0t/o/t8pTXELjPI62qfAHQfRfGY=; b=w4N6wvEGvgLiZKQkUvtFkUBxJm/cimDFfrfX/MyvNrs6uQ1iprsUx5OPOllLgl1VRB frshTn0rWM6w7amM65nyIslnVPQi0EScHNZhQJpiE8j+ZOZYtcPaKl0Un4yu+VF4KcqV tPGCj+qP9CoOM5LeOT7/7Wify8jAWdYpERYTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=NlF0eG3O/bkefpctFZmPTmi9n6lm8j4U0/qvmlZrV+tEGeX9o03sQiNGuAVEULiEaD O/rl/7y43Fn+oNeuZMODeo31AYKzqk+83/hKjMMt710WkSKMGwEDAdbOpYUIf7Mk7Tf0 PxBLHGz4pmSb6UXQnM2vyMrHVvUXBfLdgMinc= Received: by 10.86.68.2 with SMTP id q2mr2563781fga.3.1225396738206; Thu, 30 Oct 2008 12:58:58 -0700 (PDT) Received: from ?10.0.1.2? (33-98.0-85.cust.bluewin.ch [85.0.98.33]) by mx.google.com with ESMTPS id 4sm3374154fge.8.2008.10.30.12.58.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Oct 2008 12:58:57 -0700 (PDT) Message-Id: <488D129D-0273-4DD0-AA2D-D39FC02594E6@erratique.ch> From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= To: OCaml Mailing List In-Reply-To: <4d1b2df20810301240o77e110cft6070c5cd0ad863b6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [Caml-list] let rec and environment sharing Date: Thu, 30 Oct 2008 20:58:29 +0100 References: <4d1b2df20810301240o77e110cft6070c5cd0ad863b6@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Sender: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= X-Miltered: at concorde with ID 490A1203.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 mutable:01 bool:01 mutable:01 rec:01 rec:01 caml-list:01 int:01 objects:02 unit:03 unit:03 let:03 let:03 daniel:04 Le 30 oct. 08 =E0 20:40, Philippe Wang a =E9crit : > If you mean [...] No I'm talking about the internal representation. For example if you =20 implement objects with records : > type o =3D { mutable m1 : unit -> bool; mutable m2 : unit -> int } > > let f bla =3D > let rec m1 () =3D bla =3D 0 > and m2 () =3D bla + 1 in > { m1 =3D m1; m2 =3D m2 } Then I hope that the closure's environment of m1 and m2 is shared, =20 that they do not each store their own mapping from bla to value. Another question I have is below, does bla leak after a call to m1 ? > let g bla blu =3D > let rec o =3D { m1 =3D m1; m2 =3D m2 } > and m1 () =3D > let rec m1' () =3D blu =3D 0 (* new method definitions = =20 > refers only blu *) > and m2' () =3D blu + 1 in > o.m1 <- m1'; o.m2 <- m2'; > bla =3D 0 > and m2 () =3D bla + 1 in > o Best, Daniel =20 =20=