-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What about sets? #377
Comments
Agreed. Sets are essential and can have better performance characteristics for many operations and contexts that we lean too heavily on Arrays/Tuples for, aside from their obvious utilities as mathematical sets. Coming from Clojure(Script), I find them to be something I desire to be ready at hand. |
Should sets be ordered or unordered? Does |
@errorx666 JS Sets are ordered. |
Order is one of the key issues that make Sets harder to add as primitives compared to records and tuples. Tuple entries are ordered by their index (numbers), and Record entires are ordered by their key (strings). But there isn't a global ordering of all primitives values in the language so they would most likely be sorted by insertion order like the existing |
In part, adding the |
const queue = #[ 'encodeURIComponent', 'encodeURIComponent', 'base64' ];
for ( const task of queue ) { input = process(input, task); }
queue===#[ 'encodeURIComponent', 'base64' ]; // false
const valueSet = #[ 123, 123, 456 ];
valueSet.includes(123); // includes (or any api same to this) will be internal optimized for performance.
valueSet==#[ 456, 123 ]; // true
const options = #{ limitedKey1: 'freeValue', limitedKey2: 'freeValue' };
options.limitedKey1;
const simpleSet = #{ limitedKey1, limitedKey2 };
simpleSet.limitedKey1; // default to true
simpleSet==#{ limitedKey2, limitedKey1 }; // true
const conditionTree = #{ import: 'path', require: 'path' };// node package.json condition exports rule use case
conditionTree===#{ require: 'path', import: 'path' };// false I think there are different use cases for queue/set, valueSet/simpleSet, options/conditionTree. Different use case shouldn't be differentiated while created, but should in using (because they are static, and any optimizing in engine side is acceptable). |
As a follow on proposal, it might be interesting if sets also had their own literal syntax. const s = new Set([1,2,1,3,2]); //1,2,3 Why not? const s = ![1,2,1,3,2]; So that it has neat parity with its immutable counterpart: const s = #![1,2,1,3,2]; The idea is if you're of a mind to begin with an array, then consider the uniqueness constraint momentarily later, you just insert the bang. |
const x = Symbol();
const y = Symbol();
const a = #![x, y];
const b = #![y, x]; Are
Also |
If I only offered an example. The desire is for some literal syntax for sets, whatever that may be. |
Sets and Maps in JS are effectively ordered, by insertion order. |
But how should the immutable counterparts compare and decide on equality? |
I'm not sure where you're trying to get. Unless you cannot iterate over entries, there has to be an order for collections. As @acutmore said, there is no global ordering of primitive values, so there can't be a different order than insertion order, or a user provided ordering predicate. The question of equality is somewhat orthogonal. Order does not strictly have to be considered part of the equality for immutable sets. We could imagine that immutable set would be equal iff every item of the set exists in the other set. That would result in sets that are observably different, yet "equal". There is a precedent in the case of |
I am just reflecting today's earlier comment about equality. const result = #![x, y] === #![y, x]; //true? It's true if sets have no ordering semantic. If they do, e.g. OrderedSet, this would not be true. |
any iterable collection must have ordering semantics, or their iteration would be non deterministic, which the language has been avoiding. Can you clarify why you think the iteration order of an immutable set must affect its equality?
Given the potential new direction of this proposal, the former might not be as surprising (the equality predicate would no longer be Btw, I am avoiding mixing any syntax concerns of how these immutable sets are created, as it's not relevant to the equality question. |
JavaScript has objects, arrays, dates, and sets. In regard to immutables, with the advent of records and tuples, objects now map to records, arrays to tuples, dates to temporals (soon enough), but sets have no counterpart.
Any designs on implementing immutable sets as a follow-on proposal? When creating structured data to represent app state sets are handy and map to many real world (domain sensible) scenarios.
Having them as loosely built from tuples but with uniqueness enforcement would make dealing with such scenarios much friendlier (e.g. not having to regularly check a tuple before adding a value).
The text was updated successfully, but these errors were encountered: