Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

[Viktor Kronvall]

The “let bindings in expression” originates in mathematics and logic.

I cannot speak for the original proposal but the major difference between
this syntax is that it evaluates to an expression compared to the let
statement which evaluates to undefined.

One benefit of “let in” is that it is easier to compose with other
syntactic constructs which expect an expression.

The semantics of the “let bindings in expression” is to evaluate the
expression after “in” with variables substituted by the definitions in the
bindings. Essentially, the syntax allows you to create a modified scope for
that one expression.

However, I find nested let expressions difficult to parse in my head and
would personally not suggest this syntax to be added to the language. I use
Haskell as my main programming language and there using the “where” syntax
often leads to easier to read code than using “let … in”.
2018年8月24日(金) 17:41 Darien Valentine :

> Herby, for those like myself who aren’t familiar with “classical let-in,”
> could you explain more about the objective? It’s not clear to me from the
> brief example what advantages this would provide.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function composition vs pipeline

[Viktor Kronvall]

I don’t know the implications but I could easily imagine the pipeline
proposal being extended to not taking any input on the left hand side and
effectively represent composition in the opposite direction.

For example:
```
let h = |> f |> g
h(2) //g(f(2))
```

That said, the point holds for the proposal in its current state. Being
able to compose functions
leads to much more expressivity than if you have
to call the pipeline (and collapse) where it is defined.
2018年2月24日(土) 14:32 Naveen Chawla :

> The function composition operator composes function pipelines into
> functions for later use and/or further composition. Those functions still
> need to be called via the existing `()` syntax, so it doesn't offer a
> different way of calling functions as such.
>
> The function pipeline operator calls the function pipeline immediately, so
> it is really only a different way of calling functions.
>
> On Fri, 23 Feb 2018 at 12:37 Jordan Harband  wrote:
>
>> How is either operator not "a different way of calling functions"?
>>
>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
>> wrote:
>>
>>> I was just thinking about the relative merits and coexistence (or not)
>>> of function composition operator and function pipeline operator features:
>>>
>>> e.g.
>>>
>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
>>> https://github.com/tc39/proposal-pipeline-operator
>>>
>>> They can of course co-exist, but there is overlap only in the respect
>>> that both allow function pipelines to be called from left to right (except
>>> the input parameter in the case of the composition feature, which requires
>>> existing bracket syntax to be used to call it). If one were to be chosen,
>>> would say that a function composition operator adds a whole new dimension
>>> of expressive power to the language, whereas a pipeline operator only
>>> offers a different way of calling functions.
>>>
>>> I was wondering about all of your thoughts about whether you'd prefer
>>> only the pipeline operator, only the composition operator, or both, or
>>> neither to be added to the language (these are pretty much all the
>>> possibilities), and why.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise finally

[Viktor Kronvall]

Since these two Promises aren't chained to one another I wouldn't expect
any specific
deterministic ordering between the `console.log` statements. Are you
suggesting that
such a deterministic ordering should be imposed by using micro tasks or
what are you
proposing here exactly?

In other words, why exactly do you expect the result to always be printing
1 before
printing 2?

2018年2月23日(金) 19:21 Raul-Sebastian Mihăilă :

> I find it weird that
>
> ```js
> Promise.resolve().finally(() => {}).then(() => { console.log(1); });
> Promise.resolve().then(() => {}).then(() => { console.log(2); });
> ```
>
> prints 2 and then 1. It would have been possible to spec it in such a way
> that it would have printed 1 and 2.
>
> On the other hand
>
> ```js
> Promise.resolve().finally().then(() => { console.log(1); });
> Promise.resolve().then().then(() => { console.log(2); });
> ```
>
> prints 1 and then 2.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: an operator for ignoring any exceptions

[Viktor Kronvall]

I think this proposal has the risk of swallowing too many errors making
code hard to debug and would therefore suggest this shouldn’t be added to
the language. Silent errors are hard to find the origin and cause for
especially if you throw away the error message.

This might be slightly off topic but, I think we should instead wait for
proper pattern matching and include a Result type similar to Scala Option
or Haskell Either that is falsy in the Left error case (containing the
error message) and truthy otherwise.
2017年8月11日(金) 10:17 Hikaru Nakashima :

> I think this idea is useful in async function.
>
> For exsample, we write codes as below, when we use fetch()  in async
> function.
>
> ```js
>
> let res, text
>
> try {
> res = await fetch( url )
> } catch ( err ) { console.log( 'network error' ) }
>
> if ( ! res.ok ) console.log( 'server error' )
> else text = await res.text( )
>
>
> ```
>
> or
>
> ```js
>
> let res, text
>
> res = await fetch( url ).catch( err => null )
> if ( ! res ) console.log( 'network error' )
>
> else if ( ! res.ok ) console.log( 'server error' )
> else text = await res.text( )
>
>
> ```
>
> but, we can write as below  if we use this proposal.
>
> ```js
>
> let res, text
>
> res = try await fetch( url )
> if ( ! res ) console.log( 'network error' )
>
> else if ( ! res.ok ) console.log( 'server error' )
> else text = await res.text( )
>
> ```
>
> or do we need another syntax like "await?" ?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stage 0 Proposal: Extensible Collection Literal

