I was actually talking about the syntax itself. I'd be fine with less
verbose, extensible Map semantics.
On Sun, Nov 29, 2015, 12:14 Alexander Jones <a...@weej.com> wrote:
> I think you're overlooking the parse-time shape checking, Isiah, which in
> the new world order of type inference and checking seems like a necessity
> to me.
>
> While I fully appreciate that Tab's solution involves the least number of
> specification additions, I still would rather write this without the extra
> pair of parens and the `new` which was omitted, just to cut down on the
> noise and really reduce the number of reasons people have to use `Object`
> instead of a more suitable type. Consider embedding lists as keys in a map
> which compares keys by value:
>
> ```
> let m = new Dict(#(1: "one", new List(#(1, 2)): "array of 1 and 2", null:
> "the null value"));
> ```
>
> I think this just starts to look quite gnarly, and the fewer occurrences
> of `new` I see in declarative code the better.
>
> Re-consider my offered alternative, (putting `#{}` and `#[]` back on the
> table to visually distinguish abstract list and abstract mapping):
>
> ```
> let m = Dict#{1: "one", List#[1, 2]: "array of 1 and 2", null: "the null
> value"};
>
> let platonics = Set#["tetrahedron", "cube", "octahedron", "dodecahedron",
> "icosahedron"];
> ```
>
> I think it would also make sense to allow `...` to include the results of
> iteration over some other iterable.
>
> ```
> let nums = [2, 3, 4];
> let setOfNums = Set#[1, 2, 3, ...nums, ...range(20, 50)];
> ```
>
> Cheers
>
>
> On Sunday, 29 November 2015, Isiah Meadows <isiahmead...@gmail.com> wrote:
>
>> With that syntax, I'm not even sure it's necessary. It's not much more
>> concise than a list of 2-tuples. Don't quite see the benefit the other than
>> a few characters.
>>
>> On Sat, Nov 28, 2015, 22:22 Tab Atkins Jr. <jackalm...@gmail.com> wrote:
>>
>>> On Thu, Oct 29, 2015 at 6:23 PM, Alexander Jones <a...@weej.com> wrote:
>>> > I don't think borrowing object notation is a good idea. What exactly
>>> does
>>> >
>>> > ```
>>> > const myMap = Map#{
>>> > get foo() { return 100; },
>>> > set foo(v) {}
>>> > constructor() {}
>>> > };
>>> > ```
>>> >
>>> > mean?
>>> >
>>> > Honestly, a very significant portion of the use cases I have for
>>> *actual
>>> > maps* don't involve string keys. So to borrow object notation and have
>>> to
>>> > constantly write keys in [] is pretty naff:
>>> >
>>> > ```
>>> > const describe = Dict#{
>>> > [1]: "one",
>>> > [[1, 2]]: "array of 1 and 2",
>>> > [null]: "the null value",
>>> > }; // please no!
>>> > ```
>>> >
>>> > If it makes people feel too weird to have comma separated, colon split
>>> > key-value pairs within curlies that *don't* parse like POJSOs, we
>>> could have
>>> > completely non-ambiguous parse with normal parentheses, I think?
>>> >
>>> > ```
>>> > const describe = Dict#(
>>> > 1: "one",
>>> > [1, 2]: "array of 1 and 2",
>>> > null: "the null value",
>>> > );
>>> > ```
>>> >
>>> > That might limit confusion while giving a syntactically clean way to
>>> define
>>> > maps. Let's consider that a future mapping type like Dict compares
>>> > non-primitive keys by abstract value instead of by reference identity.
>>> There
>>> > are *tonnes* of nice use cases that open up that are taken for granted
>>> in
>>> > other languages and other classes like Immutable.Map - we're not there
>>> yet
>>> > with ES6 built-ins, so perhaps people might not yet appreciate the
>>> value of
>>> > this.
>>> >
>>> > To reiterate a previous point, object property access with a statically
>>> > defined string key is idiomatically written `obj.foo`, so it makes
>>> sense for
>>> > symmetry to have `foo` appear as a bareword in a literal defining `obj
>>> =
>>> > {foo: 42}`. For most mapping-type classes this symmetry simply does not
>>> > apply, and frankly neither should it.
>>> >
>>> > Also, I specifically suggested that the consumed value is an
>>> ArrayIterator
>>> > rather than an Array, because I feel having an intermediate Array
>>> around is
>>> > placing too high an importance on the humble Array. If the
>>> implementation
>>> > really wants an Array to work on internally, they can simply call
>>> > `Array.from` with little cost. But if they want an Immutable.List they
>>> can
>>> > have that instead without ever seeing an actual Array. (The
>>> Symbol.fromHash
>>> > method is just Symbol.literalOf as I called it - same thing, modulo
>>> > bikeshed.)
>>>
>>> I strongly agree with a lot of the points here, and think they suggest
>>> the OP's suggestion was generalized in slightly the wrong way.
>>> Producing a Map literal is indeed too specific to justify syntax, but
>>> what's suggested is not a special way of calling some constructors,
>>> but *a literal syntax for 2-value iterators*.
>>>
>>> We have a literal syntax for 1-value iterators: just use an Array.
>>> It's lightweight (2 chars + 1 char per item), and typos in the syntax
>>> are caught at compile time. Our existing literal syntax for 2-value
>>> iterators (an array of length-2 arrays) fails at both of these: it's
>>> heavyweight (4 chars + 4 chars per item), and typos in the syntax are
>>> only caught at runtime, when it's actually iterated over.
>>>
>>> Having a lightweight, compile-time-checked 2-value iterator literal
>>> that desugars to an N×2 Array (or ArrayIterator) fixes all these
>>> problems, and makes it easy to write Map literals, Immutable.Dict
>>> literals, or anything else. Using the hash-paren syntax suggested
>>> above:
>>>
>>> ```
>>> let m = Map(#(1: "one", [1, 2]: "array of 1 and 2", null: "the null
>>> value"));
>>> ```
>>>
>>> There's no need to invent a new function-calling syntax or add a new
>>> well-known symbol to anything. It Just Works™ as long as the function
>>> you pass it to expects a 2-value iterator.
>>>
>>> (From other languages, there doesn't appear to be any call for N×3
>>> literals or anything higher
>>>
>>> ~TJ
>>>
>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
