Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Kenneth Adam Miller <kennethadammiller@gmail.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Compiler Intrinsics question
Date: Wed, 18 Mar 2015 07:10:51 +0100	[thread overview]
Message-ID: <CAPFanBGktV+RZuBM4HHnD4tr=3xL_Fc9zffqBCWFt8F_2UDdrg@mail.gmail.com> (raw)
In-Reply-To: <CAK7rcp_dNwJmFdhv_z0ArDB=KorRsfKm==b0_qvLiTCb4J6SQA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

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"?
>

[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

  reply	other threads:[~2015-03-18  6:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18  3:16 Kenneth Adam Miller
2015-03-18  6:10 ` Gabriel Scherer [this message]
2015-03-20  8:38   ` Ben Millwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPFanBGktV+RZuBM4HHnD4tr=3xL_Fc9zffqBCWFt8F_2UDdrg@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=kennethadammiller@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox