From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p9F97Bkw006591 for ; Sat, 15 Oct 2011 11:07:11 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBANpLmU7RVaC2kGdsb2JhbABDhHajZwgiAQEBAQkJDQcUBCGBbgEBAQQSAg8EGQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEyKhOQqLDEWCYIR2PYhuAgUKgSaFQIEUBJN6jSo9g3E X-IronPort-AV: E=Sophos;i="4.69,350,1315173600"; d="scan'208";a="113008158" Received: from mail-gy0-f182.google.com ([209.85.160.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Oct 2011 11:07:05 +0200 Received: by gyd8 with SMTP id 8so2690306gyd.27 for ; Sat, 15 Oct 2011 02:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=USuO1FEtL8vJOtcSjiqtYy41TebS6fXWGz6VcRkEVjM=; b=aedJrIXtSFtG1YrJVn4kGR+t0BUfjRngF6R85ZeQtSe52RCD2wYrobmZUVtKq5I+z1 DrogE9LIdlpJlh7zTYmi2IoCh9yrbk+1GPTtYSC/wtMvhQwuV36FjeOzOCsEy9Wmdmsy FHUvC2cBAIIDca0ttTnp1tN6b0/KEnVgmOd+I= MIME-Version: 1.0 Received: by 10.68.29.101 with SMTP id j5mr22646927pbh.61.1318669623681; Sat, 15 Oct 2011 02:07:03 -0700 (PDT) Received: by 10.143.34.7 with HTTP; Sat, 15 Oct 2011 02:07:03 -0700 (PDT) In-Reply-To: <4E993FE5.7080409@ens-lyon.org> References: <4E993FE5.7080409@ens-lyon.org> Date: Sat, 15 Oct 2011 11:07:03 +0200 Message-ID: From: Nicolas Pouillard To: Martin Jambon Cc: OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] How to mutate immutable record fields? On Sat, Oct 15, 2011 at 10:10 AM, Martin Jambon wrote: > Dear fellow OCamlers, My guess is that set_field is not to blame here. The ``trouble'' is that ocamlopt optimizes the immutable read access to the supposed immutable foo field, and reads it before the call to set_field. We can see this in sevral ways: first making it a mutable field gives the expected behavior, second making the projection harder to optimize by turning t.foo into ((fun x -> x) t).foo has also the correct behavior. Other simple variations reveal the same behavior. Obj.regards, -- Nicolas Pouillard http://nicolaspouillard.fr