Immutable collection values
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).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Immutable collection values
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)
http://wiki.ecmascript.org/doku.php?id=strawman:records
http://wiki.ecmascript.org/doku.php?id=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.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Immutable collection values
On Sun, Nov 9, 2014 at 5:39 PM, David Bruant bruan...@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)
http://wiki.ecmascript.org/doku.php?id=strawman:records
http://wiki.ecmascript.org/doku.php?id=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!
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