[Viktor Kronvall]

One of the stated advantages of the proposal is that because it is syntax
driven it allows for static error messages limiting some bugs.

Using a method would not give the same degree of certainty of correctness
as that would require assertions to be deferred to runtime, since
EcmaScript is not statically typed.

I think there could be other alternatives for the operator but I agree with
the original proposal that it is good to use syntax for this use case.

2017年7月30日(日) 9:06 Naveen Chawla :

> I don't like the # symbol there.
>
> I would prefer something like Map.fromObject({ 'myKey': {}, myKey2: [] });
> etc.
>
> On Sun, 30 Jul 2017 at 02:51 Alexander Jones  wrote:
>
>> As a follow-up to https://esdiscuss.org/topic/map-literal I've finally
>> (2 years? Really?) written up a proposal for extensible collection
>> "literal" syntax (for Map, Set, Immutable.List, etc.)
>>
>> https://github.com/alex-weej/es-extensible-collection-literal
>>
>> Thanks
>>
>> Alex
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

Even more interestingly what would `String.range("","zzz")` produce. From
what code point is the range started? Will this throw? Is the empty string
included in the iterator?
2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:

> Actually, after giving it some more thought for that case there is just
> that one possibility that makes sense.
>
> However, there are more ambiguous cases such as `String.range("AAA",
> "ZZZ")` (should all letters increase at once or should the rightmost letter
> be incremented first)
>
> Also, how would range handle the arguments in inverted order? Should there
> be a decreasing range or should it terminate with no elements in the
> iterator?
> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>
> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > es-discuss mailing list
> > > > > es-discuss@mozilla.org
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > >
> > > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

Actually, after giving it some more thought for that case there is just
that one possibility that makes sense.

However, there are more ambiguous cases such as `String.range("AAA",
"ZZZ")` (should all letters increase at once or should the rightmost letter
be incremented first)

Also, how would range handle the arguments in inverted order? Should there
be a decreasing range or should it terminate with no elements in the
iterator?
2016年11月3日(木) 21:05 kdex <k...@kdex.de>:

> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > es-discuss mailing list
> > > > > es-discuss@mozilla.org
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > >
> > > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

For `String.range` what would the expected result of
`String.range('A','zzz')` be?

Is an exhaustive pattern expected?

