ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Dean Landolt dean at
Mon Apr 22 06:43:45 PDT 2013

On Sun, Apr 21, 2013 at 9:29 PM, Mark S. Miller <erights at> wrote:

> Agreed that Object.freeze does not give you what you need.
> RiverTrail already needs a kind of collection that is transitively
> immutable by construction. They need this for safe data parallelism. But
> the reason they are safe for parallel access within a vat/worker is the
> same reason they would be safe to pass-by-sharing between vats/workers that
> share an address space. And between address spaces, including between
> machines, they would be passed by copy, but without any observable
> difference beyond performance. We should keep this in mind as we proceed on
> the RiverTrail work.

I completely agree with Mark, and would add that there's a lot to be
learned from the kind of transitive immutability employed by clojure's
persistent data structures. Bringing this kind of thing to js could be
pretty straitforward, and IIUC modern js vms already employ this kind of
structural sharing in the form of ropes for string manipulation. If this
kind of primitive could be extended to userland (perhaps in conjunction
with value types) it would be a huge win for concurrency (safe and free to
pass between workers -- no ownership transfer semantics necessary),
parallelism (RiverTrail would eat this up), but it could be an even bigger
win for run-of-the-mill js code.

Persistent immutable data structures would be a big usability improvement
in their own right. In a world where it's just as cheap and convenient to
use immutable structures as it is to depend on side-effects, code that does
this (including your own) would be a whole lot easier to reason about and
would have objectively better security properties. I'd think this alone
would justify their consideration -- but as Mark suggested, they could also
have real performance advantages given RiverTrail or workers.

But I'll double down on that and suggest there are perf wins to be had for
regulation js code w/o any concurrency or parallelism primitives. For
instance, a persistent immutable array primitive backed by something like a
fingertree would have some really interesting characteristics compared to a
standard js array -- efficient splicing, binary search, deque operations,
constant-time reverse, to name a few. And I won't even start on the
amazingly cool things that could be done if you could provide group
calculations for caching in the branches of your tree (except to say that
js devs should be shouting about monoids, not monads!). And of course this
kind of group-theoretical approach could extend naturally to RiverTrail
code as well...

I bring this up because I think these kinds of optimizations and
performance-specific features would be interesting and useful to explore,
but having said all that, I believe the utility of persistent data
structures stands on it's own, regardless of possible perf wins (parallel,
concurrent or otherwise). I would love to see this discussed along with
value types for es7.

> On Sun, Apr 21, 2013 at 3:49 PM, Sam Tobin-Hochstadt <samth at>wrote:
>> Then consider `Object.freeze(console)`.
>> Fundamentally, frozen objects are not appropriate for prohibiting shared
>> state.
>> Sam
>> On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd <kevin.gadd at> wrote:
>> > isn't typeof (console.log) "function" and not "object"? by object I
>> meant an
>> > Object object, not 'any arbitrary JS value'. I suppose the distinction
>> is
>> > really blurry, and you would still have to deal with problems like the
>> > object's prototype chain containing callables...
>> >
>> >
>> > On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt <samth at
>> >
>> > wrote:
>> >>
>> >> On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd <kevin.gadd at>
>> wrote:
>> >> > if I called Object.freeze or Object.seal on a JS object would it
>> >> > actually be
>> >> > safe to pass it to another thread and let both threads use it without
>> >> > any
>> >> > locking or guards?
>> >>
>> >> No, it's not safe.  Consider Object.freeze(console.log).
>> >>
>> >> Sam
>> >
>> >
>> >
>> >
>> > --
>> > -kg
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list