caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Leandro Ostera <leandro@ostera.io>
To: Leo White <leo@lpw25.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] <DKIM> flambda for bytecode backend
Date: Mon, 15 Jan 2018 10:51:55 +0000	[thread overview]
Message-ID: <CAH2TZMgyjN2gBZhosRRkTXy08P9AQ5oP8-w35mxykUmGGZ3ayg@mail.gmail.com> (raw)
In-Reply-To: <1516012497.2168791.1235601456.5B7510E5@webmail.messagingengine.com>

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

You could also use the binding mechanism that js functions have to swap the
context they are ran in, although I’m not sure if it’s going to be faster
than the two options already provided above.

function f_unbound(x) { return (x + this.y); }

const env = { y: 1 };
const f = f_unbound.bind(env);
f(1) // 2
mån 15 jan. 2018 kl. 11:35 skrev Leo White <leo@lpw25.net>:

> > The best we could do (without doing some magic) would look like:
> >
> > let f x =
> >   let y = x + 1 in
> >   let g z = z + y in
> >   g
> >
> > compiled to:
> >
> > function f_code(x, env) {
> >   let y = x + 1;
> >   function g_code(y, env) {
> >     return(z + env.y);
> >   }
> >   let g = { code : g_code, env : { y: y };
> >   return(g);
> > }
> >
> > let f = { code : f_code, env : { } }
>
> Pierre is right about the reason we don't use flambda with
> bytecode, although I don't think that is the best JavaScript we
> could produce.
>
> It would not be to difficult to undo closure conversion within
> the function body itself. This still leaves references to the
> closure outside of the function body.  These aren't shown in
> Pierre's example but they are produced during inlining and are
> the main thing that flambda uses which bytecode doesn't
> support. For these we can take advantage of the fact that
> JavaScript functions are also ordinary objects, attaching the
> environment to the function as fields:
>
>     function f(x) {
>       let y = x + 1;
>       function g(z) {
>         return(z + y);
>       }
>       g.y = y;
>       return(g);
>     }
>
> Of course, this could still have an adverse effect on how the JIT
> of different browsers deals with these functions, so some
> benchmarking would be needed to confirm the viability of this
> approach.
>
> Regards,
>
> Leo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

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

  reply	other threads:[~2018-01-15 10:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 18:36 [Caml-list] " Alexey Egorov
2018-01-14 18:29 ` [Caml-list] <DKIM> " Pierre Chambart
2018-01-15 10:34   ` Leo White
2018-01-15 10:51     ` Leandro Ostera [this message]
2018-01-29 16:26     ` [Caml-list] OCaml <-> Computer Algebra Nicolas Ratier

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=CAH2TZMgyjN2gBZhosRRkTXy08P9AQ5oP8-w35mxykUmGGZ3ayg@mail.gmail.com \
    --to=leandro@ostera.io \
    --cc=caml-list@inria.fr \
    --cc=leo@lpw25.net \
    /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;
as well as URLs for NNTP newsgroup(s).