`['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
2016年11月3日(木) 19:21 Michael J. Ryan :

> If there's a Number.range, if suggest a corresponding String.range for
> character ranges...  Agreed on it being a utility function over me syntax.
>
> On Nov 3, 2016 10:25 AM, "Isiah Meadows"  wrote:
>
> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex  wrote:
>
> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> return a generator
> or at least something that extends a generator, though. I wonder if it's
> viable to implement
> something akin to `.length` on ranges, which could be natural numbers or
> `Infinity`.
>
> As for numbers, I don't see any issues. One issue that came up in the
> original thread was
> that string ranges may need a better definition, as ["A".."C"] might not
> necessarily transpile
> to be a generator that yields "A", "B" and "C".
>
> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > removed.
> >
> > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > also possible, and so it doesn't have to be eager.
> >
> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima 
> > wrote:
> >
> > > How about this
> > >
> > > ```
> > > for ( i of Array.range(1, 10) ) { ... }
> > > // OR
> > > for ( i of [1..10] )  { ... }
> > > ```
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: anaphoric if and while syntax

[Viktor Kronvall]

Does this really need new semantic interpretation of the syntax? Using the
`Array.prototype` methods `.forEach` and `.map` already mitigates this
problem as far as I can tell by having a different bound variable (argument
in this case) for each call.

I agree that the behavior may be non-intuitive if you have a background
coming from Java or C++ but the implications would be quite far-reaching
and the backward compatibility with previous versions would be difficult to
handle. Wouldn't this require a new 'use strict'-like mode?
2016年9月14日(水) 7:51 Dan Peddle :

> An alternative to the block which you ended up with is to extract that
> logic to a function, which provides something which can be tested too.
> Possibly overkill for oneliners like this though.
>
> However, writing a lot of code like this myself (get a value, if it's
> truthy do something, else do other), that's a nice idea for an extension
> that doesn't add extra variable bindings to the containing scope.
>
> On Tue, Sep 13, 2016 at 2:32 AM, Danielle McLean 
> wrote:
>
>> In current ECMAScript, it is legal to place a variable declaration inside
>> the
>> initialiser of a `for` loop, as well as to declare the variable used by a
>> `for...in` or `for...of` loop within the declaring expression:
>>
>> for (let i = 0; i < 5; ++i) console.log(i);
>> for (let item of collection) process(item);
>>
>> When this syntax is used with `let` or `const`, the resulting variable is
>> scoped to the loop and is not visible to the rest of the surrounding
>> block.
>>
>> I propose that this syntax be extended, making it legal to place a
>> variable
>> declaration within the condition of an `if` or `while` statement. Any
>> truthy
>> value will cause the `if` block to run or `while` loop to repeat, as
>> usual -
>> the advantage is that the particular truthy value is bound to a variable
>> and
>> can be used inside the conditional block. For example, here is the
>> situation
>> that prompted my writing this proposal:
>>
>> if (const oldValue = _.get(object, 'some.long.path')) {
>>   object.some.long.path = transform(oldValue);
>> }
>>
>> As with the existing behaviour of declarations inside `for`, variables
>> declared
>> using `let` or `const` would be scoped to the individual `if` or `while`
>> statement, rather than the containing block. In other words, the above
>> syntax
>> would be equivalent to the following currently-valid form I ended up
>> writing:
>>
>> {
>>   const oldValue = _.get(object, 'some.long.path');
>>   if (oldValue) object.some.long.path = transform(oldValue);
>> }
>>
>> Another use case which C aficianados might recognise:
>>
>> while (const c = getchar()) {
>> process(c);
>> }
>>
>> This syntax is already legal in C++, although not in C - in general this
>> support is known as "anaphoric if", as it allows the body of the
>> statement to
>> refer back to the condition value. It's especially helpful in languages
>> with
>> truthiness, which ECMAScript has, as it allows access to the *specific*
>> truthy
>> value without further finagling.
>>
>> Thoughts?
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>
> Dan Peddle
> *tel*: +49 157 3918 2066
> *email*: d...@flarework.com
> *www*: http://flarework.com
> *in*: http://pt.linkedin.com/in/danpeddle
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map literal

[Viktor Kronvall]

Hello Alexander,

I see now that I misread your desugaring.

I read:

```
Map#{1: 6, bar: 'Hello', 2: 8};
```
as being desugared to:

```
Map[Symbol.literalOf]({1: 6, bar: 'Hello', 2: 8}[Symbol.iterator]());
```

But your proposal clearly states that is should be:

```
Map[Symbol.literalOf]([[1, 6], ['bar', 'Hello'], [2,8]][Symbol.iterator]());
```

Which would preserve lexical ordering of entries. The fault is completely
mine. Sorry.

I like this proposal as it is extensible and not that noisy in syntax.
Using the `#` for this doesn't
seem like a bad idea either. People coming from Erlang will be familiar
with this as well.


2015-10-28 10:53 GMT+01:00 Alexander Jones <a...@weej.com>:

