Discuss
  • Immutable collection values

Immutable collection values

# Jussi Kalliokoski (10 years ago)

I figured I'd throw an idea out there, now that immutable data is starting to gain mainstream attention with JS and cowpaths are being paved. I've recently been playing around with the idea of introducing immutable collections as value types (as opposed to, say, instances of something).

So at the core there would be three new value types added:

  • ImmutableMap.
  • ImmutableArray.
  • ImmutableSet.

In the spirit of functional programming and simplicity, these types have no prototype chain (i.e. inherit from null). Instead, all the built-in functions that deal with these are accessible via respective utility modules or like with Array and Object, available as static methods of the constructors. I don't really have a preference in this.

We could also introduce nice syntactic sugar, such as:

var objectKey = {};

var map = {:
  [objectKey]: "foo",
  "bar": "baz",
}; // ImmutableMap [ [objectKey, "foo"], ["bar", "baz"] ]

var array = [:
  1,
  1,
  2,
  3,
]; // ImmutableArray [ 1, 2, 3, 4 ]

var set = <:
  1,
  2,
  3,
>; // ImmutableSet [ 1, 2, 3 ]

Being values, there could be nice syntax for common operations too:

{: foo: "bar" } === {: foo: "bar" } // true
{: foo: "bar", qoo: 1 } + {: qoo: 2, baz: "qooxdoo" } // ImmutableMap [
["foo", "bar"], ["qoo", 2], ["baz", "qooxdoo"] ]
<: 1, 2, 3 > + <: 3, 4, 5 > // ImmutableSet [ 1, 2, 3, 4, 5 ]
<: 1, 2, 3 > - <: 2, 4 > // ImmutableSet [ 1, 3 ]
[: 1, 2, 3 ] + [: 3, 4, 5 ] // ImmutableArray [ 1, 2, 3, 3, 4, 5 ]
"foo" in {: foo: "bar" } // true
"bar of {: foo: "bar" } // true
2 of <: 1, 2, 3 > // true

2 of [: 1, 2, 3 ] // true
var x = {}; x in { [x]: 1 } // true

Having no prototype chain combined with being a value also enables nice access syntax and errors:

var map = {: foo: "bar" }; set.foo // "bar"
map.foo = "baz"; // TypeError: cannot assign to an immutable value.

The syntax suggestions are up to debate of course, but I think the key takeaway from this proposal should be that the immutable collection types would be values and have an empty prototype chain.

I think this would make a worthwhile addition to the language, especially considering functional compile-to-JS languages. With the syntactic sugar, it would probably even render a lot of their features irrelevant because the core of JS could provide a viable platform for functional programming (of course one might still be happier using abstraction layers that provide immutable APIs to the underlying platforms, such as DOM, but then that's not a problem in the JS' domain anymore).

# David Bruant (10 years ago)

Le 09/11/2014 15:07, Jussi Kalliokoski a écrit :

I figured I'd throw an idea out there, now that immutable data is starting to gain mainstream attention with JS and cowpaths are being paved. I've recently been playing around with the idea of introducing immutable collections as value types (as opposed to, say, instances of something).

So at the core there would be three new value types added:

  • ImmutableMap.
  • ImmutableArray.
  • ImmutableSet.

Why would both Array and Set be needed?

We could also introduce nice syntactic sugar, such as:

var objectKey = {};

var map = {: [objectKey]: "foo", "bar": "baz", }; // ImmutableMap [ [objectKey, "foo"], ["bar", "baz"] ]

var array = [: 1, 1, 2, 3, ]; // ImmutableArray [ 1, 2, 3, 4 ]

var set = <: 1, 2, 3,

; // ImmutableSet [ 1, 2, 3 ]

The syntax suggestions are up to debate of course, but I think the key takeaway from this proposal should be that the immutable collection types would be values and have an empty prototype chain.

I find ":" too discrete for readability purposes. What about # ? That's what was proposed for records and tuples (which are pretty much the same thing as ImmutableMap and ImmutableSet respectively) strawman:records, strawman:tuples #SyntaxBikeshed

I think this would make a worthwhile addition to the language, especially considering functional compile-to-JS languages. With the syntactic sugar, it would probably even render a lot of their features irrelevant because the core of JS could provide a viable platform for functional programming (of course one might still be happier using abstraction layers that provide immutable APIs to the underlying platforms, such as DOM, but then that's not a problem in the JS' domain anymore).

It would also open the possibility of a new class of postMessage sharing (across iframes or WebWorkers) that allows parallel reading of a complex data structure without copying.

A use case that would benefit a lot from this would be computation of a force-layout algorithm with real-time rendering of the graph.

# Jussi Kalliokoski (10 years ago)

On Sun, Nov 9, 2014 at 5:39 PM, David Bruant <bruant.d at gmail.com> wrote:

Le 09/11/2014 15:07, Jussi Kalliokoski a écrit :

I figured I'd throw an idea out there, now that immutable data is starting to gain mainstream attention with JS and cowpaths are being paved. I've recently been playing around with the idea of introducing immutable collections as value types (as opposed to, say, instances of something).

So at the core there would be three new value types added:

  • ImmutableMap.
  • ImmutableArray.
  • ImmutableSet.

Why would both Array and Set be needed?

Because sometimes you want lists of unique values (e.g. the list of doors opened) and sometimes you want to have duplicates (e.g. the durabilities of all doors).

We could also introduce nice syntactic sugar, such as:

var objectKey = {};

var map = {: [objectKey]: "foo", "bar": "baz", }; // ImmutableMap [ [objectKey, "foo"], ["bar", "baz"] ]

var array = [: 1, 1, 2, 3, ]; // ImmutableArray [ 1, 2, 3, 4 ]

var set = <: 1, 2, 3,

; // ImmutableSet [ 1, 2, 3 ]

The syntax suggestions are up to debate of course, but I think the key takeaway from this proposal should be that the immutable collection types would be values and have an empty prototype chain.

I find ":" too discrete for readability purposes. What about # ? That's what was proposed for records and tuples (which are pretty much the same thing as ImmutableMap and ImmutableSet respectively) strawman:records, strawman:tuples #SyntaxBikeshed

Like I said, I don't have a strong preference on the syntax. I chose : instead of # purely because # is often suggested for many other things. Also : makes happy beginnings and sad endings. :]

I think this would make a worthwhile addition to the language, especially

considering functional compile-to-JS languages. With the syntactic sugar, it would probably even render a lot of their features irrelevant because the core of JS could provide a viable platform for functional programming (of course one might still be happier using abstraction layers that provide immutable APIs to the underlying platforms, such as DOM, but then that's not a problem in the JS' domain anymore).

It would also open the possibility of a new class of postMessage sharing (across iframes or WebWorkers) that allows parallel reading of a complex data structure without copying.

A use case that would benefit a lot from this would be computation of a force-layout algorithm with real-time rendering of the graph.

Good points, agreed!