> 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. >
+1000 I would love to see persistent immutable data structures part of ES7. I think they would be a fantastic fit for both concurrent and non-concurrent js code.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
