Safe, Closure-free, Serializable functions

Bradley Meck bradley.meck at
Thu Sep 26 06:36:42 PDT 2013

The only really think of that would be of benefit is parallel execution. I
can think of is a work stealing scheduler like Rust is getting, or a
symmetric operation like mapping an array / comprehensions being able to
exploit that work can be done on multiple threads without issue (for
example on very large arrays). This is all currently doable with a
"sufficiently clever compiler", but languages such as D implement a "pure"
keyword for things such as this.

Just things to think about,

On Thu, Sep 26, 2013 at 4:21 AM, David Bruant <bruant.d at> wrote:

> Le 26/09/2013 01:29, François REMY a écrit :
>  Hi,
>> TLDR ==> The web needs a way to express executable code that does not
>> rely on its parent context, is guaranteed to be side-effect-free, and can
>> be executed safely anywhere (even in a different
>> thread/worker/window/device, or as callback for browser code being executed
>> while the DOM is not ready to be accessed)
> Why "need"? You don't really expose a use case. You only start with "It's
> been some time I've been working on this idea of a..."
> Also, one thing is not really clear to me. Are you trying to protect the
> function from its caller/loader or the caller from the function? both?
>  The good thing about those functions, is that they can safely be sent
>> over the wires to another thread, or to another web page, because they do
>> not possibly rely on any state or context.
> This is an interesting use case.
> I've come across such a use case when doing MongoDB MapReduce [1]. I was
> doing Node.js code and unlike in other MongoDB clients, I had the
> interesting benefit of having syntax coloration for my map and reduce
> functions:
>     // global scope
>     var map = '' + function(){
>        // map code
>     }
> (in other language, you have to put the JS in a string and so don't have
> syntax coloration).
> Of course, my functions couldn't use any Node.js built-in since they were
> meant to be serialized to be sent to MongoDB.
> To be honest, I did fine with this trick. The function being global, I had
> no temptation to use anything from the parent scope... since there was no
> parent scope.
> At scale, maybe I would have needed a more systematic approach to make
> sure my functions weren't using non-standard globals. But that can be part
> of my test infrastructure. I'm pretty sure an Esprima-based tool already
> exists to find free variables.
> In the previous paragraph, I loosely used the word "standard". Indeed,
> there is no standard JavaScript implementation. There are a bunch of
> implementations with different levels of conformance to existing standards.
> For instance, at the time I used MongoDB, it was using an old SpiderMonkey
> that didn't have Object.keys. I learned this the hard way. In that
> experience, I learned that one of the things you're trying to achieve (move
> "standard" code from machine to machine) is somewhat undoable. It's a very
> context-sensitive problem. Now that MongoDB is using v8, maybe I can use
> Object.keys, but won't be able to use the non-standard-then-yet-**convenient
> destructuring available in SpiderMonkey.
> Also, MongoDB provides to the serialized function a non-standard "emit"
> function. Your proposal prohibits non-ES6 built-ins, thus preventing such
> an emit function to be provided (arguably, they should pass this function
> an argument). I can also easily imagine that if sharing code between two
> same-version Node.js instances, one may want to be able to use
> Node.js-specific additional globals.
>  Is there some interest from anyone else in formalizing this for a future
>> version of EcmaScript? Or any comment?
> Given my experience with MongoDB, I'm tempted to ask: do we need this at
> all? A global function (no parent scope) and combined with a tool finding
> free variables might be enough to cover this use case.
> David
> [1]**manual/core/map-reduce/<>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list