On Sun, Apr 21, 2013 at 9:29 PM, Mark S. Miller <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected] >> > >> > wrote: >> >> >> >> On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd <[email protected]> >> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
