Immutable collection values

[Jussi Kalliokoski]

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)
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141109/d10e2cde/attachment.html>