From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3FB837EEE0 for ; Wed, 18 Mar 2015 07:11:35 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.181 as permitted sender) identity=mailfrom; client-ip=209.85.213.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f181.google.com) identity=helo; client-ip=209.85.213.181; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f181.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpAADPFglVm7XVVdFbhDIEgwnIeQKBPgdMAQEBAQEBEQEBAQEBBgsLCRQuhBABAQMBEhEdARsdAQMBCwYFBAc3AgIhAQERAQUBHAYTIod4AQMJCKNmPjGLMYFrgneQZQoZJw1UhGcBAQEBAQUBAQEBAQEWAQUOiwmCRIItB4JogUUFmC4zgUyBGxGMBkyEXBIjgQwJhBI9MYJDAQEB X-IPAS-Result: A0DpAADPFglVm7XVVdFbhDIEgwnIeQKBPgdMAQEBAQEBEQEBAQEBBgsLCRQuhBABAQMBEhEdARsdAQMBCwYFBAc3AgIhAQERAQUBHAYTIod4AQMJCKNmPjGLMYFrgneQZQoZJw1UhGcBAQEBAQUBAQEBAQEWAQUOiwmCRIItB4JogUUFmC4zgUyBGxGMBkyEXBIjgQwJhBI9MYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,420,1422918000"; d="scan'208";a="103774955" Received: from mail-ig0-f181.google.com ([209.85.213.181]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Mar 2015 07:11:33 +0100 Received: by igbue6 with SMTP id ue6so67193416igb.1 for ; Tue, 17 Mar 2015 23:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bKS6HxB5/WKF0sNaFIiJJsTFWyfm1orz9ujtM4uln5g=; b=UCZyigPy7JnHi5s/evbmI0qFMyOSR/BaZAFXJ4vJH+Kz3jkBE1Nv57jjN+IzGZHC2B CTZQCvc/6opkJVA/p09/8DZVGSAQjvpdOr8rqM+nJ59gMeQ0QhBh7o6NzQAg8sleNdsC KRmJ6IMiM/P1hHx2UG4+kBSEDsaq7AjTEUFETvUes9H9X7QJCOef2xMmEpqFvmJbkHCV MnQXUCFTz/TdfgqjZhPfEbdPMNUHhGoezmfw5h4aRYZQyb4iDxeepJS+QkCdrDviyeWI E1IUuImRVPTdBAYn+E0PsxHQKD/naNuufC6IjyuBLqJwDP4K45vjlO2LSyPkVtblLx0w Zwpw== X-Received: by 10.107.148.198 with SMTP id w189mr37918777iod.14.1426659092031; Tue, 17 Mar 2015 23:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.53.69 with HTTP; Tue, 17 Mar 2015 23:10:51 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Wed, 18 Mar 2015 07:10:51 +0100 Message-ID: To: Kenneth Adam Miller Cc: caml users Content-Type: multipart/alternative; boundary=001a113ff6d8656f8a051189f477 Subject: Re: [Caml-list] Compiler Intrinsics question --001a113ff6d8656f8a051189f477 Content-Type: text/plain; charset=UTF-8 I think the effect you may be thinking of is to notice that the immutable structure for which a field update is performed is uniquely owned / linearly used (the old version before-update is never used again), and to perform the mutation in place in this case. OCaml does not perform this optimization. It's not immediate that this could be done at all, because mutation has a tricky interaction with the GC invariants. On Wed, Mar 18, 2015 at 4:16 AM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > So, OCaml uses a lot of immutable data structures by default, and there's > a way in OCaml to express how to replace everything else in a type with the > same edition, with the exception of a single variable being updated. > > > But does that mean that the compiler is sufficiently capable to conclude > side effects that are more efficient rather than just the nieve > explanation, which is a *copy* of the entire data structure with only the > specified changed variable updated? Can OCaml conclude that it can update > only one variable for efficiency, and know that the rest of the data > structure is safe? > > For example, in tail recursion, it's provably equivalent to produce code > that doesn't blow the stack and is faster, and that's exactly what the > compiler does. So are side effects a "conclusion"? > --001a113ff6d8656f8a051189f477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the effect you may be thinking of is to notice tha= t the immutable structure for which a field update is performed is uniquely= owned / linearly used (the old version before-update is never used again),= and to perform the mutation in place in this case. OCaml does not perform = this optimization. It's not immediate that this could be done at all, b= ecause mutation has a tricky interaction with the GC invariants.
=

On Wed, Mar 18, 2= 015 at 4:16 AM, Kenneth Adam Miller <kennethadammiller@gmail.com= > wrote:
S= o, OCaml uses a lot of immutable data structures by default, and there'= s a way in OCaml to express how to replace everything else in a type with t= he same edition, with the exception of a single variable being updated.

But does that mean that the compiler is suff= iciently capable to conclude side effects that are more efficient rather th= an just the nieve explanation, which is a *copy* of the entire data structu= re with only the specified changed variable updated? Can OCaml conclude tha= t it can update only one variable for efficiency, and know that the rest of= the data structure is safe?

For example, in tail = recursion, it's provably equivalent to produce code that doesn't bl= ow the stack and is faster, and that's exactly what the compiler does. = So are side effects a "conclusion"?

--001a113ff6d8656f8a051189f477--