> Hi Victor
>
> Not sure I understand - the desugaring I wrote would absolutely preserve
> the written ordering because it speaks in terms of an ArrayIterator of
> key-value pairs. If the map type to which it's applied chooses to forget
> the ordering then that's fine.
>
> Alex
>
>
> On Wednesday, 28 October 2015, Viktor Kronvall <viktor.kronv...@gmail.com>
> wrote:
>
>> > ```
>> > const map = IMap#{"foo": 42, bar: 44};
>> > ```
>> > It could desugar as, for the sake of example:
>> >
>> > ```
>> > Foo#{key: value, ...}
>> > ➔
>> > Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())
>> > ```
>>
>> I like this proposal. However, Maps should guarantee insertion order when
>> traversing the keys and values and desugaring it like that does not respect
>> this guarantee or more precisely it will lead to (in my opinion) unexpected
>> order of the keys.
>>
>> ```
>> Object.keys({1: 6, bar: 'Hello', 2: 8}); // → [ '1', '2', 'bar' ]
>> ```
>>
>> If I'm not mistaken this will be same order for `{1: 6, bar: 'Hello', 2:
>> 8}[Symbol.iterator]()`.
>>
>> This implies that:
>>
>> ```
>> Map#{1: 6, bar: 'Hello', 2: 8};
>> ```
>>
>> Will not have entries in the order `[[1, 6], ['bar', 'Hello'], [2,8]]`
>> but instead `[[1,6], [2,8], ['bar','Hello']]`.
>>
>> This means that possible future destructuring of a Map will be harder to
>> reason about.
>>
>>
>> 2015-10-28 2:21 GMT+01:00 Alexander Jones <a...@weej.com>:
>>
>>> True, but easy to mess up and only be treated to a runtime error. Three
>>> nested brackets at the start and end could definitely be better, and
>>> this just encourages people to use POJSOs instead. Also not a very uniform
>>> interface if you look at how to construct a Map, Set or Immutable.List at
>>> present, though admittedly constructor call for the ES6 types would be a
>>> partial improvement.
>>>
>>> On Wednesday, 28 October 2015, Tab Atkins Jr. <jackalm...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones <a...@weej.com> wrote:
>>>> > I agree this is pretty important. Using actual maps really frees up a
>>>> lot of
>>>> > complexity, but the syntax is cumbersome to say the least.
>>>> >
>>>> > Whatever the decided syntax, bare words as string keys is a really
>>>> bad idea
>>>> > IMO. The key syntax should be parsed as an expression, like the
>>>> values are,
>>>> > and like they are in basically every other language.
>>>> >
>>>> > Another outstanding issue is that we might want the syntax for
>>>> > `Immutable.Map`, or `WeakMap`, or `MapTwoPointOh` that improves
>>>> deficiency
>>>> > $x, $y and $z. I'd say introducing a special syntax for `Map` right
>>>> now is
>>>> > not ideal.
>>>>
>>>> Currently, the "extensible literal syntax" for this isn't that bad:
>>>>
>>>> const bar = 43;
>>>> const map = Immutable.Map([["foo", 42], [bar, 44]]);
>>>>
>>>> It's a little more verbose because the entries have to be surrounded
>>>> by [], but hey.
>>>>
>>>> ~TJ
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map literal

[Viktor Kronvall]

> ```
> const map = IMap#{"foo": 42, bar: 44};
> ```
> It could desugar as, for the sake of example:
>
> ```
> Foo#{key: value, ...}
> ➔
> Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())
> ```

I like this proposal. However, Maps should guarantee insertion order when
traversing the keys and values and desugaring it like that does not respect
this guarantee or more precisely it will lead to (in my opinion) unexpected
order of the keys.

```
Object.keys({1: 6, bar: 'Hello', 2: 8}); // → [ '1', '2', 'bar' ]
```

If I'm not mistaken this will be same order for `{1: 6, bar: 'Hello', 2:
8}[Symbol.iterator]()`.

This implies that:

```
Map#{1: 6, bar: 'Hello', 2: 8};
```

Will not have entries in the order `[[1, 6], ['bar', 'Hello'], [2,8]]` but
instead `[[1,6], [2,8], ['bar','Hello']]`.

This means that possible future destructuring of a Map will be harder to
reason about.


2015-10-28 2:21 GMT+01:00 Alexander Jones :

> True, but easy to mess up and only be treated to a runtime error. Three
> nested brackets at the start and end could definitely be better, and
> this just encourages people to use POJSOs instead. Also not a very uniform
> interface if you look at how to construct a Map, Set or Immutable.List at
> present, though admittedly constructor call for the ES6 types would be a
> partial improvement.
>
> On Wednesday, 28 October 2015, Tab Atkins Jr. 
> wrote:
>
>> On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones  wrote:
>> > I agree this is pretty important. Using actual maps really frees up a
>> lot of
>> > complexity, but the syntax is cumbersome to say the least.
>> >
>> > Whatever the decided syntax, bare words as string keys is a really bad
>> idea
>> > IMO. The key syntax should be parsed as an expression, like the values
>> are,
>> > and like they are in basically every other language.
>> >
>> > Another outstanding issue is that we might want the syntax for
>> > `Immutable.Map`, or `WeakMap`, or `MapTwoPointOh` that improves
>> deficiency
>> > $x, $y and $z. I'd say introducing a special syntax for `Map` right now
>> is
>> > not ideal.
>>
>> Currently, the "extensible literal syntax" for this isn't that bad:
>>
>> const bar = 43;
>> const map = Immutable.Map([["foo", 42], [bar, 44]]);
>>
>> It's a little more verbose because the entries have to be surrounded
>> by [], but hey.
>>
>> ~TJ
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Viktor Kronvall]

> but I'd vote for `Math.greaterThan`

I agree with this. This solution also disambiguates negate and minus which
is good. If we were to introduce operators as functions with syntax I would
prefer if there was some syntax to know if the operator was a binary or
unary function.

Regarding operators how does this proposal interact with the proposal for
value types and operator overloading?

2015-10-15 23:08 GMT+02:00 Michael McGlothlin :

> It'd be simple to just define all operators as function​s and the actual
> operator is just syntaxial sugar. And then if you wanted to pass the
> operator you'd simply pass it's function around like you would any other
> function. Even your `Math.['>']` seems far safer than `Math.>` or just `>`
> but I'd vote for `Math.greaterThan` as being the best name. Saving a couple
> letters of typing isn't worth the price of hours more debugging.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss