Re: Function composition vs pipeline

[Alexander Jones]

Straw man. The problem is variables named h, f and g, not the use of a
composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu  wrote:

> @peter, put yourself in the shoes of a senior-programmer responsible
> for overseeing an entire web-project.  the project is @ the
> integration-stage and you're busy debugging an async
> timeout/near-timeout bug preventing the frontend from talking to the
> backend (which btw, is one of the most common integration/qa
> javascript-bugs).
>
> while trying to figure out what's causing the timeout-issue, you're
> debugging i/o code with operators that look like this:
>
> ```
> const h = ? |> f |> g;
> ```
>
> maybe it is useful for the small-picture sub-problem you were
> originally trying to solve. but now that you're a bigger-fish with
> bigger-picture integration i/o issues, doesn't this look alot like
> technical-debt that no one will have a clue how to debug once a month
> or two has passed?
>
> -kai
>
> On 3/11/18, Peter Jaszkowiak  wrote:
> > Oh please,
> >
> > This is an alternative syntax that's very useful for many people. If you
> > want too simplify syntax yourself you can use a linter to disable
> > alternatives.
> >
> > On Mar 10, 2018 22:56, "kai zhu"  wrote:
> >
> >> my vote is for neither.  exactly what industry painpoint or
> >> problem-space do either of these proposals solve?
> >>
> >> rather, they compound an existing industry painpoint; where
> >> ocd-programmers have problems in deciding-and-choosing which es6
> >> style/design-pattern to employ and stick with before coding even
> >> begins. many of us wish there were less choices, like python (and a
> >> more assertive tc39 that makes clear certain proposals are
> >> productivity-negative and not open for debate) so we could get on with
> >> the actual coding-part.
> >>
> >> from a senior-engineer / technical-manager perspective, it also
> >> doesn't help in managing an entire web-project; comprised of dozens of
> >> sub-components that you didn't all write yourself; and having to
> >> context-switch for each sub-component's quirky es6/es7/es8/es9
> >> style-guide/design-pattern.
> >>
> >> On 3/4/18, Isiah Meadows  wrote:
> >> > Just thought I'd point out that the proposal itself entertains the
> >> > possibility of a corresponding composition proposal [1]. Also, in my
> >> > proposal, one of my "potential expansions" [2] would open a generic
> >> > door for "lifting" over a type, addressing the concern of
> >> > extensibility. (It's not ideal, and I just filed an issue in my repo
> >> > for that, but that's orthogonal.)
> >> >
> >> > [1]: https://github.com/tc39/proposal-pipeline-operator#
> >> related-proposals
> >> > [2]:
> >> >
> https://github.com/isiahmeadows/function-composition-proposal#possible-
> >> expansions
> >> >
> >> > -
> >> >
> >> > Isiah Meadows
> >> > m...@isiahmeadows.com
> >> >
> >> > Looking for web consulting? Or a new website?
> >> > Send me an email and we can get started.
> >> > www.isiahmeadows.com
> >> >
> >> >
> >> > On Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla  >
> >> > wrote:
> >> >> Although it doesn't allow composition with generator functions like
> >> >> the
> >> >> composition proposal does, otherwise it's a pretty good solution.
> >> >>
> >> >> My only concern with pipeline is that since it offers a different way
> >> >> of
> >> >> calling functions than the `()` syntax, it can lead to mixed and
> hence
> >> >> slightly more confusing code when both `()` and `|>` are used. For
> >> example
> >> >> multi arg and no-arg functions would still use `()`, and single arg
> >> >> functions may or may not use `|>` depending on whether or not they
> may
> >> >> prospectively use a pipeline. The composition operator doesn't
> >> >> supersede
> >> >> the
> >> >> `()` syntax in any context, and so it could be argued it would lead
> to
> >> >> more
> >> >> consistent, more readable code.
> >> >>
> >> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak 
> >> wrote:
> >> >>>
> >> >>> I'd like to point out the partial application operator:
> >> >>> https://github.com/tc39/proposal-partial-application
> >> >>>
> >> >>> Sounds like the combination of pipeline + partial application would
> >> >>> result
> >> >>> in what is essentially the same as function composition operator:
> >> >>>
> >> >>> ```
> >> >>> const h = ? |> f |> g;
> >> >>> ```
> >> >>>
> >> >>> Which results in `h` being the composition `g • f`.
> >> >>>
> >> >>>
> >> >>> On Feb 24, 2018 02:21, "Naveen Chawla" 
> wrote:
> >> >>>
> >> >>> That could be a problem for readability.
> >> >>> I agree with the rest of what you said.
> >> >>>
> >> >>>
> >> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
> >> viktor.kronv...@gmail.com>
> >> >>> wrote:
> >> 
> >>  I don’t know the implications but I could easily imagine the
> >>  pipeline
> >>  

Re: Suggestion: Destructuring object initializer.

[Alexander Jones]

The difference between `{...a, ...b}` and `Object.assign({}, a, b)` is the
same as the difference between `[a, b]` and `new Array(a, b)`. The latter
cases (correct me if I'm wrong) rely on dynamic lookup of names and
methods, whereas the former cases, as syntactical constructs, have
statically defined semantics. Not really sure if modern engines are able to
optimize around this yet. I'm sure someone here knows...

On 12 February 2018 at 13:45, Bob Myers  wrote:

> Thanks for reading my post down to the part that caught your attention.
> Concerning this:
>
> > engines can optimize for objects that are not referenced elsewhere by
> not actually copying them, something harder to do with `Object.assign`.\*
>
> I'm intrigued; please elaborate. I had thought that `{...a, ...b}` was
> 100% identical in every way to `Object.assign({}, a, b)`.
>
> > \* I don't know/believe if they do, but it's pretty easy to implement
> with type info.
>
> What kind of type info did you have in mind? Type info based on static
> analysis currently performed and/or theoretically able to be performed by
> engines against ECMAScript 20xx programs? In that case, why couldn't such
> type inferencing be applied to optimizing the `Object.assign`-based
> construct? Or do you mean type info from some kind of type annotation
> system in the future?
>
> Bob
>
> On Sun, Feb 11, 2018 at 5:03 AM, Isiah Meadows 
> wrote:
>
>>
>> Another common reaction is "big deal, saving a few characters or lines".
>>> But more than one recent language feature also falls into this category of
>>> mainly or purely sugar and brevity. For instance, property spread syntax is
>>> pretty much just sugar for `Object.assign`, yet everyone seems to think
>>> it's the best thing since sliced bread.
>>>
>>
>> My understanding of this differs:
>>
>> - It was to bring feature parity with array spread destructuring.
>> - The proposal included both merging and extracting.
>> - It actually optimized for an exceptionally common case (React circles
>> benefitted the most, but others did quite a bit, too), immutable update of
>> record-like objects. In my experience, that scenario is *more* common than
>> array spread (beyond rest parameters), and engines can optimize for objects
>> that are not referenced elsewhere by not actually copying them, something
>> harder to do with `Object.assign`.\*
>> - You *could* implement it via `Object.assign`, but it chopped the number
>> of characters down to less than half for most cases if you're not just
>> merging. Most of these pick proposals aren't coming close.
>>
>> \* I don't know/believe if they do, but it's pretty easy to implement
>> with type info.
>>
>
> ___
> 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: async/await -> await/async: a simpler, less error-prone async syntax

[Alexander Jones]

FTR, TypeScript and Flow (I assume) know when the static type of a function
call (or any other expression that evaluates to a Promise) is a Promise,
and if you try to use it as if it wasn't, it will almost surely be a type
error.

On 12 February 2018 at 10:27, Алексей  wrote:

> I think there is something we could have right now to solve the problem of
> missing `await` without changes to the ES - it should be collored
> differently in IDE or texteditor you are using. Not like an error - because
> it's actually not. But to be obvious that "here" and "here" you have an
> `async` function calls and values are promises
>
> 2017-12-08 6:27 GMT+02:00 Naveen Chawla :
>
>> Um, no the increased rate of productivity is in converting
>>
>> ```js
>> getUserInfoAsync()
>> .then(
>> userInfo=>{
>>  //Do stuff with userInfo
>> }
>> )
>> ```
>>
>> into
>>
>> ```js
>> const userInfo = await getUserInfoAsync();
>> //Do stuff with userInfo
>> ```
>>
>> ...allowing complex async data flows to be expressed much more simply,
>> hence more quickly, more manageably and with less chance of bugs/mistakes.
>> The `autoasync` `background` concept makes this even more so, hence why I
>> would use it throughout instead of `await` `async` if introduced
>>
>>
>> On Thu, 7 Dec 2017 at 21:41 Florian Bösch  wrote:
>>
>>> I fail to see the increased productiveness by converting:
>>>
>>> FunctionExpression => function FunctionSignature Block
>>>
>>>
>>> To:
>>>
>>> FunctionExpression => async function FunctionSignature Block
>>>
>>>
>>> And the equivalent for the grammar for await. Probably:
>>>
>>> UnaryExpression =>
>>>   await RealUnaryExpression
>>>
>>> Or something
>>>
>>>
>>>
>>> On Thu, Dec 7, 2017 at 4:18 PM, Naveen Chawla 
>>> wrote:
>>>
 You've lost me. It's not intended to add logic. It's a replacement for
 callbacks, and makes expressing async data flows simpler & more manageable,
 allowing more complex async data flows to be expressed more quickly and be
 less prone to bugs. The `autoasync` `background` concept makes this even
 more so. Retaining all the functionality, increasing rate of productivity.
 That's the whole point.

 On Thu, 7 Dec 2017 at 20:36 Florian Bösch  wrote:

> On Thu, Dec 7, 2017 at 2:34 PM, Naveen Chawla 
> wrote:
>
>> How has using async await made you type more? Can you give an
>> example? I suspect you're not using it in the way it was intended to be
>>
>
> See example OP pasted. It's nothing but async/await. It doesn't add
> any semantic, syntactic or logic thing to the code. It could be 4
> white-spaces and you'd not loose any meaning.
>
>
>

>>>
>> ___
>> 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: Suggestion: Infix operators/functions

[Alexander Jones]

Time to put infix operators into TypeScript, first, then?

On Sat, 3 Feb 2018 at 04:25, kdex  wrote:

> People in the C++ community have been using overloaded operators since the
> 1980's, and I wouldn't say that different semantics for the same operator
> have
> been a bad idea at all, given that the operator handles completely
> different
> types (that can and should be statically analyzable).
>
> I wouldn't even think that these features are abused in the C++ community:
> Think vector/matrix operations, for instance. Very expressive stuff.
>
> Depending on the application, it could be nicer for Array + Array to become
> Array(Array, Array) rather than Array(...Array, ...Array). Depends on your
> use
> case. As for function composition, it's a matter of preference if A + B is
> supposed to mean (...args) => A(B(...args)) or rather (...args) =>
> B(A(...args)).
>
> My point is, as long as there is a statically analyzable definition for how
> operators are supposed to behave for a given set of input types, there's no
> reason not to give programmers the ability to provide such definitions.
>
> But again, these discussions will be much more relevant if proposals such
> as
> [this one](https://github.com/sirisian/ecmascript-types) are discussed for
> standardization at some point.
>
> On Saturday, February 3, 2018 4:57:34 AM CET Naveen Chawla wrote:
> > I don't like the idea of custom operators only because of readability of
> > code - it can be different for different pieces of code, and so I think
> it
> > is a larger surface area for bugs, so I think it would be a net negative.
> >
> > However, I do like the idea of allowing e.g. `+` to be used intuitively
> and
> > consistently (i.e. with a fixed meaning) between certain data types that
> > are not currently supported, e.g.:
> >
> > Array + Array (array concatenation)
> > Function + Function (function composition)
> >
> > On Fri, 2 Feb 2018 at 22:02 Michael Haufe 
> wrote:
> > > How would operator precedence work? Would we be restricted to
> 2-argument
> > > functions only?
> > >
> > > On Fri, Feb 2, 2018 at 5:55 AM, Thomas Grainger 
> wrote:
> > >> I'm porting this from the TypeScript issue tracker, original from:
> > >> https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953
> > >>
> > >> Since it's very unlikely that the extension methods will ever be
> > >> implemented [in a call-site-rewrite
> > >> manner](
> > >>
> https://github.com/Microsoft/TypeScript/issues/9#issuecomment-74302592),
> > >> please consider adding infix operators to enable writing in functional
> > >> style similarly to what can be done in Haskell:
> > >>
> > >> Monoids
> > >>
> > >> ```js
> > >>
> > >> function '+' (left, right) {
> > >>
> > >>return left.concat(right);
> > >>
> > >> }
> > >>
> > >> [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]
> > >>
> > >> ```
> > >>
> > >> Monads
> > >>
> > >> ```js
> > >>
> > >> function '>>=' (promise, bind) {
> > >>
> > >>return promise.then(bind);
> > >>
> > >> }
> > >> $.get('/get') '>>=' x => $.post('/save', x + 1)
> > >>
> > >> ```
> > >>
> > >> Functors
> > >>
> > >> ```js
> > >>
> > >> function '.' (inner, outer) {
> > >>
> > >>return function(value: a) : c {
> > >>
> > >>   return outer(inner(value))
> > >>
> > >>}
> > >>
> > >> }
> > >>
> > >> function f(x) { }
> > >> function g(y) { }
> > >> (f '.' g)(x); // z
> > >>
> > >> ```
> > >>
> > >>
> > >>
> > >> Thomas Grainger
> > >>
> > >> ___
> > >> 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: Partial Expression proposal

[Alexander Jones]

The real JavaScript 'character wall'.

On 27 December 2017 at 21:30, Sebastian Cholewa <
sebastian.chol...@interia.eu> wrote:

> On PC writing “§” character wouldn’t be convenient, as it’s not on
> keyboard. One would has to copy and paste it. I see this as problematic.
> Writing code should not require any extra acrobatics with set of characters.
>
> To be more constructive, available characters are:
> !@#$%^&*()_+-=[]{};:'",<.>/?
>
> W dniu .12.2017 o 21:56 Tamás Halasi  pisze:
>
>
> Hmm I see. I'll definitely remove the multiple ? marks and keep it one
>> level.
>> And change the # to something else... For example, §.
>> With these changes, is there anything which should be changed?
>>
>> 2017-12-27 21:17 GMT+01:00 Isiah Meadows :
>>
>> My concern: I get the concept, and could see how at the first level
>>> (e.g. `#? + ?`) it could be useful, but I can tell you that this
>>> doesn't look especially obvious, and starts to look almost like the
>>> line noise of some Perl or APL [1]/J [2]/etc.:
>>>
>>> ```
>>> // Example 1:
>>> let foo = #foo(#???:??)
>>>
>>> // Example 2:
>>> let constant = ##??
>>>
>>> // Example 3:
>>> let makeAdder = ##?+??
>>> ```
>>>
>>> And I agree with Mike in that it does remind me of De Bruijn indices.
>>> Those are nice in binary encodings, but they tend to start looking
>>> like line noise after sufficient depth. (An entire esoteric language
>>> has been formed based on this whole thing: Binary Lambda Calculus
>>> [3].)
>>>
>>> Oh, and this will most *certainly* conflict with the stage 3 private
>>> property proposal:
>>>
>>> ```js
>>> let bar = () => console.log("outer")
>>> class Foo {
>>> #bar = () => console.log("inner")
>>>
>>> method() {
>>> // Should this return a thunk or log "inner"?
>>> list.map(##bar(1, 2, ?))
>>> }
>>> }
>>> ```
>>>
>>> [1]: https://en.wikipedia.org/wiki/APL_(programming_language)
>>> [2]: https://en.wikipedia.org/wiki/J_(programming_language)
>>> [3]: http://web.archive.org/web/20161019165606/https://en.
>>> wikipedia.org/wiki/Binary_lambda_calculus
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>>
>>> Looking for web consulting? Or a new website?
>>> Send me an email and we can get started.
>>> www.isiahmeadows.com
>>>
>>>
>>> On Wed, Dec 27, 2017 at 2:55 PM, Tamás Halasi 
>>> wrote:
>>> >> This sentence ends abruptly.  What would this proposal improve?
>>> >
>>> > Oops, I accidentally pressed Send...
>>> > So, it would improve functional programming in general, the examples
>>> are
>>> in
>>> > the README.
>>> >
>>> >> Is this lambdas with De Bruijn indices?
>>> >
>>> > Hmm, I haven't heard of them yet, but by looking at the surface, they
>>> seems
>>> > to be similar.
>>> >
>>> >> You have ?? and ??? for referring to outer layers.  Is there no
>>> ambiguity
>>> >> there?
>>> >
>>> > That's a very good point! I haven't thought of that. I can't think of a
>>> > solution, the lookahead is indeed very bad. I opened an issue. I think
>>> the
>>> > notation (for accessing arguments from outer layers) will have to be
>>> changed
>>> > / removed.
>>> >
>>> > Thanks for the feedback! :)
>>> >
>>> > ___
>>> > 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: Allow any quoted string to be multiline?

[Alexander Jones]

Good point, but generally quoted keys like that are signs that you probably
really need a Map!

Aside, seems like it could be a fairly cheap spec change to allow template
literals for string property keys.

On Mon, 18 Dec 2017 at 11:20, Michael Rosefield <rosyatran...@gmail.com>
wrote:

> There can absolutely be breaking changes from doing that. Take this, for
> example:
>
> const someObj = { 'some.key': 'some value' };
>
> That throws an error if using template literals, as you need to use
> computed property syntax (i.e., enclose the template literal in square
> brackets).
>
> [image: image.png]
>
>
> On Mon, 18 Dec 2017 at 10:09 Alexander Jones <a...@weej.com> wrote:
>
>> I question why 3 forms of quotation exist in modern codebases. Just use
>> template literals. The only reason not to is resistance to change. ESLint
>> will autofix for you.
>>
>> On 18 December 2017 at 09:47, J Decker <d3c...@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <claude.pa...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> > Le 17 déc. 2017 à 22:03, J Decker <d3c...@gmail.com> a écrit :
>>>> >
>>>> > I do see there are work-arounds (similar as using a hammer to put in
>>>> a screw)
>>>> >
>>>> > I don't see a reason for why not allow multiline strings for other
>>>> quote types.  I know... because people want more errors and to have their
>>>> hand held to identify missing close quotes?  much like the desire to add
>>>> types and type checking.
>>>>
>>>> Yes, you gave a valid reason just after having said you didn’t see a
>>>> reason: transforming bugs (missing quote) into early errors, so that it is
>>>> easier to debug...
>>>>
>>>> The obvious workaround, i.e. using a template literal without
>>>> placeholder, doesn’t seems too heavy-weight; on the contrary, it is
>>>> probably the lightest one can imagine.
>>>>
>>>>
>>> It's not actually :) lightest I can imagine is to allow single and
>>> double quoted strings to be multiline also.
>>> I was considering this because of an issue on my extended json parser.
>>> during development it simplified the code making a single path for
>>> gathering a string that only had to check for closing quote or backslash.
>>> having to test for 4 more characters was then 3x the work... so I just cut
>>> out the extra work, since it break anything.  The only thing left was ...
>>> that it didn't break anything if a newline was found.
>>>
>>> So I figured I'd mention the possibility here and see how much push back
>>> I got.  I don't actually think that 'protection from bad coding' is a very
>>> strong argument.  there's lots of single character omissions or insertions
>>> that can cause ghosted errors that aren't nearly so obvious.  Especially
>>> since syntax highlighting would show a overflowing string very quickly
>>> (more than missing a + in += or having a +  on an = that you didn't mean
>>> for instance).  It would be a change that would take some time to propagate
>>> to a lot of tools; but is a change that's entirely backward compatible and
>>> breaks nothing from the past.
>>>
>>>
>>>
>>>
>>>> —Claude
>>>
>>>
>>>
>>> ___
>>> 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: Allow any quoted string to be multiline?

[Alexander Jones]

I question why 3 forms of quotation exist in modern codebases. Just use
template literals. The only reason not to is resistance to change. ESLint
will autofix for you.

On 18 December 2017 at 09:47, J Decker  wrote:

>
>
> On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache 
> wrote:
>
>>
>>
>> > Le 17 déc. 2017 à 22:03, J Decker  a écrit :
>> >
>> > I do see there are work-arounds (similar as using a hammer to put in a
>> screw)
>> >
>> > I don't see a reason for why not allow multiline strings for other
>> quote types.  I know... because people want more errors and to have their
>> hand held to identify missing close quotes?  much like the desire to add
>> types and type checking.
>>
>> Yes, you gave a valid reason just after having said you didn’t see a
>> reason: transforming bugs (missing quote) into early errors, so that it is
>> easier to debug...
>>
>> The obvious workaround, i.e. using a template literal without
>> placeholder, doesn’t seems too heavy-weight; on the contrary, it is
>> probably the lightest one can imagine.
>>
>>
> It's not actually :) lightest I can imagine is to allow single and double
> quoted strings to be multiline also.
> I was considering this because of an issue on my extended json parser.
> during development it simplified the code making a single path for
> gathering a string that only had to check for closing quote or backslash.
> having to test for 4 more characters was then 3x the work... so I just cut
> out the extra work, since it break anything.  The only thing left was ...
> that it didn't break anything if a newline was found.
>
> So I figured I'd mention the possibility here and see how much push back I
> got.  I don't actually think that 'protection from bad coding' is a very
> strong argument.  there's lots of single character omissions or insertions
> that can cause ghosted errors that aren't nearly so obvious.  Especially
> since syntax highlighting would show a overflowing string very quickly
> (more than missing a + in += or having a +  on an = that you didn't mean
> for instance).  It would be a change that would take some time to propagate
> to a lot of tools; but is a change that's entirely backward compatible and
> breaks nothing from the past.
>
>
>
>
>> —Claude
>
>
>
> ___
> 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: async/await -> await/async: a simpler, less error-prone async syntax

[Alexander Jones]

> with the added bonus of transparently allowing sync functions to be
converted to async functions without fundamentally affecting consumer
calling code.

It does fundamentally affect calling code if the calling code reaches
outside of its local variables. The state of the world around you might
change any time you await and give control back to the event loop.

On Mon, 4 Dec 2017 at 19:16, Naveen Chawla  wrote:

> Obviously. The whole point of this proposal is that awaiting async
> functions is automatically _implied_ inside an `autoasync` function, unless
> an async function is called with a `background` qualifier (which thereby
> makes it return its promise instead). The OP is right: this is a far less
> bug prone way to do async programming than `async` `await`, while offering
> all its functionality, with the added bonus of transparently allowing sync
> functions to be converted to async functions without fundamentally
> affecting consumer calling code.
>
> For those who want to be able to do extensive async programming, having
> this in the language, and using it instead of `await` `async` throughout,
> is a no-brainer.
>
> Of course, I am qualifying that it must be new keywords, not `await`
> `async` juggled like in the original post, but that wasn't the thrust of
> the proposal anyway.
>
> On Mon, 4 Dec 2017 at 21:09 Isiah Meadows  wrote:
>
>> Am I misunderstanding something about this proposal that it's
>> substantially any different from `.then` or immediately invoked async
>> functions?
>>
>> ```js
>> // Original
>> await function foo() {
>> const bar = async baz()
>> use(bar)
>> }
>>
>> // What I'm reading
>> function foo() {
>> ;(async () => {
>> const bar = await baz()
>> use(bar)
>> })()
>> }
>> function foo() {
>> try {
>> Promise.resolve(baz())
>> .then(bar => { use(bar) })
>> } catch (e) {
>> Promise.reject(e)
>> }
>> }
>> ```
>>
>> On Mon, Dec 4, 2017, 09:54 T.J. Crowder 
>> wrote:
>>
>>> On Mon, Dec 4, 2017 at 2:37 PM, Bob Myers  wrote:
>>> >
>>> > It turns out that this approach has a number of problems.
>>> > As a result, future versions of selenium will no longer support it.
>>> > Test writers will be asked to write `await` where needed.
>>>
>>> Were there problems other than the complexity of maintaining the
>>> promise manager tool and issues with debuggability? Neither of those
>>> seems like it would be an issue with Steven's proposal...
>>>
>>> (I just realized for the first time, Bob, that your initials are RTM.
>>> I love it. You should adopt Frank as a second middle name. ;-) )
>>>
>>> -- T.J. Crowder
>>> ___
>>> 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: How it feels to learn JavaScript in 2016

[Alexander Jones]

They’re not even *objects*, let alone regular objects! :)

Making every new addition to the language be a subtype of object just
creates a worse language. Given the constraints and requirements it was the
right choice to make symbol a new primitive. Technically it “broke the
web”, like literally every new change to the language. But that’s not as
black and white as people make it out to be, by using such a catchy phrase.

typeof: officially subject to extensions.

Alex

On Sun, 26 Nov 2017 at 01:23, Jordan Harband  wrote:

> Except that they're not regular objects; and if they'd done that, there'd
> just be the same potential problems with code naively written to accept an
> object (since Symbols are primitives, they don't have persistent
> properties, for example).
>
> Code that's written as if things will never change is brittle; "paranoid"
> code isn't over-engineered, it's simply *engineered* to handle change
> robustly.
>
> On Sat, Nov 25, 2017 at 5:30 PM, kai zhu  wrote:
>
>> claude, mature nodejs database drivers with frozen business logic for
>> stability reasons are examples of libraries that you are asking to
>> change whenever tc39 decides to expand typeof's on a whim which may
>> break them.
>>
>> the maintainers of sqlite3 for example have stated its in maintennance
>> mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
>> commits for the past 2 years have dealt exclusively with its build
>> process so it can successfully compile with each nodejs release.
>>
>> i write database code myself.  what was my reaction to the
>> introduction of the 'symbol' typeof?  annoyance at trying to figure
>> out what pathological use-case a user might want to pass a 'symbol'
>> type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
>> are equally annoyed with trying to figure that out.  if tc39 had
>> treated symbols as a regular 'object' type, then we wouldn't have that
>> problem, and the current undefined behavior when its encountered in db
>> drivers.
>>
>>
>> On 11/26/17, Claude Pache  wrote:
>> >
>> >> Le 25 nov. 2017 à 16:03, kai zhu  a écrit :
>> >>
>> >> i disagree.  you can write more maintainable and cleaner code with the
>> >> premise typeof's will never change again (and give a one-time pass for
>> >> symbols), instead of over-engineered paranoid code that it *may*
>> >> change again in the future.
>> >>
>> >
>> > It is the responsibility of the programmer to write *forward-compatible*
>> > code, i.e., code that does not make assumptions that are *likely* to
>> break
>> > in the future. For instance, one can *reasonably* think that the domain
>> of
>> > the `typeof` operator may expand.
>> >
>> > Naturally, the programmer should be smart enough in order to make the
>> > difference between paranoia and common sense: this is part of the art of
>> > programming.
>> >
>> > —Claude
>> >
>> >
>> ___
>> 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: Array.prototype.remove(item)

[Alexander Jones]

Small Sets could maybe be represented without the tree?

And everything you say about SIMD could be done too when the set has a
viable homogeneous type.



On Fri, 10 Nov 2017 at 14:26, T.J. Crowder 
wrote:

> On Fri, Nov 10, 2017 at 2:17 PM, Isiah Meadows
>  wrote:
> > Inline. (Hindsight, should've included this in the previous email)
>
> Good deal, that's the kind of thing I was thinking would strengthen the
> argument.
>
> I think you may have meant to have more after *"In nearly every virtual
> DOM library, in
> most , the core involves..."* ? (Ignore this if the rest of that sentence
> wasn't important.)
>
> -- T.J. Crowder
> ___
> 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: Syntax is the Problem

[Alexander Jones]

This is projective editing. See for example https://www.jetbrains.com/mps/

On 5 November 2017 at 13:22, Michael Lewis  wrote:

> Raul-Sebastian Mihăilă just made a post here about some mixin syntax.  I
> didn't read it (sorry).
>
> But, it got me thinking about a concept I've been thinking for years:  *syntax
> is the problem*, and there's a better solution.
>
> If you define syntax as a human <--> computer language (a human-readable
> and computer-readable form of text), you necessarily need a very strictly
> defined syntax.  One missing curly, and you're f'd.
>
> Duh, we all know this.  Hang onto your pants for a second, let's explore
> an alternative.
>
> What if we edited scripts more directly in AST form (abstract syntax
> tree).  Developers could implement their own UI to manipulate this AST.
> There are many, many benefits to this, I'll get to in a second.
>
> First, let's remember what everyone in the JS community is doing right
> now:  running their code through transpilers.  (I refuse to do this, that's
> why I'm unemployed - I strongly dislike the concept).  What is a
> transpiler?  It's an unofficial middleman that interprets the syntax,
> converts it to an AST, performs transformations, and then returns the AST
> to syntax form.
>
> Suddenly, scripting in AST form doesn't sound so crazy.
>
> Clearly, you wouldn't be writing JSON.  We would be using a GUI to create
> the AST.  And this is the greatest benefit: moving away from *syntax*,
> and moving to a GUI.
>
> Then, instead of babel plugins that provide alternative *syntax*, you
> could have plugins that provide alternative *experiences.*
>
> What would designing a class look like, if using a GUI?
>
>1. Click [ create new class ]
>2. Click [ add new method ]
>
> Or, click the [ extend ] button next to an existing class...
>
> This is the future.  I have to go eat breakfast, but I'd love to discuss
> this future if anyone is interested...
>
> ___
> 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: How it feels to learn JavaScript in 2016

[Alexander Jones]

This appears to be borderline trolling.

I can assert with confidence that ES6+ is bringing clear wins in
maintainability and developer efficiency. If your colleagues are writing
‘brittle’ code in ES6 I’d argue it’d be worse in ES5 on average.

(Also a mailing list is a great way to get FUD into a discussion without
fear of downvotes. Who knew?)

 — The Silent Majority



On Sat, 28 Oct 2017 at 09:19, kai zhu  wrote:

> naveen, how are es modules or generators superior in getting a
> frontend product shipped?  "powerful" does not equate superior.
>
> success in shipping a product correlates highly to having maintainable
> code (with consistent styguide) that's easy to debug.  generators are
> a nightmare to debug (compared to callbacks and promises) when doing
> integration and qa.  es modules have confusing async-magic that few
> frontend devs really understand, and results in brittle module-loading
> code nobody wants to touch and risk breaking after its written.
>
> the es6+ projects i've worked on all have significant amounts of
> brittleness which leads to them being difficult-to-ship as features
> could not be added or modified without fear of code-changes breaking
> something.  2016 and 2017 have been rough years for anyone trying to
> get es6+ products shipped.  and i suspect it will remain the same for
> 2018.
>
> if you're a product manager and your priority is to ship a frontend
> product, then your safest bet is to avoid es6 altogether.
>
> On 10/27/17, Naveen Chawla  wrote:
> > kai zhu, it sounds like you have a bad manager who is over eagerly
> pushing
> > for a disruptive transition in a well established ES5 project to new
> > features. The way to gracefully introduce the new features is
> incrementally
> > in new code, not existing code, or when modifying existing code. If your
> > manager is pushing to translate the whole code base and you are finding
> > that a waste of time, then that is not the fault of TC39 or the language;
> > that is the fault of the manager.
> >
> > The features themselves are superior, more powerful and easier to use
> than
> > the former ES5, so "everyday javascript programmers" will have a better
> > time whether they are writing tiny or massive apps.
> >
> > Yes, new apps should use those features immediately, and the developers
> > will experience the benefits, sometimes very significant
> >
> >
> > On Fri, 27 Oct 2017, 11:52 am kai zhu,  wrote:
> >
> >> in frontend-development, the majority of use-cases are for
> >> small/medium-scale applications, where es6 toolings are inappropriate
> >> due to their complexity.
> >>
> >> "reliable, well-engineered, large-scale, performant applications" are
> >> a niche application of javascript.  tc39 should focus on making lives
> >> of everyday javascript programmers easier (who mainly want simple and
> >> stable tooling for simple/moderate webapps), instead of catering to
> >> niche people wanting google/facebook-scale apps.
> >>
> >>
> >> On 10/27/17, Bob Myers  wrote:
> >> > If you don't like those features or the associated tooling, then don't
> >> use
> >> > them.
> >> > Meanwhile, other people will be using them to build reliable,
> >> > well-engineered, large-scale, performant applications.
> >> > Bob
> >> >
> >> > On Fri, Oct 27, 2017 at 10:57 AM, kai zhu 
> wrote:
> >> >
> >> >> tc39 is partly to blame for promoting the perception of javascript
> >> >> language instability, which promotes tooling instability.
> >> >>
> >> >> generators, es modules, destructing, let, fat arrows have caused
> >> >> tremendous harm to tooling stability, which has made
> >> >> frontend-development hell for everyone.
> >> >>
> >> >>
> >> >> On 10/27/17, Jordan Harband  wrote:
> >> >> > aka "how it feels to learn"?
> >> >> >
> >> >> > A decent response:
> >> >> > https://medium.com/front-end-hacking/how-it-feels-to-learn-
> >> >> javascript-in-2017-a934b801fbe
> >> >> >
> >> >> > On Thu, Oct 26, 2017 at 3:38 PM, J Decker 
> wrote:
> >> >> >
> >> >> >> (humor?)
> >> >> >> https://hackernoon.com/how-it-feels-to-learn-javascript-in-
> >> >> 2016-
> >> >> >> d3a717dd577f
> >> >> >>
> >> >> >> It all seemed so simple
> >> >> >>
> >> >> >> ___
> >> >> >> 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
> 

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

[Alexander Jones]

I used the term 'language contributors' rather than TC39 as an
intentionally vague way of describing people like us.

The ISO C++ Committee also lacks a consensus on everything, but that
doesn't mean those people and the people around them can't debate and
establish a consensus on *something*. Hence, C++ Core Guidelines.

I think the reality is that people are averse to this because they don't
want their pet practices at work being discouraged by anything resembling
official guidance — having to justify a decision to use `var` instead of
`const` by default is *effort*, right? But they're perhaps not always
considering the benefits that an improvement in (not necessarily total)
uniformity can bring.

I claim that the majority in the Python community would say that PEP-8 has
been a net benefit. (Yes I break its rules from time to time. That's what
rules are for. ;) )

On 20 October 2017 at 00:54, Isiah Meadows <isiahmead...@gmail.com> wrote:

> In general, it's not the TC39 who should be dictating how code is
> written - in particular, even they have their stylistic disagreements
> (like with ASI and `let` vs `const`), and active TC39 representative
> maintain both JSHint (opinionated) and ESLint (unopinionated).
> Additionally, JSLint (the predecessor to JSHint) was created by a
> formerly active TC39 representative. If you want to see more of these
> broad stylistic disagreements, check out [their meeting notes][1]. A
> few things that come to mind are decorators, cancellation, recent
> class additions, and [BigInt][2].
>
> Instead, if you have your own strong opinions on everything, try
> introducing [ESLint][3] to your projects. They have numerous presets
> and rules built-in, and you can create your own custom presets, rules,
> and plugins. If you want to ban `null`, write a custom rule for it. If
> you want to ban anything not ES5, write a rule that catches every
> expression that isn't ES5. If you want to define local rules, use
> [eslint-plugin-local][4]. In my case, I decided I didn't want to use
> default exports, so I wrote a local rule banning all default exports.
> Not that I have a problem with those who use it - I don't. I just feel
> it's easier for me to wrap my head around named exports without
> introducing the cognitive overhead of default exports.
>
> [1]: https://esdiscuss.org/notes
> [2]: https://esdiscuss.org/notes/2017-01-25#15iv-progress-
> report-and-request-for-comments-on-64-bit-int-support
> [3]: https://eslint.org/
> [4]: https://github.com/taskworld/eslint-plugin-local
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla <naveen.c...@gmail.com>
> wrote:
> > I disagree that the language contributors should be involved in best
> > practice guidance. Patterns evolve over usage and experience with the
> > constructs. I bet the implementors of `&&` and `||` didn't necessarily
> > expect them to be used so effectively for non-boolean logic e.g. `car &&
> > car.drive()` instead of `if(car!==undefined) car.drive()` or whatever...
> Or
> > maybe they did. But the point is language usage is often a matter of
> opinion
> > and preference, and not something that should be set as a tide against a
> > possibly justifiable opposition. As a response to the original question,
> I
> > gave my opinion and reason in brackets. If the reader prefers a different
> > way for their own reasons, fine - I would just expect them to give their
> own
> > reasons for superseding my reasons...
> >
> > On Wed, 18 Oct 2017 at 14:34 Alexander Jones <a...@weej.com> wrote:
> >>
> >> The beauty of (coding) standards is that there are so many to choose
> from.
> >> :)
> >>
> >> IMO it’s a false dichotomy though. A respected and credible group of
> >> language contributors should pool some energy together and ratify some
> >> opinionated best practices, a la the C++ Core Guidelines and PEP-8. No,
> it’s
> >> not *necessary*—neither is the exponent operator—but it does have clear
> >> benefits.
> >>
> >> I believe most in the community would rather not have to sell things
> like
> >> “const by default” to their team members, when it could be “official”
> >> guidance instead. It’s energy we’d rather be spending on other things!
> >>
> >> Alex
> >>
> >> On Wed, 18 Oct 2017 at 06:59, Jordan Harband <ljh...@gmail.com> wrote:
> >>>
> >>> These questions have consumed programmers in most languages since
> >>> forev

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

[Alexander Jones]

The beauty of (coding) standards is that there are so many to choose from.
:)

IMO it’s a false dichotomy though. A respected and credible group of
language contributors should pool some energy together and ratify some
opinionated best practices, a la the C++ Core Guidelines and PEP-8. No,
it’s not *necessary*—neither is the exponent operator—but it does have
clear benefits.

I believe most in the community would rather not have to sell things like
“const by default” to their team members, when it could be “official”
guidance instead. It’s energy we’d rather be spending on other things!

Alex

On Wed, 18 Oct 2017 at 06:59, Jordan Harband  wrote:

> These questions have consumed programmers in most languages since forever.
> It's not TC39's place to tell people how to write code - but there's plenty
> of style guides that have answers to these questions.
>
> On Tue, Oct 17, 2017 at 10:44 PM, kai zhu  wrote:
>
>> there are several factors for the current javascript-fatigue.  one factor
>> which tc39 could help mitigate is to provide a narrative on how to
>> consistently apply proposed language-features (over existing-practices and
>> interfacing with legacy-code).
>>
>> i feel too many new and old javascript-programmers alike are unable to
>> adopt a consistent programming-style for post-es5 features in
>> production-code.  style-issues which are problematic when a project has to
>> deal with legacy libraries include:
>>
>> - when is it appropriate to use callback vs promise vs async-generator vs
>> async/await, when interfacing with legacy-code (aka context-switching-hell
>> or baton-passing-hell)?
>> - when is it appropriate to use var vs let, when interfacing with
>> legacy-code?
>> - when is it appropriate to use function vs fat-arrow, when interfacing
>> with legacy-code?
>> - how can we apply destructuring in a consistent and readable manner?
>> - when is it appropriate to use (proposed) pipeline-operator, and when is
>> it not?
>>
>> es6/es7/es8 introduces hundreds of these kinds of questions which
>> distract us from actual coding and shipping features.
>> ___
>> 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: Make comma at the end of line optional

[Alexander Jones]

IIFEs start with a (. Putting line breaks before certain expressions can
help improve clarity. Your mind is made up but I have to protest. ASI
*sucks*. And the extra cognitive overhead it causes is utterly pointless.
If you don’t want to type them, why not program your editor to actually
insert ; and a linebreak at the same time when you want to terminate a
statement?

Many problems arise from parsing ambiguities — when writing code authors
know exactly what they intend, why make future readers second guess?

On Fri, 15 Sep 2017 at 11:12, Reinis Ivanovs  wrote:

> The "some examples" of ASI problems might as well say "all", since there
> aren't more than the two listed cases worth mentioning, and even the
> `return` one is kind of contrived, because putting line breaks after
> `return` isn't usually a thing. It also doesn't follow that ASI would be a
> "bad idea"; remembering not to start lines with brackets or parens is easy
> (especially with a linter, which people should be using anyway), and the
> benefit is less visually noisy code and a bit less typing. The same can't
> be said for comma insertion, because commas aren't as noticable or often
> used as semicolons, and the syntax would have more 'gotchas' than with ASI,
> so it's just not worth it.
>
> On Wed, Sep 13, 2017 at 6:22 PM, Boris Zbarsky  wrote:
>
>> On 9/13/17 9:57 AM, Naveen Chawla wrote:
>>
>>> By this behaviour (a modification to the initial "complete statement
>>> produces comma" version of this proposal), everything would work perfectly,
>>> no?
>>>
>>
>> If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
>> behavior that makes any code relying on this a hard-to-read footgun", then
>> the answer might be "yes".  For pretty much any other definition of
>> "perfectly", I'm fairly sure the answer is "no".
>>
>> Great to hear those counter-examples as I don't know enough about ASI,
>>>
>>
>> Still in the context of ASI, here are some examples of why ASI is a bad
>> idea:
>>
>> 1) What does this return?
>>
>>   function f() {
>> return
>> 5;
>>   }
>>
>> 2) What does this alert?
>>
>>   var str = "hello";
>>   var x = str
>>   [x].forEach(() => alert(x))
>>
>> Now back to automatic comma insertion... In your example:
>>
>>   function doStuff(
>>   x
>>   y
>>   z
>>   ){
>>   }
>>
>> if someone changes doStuff to take an array as the second arg and you
>> modify the call as:
>>
>>   function doStuff(
>>   x
>>   [y]
>>   z
>>   ){
>>   }
>>
>> suddenly you need to insert a comma after the "x" to preserve the right
>> semantics, no?  This is not terribly intuitive or obvious.  It gets even
>> worse in a situation like this:
>>
>>   function doStuff(
>>   x
>>   /* The next argument is an array for good reasons that we
>>  will now expound on in a long comment, etc, etc */
>>   [y]
>>   ){
>>   }
>>
>> Quick, tell me without testing this or looking at the spec for a while
>> whether this is a valid call to doStuff, with one argument, or a syntax
>> error that would trigger comma insertion.
>>
>> But more generally, if you just use your favorite search engine on the
>> phrase "automatic semicolon insertion", you will get a slew of articles
>> explaining the pitfalls.
>>
>>
>> -Boris
>> ___
>> 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: super return

[Alexander Jones]

Perhaps if the nested function is lexically inside such super function it
can be fair game and actually quite powerful and liberating.

Unconstrained 'upleveling' is IIRC valid in such wonderful languages as
Tcl. This unverified fact is presented without opinion :D

On Tue, 29 Aug 2017 at 16:57, Allen Wirfs-Brock 
wrote:

> On Aug 28, 2017, at 12:29 PM, Sebastian Malton 
> wrote:
>
> The outcome of this basically means "return from current context up one
> level and then return from there”.
>
>
> This would be a terrible violation of functional encapsulation.  How do
> you know that the (e.g.) forOf function isn’t internally using a
> encapsulated helper function that is making the actual call to the call
> back.  You simply have no way to predict where returning from the current
> context “up one” means.
>
>
> A current method of doing this is by using try / catch but it is not
> ideal. Using the above method I believe that it would be able to be better
> optimized.
>
>
> This technique provides a meaningful semantics because it allows the
> controlling outer function to define what early return means.
>
>
> ___
> 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: Proposing a conditional assignment (or equals) operator

[Alexander Jones]

For what it's worth, doubling down on a design that exposes such poor
choices wouldn't necessarily be a bad thing ;)

On Wed, 16 Aug 2017 at 02:56, kai zhu  wrote:

> this proposal is not as useful as you would think.  when integrating
> with api's and modules not written by yourself, you will always be
> self-doubting whether the "other" guy who wrote their code used
> null/undefined/false/0/ values, causing you to avoid
> using this feature in general.
>
> the  is commonly treated as a defacto null when reading
> dom-element attributes or when fetching web-data
>
>
> On 8/15/17, Claude Pache  wrote:
> > This feature is more related to null coalescing (evaluate the RHS when
> the
> > LHS is null) than to optional chaining (evaluate the LHS when the LHS is
> > *not* null).
> >
> > See https://github.com/gisenberg/proposal-nullary-coalescing/issues/1
> > 
> >
> > —Claude
> >
> >> Le 15 août 2017 à 03:11, Ari Porad  a écrit :
> >>
> >> Hi All,
> >>
> >> Given that optional chaining is now stage–1, would there be interest in
> >> reviving this proposal? (This idea originated from my comment here
> >> <
> https://github.com/tc39/proposal-optional-chaining/issues/18#issuecomment-322329156
> >.)
> >>
> >> Apologies if this isn’t the proper way to suggest this idea, it’s my
> first
> >> time posting on 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: Re: Array.prototype.toObjectByProperty( element=>element.property )

[Alexander Jones]

> is nearly always a perfect fit for this

The fact that it is so close to being useful, but has silly surprises like
`'toString' in everyObject`, actually gives JS a bad reputation and
contributes towards people being driven to other languages that have
cleaner approaches to data types.

On 13 August 2017 at 20:07, Naveen Chawla <naveen.c...@gmail.com> wrote:

> Object self-promotes because it is nearly always a perfect fit for this:
> great performance, great literal syntax, concise access syntax. The only
> compelling case to use a map instead is when insertion ordering is
> required, despite the MDN article. I wouldn't oppose an equivalent
> `Array.prototype.toMap` and `Map.fromIterable`, I would just hardly ever
> use it
>
> On Sun, 13 Aug 2017, 10:33 p.m. Alexander Jones, <a...@weej.com> wrote:
>
>> Honestly, promoting the use of Object for this, and coupling the solution
>> to Array, feels like the wrong direction for the language to me personally.
>> By definition, such a map constructed from a set of homogenous values, for
>> indexing purposes, has a clear key and value type. This guidance from MDN
>> seems to be the right message we should be sending to developers:
>>
>> https://developer.mozilla.org/en/docs/Web/JavaScript/
>> Reference/Global_Objects/Map
>>
>> > ... ask yourself the following questions:
>> >
>> >  * Are keys usually unknown until run time? Do you need to look them up
>> dynamically?
>> >  * Do all values have the same type? Can they be used interchangeably?
>> >  * Do you need keys that aren't strings?
>> >  * Are key-value pairs frequently added or removed?
>> >  * Do you have an arbitrary (easily changing) number of key-value pairs?
>> >  * Is the collection iterated?
>> >
>> > If you answered 'yes' to any of those questions, that is a sign that
>> you might want to use a Map. Contrariwise, if you have a fixed number of
>> keys, operate on them individually, or distinguish between their usage,
>> then you probably want to use an Object.
>>
>>
>> On 13 August 2017 at 05:49, Naveen Chawla <naveen.c...@gmail.com> wrote:
>>
>>> Verbosity.
>>>
>>> It's a task common across many project types and involves only 2
>>> fundamental types in ES: array and object
>>>
>>> Compare:
>>>
>>> ```
>>> const cache = array.reduce((cache, element)=>{cache[element.id] =
>>> element; return cache;}, {});
>>> ```
>>>
>>> with
>>>
>>> ```
>>> const cache = array.toObject(element=>element.id);
>>> ```
>>>
>>> since the signature would offer additional optional `valueFromElement`
>>> and `startingObject` parameters nobody loses anything.
>>>
>>> On Sun, 13 Aug 2017 at 09:51 Barret Furton <barretfur...@gmail.com>
>>> wrote:
>>>
>>>> Why not embrace `Array.prototype.reduce` instead of trying to abstract
>>>> it away?
>>>>
>>>> ```js
>>>> const identity = a => a
>>>>
>>>> const toObject = (fk, fv = identity) =>
>>>> (acc, curr) => (acc[fk(curr)] = fv(curr), acc)
>>>>
>>>> const arr = [['a', '1'], ['b', '2'], ['c', '3']]
>>>>
>>>> arr.map(a => [a[0], parseInt(a[1], 10)])
>>>>.filter(a => a[0] !== 'c')
>>>>.reduce(toObject(a => a[0]), {}) // { a: 1, b: 2 }
>>>> ```
>>>>
>>>> `reduce(toObject)` clearly communicates intent, and you can even
>>>> provide an existing object for merging.
>>>>
>>>> On Sat, Aug 12, 2017 at 1:58 PM, Naveen Chawla <naveen.c...@gmail.com>
>>>> wrote:
>>>>
>>>>> My proposal was `Map.fromIterable(iterable, keyFromElement[,
>>>>> valueFromElement[, existingMap]])` so it's not meant to be symmetrical 
>>>>> with
>>>>> `values` anyway. It was as an equivalent of `Object.fromIterable(iterable,
>>>>> keyFromElement[, valueFromElement[, existingObjectToUse]])` as a means to
>>>>> construct an object's keys and values from any iterable.
>>>>>
>>>>> I also was just thinking that both can perfectly coexist with
>>>>> `Array.prototype.toObject(keyFromElement[, valueFromElement])` which
>>>>> has the advantage of chain-ability after array transformation methods 
>>>>> (like
>>>>> `filter` etc.). Array is such a fundamental construct that I would find
>>>>

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

[Alexander Jones]

Honestly, promoting the use of Object for this, and coupling the solution
to Array, feels like the wrong direction for the language to me personally.
By definition, such a map constructed from a set of homogenous values, for
indexing purposes, has a clear key and value type. This guidance from MDN
seems to be the right message we should be sending to developers:

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Map

> ... ask yourself the following questions:
>
>  * Are keys usually unknown until run time? Do you need to look them up
dynamically?
>  * Do all values have the same type? Can they be used interchangeably?
>  * Do you need keys that aren't strings?
>  * Are key-value pairs frequently added or removed?
>  * Do you have an arbitrary (easily changing) number of key-value pairs?
>  * Is the collection iterated?
>
> If you answered 'yes' to any of those questions, that is a sign that you
might want to use a Map. Contrariwise, if you have a fixed number of keys,
operate on them individually, or distinguish between their usage, then you
probably want to use an Object.


On 13 August 2017 at 05:49, Naveen Chawla <naveen.c...@gmail.com> wrote:

> Verbosity.
>
> It's a task common across many project types and involves only 2
> fundamental types in ES: array and object
>
> Compare:
>
> ```
> const cache = array.reduce((cache, element)=>{cache[element.id] =
> element; return cache;}, {});
> ```
>
> with
>
> ```
> const cache = array.toObject(element=>element.id);
> ```
>
> since the signature would offer additional optional `valueFromElement` and
> `startingObject` parameters nobody loses anything.
>
> On Sun, 13 Aug 2017 at 09:51 Barret Furton <barretfur...@gmail.com> wrote:
>
>> Why not embrace `Array.prototype.reduce` instead of trying to abstract it
>> away?
>>
>> ```js
>> const identity = a => a
>>
>> const toObject = (fk, fv = identity) =>
>> (acc, curr) => (acc[fk(curr)] = fv(curr), acc)
>>
>> const arr = [['a', '1'], ['b', '2'], ['c', '3']]
>>
>> arr.map(a => [a[0], parseInt(a[1], 10)])
>>.filter(a => a[0] !== 'c')
>>.reduce(toObject(a => a[0]), {}) // { a: 1, b: 2 }
>> ```
>>
>> `reduce(toObject)` clearly communicates intent, and you can even provide
>> an existing object for merging.
>>
>> On Sat, Aug 12, 2017 at 1:58 PM, Naveen Chawla <naveen.c...@gmail.com>
>> wrote:
>>
>>> My proposal was `Map.fromIterable(iterable, keyFromElement[,
>>> valueFromElement[, existingMap]])` so it's not meant to be symmetrical with
>>> `values` anyway. It was as an equivalent of `Object.fromIterable(iterable,
>>> keyFromElement[, valueFromElement[, existingObjectToUse]])` as a means to
>>> construct an object's keys and values from any iterable.
>>>
>>> I also was just thinking that both can perfectly coexist with
>>> `Array.prototype.toObject(keyFromElement[, valueFromElement])` which
>>> has the advantage of chain-ability after array transformation methods (like
>>> `filter` etc.). Array is such a fundamental construct that I would find
>>> myself using this one the most frequently
>>>
>>> On Sat, 12 Aug 2017 at 21:44 Alexander Jones <a...@weej.com> wrote:
>>>
>>>> `Map.fromIterable` takes an iterable of values, and a key function.
>>>> Would a `Map.prototype.toIterable` return only the values - that's already
>>>> `Map.prototype.values`? It feels like there is a symmetry issue here.
>>>> Perhaps this could be `Map.fromValues`?
>>>>
>>>> Worth also remembering that compressing every possible use case down to
>>>> an absolute minimum has a cost if the resultant language has too many
>>>> features like this. I think `new Map(...kvps)` is a general solution that
>>>> is actually good enough for "indexing" purposes, and means that people only
>>>> have to internalise one method of construction via iterables.
>>>>
>>>> That said, a helper function to allow constructing map-like objects
>>>> from arbitrary iterables would maybe be a bit more composable?
>>>>
>>>> ```js
>>>> // This works with Map, WeakMap, Immutable.Map, etc.
>>>> function* keyedBy(iterable, keyFn) {
>>>>   for (const element of iterable) {
>>>> yield [keyFn(element), element];
>>>>   }
>>>> }
>>>>
>>>> const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age:
>>>> 43}, ...];
>

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

[Alexander Jones]

`Map.fromIterable` takes an iterable of values, and a key function. Would a
`Map.prototype.toIterable` return only the values - that's already
`Map.prototype.values`? It feels like there is a symmetry issue here.
Perhaps this could be `Map.fromValues`?

Worth also remembering that compressing every possible use case down to an
absolute minimum has a cost if the resultant language has too many features
like this. I think `new Map(...kvps)` is a general solution that is
actually good enough for "indexing" purposes, and means that people only
have to internalise one method of construction via iterables.

That said, a helper function to allow constructing map-like objects from
arbitrary iterables would maybe be a bit more composable?

```js
// This works with Map, WeakMap, Immutable.Map, etc.
function* keyedBy(iterable, keyFn) {
  for (const element of iterable) {
yield [keyFn(element), element];
  }
}

const allThePeople = [{name: "Joe", age: 24}, {name: "Barbara", age: 43},
...];

const index1 =
  new Map(keyedBy(allThePeople, _ => _.name));

// c.f.
const index2 =
  Map.fromValues(allThePeople, _ => _.name);
```

On 11 August 2017 at 10:26, Naveen Chawla  wrote:

> Of these, insertion ordering is the only one that may be compelling enough
> to me when I require that, to overcome the disadvantages. I never use the
> object prototype and I'm not convinced about the performance aspect. I
> reiterate though that `Map.fromIterable(allThePeople, person=>person.name)`
> is less verbose for the stated use case
>
> On Fri, 11 Aug 2017 at 11:55 Darien Valentine 
> wrote:
>
>> @Alexander The idea of a generalized `map` function (etc, I’m guessing) is
>> appealing. From the way you talked about it, it sounds like there may
>> have been
>> past discussion on the topic. Are there any proposals for this or major
>> ideas
>> being batted around?
>>
>> > Why? What's the advantage? You lose at least the square bracket and dot
>> > notations for access, as disadvantages, and I'm not aware of any
>> advantages.
>> > If there aren't any that compensate for the disadvantages, then it's a
>> net
>> > negative
>>
>> @Naveen — a handful of things. Objects are indeed a perfectly reasonable
>> choice
>> for modeling kvp collections a lot of the time. On the other hand, because
>> objects in ES serve double duty as ways to model data and ways to "model
>> code",
>> they are not always ideal for the former case on account of the features
>> that
>> exist mainly to serve the second. Some examples of things that make maps
>> useful:
>> inherently iterable; no prototype chain access lookup; no collision with
>> `Object.prototype` property name when hashing by arbitrary keys;
>> potentially
>> more efficient for situations where keys are frequently removed;
>> `map.has()` is
>> more straightforward than having to consider whether you want `key in` or
>> `Object.hasOwnProperty` or which properties have been defined as
>> enumerable or
>> not; iteration order of entries is 1:1 with insertion order; and of
>> course, keys
>> can be of any type. Further, maps can be subclassed to constrain the
>> types that
>> they may hold or add other behaviors without needing to define custom
>> Proxies.
>>
>> Some general use cases: registries; hashing data where keys are from
>> external
>> input; kvp collections which are ordered; kvp collections which will be
>> subject
>> to later transformations; kvp collections to which new keys are
>> frequently added
>> or removed.
>>
>> While I hope that information is somewhat helpful, there are probably
>> much more
>> detailed resources online (including, I suspect, past discussions on this
>> list)
>> which could explain some of those things better or which include cases I
>> haven’t
>> thought of.
>> ___
>> 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: Re: Stage 0 Proposal: Extensible Collection Literal

[Alexander Jones]

https://github.com/tc39/proposal-pattern-matching/issues/47

On 30 July 2017 at 17:13, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Which is why I said there should be an issue filed there for it, so it
> *does* get considered. My point was that we shouldn't get too in depth
> independently of that proposal.
>
> Currently, that strawman is so incomplete in its current state it doesn't
> even fully cover existing destructuring yet (like nested patterns). That's
> where I was coming from when I recommended delaying until the pattern
> matching proposal gets to a state we can consider it.
>
> On Sun, Jul 30, 2017, 12:04 Alexander Jones <a...@weej.com> wrote:
>
>> Hey Isiah
>>
>> Good shout - definitely worth connecting pattern matching/destructuring
>> to the same concept.
>>
>> Let's assume `#{}` is kept, for the avoidance of bikeshedding:
>>
>> ```js
>> const map = Map#{42: "the answer"};
>>
>> const #{42: fortyTwo} = someMap;
>> // or?
>> const {[42]: fortyTwo} = someMap;
>> console.log(fortyTwo);  // "the answer"
>> ```
>>
>> And presumably:
>>
>> ```js
>> match (map) {
>> #{42: _}: `42 is ${_}`,
>> else: `who knows?`,
>> }
>> ```
>>
>> I'd be wary of just powering ahead with pattern matching /without/
>> considering generalised mapping/sequence syntax...
>>
>> On 30 July 2017 at 16:41, Isiah Meadows <isiahmead...@gmail.com> wrote:
>>
>>> How about for now, let's hold off on anything concrete until after the
>>> pattern matching proposal gets to a point we can model the syntax and
>>> semantics after that. There's quite a bit of overlap in terms of behavior,
>>> too, which is more reason to consider this together with it.
>>>
>>> https://github.com/tc39/proposal-pattern-matching
>>>
>>> (I don't believe there's an issue over there for potential future
>>> expansion to extensible destructuring assignment, but there should be.)
>>>
>>> On Sun, Jul 30, 2017, 11:34 Darien Valentine <valentin...@gmail.com>
>>> wrote:
>>>
>>>> While static analysis is one advantage, there are additional reasons
>>>> for this to be a syntactic proposal. A helper method like `Map.fromObject`
>>>> could indeed be a useful addition to the language (though it is simple
>>>> enough to do already: `new Map(Object.entries(obj))`) — however that does
>>>> not work for maps whose keys are not also valid property keys.
>>>>
>>>> In general I’m in the less-new-syntax camp, but I find this idea
>>>> intriguing. My initial impression is that it’s fairly convincing, mainly
>>>> because my (purely anecdotal) experience is that it is an attempt to solve
>>>> a real problem — many devs seem to be reluctant to use `Map` and `Set`,
>>>> despite knowing they exist and are sometimes more appropriate models, and I
>>>> think it is in part due to their "second class" nature; in ES folks are
>>>> accustomed to "seeing" data structures. Similarly there is reluctance to
>>>> work with subclasses of data structures, which are put on equal-footing by
>>>> this proposal.
>>>>
>>>> The `#` is indeed ugly, but the particular symbol I imagine is highly
>>>> bikesheddable and consideration of it could probably be deferred till it’s
>>>> determined whether the core ideas of the proposal represent a worthwhile
>>>> addition.
>>>> ___
>>>> 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: Re: Stage 0 Proposal: Extensible Collection Literal

[Alexander Jones]

Hey Isiah

Good shout - definitely worth connecting pattern matching/destructuring to
the same concept.

Let's assume `#{}` is kept, for the avoidance of bikeshedding:

```js
const map = Map#{42: "the answer"};

const #{42: fortyTwo} = someMap;
// or?
const {[42]: fortyTwo} = someMap;
console.log(fortyTwo);  // "the answer"
```

And presumably:

```js
match (map) {
#{42: _}: `42 is ${_}`,
else: `who knows?`,
}
```

I'd be wary of just powering ahead with pattern matching /without/
considering generalised mapping/sequence syntax...

On 30 July 2017 at 16:41, Isiah Meadows  wrote:

> How about for now, let's hold off on anything concrete until after the
> pattern matching proposal gets to a point we can model the syntax and
> semantics after that. There's quite a bit of overlap in terms of behavior,
> too, which is more reason to consider this together with it.
>
> https://github.com/tc39/proposal-pattern-matching
>
> (I don't believe there's an issue over there for potential future
> expansion to extensible destructuring assignment, but there should be.)
>
> On Sun, Jul 30, 2017, 11:34 Darien Valentine 
> wrote:
>
>> While static analysis is one advantage, there are additional reasons for
>> this to be a syntactic proposal. A helper method like `Map.fromObject`
>> could indeed be a useful addition to the language (though it is simple
>> enough to do already: `new Map(Object.entries(obj))`) — however that does
>> not work for maps whose keys are not also valid property keys.
>>
>> In general I’m in the less-new-syntax camp, but I find this idea
>> intriguing. My initial impression is that it’s fairly convincing, mainly
>> because my (purely anecdotal) experience is that it is an attempt to solve
>> a real problem — many devs seem to be reluctant to use `Map` and `Set`,
>> despite knowing they exist and are sometimes more appropriate models, and I
>> think it is in part due to their "second class" nature; in ES folks are
>> accustomed to "seeing" data structures. Similarly there is reluctance to
>> work with subclasses of data structures, which are put on equal-footing by
>> this proposal.
>>
>> The `#` is indeed ugly, but the particular symbol I imagine is highly
>> bikesheddable and consideration of it could probably be deferred till it’s
>> determined whether the core ideas of the proposal represent a worthwhile
>> addition.
>> ___
>> 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

Stage 0 Proposal: Extensible Collection Literal

[Alexander Jones]

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

Re: Removal of language features

[Alexander Jones]

Removing things also frees up syntax and names for future extensions. Never
removing features is simply unscalable, and it's only going to accelerate
JS's demise!

I still think version pragmas are probably worth exploring to mitigate
this, while not 'breaking the web' is a stated goal.

Alex

On Thu, 20 Jul 2017 at 07:53, T.J. Crowder 
wrote:

> On Thu, Jul 20, 2017 at 7:13 AM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> Maybe ES should introduce something like a configuration object, in which
>> developers can enable / disable or in general configure features for their
>> module in a fine granular way. Of course all features which exist at the
>> time of introducing such a mechanism would have to be enabled by default...
>>
> As you say, this is more a job for linters / code analysis / code quality
> tools. The only time it's relevant to the JavaScript engine itself is where
> the elimination of a feature allows the engine to do a better/faster
> optimization job (for instance in strict mode, `with`, the link between
> `arguments` and named parameters, ...) or where only the engine can know
> about something problematic (viz. automatic globals). Those are relatively
> rare.
>
> I can't recall details, but I seem to recall an indication on the list at
> some stage that there's little-to-no appetite for further `"use
> strict"`-like directives. It's a big hammer, used once so far to fix some
> long-standing performance and correctness pain-points. Maybe TC-39 will use
> it again, but the indication was, not any time soon, and certainly not just
> to turn off features people don't like.
>
> -- T.J. Crowder
> ___
> 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: A twist on functional operatorsr

[Alexander Jones]

I think JavaScript has reached "peak token"... I also wanted to use the #
for generic map/list literal syntax: https://esdiscuss.org/topic/map-literal

On 15 July 2017 at 04:24, Isiah Meadows  wrote:

> Few nits inline:
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Fri, Jul 14, 2017 at 11:11 PM, Bob Myers  wrote:
> > The proposal to write `arr.reduce((+))`, with `(+)` as an alternative to
> > `(a, b) => a + b` is admirably concise, but syntactically challenging.
>
> Actually, it's not as *syntactically* challenging as you might think;
> it can be discerned just by recognizing the token sequence `(` @ `)`,
> where @ is the operator's token in question.
>
> >
> > The idea is a new form of function we'll call a "pound function",
> written as
> > `#{ }`, Within the body, parameters are available as `#0`, `#1`, etc.
>
> Potential complication: the parameter names visually conflict with the
> private member proposal.
>
> https://github.com/tc39/proposal-class-fields
>
> >
> > ```js
> > arr.reduce(#{# + #})
> > arr.sort(#{#.order - #.order})
> > ```
>
> This quite honestly looks like line noise. Also, it doesn't look clear
> at a glance whether it should be equivalent to `(a, b) => a + b` or `a
> => a + a` (using the first example).
>
> >
> > If need be, we can define `...##` inside pound functions as referring to
> the
> > argument list, so
> >
> > ```js
> > const sumParams = #{##.reduce(#{# + #})};
> > ```
>
> That does not look very elegant nor readable.
>
> >
> > Ugh. Anyway, I will leave it others to opine on whether this cryptic
> syntax
> > is worth the trouble, issues related to nested pound functions, etc. etc.
> >
>
> You might want to investigate Clojure's [1] and Swift's [2] similar
> existing syntaxes for this.
>
> [1]: https://coderwall.com/p/panlza/function-syntax-in-clojure
> [2]: https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/Functions.html
>
> >
> > Bob
> >
> >
> >
> > ___
> > 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: Naming convention for multi-word identifiers with initialisms

[Alexander Jones]

Just for funsies I looked this up - In the interests of honesty I should
point out that apparently it was Mozilla who named this `XMLHttpRequest`
thing.
https://softwareengineering.stackexchange.com/questions/157375/why-does-xmlhttprequest-not-seem-to-follow-a-naming-convention

On 11 July 2017 at 13:07, Alexander Jones <a...@weej.com> wrote:

> Occasionally this comes up when deciding on a spelling for something.
> There are numerous examples in ECMAScript and other Web standards that seem
> to defy the most uniform convention:
>
>  * `JSON` vs. `Json`
>  * `toJSON` vs. `toJson`
>  * `XMLHttpRequest` vs. `XmlHttpRequest`
>  * `DOMElement` vs. `DomElement`
>
> While it looks initially strange to specifically drop the capital letters
> on an initialisms like XML, the rule is simple in that it has an obvious
> machine decoding - a capital letter starts a new word. Thus, translations
> of identifiers to other case conventions are automatic (so long as numbers
> never appear at the start of a word). This helps a lot when e.g. generating
> bindings for IDLs to different languages, or in general interfacing
> different systems that really, really want to use their own naming
> conventions.
>
>  * mixed case: `myTlaIdentifierHere`
>  * pascal case: `MyTlaIdentifierHere`
>  * underscore case: `my_tla_identifier_here`
>  * uppercase: `MY_TLA_IDENTIFIER_HERE`
>  * kebab case: `my-tla-identifier-here`
>  * spaces case: `my tla identifier here`
>
> ---
>
> My question is whether there is an existing community recommendation
> anywhere for naming ECMAScript identifiers. Clearly, when Microsoft devised
> the name `XMLHttpRequest`, someone was having a difficult time figuring out
> how to spell adjacent initialisms in PascalCase.
>
> If there is no recommendation, perhaps there should be? Is there any scope
> for non-normative sections of information like this in the ECMAScript spec?
>
> Thanks
>
> Alex
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Array Functions

[Alexander Jones]

`array.get(-1)` could have the desired semantics (and be nicely symmetric
with Map), but actually in other languages (e.g. Python) I find that this
"trick" with negative numbers can lead to a surprising (and scary)
propagation of bugs, where array bounds checking is not correctly done.
Actually this exact behaviour caught me^Wsomeone who isn't me out, in
Immutable.js's `List` type already.

On 11 July 2017 at 18:31, Guylian Cox  wrote:

> Unfortunately, what you're proposing is already valid and has a different
> behavior:
>
> ```javascript
> > x = [1, 2, 3, 4, 5];
> [ 1, 2, 3, 4, 5 ]
> > x[-1] = 'oh no'
> 'oh no'
> > x[~0]
> 'oh no'
> > x[4]
> 5
> ```
>
> What about adding a prototype method like `last` to Array instead? With
> `[1,2,3].last()` returning 3, `[1,2,3].last(1)` returning 2, etc
>
> Le mar. 11 juil. 2017 à 19:19, Sebastian Malton  a
> écrit :
>
>> Using the ~ to count from the back of the array.
>>
>> Basically
>>
>> ```js
>> let x = [1,2,3,4,5];
>> x[4] === x[~0] === 5; //I know this is not how JS checking works
>> ```
>>
>> Sebastian
>> ___
>> 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: Naming convention for multi-word identifiers with initialisms

[Alexander Jones]

Thanks for the pointer Dominic - it does make me weep a bit
(`HTMLHRElement` u wot) but I'm glad someone wrote it down! (And it seems
`XMLHttpRequest` is still in violation...)

The next step is probably something more akin to PEP-8 than a partial
codification of existing norms.

On 11 July 2017 at 16:37, Domenic Denicola <d...@domenic.me> wrote:

> https://w3ctag.github.io/design-principles/#casing-rules
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of 
> *Alexander
> Jones
> *Sent:* Tuesday, July 11, 2017 08:07
> *To:* es-discuss@mozilla.org
> *Subject:* Naming convention for multi-word identifiers with initialisms
>
>
>
> Occasionally this comes up when deciding on a spelling for something.
> There are numerous examples in ECMAScript and other Web standards that seem
> to defy the most uniform convention:
>
>
>
>  * `JSON` vs. `Json`
>
>  * `toJSON` vs. `toJson`
>
>  * `XMLHttpRequest` vs. `XmlHttpRequest`
>
>  * `DOMElement` vs. `DomElement`
>
>
>
> While it looks initially strange to specifically drop the capital letters
> on an initialisms like XML, the rule is simple in that it has an obvious
> machine decoding - a capital letter starts a new word. Thus, translations
> of identifiers to other case conventions are automatic (so long as numbers
> never appear at the start of a word). This helps a lot when e.g. generating
> bindings for IDLs to different languages, or in general interfacing
> different systems that really, really want to use their own naming
> conventions.
>
>
>
>  * mixed case: `myTlaIdentifierHere`
>
>  * pascal case: `MyTlaIdentifierHere`
>
>  * underscore case: `my_tla_identifier_here`
>
>  * uppercase: `MY_TLA_IDENTIFIER_HERE`
>
>  * kebab case: `my-tla-identifier-here`
>
>  * spaces case: `my tla identifier here`
>
>
>
> ---
>
>
>
> My question is whether there is an existing community recommendation
> anywhere for naming ECMAScript identifiers. Clearly, when Microsoft devised
> the name `XMLHttpRequest`, someone was having a difficult time figuring out
> how to spell adjacent initialisms in PascalCase.
>
>
>
> If there is no recommendation, perhaps there should be? Is there any scope
> for non-normative sections of information like this in the ECMAScript spec?
>
>
>
> Thanks
>
>
>
> Alex
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Naming convention for multi-word identifiers with initialisms

[Alexander Jones]

Occasionally this comes up when deciding on a spelling for something. There
are numerous examples in ECMAScript and other Web standards that seem to
defy the most uniform convention:

 * `JSON` vs. `Json`
 * `toJSON` vs. `toJson`
 * `XMLHttpRequest` vs. `XmlHttpRequest`
 * `DOMElement` vs. `DomElement`

While it looks initially strange to specifically drop the capital letters
on an initialisms like XML, the rule is simple in that it has an obvious
machine decoding - a capital letter starts a new word. Thus, translations
of identifiers to other case conventions are automatic (so long as numbers
never appear at the start of a word). This helps a lot when e.g. generating
bindings for IDLs to different languages, or in general interfacing
different systems that really, really want to use their own naming
conventions.

 * mixed case: `myTlaIdentifierHere`
 * pascal case: `MyTlaIdentifierHere`
 * underscore case: `my_tla_identifier_here`
 * uppercase: `MY_TLA_IDENTIFIER_HERE`
 * kebab case: `my-tla-identifier-here`
 * spaces case: `my tla identifier here`

---

My question is whether there is an existing community recommendation
anywhere for naming ECMAScript identifiers. Clearly, when Microsoft devised
the name `XMLHttpRequest`, someone was having a difficult time figuring out
how to spell adjacent initialisms in PascalCase.

If there is no recommendation, perhaps there should be? Is there any scope
for non-normative sections of information like this in the ECMAScript spec?

Thanks

Alex
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extends expression performs differently on Edge

[Alexander Jones]

`y, z` is comma operator, no?

On Fri, 26 May 2017 at 08:57, Gareth Heyes 
wrote:

> ```javascript
> class y{}class z{}
> class x extends y, z{}/alert(1)/+alert(2)
> ```
>
> Edge seems to allow non-standard syntax here. I guess to allow you to
> extend multiple classes but as far as I'm aware this is non-standard
> syntax. The code above calls alert(2), if you change it to a class
> expression both alerts are called. It's a syntax error on other browsers.
> ___
> 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: Officially support a shebang line

[Alexander Jones]

It doesn't make any sense. The shebang is a UNIX way of declaring the
interpreter for an executable script, not for hinting your syntax
highlighter. If your file is not executable (as in, it can't be run with
`./filename`, it shouldn't have a shebang).

On 19 May 2017 at 02:44, Jan Krems  wrote:

> Tried to search past proposals for this but couldn't find one The short
> version: Most editors / syntax highlighting engines, non-engine parsers,
> node.js - they all support a leading shebang line in .js files. With the
> advent of ES6 modules it's the final holdout where node has to patch the
> script source to make V8 parse the code (and thus producing a mismatch
> between what's on disk and what the engine sees).
>
> Is there a downside to allow any script or module to begin with the
> magical #! bytes? It should not break existing scripts because it's invalid
> syntax today & the parse overhead should be fairly limited.
>
> ___
> 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: Object.isEqual

[Alexander Jones]

No I was not proposing that it actually *be* stringified-comparison... or
in any way be related to the JSON global.

* Property order would not be important for equality. Precedent is set by
common sense.
* Reference semantics (i.e. visitation) would be exactly as you'd expect -
look at Python's `dict` implementation for IMO the only obvious answer.
* I acknowledged specifically that JSON does not support all types, just
use SameValueZero for primitives and be done with it.
* Cycles are a subset of all possible reference semantics.
* Getters should be called. It already works for JSON and I don't hear
anyone complaining about it. (Maybe I wasn't listening?) - same for
prototype chain questions...

That said, most of these questions evaporate if people would just start
using Map for things. AFAIAC the main reason people don't is due to the
absence of a Map literal and JSON parsing tending to give you Object back
instead of a more appropriate type without such weirdness as prototypes and
property descriptors (yes, I went there!).



On 1 May 2017 at 22:55, Steve Fink <sph...@gmail.com> wrote:

> It would be nice to have *something* for this. Some remaining problems I
> see with using JSON serialization, let's call it JSON.isEqual:
>  - JS has order, JSON does not
>  - JSON lacks NaN, +/-Infinity (and JSON.stringify maps these to null,
> which means JSON.isEqual({x: 0/0}, {x: 1/0}))
>  - cycles
>  - ...and everything under your "trivial generalisation"
>
> It still seems like it'd be unfortunate if !JSON.isEqual({foo: val1},
> {foo: val2}) where val1 === val2 (because val1/2 is not serializable, eg it
> has a cycle).
>
>
> Also, what is
>
> var x = 4;
> JSON.isEqual({get foo() { return x++; }}, {foo: 4})
>
> ? If you went purely by "whatever JSON.stringify would return", then this
> would be true once and false afterwards.
>
> This may seem like nitpicking, but if you don't nail down the exact
> semantics, then engines will end up doing the JSON serialization and a
> string compare, which rather defeats the purpose. If you stick to something
> simple like comparing JSON.stringify output, then they will pretty much
> *have* to do this, since there are so many observable side effects like
> getter invocation and proxy traps. You *could* define semantics that cover
> a large percentage of the interesting cases, but JSON isn't going to be of
> much help.
>
> And for the record, JSON does not have an intuitive semantics at all. It
> has intuitive semantics for a small subset of values, a subset that is
> rarely adhered to except near interchange points where JSON makes sense.
> (And even then, it's common to accidentally step outside of it, for example
> by having something overflow to Infinity or accidentally produce a NaN.)
>
> On 05/01/2017 02:04 PM, Alexander Jones wrote:
>
> I hear this argument a lot but it strikes me with cognitive dissonance!
> JSON defines a very intuitive notion of object value-semantics - whether
> the serialized JSON is an equivalent string. Granted that many value types
> are not supported by JSON, but it's a trivial generalisation.
>
> Let's just give the above a name and get on with it. For 99% of use cases
> it would be ideal, no?
>
> Thoughts?
>
> On 1 May 2017 at 20:58, Oriol _ <oriol-bugzi...@hotmail.com> wrote:
>
>> This is not easy to generalize. Comparing objects is one thing lots of
>> people want, but not everybody needs the same kind of comparison.
>> For example, you compare own property strings. But what about symbols?
>> Somebody might consider two objects to be different if they have different
>> symbol properties.
>> Or the opposite, somebody may think that checking enumerable properties
>> is enough, and non-enumerable ones can be skipped.
>> Then some property values might be objects. Are they compared with === or
>> recursively with this algorithm (be aware of cycles)?
>> Similarly, for the [[Prototype]]. Do inherited properties matter? Should
>> [[Prototype]]s be compared with === or recursively?
>> There is also the problem of getters: each time you read a property, it
>> might give a different value! You might want to get the property descriptor
>> and compare the values or the getter functions.
>> And then there are proxies. Taking them into account, I don't think there
>> is any reasonable way to compare objects.
>>
>> So I think it's better if each person writes the code that compares
>> objects according to their needs.
>>
>> --Oriol
>>
>
>
> ___
> 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: Object.isEqual

[Alexander Jones]

I hear this argument a lot but it strikes me with cognitive dissonance!
JSON defines a very intuitive notion of object value-semantics - whether
the serialized JSON is an equivalent string. Granted that many value types
are not supported by JSON, but it's a trivial generalisation.

Let's just give the above a name and get on with it. For 99% of use cases
it would be ideal, no?

Thoughts?

On 1 May 2017 at 20:58, Oriol _  wrote:

> This is not easy to generalize. Comparing objects is one thing lots of
> people want, but not everybody needs the same kind of comparison.
> For example, you compare own property strings. But what about symbols?
> Somebody might consider two objects to be different if they have different
> symbol properties.
> Or the opposite, somebody may think that checking enumerable properties is
> enough, and non-enumerable ones can be skipped.
> Then some property values might be objects. Are they compared with === or
> recursively with this algorithm (be aware of cycles)?
> Similarly, for the [[Prototype]]. Do inherited properties matter? Should
> [[Prototype]]s be compared with === or recursively?
> There is also the problem of getters: each time you read a property, it
> might give a different value! You might want to get the property descriptor
> and compare the values or the getter functions.
> And then there are proxies. Taking them into account, I don't think there
> is any reasonable way to compare objects.
>
> So I think it's better if each person writes the code that compares
> objects according to their needs.
>
> --Oriol
>
>
>
>
> ___
> 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: Re: Strict Relational Operators

[Alexander Jones]

Personally I think `a < b` should just become a compile error if the types
are not number. TypeScript?

If you want to also check that they are both number (that's surely what we
mean here and not that they are both string!) and return `false` if not,
that's a separable concern which should not be part of the operator's
behaviour IMO. It would appear to just mask fundamental typing errors,
unless I am missing some perspective?

Alex

On Wed, 12 Apr 2017 at 09:02, T.J. Crowder 
wrote:

> Grr, there's always something. I forgot to mention that solving this with
> functions is an option because short-circuiting isn't an issue, both
> operands have to be evaluated by these relational operators anyway. So
> unlike the motiviations for infix functions or macros or whatever, we don't
> have that issue here.
>
> -- T.J. Crowder
>
>
> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
> Very interesting stuff so far.
>
> My take on some options, organized into sections:
>
> * Solving it in userland
> * Using symbolic operators
> * Using functions
> * Using non-symbolic operators
>
> # Solving it in userland:
>
> Anyone wanting strict relational operators today can readily give
> themselves functions for it:
>
> ```js
> const lt = (a, b) => typeof a === typeof b && a < b;
> ```
>
> Usage:
>
> ```js
> if (lt(a, b)) {
> // ...
> }
> ```
>
> So the question is whether the value of having a standard way of
> expressing this is worth the cost of adding it?
>
> Playing into that is that various options come with varying costs:
>
> * Using symbolic operators has a cost, but doesn't change fundamentals;
> I'm not an implementer, but I'd think the cost would be fairly low (but
> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax
> changes are now fairly regular occurrences in JavaScript.
> * Using functions means no new syntax, which means not rattling parsing
> cages, and are polyfillable.
> * Using non-symbolic operators rattles cages, and probably more
> significantly than new symbolic ones, and has been rejected in the past
> (`is`/`isnt`).
>
> So that's in the mix.
>
> # Using symbolic operators:
>
> ## Form
>
> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is:
>
> LooseStrict
>  ==   ===
>  !=   !==
>  <<=<
>  >>=>
>  <=   <==
>  >=   >==
>
> We can think of the `=` in the middle as being what signifies the strict
> type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, but a
> reasonable hack that's in the spirit of the original two strict operators.
> :-)
>
> ## Semantics
>
> Because they're like `!==` and `===`, their semantics would have to be in
> line with `!==` and `===`: The result is `true` if the operands are of the
> same type and the relation is true, `false` otherwise.
>
> # Using functions:
>
> ## Form
>
> Given `Object.is(value1, value2)` there's an argument for putting these on
> `Object` as well. But `Object` is an odd place for them (and indeed for
> `is`). Perhaps we need a place for these to go. But sticking with `Object`
> for now:
>
> ```js
> Object.lt(value1, value2)
> Object.gt(value1, value2)
> Object.lte(value1, value2)
> Object.gte(value1, value2)
> ```
>
> So:
>
> ```js
> if (Object.lt(a, b)) {
> // ...
> }
> ```
>
> Verbose, and again, using `Object` if I'm comparing numbers or strings
> seems wrong. But it's consistent with the prior practice of `Object.is`.
>
> Michael J. Ryan suggested putting them on `Number`, `String`, and `Object`
> instead, on the theory that if you're being strict, you know what you're
> comparing. I'm not sure I agree that you do (a generic "take the lower of
> these two" function, for instance), but there's something there. It doesn't
> address the verbosity issue. (Presumably we only need `Number` and `String`
> though, unless we're going to introduce a whole mechanism for relational
> comparison of objects. Or unless the `Object` version just hands off to the
> `Number` or `String` version based on the first operand type.)
>
> ## Semantics
>
> Using functions gives us the opportunity to use slightly different
> semantics:
>
> 1. `true`: The operands are the same type and the relation is true
> 2. `false`: The operands are the same type and the relation is false
> 3. `undefined`: The operands are of different types
>
> This takes advantage of the fact `undefined` is falsy to not get in the
> way of people just using the result in a condition, but if they examine the
> result itself, it's possible to differentiate between #2 and #3.
>
> Sadly, `Object.is` (the exposed version of the SameValue algorithm) does
> not make this distinction.
>
> # Non-symbolic operators
>
> JavaScript already has at least one binary operator that isn't symbolic:
> `in`. Maybe there's a case for adding more. Brendan Eich is [on record](
> 

Re: Proxies fail comparison operator

[Alexander Jones]

I would really hope that `===` can never be trapped. So much code would
break! (Then again, I thought that about toString... :/)

On Fri, 31 Mar 2017 at 15:21, Michael Lewis  wrote:

> Proxies do not reflect internal slots (Oriol)
>
>
>  You really don't *want* proxies to equal their underlying objects:
> proxies can show properties that the underlying object doesn't have, hide
> properties that the underlying object does have, alter the appearance of
> other proxies, etc.  (Alex Vincent)
>
>
> What you really want to ask for is for JavaScript support for overriding
> the comparison operator for a class. (and other operators, too...)
>  (Michael Kriegel)
>
>
>
> Sounds like the purpose of Proxies evades me and unfortunately, I don't
> have time to read up on it, but thanks for the link, Allen.  Any article
> that begins with the word *abstract* scares me.
>
> Yes, Michael, I think *operator traps* for the proxies would be a perfect
> solution.  Then I could let my proxies === my targets, woohoo!
>
> Thanks everyone, great feedback.
>
>
>
>
> On Fri, Mar 31, 2017 at 5:06 AM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
> I agree with everyone, that the proxy object should not equal the proxied
> object.
>
> What you really want to ask for is for JavaScript support for overriding
> the comparison operator for a class. (and other operators, too...)
>
> On 30.03.2017 21:44, Michael Lewis wrote:
>
> I don't believe Proxies are designed to give you any encapsulation to a
> user who also has a reference to the target object
>
>
> So the Proxy wasn't designed to proxy real objects that operate with real
> code?
>
> `myRealFunction(obj)` <---> `myRealFunction(proxy)`
>
> This could be incredibly useful.  You could log every get/set/method call
> on the obj.  And, this *will* work in 99% of use cases.  Just cross your
> fingers that your code doesn't use the comparison operator.
>
> you'd have to never provide the reference to the target object in the
> first place.
>
>
> Yea, that's what I'm doing.  But inside a constructor, you basically have
> to create the proxy first thing, call all initialization logic on the proxy
> instead of `this`, and return the proxy.  And when you're only proxying if
> `log: true` has been set, you have to maybe proxy, but maybe not.  I can
> work around it, but I'm not happy about it ;)
>
> ljharb ftw!  (I am delevoper on IRC, the one frequently ranting about the
> software revolution)
>
> On Thu, Mar 30, 2017 at 1:53 PM, Jordan Harband  wrote:
>
> I don't believe Proxies are designed to give you any encapsulation to a
> user who also has a reference to the target object - you'd have to never
> provide the reference to the target object in the first place.
>
> On Thu, Mar 30, 2017 at 11:50 AM, Michael Lewis  wrote:
>
> Hello community,
>
> The proxy is almost an identical to the underlying object, but it* fails
> a comparison check with the underlying object.*
>
> This means that if anyone gets a reference to the underlying object before
> it is proxied, then we have a problem.  For example:
>
> var obj = {};
> var proxy = new Proxy(obj, {});
> obj == proxy; // false
>
> *Isn't the purpose of the proxy to be exchanged with the original**,
> without any negative side effects?  *Maybe that's not the intended use
> case, but it's a useful one.  And, besides the comparison, I can't think of
> any other "negative side effects".
>
> It seems like the Proxy could have a *comparison trap*.  The comparison
> could pass by default, and you could use the trap if you wanted to make
> `proxy == obj` fail.
>
> Also, a slight tangent: it would be awesome if you could *skip debugging
> proxy traps when stepping through code.  *When you proxy both `get` and
> `apply` for all objects/methods, you have 10x the work when trying to step
> through your code.
>
> I just subscribed to this list.  Is this an appropriate venue for this
> type of inquiry?  I appreciate any feedback.
>
>
>
> Thanks!
>
> Michael
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
> ___
> es-discuss mailing 
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> --
> Michael Kriegel • Head of R • Actifsource AG • Haldenstrasse 1 • CH-6340 
> Baar • www.actifsource.com • +41 56 250 40 02 <+41%2056%20250%2040%2002>
>
>
> ___
> 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: An alternate way of integrating integers

[Alexander Jones]

Not been following this, but given that JSON supports arbitrary precision
*numbers* (that JS cannot decode), not just integers, my hunch is that we
could/should explore this option too!

Python seems to do pretty well (right?) with integers being bignum (and,
aside, all strings being Unicode, magically stored in one of several
representations depending on content), can we do better in JS with all
numbers being arbitrary precision? Or is it simply too much for optimizers
to do well with?

Alex

On 29 March 2017 at 20:44, Axel Rauschmayer  wrote:

> I’ve written a proposal that sketches an alternative to Dan’s proposal. It
> has different pos and cons, so it’s mainly about exploring if there are
> other options.
>
> https://gist.github.com/rauschma/13d48d1c49615ce2396ce7c9e45d4cd1
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> dr-axel.de
>
>
> ___
> 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: Standardizing conditional try/catch

[Alexander Jones]

To be clear I was talking about advanced pattern matching for exception
handling. Y(probably)AGNI?

On Tue, 21 Mar 2017 at 05:08, Isiah Meadows <isiahmead...@gmail.com> wrote:

> It's possible to add a "[No LineTerminator here]" constraint when
> necessary, as was done for async functions.
>
> As for pattern matching, if you start paying attention to features of
> newer programming languages, especially those just getting past their
> hype stage (like Kotlin, Rust, and Swift), that YAGNI argument is
> starting to seem harder to accept.
>
> Pattern matching is to conditionals as async/await is to async tasks -
> it lifts the logic from fairly imperative, low level form to a high
> level, declarative form, with only a small loss of low-level control.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <a...@weej.com> wrote:
> > Any future matching syntax would clearly support the special cases people
> > want to codify now. It might be that the best possible syntax is lost,
> but
> > e.g. ASI alone is probably a much bigger cause of syntax showstoppers to
> be
> > worried about. IMO, let it build up, then we can start thinking about a
> > syntax overhaul another day. The chances are that We Ain't Gonna Need It.
> >
> > On 19 March 2017 at 22:47, kdex <k...@kdex.de> wrote:
> >>
> >> But then, we might be adding new syntax twice to solve the same problem.
> >> First specifically, then generally. The latter likely using an entirely
> >> different syntax, making the former syntax obsolete.
> >> Why not start speccing out some details for an optional typing proposal
> >> instead, so we can get the ball rolling for true pattern matching?
> >>
> >> On Sunday, March 19, 2017 11:18:25 PM CET Zach Lym wrote:
> >> > >
> >> > > I read that TC39 agreed on adding pattern matching to language in
> >> > > March
> >> > > 2013. 4 years later we don't have even stage 0 proposal - so I would
> >> > > consider it to be a dead end or wishful thinking.
> >> > >
> >> >
> >> > Exactly, this proposal has been kicking around for ~15 years but keeps
> >> > getting deferred in favor of "something better."  I would be all for a
> >> > special syntax using type hints or targeting easier-to-optimize
> subsets,
> >> > but they can be added later.
> >> >
> >> > This proposal introduces the minimum number of features needed to
> handle
> >> > the dynamic nature of JS.
> >> >
> >> > Thank you,
> >> > -Zach Lym
> >> >
> >> > On Sun, Mar 19, 2017 at 8:23 AM, kdex <k...@kdex.de> wrote:
> >> >
> >> > > Well, there has been some discussion of potentially adding something
> >> > > like
> >> > > static type hints at some point in the future.
> >> > > Pattern matching is a feature that inevitably requires type
> >> > > information at
> >> > > runtime.
> >> > >
> >> > > So as long as the "optional typing" story isn't dead, I would assume
> >> > > that
> >> > > pattern matching isn't quite dead either, it's just not in the
> >> > > currently
> >> > > possible scope of things.
> >> > > ECMAScript wouldn't be the only language which would have taken
> years
> >> > > to
> >> > > come around to implementing type hinting: IIRC Python got its type
> >> > > hinting
> >> > > feature pretty late, too.
> >> > >
> >> > > On Sunday, March 19, 2017 4:22:26 PM CET Michał Wadas wrote:
> >> > > > Is there a serious push to add pattern matching to language? Does
> >> > > > any
> >> > > > popular dynamically typed language have pattern matching?
> >> > > > I read that TC39 agreed on adding pattern matching to language in
> >> > > > March
> >> > > > 2013. 4 years later we don't have even stage 0 proposal - so I
> would
> >> > > > consider it to be a dead end or wishful thinking.
> >> > > >
> >> > > > On Sat, Mar 18, 2017 at 5:16 PM, kdex <k...@kdex.de> wrote:
> >> > > >
> >> > > > > I'm not sure if embedding this idea into the language will make
> >> > > > > future
> >> > > > > ideas about true pattern

Re: Standardizing conditional try/catch

[Alexander Jones]

Any future matching syntax would clearly support the special cases people
want to codify now. It might be that the best possible syntax is lost, but
e.g. ASI alone is probably a much bigger cause of syntax showstoppers to be
worried about. IMO, let it build up, then we can start thinking about a
syntax overhaul another day. The chances are that We Ain't Gonna Need It.

On 19 March 2017 at 22:47, kdex  wrote:

> But then, we might be adding new syntax twice to solve the same problem.
> First specifically, then generally. The latter likely using an entirely
> different syntax, making the former syntax obsolete.
> Why not start speccing out some details for an optional typing proposal
> instead, so we can get the ball rolling for true pattern matching?
>
> On Sunday, March 19, 2017 11:18:25 PM CET Zach Lym wrote:
> > >
> > > I read that TC39 agreed on adding pattern matching to language in March
> > > 2013. 4 years later we don't have even stage 0 proposal - so I would
> > > consider it to be a dead end or wishful thinking.
> > >
> >
> > Exactly, this proposal has been kicking around for ~15 years but keeps
> > getting deferred in favor of "something better."  I would be all for a
> > special syntax using type hints or targeting easier-to-optimize subsets,
> > but they can be added later.
> >
> > This proposal introduces the minimum number of features needed to handle
> > the dynamic nature of JS.
> >
> > Thank you,
> > -Zach Lym
> >
> > On Sun, Mar 19, 2017 at 8:23 AM, kdex  wrote:
> >
> > > Well, there has been some discussion of potentially adding something
> like
> > > static type hints at some point in the future.
> > > Pattern matching is a feature that inevitably requires type
> information at
> > > runtime.
> > >
> > > So as long as the "optional typing" story isn't dead, I would assume
> that
> > > pattern matching isn't quite dead either, it's just not in the
> currently
> > > possible scope of things.
> > > ECMAScript wouldn't be the only language which would have taken years
> to
> > > come around to implementing type hinting: IIRC Python got its type
> hinting
> > > feature pretty late, too.
> > >
> > > On Sunday, March 19, 2017 4:22:26 PM CET Michał Wadas wrote:
> > > > Is there a serious push to add pattern matching to language? Does any
> > > > popular dynamically typed language have pattern matching?
> > > > I read that TC39 agreed on adding pattern matching to language in
> March
> > > > 2013. 4 years later we don't have even stage 0 proposal - so I would
> > > > consider it to be a dead end or wishful thinking.
> > > >
> > > > On Sat, Mar 18, 2017 at 5:16 PM, kdex  wrote:
> > > >
> > > > > I'm not sure if embedding this idea into the language will make
> future
> > > > > ideas about true pattern matching harder to implement or not.
> > > > > Destructuring assignments are pretty slow from what I've measured,
> and
> > > > > they still made it in, so I hardly see performance being a
> showstopper
> > > here.
> > > > >
> > > > > On Saturday, March 18, 2017 12:18:22 PM CET Michael J. Ryan wrote:
> > > > > > The if condition doesn't need to be limited to instance of...
> > > > > >
> > > > > > catch (err if !isNaN(err.status))
> > > > > >
> > > > > > Aside: entering code in a phone is hard...
> > > > > >
> > > > > > > `instanceof` doesn't work across realms (iframes, for
> example). If
> > > we
> > > > > > > introduced conditional catch blocks, I'd want a more reliable
> > > matching
> > > > > > > mechanism than instanceof.
> > > > > > >
> > > > > > > On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym <
> zach...@indolering.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> Firefox supports the following conditional `catch` syntax:
> > > > > > >>
> > > > > > >> try {
> > > > > > >> let result = await ();
> > > > > > >> } catch (e if e instanceof ErrorType) {
> > > > > > >> ...
> > > > > > >> }
> > > > > > >>
> > > > > > >>
> > > > > > >> This was originally implemented in Spidermonkey as part of an
> ES
> > > > > proposal
> > > > > > >> around 2000, but it was rejected for unknown reasons [0]. A
> 2012
> > > > > email to
> > > > > > >> this list suggesting standardization of the syntax was passed
> > > over in
> > > > > favor
> > > > > > >> of waiting for a generic pattern matching facility [0][1].
> Later
> > > > > > >> discussion suggests that the pattern matching proposal would
> have
> > > > > been very
> > > > > > >> slow [2]. A proposal for a Java-like type-based conditional
> was
> > > > > proposed in
> > > > > > >> 2016, but was criticized for lacking generality [2].
> > > > > > >>
> > > > > > >> If the above summary is accurate, I would like to try to
> > > standardize
> > > > > the
> > > > > > >> vanilla syntax once again.  It's imperative, general, and
> doesn't
> > > > > preclude
> > > > > > >> the use of any hypothetical pattern matching functionality.
> > > > > > >>
> > > > > > >> Javascript's control flow has improved 

Re: Enable async/await to work on functions that don't just return promises.

[Alexander Jones]

Required reading for anyone who wants to be so... opinionated ;)

http://joeduffyblog.com/2015/11/19/asynchronous-everything/

On Sun, 26 Feb 2017 at 16:35, Florian Bösch  wrote:

> On Sun, Feb 26, 2017 at 5:30 PM, Codefined 
> wrote:
>
> I'll be interested to see what you guys consider the
> advantages/disadvantages of this method, which I hope to be "the middle
> between two ends" on whether to go fully into promises or fully into
> co-routines.  Neither of which are in my opinion the optimal stance.
>
>
> Hereabouts nobody's going to either full co-routines or even semi-implicit
> co-routines. But JS doesn't matter, just compile to asm.js/WebAssembly or
> write a bytecode engine atop JS etc. from a language that actually solves
> concurrent programming well and isn't a hodgepodge of missed opportunities.
> ___
> 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: Enable async/await to work on functions that don't just return promises.

[Alexander Jones]

Florian, you shouldn't pass the argument of explicit vs implicit coroutines
off as being so simple. There are many compelling arguments for both!
Please Google them!


On Sun, 26 Feb 2017 at 00:01, Florian Bösch  wrote:

> On Sat, Feb 25, 2017 at 11:55 PM, Codefined 
> wrote:
>
> This seems to be so very confusing for anybody new studying this language,
> almost everyone I talk to gets stuck up on some part of it.
>
> Promises are bad, and mixing them with async/await is worse. Should never
> have been added to any kind of standard.
>
> async function asyncFunction() {let [err, data] = await asyncFunction()
> }
>
> function asyncFunction(){
>   return otherAsyncFunction();
> }
>
> Even simpler, you'd just need co-routines.
> ___
> 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: name anonymous functions on property assignments

[Alexander Jones]

Just for a bit of context, can you elaborate on how this broke your code?
Thanks

On 27 January 2017 at 16:56, Jordan Harband  wrote:

> I'd have an objection. Function name inference has already broken my code
> - luckily only tests so far, that i know of - and doing it more often would
> break more of it.
>
> On Fri, Jan 27, 2017 at 7:26 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> Two questions on the minor issue of the following not assigning a name
>> to the function:
>>
>> ```js
>> obj.foo = function() { };
>> ```
>>
>> 1) Am I correct that the only reason it doesn't (in spec terms) is
>> that Step 1.e. of [Runtime Semantics:
>> Evaluation](https://tc39.github.io/ecma262/#sec-assignment-
>> operators-runtime-semantics-evaluation)
>> reads
>>
>> > If IsAnonymousFunctionDefinition(AssignmentExpression) and
>> IsIdentifierRef of LeftHandSideExpression are both true, then
>>
>> and that changing that to
>>
>> > If IsAnonymousFunctionDefinition(AssignmentExpression) is true and
>> either IsIdentifierRef of LeftHandSideExpression is true or
>> IsPropertyReference of LeftHandSideExpression is true, then
>>
>> would mean it would assign the name `foo`? (The subsequent step
>> getting the name to use already uses GetReferencedName, which works
>> for property references as well as identifier references.)
>>
>> 2) Are there any objections to closing this gap in how function names
>> are assigned?
>>
>> -- T.J.
>> ___
>> 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: Idea: Reflect.hasExternalReference

[Alexander Jones]

Some sort of formal way for a method to accept an immutable map, and
perhaps silently convert from a mutable object if passed one.

Using a prototype chain to get 'copy on write' style sharing is really a
poor man's equivalent to a HAMT IMO.

Honestly, not sure how we get from here to there, but exposing reference
count in any way seems dubious to me!

Alex

On Sun, 15 Jan 2017 at 16:25, T.J. Crowder <tj.crow...@farsightsoftware.com>
wrote:

> I'm assuming that Alexander Jones means that you'd document you require an
> immutable, and thus not need to check, and just happily use it. (Ideally,
> syntax would enforce it.) But it's for him to say, don't want to put words
> in anyone's mouths.
>
> But if you need to merge options (as in your `setup` example), I'm not
> sure immutability helps, as it wouldn't prevent creating a new object
> (presumably you can't `setPrototypeOf` an existing immutable object) unless
> you changed the option lookup operation to be a function that first checks
> the immutable and then the defaults, trading lookup time for memory churn
> savings...
>
> FWIW, rather than having a check for outstanding references, perhaps
> something akin to the transfer concept used by web workers, where the
> receiver explicitly takes ownership of the object, and the sender's
> reference becomes invalid... Then you could just fill in missing options
> with defaults and not have to use `setPrototypeOf` (or you could if you
> preferred)... Hmmm
>
> -- T.J.
>
>
>
>
> On Sun, Jan 15, 2017 at 2:41 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> That means the receiver has to check if the object is immutable but
> there's no way to setup the prottypal inheritance at that point, right?
>
> That is the main point I've made, and for Netflix was a merge boost from
> 500ms to 60ms.
>
> They simlpy do `Object.setPrototypeOf(newState, currentState)` internally,
> but not a single library author that knows upfront if such object can be
> manipulated as such because there's no way to tell if it was unreferenced
> (aka: 0 side effects)
>
> If immutable can have mutated its `__proto__` then I'm OK with new syntax
> as long as `Reflect.isMutable` is available since a method, internally,
> wouldn't know which syntax has been used to send that argument.
>
>
>
> On Sun, Jan 15, 2017 at 2:26 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
> I think the point is that immutability syntax would apply to the use case
> you've described, because if the object passed is immutable, it doesn't
> matter whether the sender has a reference to it or not. The receiver can
> use it without caring, and without making a defensive copy, since it's
> immutable.
>
> -- T.J.
>
>
> On Sun, Jan 15, 2017 at 2:20 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> I am not following. The object is immutable from their side, because
> they'll never be able to even access it since it's not referenced.
>
> New syntax wouldn't solve anything I've talked about.
>
> Have I misunderstood you?
>
> On Sun, Jan 15, 2017 at 12:51 PM, Alexander Jones <a...@weej.com> wrote:
>
> IMO we should explore generalising syntax for map literals and object
> destructuring, bringing something like Immutable.Map into the spec, and
> thus bringing JS into a new modern era.
>
> Otherwise people who care about this stuff will just continue to move to
> other languages like ClojureScript in order to get the expressivity and
> safety they want!
>
> On Sun, 15 Jan 2017 at 10:34, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> I am not sure how feasible this concept is, and I'll start just with the
> pattern it's useful for.
>
> ```js
> someRef.setup({
>   one: 'or more',
>   runtime: 'definition'
> });
> ```
> In JS user-land, the amount of unnecessary duplicated objects is
> embarrassing.
>
> We all know that immutability is great and we all know that functions
> should never mutate received arguments, but there is absolutely zero side
> effect in modifying, changing, erasing, you name it, an object passed like
> the one in that `.setup({...})`
>
> As of today, basically every method used to setup one-off objects will use
> one of the following techniques:
>
>   * a shallow copy via `Object.create(Object.getPrototypeOf(options),
> Object.getOwnPropertyDescriptors(options))`
>   * an enumerable only copy via `Object.assign({}, options)`, probably
> more common but yet, most of the time, practically unnecesary
>
> Things become even more difficult to improve when it comes to simply
> chaining objects together, where it's not possible to simply define the
>

Re: Idea: Reflect.hasExternalReference

[Alexander Jones]

IMO we should explore generalising syntax for map literals and object
destructuring, bringing something like Immutable.Map into the spec, and
thus bringing JS into a new modern era.

Otherwise people who care about this stuff will just continue to move to
other languages like ClojureScript in order to get the expressivity and
safety they want!

On Sun, 15 Jan 2017 at 10:34, Andrea Giammarchi 
wrote:

> I am not sure how feasible this concept is, and I'll start just with the
> pattern it's useful for.
>
> ```js
> someRef.setup({
>   one: 'or more',
>   runtime: 'definition'
> });
> ```
> In JS user-land, the amount of unnecessary duplicated objects is
> embarrassing.
>
> We all know that immutability is great and we all know that functions
> should never mutate received arguments, but there is absolutely zero side
> effect in modifying, changing, erasing, you name it, an object passed like
> the one in that `.setup({...})`
>
> As of today, basically every method used to setup one-off objects will use
> one of the following techniques:
>
>   * a shallow copy via `Object.create(Object.getPrototypeOf(options),
> Object.getOwnPropertyDescriptors(options))`
>   * an enumerable only copy via `Object.assign({}, options)`, probably
> more common but yet, most of the time, practically unnecesary
>
> Things become even more difficult to improve when it comes to simply
> chaining objects together, where it's not possible to simply define the
> prototype of the received object, throwing away a performance boost
> possibility like the one Netfilx recently had [1]
>
> Shortcutting and destructuring also makes the usage of one-off literals
> great, and states are the most basic, yet common, example.
>
> ```js
> component.setState({
>   label,
>   user,
>   time: Date.now()
> });
> ```
>
> ## Back to the Reflect.hasExternalReference idea
>
> Within the hypothetical `.setState(...)` method, invoking
> `Reflect.hasExternalReference` would return `true` it the object was passed
> as literal, without any possible external reference.
>
> ```js
> class Component {
>   setState(state) {
> this.state = Reflect.hasExternalReference(state) ?
>   Object.assign({}, this.state, state) :
>   Object.setPrototypeOf(state, this.state);
> // update only differences
> this.render(Object.keys(state));
>   }
> }
> ```
> If there was a way to know passed literals, I am sure a lot of software
> could automatically boost performance:
>
>   * less polluted GC
>   * more recycled one-off objects
>   * less need to copy/clone over and over one-off literals that couldn't
> be mutate anywhere else anyway
>
> What do you think? Does any of this make sense?
>
> Best Regards
>
>
>
>
> [1]
> http://techblog.netflix.com/2017/01/crafting-high-performance-tv-user.html
>
>
>
>
>
> ___
>
> 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: Improve syntax for inline anonymous class instantiations

[Alexander Jones]

Hi Igor

With `super()` and closure binding of the anonymous class `constructor` (as
with all class methods) you can basically solve your problem of constructor
arguments appearing in the wrong place:

```
this.add(
new class extends ArrayView {
constructor() { super("items", itemsModel); }
populateItem(item) {
item.add(new Checkbox("check", new PropertyModel(item.model,
"done")));
item.add(new Label("title", new PropertyModel(item.model,
"title")));
}
}
);
```

I concede that spelling `constructor`, `super`, and the various soup of
punctuation is a little less than ideal, but at the end of the day I think
this is quite reasonable, don't you?

Cheers

Alex

On 6 January 2017 at 22:11, Igor Vaynberg  wrote:

> Given a simple class with an abstract method "populateItem"
>
> class ArrayView extends Container {
> constructor(id, model) {
> super(id);
> this.model = model;
> }
>
> // methods referencing "populateItem" omitted for clarity
> }
>
> the current anonymous instantiation syntax looks like this:
>
> this.add(new class extends ArrayView {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> }
> ("items", itemsModel)
> );
>
> The problem with this syntax is that it pushes the constructor
> parameters below the class body which I think causes two problems:
>
> When scanning code constructors often contain the piece of information
> that helps locate the anonymous class, which currently requires the
> developer to look back. This is especially problematic for anonymous
> classes with long class bodies.
>
> When writing code I usually think about the constructor first, so it
> seems it would be preferable to write it before moving onto working on
> the class body. This is also the reason why constructors are usually
> placed toward the top of named classes' source.
>
> A better syntax would move the constructor parameters between the
> super class name and the class body:
>
> this.add(new class extends ArrayView("items", itemsModel) {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> });
>
> If possible it would also be great to get rid of the "class extends"
> keywords for this usecase:
>
> this.add(new ArrayView("items", itemsModel) {
> populateItem(item) {
> item.add(new Checkbox("check", new PropertyModel(item.model,
> "done")));
> item.add(new Label("title", new PropertyModel(item.model,
> "title")));
> }
> });
>
> Thoughts?
>
>
> Thanks,
> -igor
> ___
> 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: Weak Reference proposal

[Alexander Jones]

Please correct me Isiah/Steve - but I think the problem Steve is talking
about is *cross-process* cycles. Without an inter-process protocol to
express the referencing graph, or otherwise negotiate cycles for GC, you'll
never have a way to reclaim them. Each side thinks the other side is still
needing the resource.

Cheers

On 31 December 2016 at 13:48, Isiah Meadows  wrote:

> For my particular case, yes it is. Everything mirrored have globally
> unique IDs assigned to them, managed independently of the child
> process (in most cases), and the state is tied to the ID, not the
> value, so I only need a weak reference to clear the backing ID and its
> associated state. And reference cycles within the process are
> mitigated by the existing mark-and-sweep derivatives engines already
> use.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink  wrote:
> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
> >
> > The weak reference proposal hasn't seen a lot of activity, and I haven't
> > found much news elsewhere on it. What's the status on it?
> >
> > Where I'm building a language-integrated process pool in Node.js,
> complete
> > with shared "references" and async iterator support, I really badly need
> > weak references to avoid otherwise inevitable memory leaks across
> multiple
> > processes if the references aren't explicitly released. So far, my only
> > option is to take a native dependency (I have no other dependencies), but
> > that's very suboptimal, and it eliminates the possibility of porting to
> > browsers. So I really badly need language-level weak references.
> >
> >
> > Would weak references be enough to solve cross-process garbage
> collection?
> > How would you recover a cycle of references among your processes?
> >
> >
> > ___
> > 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: Immutable const?

[Alexander Jones]

IMO we should unblock anything that stands in the way of ergonomics when
using new product type types, other than Object. If I can write code using
Immutable.Map as succinctly as I can Object then we're half way there. See
https://esdiscuss.org/topic/map-literal for discussion on generalized map
and list literals.

Formalizing things like object spread and destructuring to work on other
types would be important, too.

Then, who knows, in ES2019 we might adopt Immutable or something like it
into the core library...

On Wed, 9 Nov 2016 at 04:36, jeremy nagel  wrote:

> Just realised this is probably covered by the frozen realms proposal:
> https://github.com/FUDCo/proposal-frozen-realms
>
> Jeremy Nagel
>
> On Wed, Nov 9, 2016 at 11:33 AM, jeremy nagel 
> wrote:
>
> Ok I may have been misusing terminology. What I mean is more of a deeply
> frozen object along the lines of what happens with
> https://www.npmjs.com/package/deep-freeze
>
> The argument for it would be that we've had quite a few bugs where other
> modules have modified an instance of an object that gets passed around. We
> now often deep clone parameters at the start of methods to avoid this
> happening. Would be nicer if deep clone was not required as that has a
> performance hit.
>
> Edge cases where custom getters or setters could be avoided by throwing an
> error if someone attempted to do `frozen/final/whateverTheTermWouldBe
> someComplexObjWithGetters = ...`
>
> Jeremy Nagel
> 0414 885 787
>
>
>
> On Wed, Nov 9, 2016 at 4:58 AM, Isiah Meadows 
> wrote:
>
> JS doesn't have immutable types, which is why `Object.freeze` simply says
> "don't change this object's own properties". Frozen objects make for nice
> enumerated types, but JS has no notion of immutability. Additionally, you
> have to take into account the internal slots, which freezing objects has no
> effect on (it only has an effect with the internal `object.[[Get]]` and
> `object.[[Set]]` methods).
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
>
> On Tue, Nov 8, 2016 at 8:57 AM, Reinis Ivanovs  wrote:
>
> This idea sounds like having a version of the `const` keyword that also
> freezes objects, but that's a far cray from what Immutable.js does, which
> is about persistent data and collection methods. Freezing also doesn't work
> on things that use mutator methods like Map or Set, so it'd be confusing.
>
> On Tue, Nov 8, 2016 at 7:30 AM, jeremy nagel 
> wrote:
>
> Hi,
> was just chatting to colleagues about the utility of *const*. The fact
> that it doesn't actually lead to immutable objects or arrays seems to make
> it a bit toothless and misleading. Are there any proposals to have an
> immutable version of const? I know you could use ImmutableJS but it would
> be nice to have this part of the language.
>
> Perhaps the keyword could be *final*.
>
> cheers,
> Jeremy
>
>
>
> ___
>
>
> 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

[Alexander Jones]

IMO this is quite unnecessary syntax sugar. Python has everything you could
need here without special syntax.

On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:

> While slightly more verbose, the previously suggested `...` syntax does
> have a superficial consistency with the spread operator. Both perform an
> expansion of sorts, which has a subtle elegance to it, IMO.
>
> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
> oao.hikaru@gmail.com> wrote:
>
> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>
> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
> any kind of backwards incompatibility in new specs and trying to get this
> to stage 4 with such a glaring one would be practically  impossible.
>
>
> It's not just the incompatibility either.  You also introduce an
> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>
>
> When you consider these things, it becomes clear that it's not practical
> to change the language this way for such a small benefit.
>
>
>
> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
> wrote:
>
> Oh, I understood it.
> It looks like serious problem, but it is may not actually.
> If this spec change doesn't break web, we can introduce this idea?
>
>
> ___
>
>
> 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
>
>
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
>
>
>
> ___
>
> 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: Object.equals() and Object.clone()

[Alexander Jones]

Object has this unfortunate complication of prototypes, i.e.:

```
const objA = {foo: 1, bar: 2};
const objB = Object.create(objA);
equals(objA, objB) === ?
```

And also there is metadata on each property that can vary (one object has a
property which is configurable, and the other has the same property which
is not configurable), and raise similar questions.

Neither of these questions exist on ES's Map type, or Immutable.js's Map
and List types, for example.

IMO we should be looking at ways to make those types more suitable for many
of the use cases of Object.

On 15 November 2016 at 01:25, Kevin Barabash  wrote:

> It would be nice if deep equality checking and deep cloning of objects was
> included in the standard library.  Has there been any proposals around
> including these in the past?
>
> – Kevin
>
>
> ___
> 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: Symbol.templateTag

[Alexander Jones]

As promised (to myself!) I've written a stage-0.

https://github.com/alex-weej/es-symbol-template-tag

Your feedback is greatly appreciated.

Thanks

On 18 November 2016 at 00:30, Alexander Jones <a...@weej.com> wrote:

> OK, I was thinking about this incorrectly and I think you're right - it
> doesn't Break The Web. It's exactly the same as when @@isConcatSpreadable
> and @@toStringTag were introduced, as far as I can tell.
>
> If no-one has any obvious objections to save me the effort, I'll try to
> write up a stage 0 this weekend.
>
> Thanks
>
>
>
> On 17 November 2016 at 04:58, Mark S. Miller <erig...@google.com> wrote:
>
>> Hi Alexander, I have run into this myself. It is a real problem, and I
>> like the nature of your proposed solution. But I don't understand how it
>> might break the web. If Symbol.templateTag is a new symbol, guaranteed
>> unequal to any prior value, how can introducing it, and new behavior
>> conditional on it, change any existing behavior?
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 5:02 PM, Alexander Jones <a...@weej.com> wrote:
>>
>>> Hi es-discuss!
>>>
>>> Template tags are a great feature with many novel applications, IMO
>>> approaching macro-level expressiveness. But due to their nature in this
>>> context, it's helpful if tags are named quite tersely. Unfortunately, if
>>> you have existing API, this can be challenging.
>>>
>>> Let's say I have a DSL (domain-specific language), and I *may*,
>>> unsafely, generate typed snippets of code containing that DSL like so:
>>>
>>> ```js
>>> function dsl(code: string) {
>>> // `code` MUST be well-formed
>>> }
>>>
>>> const someStatement = dsl("val foo = " + dslEncode(foo));
>>> ```
>>>
>>> Let's say I'd like to add support in my library for ES6 clients such
>>> that they can do:
>>>
>>> ```js
>>> const someStatement = dsl`val foo = ${foo}`;
>>> ```
>>>
>>> where the `dsl` template tag would be implemented such that `dslEncode`
>>> is used on each interpolated expression.
>>>
>>> Unfortunately, the `dsl` function's arguments are already defined and
>>> can't be changed. I'd need a new name, like `dsl.tag`, which would end up
>>> being a fair bit more verbose.
>>>
>>> Would it be possible, at this point, to introduce a new behaviour into
>>> ES such that instead of merely calling the tag object, the implementation
>>> first checks for a `Symbol.templateTag` property on the tag object, and if
>>> it exists, it is invoked? I'd guess this can't Break The Web because no-one
>>> can realistically be using an existing function as a template tag if it was
>>> not already designed for it.
>>>
>>> ```js
>>> const someStatement = dsl`val foo = ${foo}`;
>>> // desugars to, approximately
>>> const someStatement = (dsl[Symbol.templateTag] || dsl)(["val foo =",
>>> ""], foo);
>>> ```
>>>
>>> To be honest, I am kind of surprised it wasn't already implemented like
>>> this, but maybe there were performance concerns with the branching.
>>> Interested in your thoughts.
>>>
>>> Thanks
>>>
>>> Alex
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Symbol.templateTag

[Alexander Jones]

OK, I was thinking about this incorrectly and I think you're right - it
doesn't Break The Web. It's exactly the same as when @@isConcatSpreadable
and @@toStringTag were introduced, as far as I can tell.

If no-one has any obvious objections to save me the effort, I'll try to
write up a stage 0 this weekend.

Thanks



On 17 November 2016 at 04:58, Mark S. Miller <erig...@google.com> wrote:

> Hi Alexander, I have run into this myself. It is a real problem, and I
> like the nature of your proposed solution. But I don't understand how it
> might break the web. If Symbol.templateTag is a new symbol, guaranteed
> unequal to any prior value, how can introducing it, and new behavior
> conditional on it, change any existing behavior?
>
>
>
>
> On Wed, Nov 16, 2016 at 5:02 PM, Alexander Jones <a...@weej.com> wrote:
>
>> Hi es-discuss!
>>
>> Template tags are a great feature with many novel applications, IMO
>> approaching macro-level expressiveness. But due to their nature in this
>> context, it's helpful if tags are named quite tersely. Unfortunately, if
>> you have existing API, this can be challenging.
>>
>> Let's say I have a DSL (domain-specific language), and I *may*, unsafely,
>> generate typed snippets of code containing that DSL like so:
>>
>> ```js
>> function dsl(code: string) {
>> // `code` MUST be well-formed
>> }
>>
>> const someStatement = dsl("val foo = " + dslEncode(foo));
>> ```
>>
>> Let's say I'd like to add support in my library for ES6 clients such that
>> they can do:
>>
>> ```js
>> const someStatement = dsl`val foo = ${foo}`;
>> ```
>>
>> where the `dsl` template tag would be implemented such that `dslEncode`
>> is used on each interpolated expression.
>>
>> Unfortunately, the `dsl` function's arguments are already defined and
>> can't be changed. I'd need a new name, like `dsl.tag`, which would end up
>> being a fair bit more verbose.
>>
>> Would it be possible, at this point, to introduce a new behaviour into ES
>> such that instead of merely calling the tag object, the implementation
>> first checks for a `Symbol.templateTag` property on the tag object, and if
>> it exists, it is invoked? I'd guess this can't Break The Web because no-one
>> can realistically be using an existing function as a template tag if it was
>> not already designed for it.
>>
>> ```js
>> const someStatement = dsl`val foo = ${foo}`;
>> // desugars to, approximately
>> const someStatement = (dsl[Symbol.templateTag] || dsl)(["val foo =", ""],
>> foo);
>> ```
>>
>> To be honest, I am kind of surprised it wasn't already implemented like
>> this, but maybe there were performance concerns with the branching.
>> Interested in your thoughts.
>>
>> Thanks
>>
>> Alex
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Symbol.templateTag

[Alexander Jones]

Hi es-discuss!

Template tags are a great feature with many novel applications, IMO
approaching macro-level expressiveness. But due to their nature in this
context, it's helpful if tags are named quite tersely. Unfortunately, if
you have existing API, this can be challenging.

Let's say I have a DSL (domain-specific language), and I *may*, unsafely,
generate typed snippets of code containing that DSL like so:

```js
function dsl(code: string) {
// `code` MUST be well-formed
}

const someStatement = dsl("val foo = " + dslEncode(foo));
```

Let's say I'd like to add support in my library for ES6 clients such that
they can do:

```js
const someStatement = dsl`val foo = ${foo}`;
```

where the `dsl` template tag would be implemented such that `dslEncode` is
used on each interpolated expression.

Unfortunately, the `dsl` function's arguments are already defined and can't
be changed. I'd need a new name, like `dsl.tag`, which would end up being a
fair bit more verbose.

Would it be possible, at this point, to introduce a new behaviour into ES
such that instead of merely calling the tag object, the implementation
first checks for a `Symbol.templateTag` property on the tag object, and if
it exists, it is invoked? I'd guess this can't Break The Web because no-one
can realistically be using an existing function as a template tag if it was
not already designed for it.

```js
const someStatement = dsl`val foo = ${foo}`;
// desugars to, approximately
const someStatement = (dsl[Symbol.templateTag] || dsl)(["val foo =", ""],
foo);
```

To be honest, I am kind of surprised it wasn't already implemented like
this, but maybe there were performance concerns with the branching.
Interested in your thoughts.

Thanks

Alex
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Alexander Jones]

+1000

Classic feature creep with basically zero application.

On Thursday, 3 November 2016, Isiah Meadows  wrote:

> Could we just *not* have a `String.range`?
>
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
>
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall  > wrote:
>
>> 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 > >:
>>
>>> 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 >> >:
>>>
 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 >:
 >
 > > 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 <
 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
 > > > > 

Re: Proposal: Array.prototype.accumulate and Array.prototype.accumulateRight

[Alexander Jones]

Can we please start talking about Iterators already? The Python community
are laughing at us! Widening the Array prototype is like putting lipstick
on a pig...

On Thursday, 27 October 2016, Bergi  wrote:

> Mark M. Young wrote:
>
>> I am proposing a replacement for Array.prototype.reduce and
>> Array.prototype.reduceRight.
>>
>
> Nice. Allowing to pass an argument for the `this` value was missing when
> folding an array, and your suggestion `accumulate` is a fitting method name.
>
> However, I fear the use cases are too unimportant to need a fix.
> The `this` keyword is becoming less and less used for anything but class
> methods. And for those, arrow functions solve the problem needing to invoke
> functions on the expected receiver.
> For passing in data to a reusable reducer function, closures are much
> simpler than setting the `this` value for the callback.
>
> https://github.com/MarkMYoung/ArrayAccumulate <
> https://github.com/MarkMYoung/ArrayAccumulate> says
>
>> `reduce` is not reusable code because there is no way to know what the
>> second parameter was once beyond the first iteration.
>>
>
> That makes no sense. The whole point of the initial value parameter is
> that it only goes into the first call (if any), or is the return value in
> case the array is empty.
>
> the second parameter is always available as `this`.
>>
>
> It really should not be. If you want to pass a value for `this`, it needs
> a third parameter.
>
> kind regards,
>  Bergi
> ___
> 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: Symbol description inference

[Alexander Jones]

IMO, the real problem that needs solving is macros. Macro-based definition
of a symbol could trivially reuse the name.

On Tuesday, 25 October 2016, Allen Wirfs-Brock 
wrote:

> Function name inferencing is possible because function definitions are all
> syntactic special forms that can be unambiguously identified during parsing.
>
> Symbols creation is just a function call so there is no way to reliably
> detect it.  `Symbol` might aliased to some other name by assignment, a
> different value other than the Symbol creation function might be assigned
> to the global `Symbol`, or some alternative declaration of `Symbol` might
> be in some at the point of use.
>
> Allen
>
> ___
> 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: JSON.stringify

[Alexander Jones]

Maybe we should just make U+2028 and U+2029 valid in JS then? What other
productions in JSON are invalid syntax in JS?

On Thursday, 29 September 2016, Mike Samuel  wrote:

> On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla
> > wrote:
> >> ECMAScript, while highly used in web browsers, should really not care
> >> about HTML constructs. That's where WHATWG and W3C come in. I suggest
> this
> >> type of feature should come from one of those groups, not ECMA.
> >
> > That applies to escaping things like `` or `]]>`, and I agree.
> But
> > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are
> not
> > valid JS expressions. I think it would make sense for `JSON.stringify` to
> > escape these.
>
> What is it that you're saying is not in TC-39's bailiwick?
>
> Is it that w3c/whatwg should define what constitutes "embeddable JSON"?
>
> Or is it that if it's worth defining a function that produces
> embeddable JSON from an EcmaScript object, that w3c/whatwg should
> include that in some set of EcmaScript APIs that it defines?
>
> If you agree with my earlier claim
> """
> We're talking about JSON serializers.  Every serializers produces
> a subset of the output language. Choices about that sublanguage affect
> how easy/hard it is to use that serializer with other tools.
> """
> then it seems that TC-39 might take embeddability into account when
> crafting the subset of JSON that JSON.stringify produces.
> ___
> 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: JSON.stringify

[Alexander Jones]

In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But
the end token has to be escaped, as discussed. Despite this escaping, the
text node can contain arbitrary strings.

In XHTML, you *can* achieve the same effect without CDATA, just by escaping
XML entities. Again, and cruciallt, the text node can contain arbitrary
strings.

In HTML without CDATA, using HTML entities within the script tag is wrong
specifically because they are *not* interpreted. The text node in the HTML
document CANNOT contain arbitrary strings, and there is no further decode
step before the JS parser hits your code, so you're forced to take other
measures to ensure that `` does not appear in your code. There are
a few places this can appear, only one of which is embedded in string
literals, so the method of avoiding this is actually sensitive to
the context and not practical to specify.

I hope you can appreciate how ridiculous this problem is for HTML - I don't
believe CDATA support in HTML 5 can solve this due to forward compatibility -
which is why it's an antipattern. Just don't do it, or use XHTML. It's not
cool to hate on XML anymore. ;)

Alex


On Thursday, 29 September 2016, Mike Samuel <mikesam...@gmail.com> wrote:

> Without CDATA you have to encode script bodies properly.  With CDATA you
> have to encode script bodies properly.  What problem did CDATA solve?
>
> On Sep 28, 2016 8:03 PM, "Alexander Jones" <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>
>> They do solve the problem. You encode your entire JS *before* pasting it,
>> encoding `]]>` and nothing more, and the XML document's text node contains
>> the unadulterated text, which the JS parser also sees. It's perfect layer
>> isolation. Ye olde HTML can't do that because there is no escaping
>> mechanism for `` that actually allows the JS parser to see the
>> text (code) content unmodified.
>>
>> Viva la `<xhtml:revolución />` ;)
>>
>> On Wednesday, 28 September 2016, Mike Samuel <mikesam...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','mikesam...@gmail.com');>> wrote:
>>
>>> I agree it's subideal which is why I work to address problems like this
>>> in template systems but ad-hoc string concatenation happens and embeddable
>>> sub-languages provide defense-in-depth without sacrificing correctness.
>>>
>>> CDATA sections solve no problems because they cannot contain any string
>>> that has "]]>" as a substring so you still have to s/\]\]>/]]>]]/g.
>>>
>>> On Sep 28, 2016 2:32 PM, "Alexander Jones" <a...@weej.com> wrote:
>>>
>>>> That's awful. As you say, it's an antipattern, no further effort should
>>>> be spent on this. JSON produced by JavaScript has far more general uses
>>>> than slapping directly into a script tag unencoded, so no-one else should
>>>> have to see this. Also, there are many other producers of JSON than
>>>> JavaScript.
>>>>
>>>> Instead, use XHTML and CDATA (which has a straightforward encoding
>>>> mechanism that doesn't ruin the parseability of the code or affect it in
>>>> any way) if you really want to pull stunts like this.
>>>>
>>>> Alex
>>>>
>>>> On Wednesday, 28 September 2016, Michał Wadas <michalwa...@gmail.com>
>>>> wrote:
>>>>
>>>>> Idea: require implementations to stringify "" as
>>>>> "<\uscript>".
>>>>>
>>>>> Benefits: remove XSS vulnerability when injecting JSON as content of
>>>>> 

Re: JSON.stringify

[Alexander Jones]

They do solve the problem. You encode your entire JS *before* pasting it,
encoding `]]>` and nothing more, and the XML document's text node contains
the unadulterated text, which the JS parser also sees. It's perfect layer
isolation. Ye olde HTML can't do that because there is no escaping
mechanism for `` that actually allows the JS parser to see the
text (code) content unmodified.

Viva la `<xhtml:revolución />` ;)

On Wednesday, 28 September 2016, Mike Samuel <mikesam...@gmail.com> wrote:

> I agree it's subideal which is why I work to address problems like this in
> template systems but ad-hoc string concatenation happens and embeddable
> sub-languages provide defense-in-depth without sacrificing correctness.
>
> CDATA sections solve no problems because they cannot contain any string
> that has "]]>" as a substring so you still have to s/\]\]>/]]>]]/g.
>
> On Sep 28, 2016 2:32 PM, "Alexander Jones" <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>
>> That's awful. As you say, it's an antipattern, no further effort should
>> be spent on this. JSON produced by JavaScript has far more general uses
>> than slapping directly into a script tag unencoded, so no-one else should
>> have to see this. Also, there are many other producers of JSON than
>> JavaScript.
>>
>> Instead, use XHTML and CDATA (which has a straightforward encoding
>> mechanism that doesn't ruin the parseability of the code or affect it in
>> any way) if you really want to pull stunts like this.
>>
>> Alex
>>
>> On Wednesday, 28 September 2016, Michał Wadas <michalwa...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','michalwa...@gmail.com');>> wrote:
>>
>>> Idea: require implementations to stringify "" as
>>> "<\uscript>".
>>>
>>> Benefits: remove XSS vulnerability when injecting JSON as content of
>>> 

Re: JSON.stringify

[Alexander Jones]

Hi Michał

Embedding a JSON literal into HTML involves first encoding to JSON then
encoding that into HTML. Two stages which must not be confused. The
'encoding into HTML' part is best done in XHTML with CDATA, and the
encoding method is taken care of by whichever XML-generating library you're
using. If you hint it to use CDATA for such a text node, or if for any
other reason it chooses to use CDATA, rather than merely converting every
`<` to ``, etc., then it will (or should) "escape" `]]>` as
`>". Mike Samuel has a
> very strong point here.
>
> And by saying "it's antipattern, don't do this" we will not make old
> vulnerable code go away. And we have a very good way to stop people from
> shooting their own feet - for free.
>
> On 28 Sep 2016 8:31 p.m., "Alexander Jones" <a...@weej.com> wrote:
>
> That's awful. As you say, it's an antipattern, no further effort should be
> spent on this. JSON produced by JavaScript has far more general uses than
> slapping directly into a script tag unencoded, so no-one else should have
> to see this. Also, there are many other producers of JSON than JavaScript.
>
> Instead, use XHTML and CDATA (which has a straightforward encoding
> mechanism that doesn't ruin the parseability of the code or affect it in
> any way) if you really want to pull stunts like this.
>
> Alex
>
>
> On Wednesday, 28 September 2016, Michał Wadas <michalwa...@gmail.com>
> wrote:
>
>> Idea: require implementations to stringify "" as
>> "<\uscript>".
>>
>> Benefits: remove XSS vulnerability when injecting JSON as content of
>> 

Re: JSON.stringify

[Alexander Jones]

That's awful. As you say, it's an antipattern, no further effort should be
spent on this. JSON produced by JavaScript has far more general uses than
slapping directly into a script tag unencoded, so no-one else should have
to see this. Also, there are many other producers of JSON than JavaScript.

Instead, use XHTML and CDATA (which has a straightforward encoding
mechanism that doesn't ruin the parseability of the code or affect it in
any way) if you really want to pull stunts like this.

Alex

On Wednesday, 28 September 2016, Michał Wadas  wrote:

> Idea: require implementations to stringify "" as
> "<\uscript>".
>
> Benefits: remove XSS vulnerability when injecting JSON as content of
> 

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

[Alexander Jones]

Yes, please don't special case for-of handling, it's nicely expressed in
terms of other concepts.

On Sunday, 25 September 2016, saam barati  wrote:

> It seems like Jordan's suggestion is what you want then.
>
> - Saam
>
> On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra  > wrote:
>
> Thank you.
>
> To elaborate a bit, what I'm trying to do is use Proxy so as to enable
> FSM-like DSLs, essentially having one Proxy type represent the current
> 'state' dictating what DSL you're in, one property access choosing to
> either yield a new proxied object, yielding an unwrapped version, or one
> wrapped in a different proxy type.
>
> This is why I'd wanted to be able to trap different operations, as they
> help to give ways to distinguish cases (return a wrapped result etc.). The
> point would be this would allow a user to 'navigate' something pretending
> to be a regular object, even though it isn't (e.g. async values like
> Promises/Observables, remote collections too costly to fetch in full unless
> needed, decycled versions of the regular object for the purpose of
> serialization, you name it...).
>
>
> On Sun, Sep 25, 2016 at 12:32 PM, saam barati  > wrote:
>
>> The purpose of the iterator protocol is to be flexible and to work well
>> with custom defined iterators. for...of is more or less sugar around the
>> iterator protocol. Not sure why you even need a Proxy to easily customize
>> for...of behavior for arbitrary objects.
>>
>> More documentation on the protocol can be found here:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
>> rence/Iteration_protocols
>>
>> - Saam
>>
>> On Sep 24, 2016, at 8:34 PM, Tycho Grouwstra > > wrote:
>>
>> I'd like to propose adding support for an iteration trap handler for
>> Proxy, fleshing out the list of [currently supported Proxy handlers](
>> https://developer.mozilla.org/en-US/docs/Web/JavaS
>> cript/Reference/Global_Objects/Proxy#Methods_of_the_handler_object).
>> I think Proxy is among the most powerful features of JS, so I find it
>> unfortunate iteration, a common operation, is still missing. No new syntax
>> would be required for this addition.
>>
>> On a side-note, I'd be happy if there were no additional [requirements](
>> http://stackoverflow.com/a/32360219/1502035) on usage of such a trap,
>> but I'm not sure that would complicate implementation.
>>
>> ___
>> 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: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

[Alexander Jones]

On 15 August 2016 at 19:20, Allen Wirfs-Brock  wrote:

>
> Because Symbol does not have a syntactic literal form, some sort of
> invocation is required to acquire a new unique primitive Symbol value.
> That is where you get the potential for confusion between `Symbol()` and
> `new Symbol()`.  And minimizing this sort of mistake is not just a matter
> of needing “better learning”.  Even an experts can have momentary mental
> slips and type a `new Symbol()` when they really meant `Symbol()`.


Honestly, I think this kind of basic type error is something which is so
trivially catchable at a very early stage when you have even a semblance of
static analysis. `new Symbol()` should give you an object of class Symbol,
and `Symbol()` should give you a symbol - and TypeScript even without
annotations is going to give you a pretty strong warning. IMO it's a bit
ugly to break the pattern of primitive wrappers being newable for the sake
of saving programming errors, when the analyzer can do a much more complete
job anyway.

```js
let s1 = String("banana"); // string
let s2 = new String("banana"); // object
let o = {banana: 2};
o[s1];
o[s2]; // red squiggly: An index expression argument must be of type
'string', 'number', 'symbol', or 'any'.
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function constants for Identity and No-op

[Alexander Jones]

Those spellings don't help when trying to visually parse a bunch of code
which already largely consists of dense punctuation, though, IMO.

On Wednesday, 10 August 2016, Tab Atkins Jr.  wrote:

> On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman  > wrote:
> > Now obviously it would be trivial for me to declare these constants in
> > userland code like I already do, e.g. `const NOOP = () => {}`, but in
> > projects where it's needed in several files, I'll have to put that in a
> > module or re-declare everywhere. This is not a huge inconvenience but
> > something that could easily allocated for in the language.
>
> Mark's argument (which I agree with) is that `x=>x` and `()=>{}` are
> good *spellings* of "identity function" and "noop function".  It's
> immediately obvious what they do; `obj.doCallback(()=>{})` is about as
> easy to understand as `obj.doCallback(Function.noop)`.  The ID
> function is even simpler - `obj.map(x=>x)` reads *extremely* well to
> me, equal or better than `obj.map(Function.id)`. If we were to reserve
> "id" and "noop" as bare global variables, I might agree that those
> were even better, but that's clearly out of the question.
>
> ~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: Operating with arbitrary timezones

[Alexander Jones]

I'm not sure I properly conveyed myself above given what you're saying. Let
me back up and explain more clearly now I have an actual keyboard in front
of me.

Currently we have `Date.prototype.toLocaleString()`, which conflates two
concerns:

1. Taking an unambiguous *time point* to a { year, month, day, hours,
minutes, seconds, milliseconds, timezoneOffset } for the selected
*timezone* (which is the subject of this thread).
2. Formatting those "local datetime components" in a way appropriate to a
specific locale.

Example:

```
d.toLocaleString("en-GB", {timeZone: "Europe/London"})
"06/08/2016, 09:02:13"
d.toLocaleString("en-US", {timeZone: "America/New_York"})
"8/6/2016, 4:02:13 AM"
```

What I'm suggesting is that these two concerns could be better separated.
Hypothetically, think of a new class with the awful and purely illustrative
name `LocalDatetimeComponents`:

```
const now = new Date();

const ldc = now.toLocalDatetimeComponents({timeZone: "Europe/London"});

assert(ldc instanceof LocalDatetimeComponents);

assert(ldc.month === AUGUST);

assert(ldc.timeZoneOffset === -1 * 60);
// UTC+1 for this specific time point, UTC+0 in winter

assert(ldc.timeZoneName === "BST");
// or GMT in winter

assert(ldc.toLocaleString("en-GB", {timeZoneName: "short"}) ===
"06/08/2016, 09:02:13 BST");
```

Note that the vast majority of the many possible `LocalDatetimeComponents`
values would not normally constitute real datetimes. But one benefit of
this separation is that it can express and format things like the time
2015-06-30T23:59:60.123Z (an actual time point within the most recent "leap
second") in spite of the fact that Date itself has no possible
representation of it. Perhaps some class or function other than `Date` can
produce `LocalDatetimeComponents` objects, maybe one that supports leap
seconds in applications that actually need it.

Alex

On 6 August 2016 at 00:08, Jon Zeppieri <zeppi...@gmail.com> wrote:

>
>
> On Fri, Aug 5, 2016 at 6:32 PM, Jon Zeppieri <zeppi...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones <a...@weej.com> wrote:
>>
>>> Don't confuse timezones with timezone offsets. They are different
>>> concepts.
>>
>>
>>
>> How am I confusing them? You wrote:
>>
>> What I meant by Date+Time components was actually { year, month, day,
>>> hours, minutes, seconds, offset }. I think it makes sense to formalise this
>>> as an expression of a time point (aka Date) *in a particular timezone*. For
>>> example this can be used to decide e.g. "are these two time points in the
>>> same month in this specific timezone", where that month may be e.g. 31 days
>>> + 1 hour. It could also be formatted for display.
>>
>>
>> And I'm saying, in response, that if you want to formalize the concept of
>> a time point in a particular time zone, this isn't a good way to do it. If
>> instead you want to formalize the concept of a particular point in time at
>> a particular UTC offset, then it's fine, of course, but at that point, I'd
>> just reiterate Tab's response.
>>
>> - Jon
>>
>
>
> Actually, let me try to clarify this a bit more. It sounds like you do not
> want a DateTime type to contain (what I would call) a robust concept of a
> time zone, because you think that date "projections" (by which I think
> you're referring to the kind of date arithmetic that I mentioned in an
> earlier post) are a separate concern.
>
> (I'm fine with that, by the way. Off the top of my head, I can't think of
> any date/time libraries that use a time zone as a separate input to date
> arithmetic functions, but it's a reasonable design.)
>
> However, you say that it would be useful to have the offset as part of a
> DateTime object, so that you could answer questions like: "Are these two
> points in time in the same month in this specific time zone?" Well, first
> question: which specific time zone (offset, actually, since that's what you
> want in the objects, right)? We're talking about either a two argument
> predicate function or a binary method, I assume. You might say that it
> doesn't matter which offset you use -- coerce in either direction you want;
> they're either in the same month or not. True (under certain assumptions,
> which I'll get back to in a moment) -- but if you're not interested in
> which month (and which offset), then you don't need the offset in the
> representation at all, because if you could coerce both to UTC to answer
> the question, then... well, you could just represent them in UTC.
>
> And all of this assumes that the question is

Re: Operating with arbitrary timezones

[Alexander Jones]

Don't confuse timezones with timezone offsets. They are different concepts.

On Friday, 5 August 2016, Jon Zeppieri <zeppi...@gmail.com> wrote:

>
>
> On Fri, Aug 5, 2016 at 5:58 PM, Alexander Jones <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>
>> What I meant by Date+Time components was actually { year, month, day,
>> hours, minutes, seconds, offset }. I think it makes sense to formalise this
>> as an expression of a time point (aka Date) *in a particular timezone*. For
>> example this can be used to decide e.g. "are these two time points in the
>> same month in this specific timezone", where that month may be e.g. 31 days
>> + 1 hour. It could also be formatted for display.
>>
>> Conflating Date projections into a timezone, with formatting, is a bit of
>> a conceptual error IMO. Convenient, but incorrect, as per Single
>> Responsibility Principle.
>>
>> Alex
>>
>>
> UTC offsets are terrible representations of time zones, because they don't
> acknowledge that many actual local timelines are discontinuous.
>
> When you don't need time zones, it's best to avoid them (and UTC offsets)
> altogether, but when you really need them, UTC offsets just aren't enough.
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operating with arbitrary timezones

[Alexander Jones]

What I meant by Date+Time components was actually { year, month, day,
hours, minutes, seconds, offset }. I think it makes sense to formalise this
as an expression of a time point (aka Date) *in a particular timezone*. For
example this can be used to decide e.g. "are these two time points in the
same month in this specific timezone", where that month may be e.g. 31 days
+ 1 hour. It could also be formatted for display.

Conflating Date projections into a timezone, with formatting, is a bit of a
conceptual error IMO. Convenient, but incorrect, as per Single
Responsibility Principle.

Alex

On Friday, 5 August 2016, Kris Siegel <krissie...@gmail.com> wrote:

>  Once you endow them with a timezone offset they cease to represent
>> points in time, but rather more points in space, which adds complexity and
>> liability to any code handling Date objects
>
>
> I would disagree. Time isn't useful without a point in space (space and
> time should be looked at as one thing, not two) and since the Date object
> tracks it internally as UTC it has a *default* space.
>
> It's unfortunate that the boat has sailed on Date, because it's actually a
>> very inappropriate name for what it is. But what I think is really needed
>> is another distinct class for Date+Time components.
>
>
> Completely agree. Other than adding functions nothing can really change
> with the existing Date object. However this could be a real start to a new
> set of standard libraries for JavaScript that require the usage of import
> (so like Python, C++, C#, etc ECMAScript could have a set of libraries that
> can be included in the exact same fashion as including external libraries).
>
> I'm not really sure about not having arithmetic on this hypothetical new
> set of components (arithmetic is one of the most useful things about date
> time libraries) but that's details to be explored later and I guess this is
> getting off track from the original proposal here.
>
> On Fri, Aug 5, 2016 at 1:01 PM, Alexander Jones <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>
>> I would object to your suggestion on the grounds that, as they stand,
>> Date objects represent exact points in time, with no ambiguities, and in
>> many cases that's exactly what you need. Once you endow them with a
>> timezone offset they cease to represent points in time, but rather
>> more points in space, which adds complexity and liability to any code
>> handling Date objects - similar to how any code expecting integral Numbers
>> has to be prepared for non-integral input.
>>
>> It's unfortunate that the boat has sailed on Date, because it's actually
>> a very inappropriate name for what it is. But what I think is really needed
>> is another distinct class for Date+Time components. You would project a
>> Date to its components (incl a tz offset, to avoid ambiguity around DST
>> shifts) for a given timezone, and with those components, answer the kinds
>> of questions you have. No arithmetic should be possible with such a
>> class, short of extracting a Date back from it and working on that.
>>
>> On Friday, 5 August 2016, Jordan Harband <ljh...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','ljh...@gmail.com');>> wrote:
>>
>>> This message was in my Gmail spam folder due to "It has a from address
>>> in yahoo-inc.com but has failed yahoo-inc.com's required tests for
>>> authentication." - so it's possible nobody saw it.
>>>
>>> Replying all to bump.
>>>
>>> On Fri, Jul 29, 2016 at 12:51 PM, Juan Dopazo <jdop...@yahoo-inc.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I’ve been working on Yahoo Mail and we’ve been running into multiple
>>>> issues with timezones. Currently EcmaScript supports only creating Date
>>>> objects with the User Agent’s timezone. However, we need to be able to
>>>> operate with whatever timezone our users selected in their settings page.
>>>> In most cases we just need to render dates with the correct timezone and
>>>> this is currently available using the Ecma 402 APIs. However, in other
>>>> cases we need to make certain computations taking into account an arbitrary
>>>> timezone and this is not covered by either EcmaScript or Ecma 402.
>>>>
>>>> In particular, we need to answer the following questions:
>>>>
>>>>- Is a certain date in the current day/month/year? This means given
>>>>a Date object, is it in the current day for an arbitrary timezone?
>>>>- When is the start of the day/month for this ti

Re: Operating with arbitrary timezones

[Alexander Jones]

I would object to your suggestion on the grounds that, as they stand, Date
objects represent exact points in time, with no ambiguities, and in many
cases that's exactly what you need. Once you endow them with a timezone
offset they cease to represent points in time, but rather more points in
space, which adds complexity and liability to any code handling Date
objects - similar to how any code expecting integral Numbers has to be
prepared for non-integral input.

It's unfortunate that the boat has sailed on Date, because it's actually a
very inappropriate name for what it is. But what I think is really needed
is another distinct class for Date+Time components. You would project a
Date to its components (incl a tz offset, to avoid ambiguity around DST
shifts) for a given timezone, and with those components, answer the kinds
of questions you have. No arithmetic should be possible with such a
class, short of extracting a Date back from it and working on that.

On Friday, 5 August 2016, Jordan Harband  wrote:

> This message was in my Gmail spam folder due to "It has a from address in
> yahoo-inc.com but has failed yahoo-inc.com's required tests for
> authentication." - so it's possible nobody saw it.
>
> Replying all to bump.
>
> On Fri, Jul 29, 2016 at 12:51 PM, Juan Dopazo  > wrote:
>
>> Hello,
>>
>> I’ve been working on Yahoo Mail and we’ve been running into multiple
>> issues with timezones. Currently EcmaScript supports only creating Date
>> objects with the User Agent’s timezone. However, we need to be able to
>> operate with whatever timezone our users selected in their settings page.
>> In most cases we just need to render dates with the correct timezone and
>> this is currently available using the Ecma 402 APIs. However, in other
>> cases we need to make certain computations taking into account an arbitrary
>> timezone and this is not covered by either EcmaScript or Ecma 402.
>>
>> In particular, we need to answer the following questions:
>>
>>- Is a certain date in the current day/month/year? This means given a
>>Date object, is it in the current day for an arbitrary timezone?
>>- When is the start of the day/month for this timezone?
>>
>> Currently the only way to answer these questions is by calculating the
>> timezone offset for the timezone around the date we’re studying. And the
>> way to do that is to render a date using Intl.DateTimeFormat and recreate a
>> date object: https://gist.github.com/juandopazo/b52820e368739ed19cb206e3f
>> 3893166.
>>
>> Ideally, EcmaScript would allow developers to operate on a Date object
>> for an arbitrary timezone. Would date.setTimezone(/* IANA string identifier
>> */) work? I know it’s a problem that is in the middle between EcmaScript
>> and Ecma 402.
>>
>> Thank you,
>>
>> Juan Dopazo
>>
>>
>> ___
>> 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: Suggestion: Object.symbols

[Alexander Jones]

Well, a map is more often of dynamic size, mapping from one specific type T
to another specific type U. (Of course, either can be variants.) An
object is a bag of properties of fixed size, with keys of type
string|symbol, values of a type specific to the property, metadata from the
property descriptor, and a prototype chain.

Nobody mention Array. ;)

On Thursday, 16 June 2016, doodad-js Admin  wrote:

> > the consensus appears to be moving towards treating Objects like records
>
> But we have Map for this ? It’s difficult to follow the consensus... Why
> they “implemented” class if they don’t want classes, but “records” and no
> methods, but global/module functions ? Are we moving back to good old BASIC
> and COBOL languages ?
>
>
>
> Anyway, I have my polyfill for “Object.symbols”, I was just hoping for
> something more performant.
>
>
>
> Thanks
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Object.symbols

[Alexander Jones]

In my opinion, the consensus appears to be moving towards treating Objects
like records, structurally typed bags of properties that don't change shape
over their lifetime, and are thus statically analysable. See TypeScript's
approach for a justification.

On Thursday, 16 June 2016, doodad-js Admin  wrote:

> >> you'd have to present a use-case that's not better solved by "just use
> a Map"
> Simple... An object used like... an object ! An object with methods and
> attributes. https://www.npmjs.com/package/doodad-js
>
>
> ___
> 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: Suggestion: Object.symbols

[Alexander Jones]

Not in general, just for map-like usages, i.e. if you have an object where
the keys are not static, you probably would be better served by a map.

The problem with those functions you describe is that there are a
large combinatorial set of them - did you want configurable, own,
non-enumerable string-keyed properties? Map is both narrower in this sense
(a map item is JUST a key and value with no metadata), and wider in its
valid key types (no toString called!), which is more appropriate for many
problems.

Cheers

Alex

On Wednesday, 15 June 2016, doodad-js Admin  wrote:

> > I consider all of the 'get some arbitrary subset of properties from an
> object' use cases obsoleted by `Map`. But maybe I'm missing something
> obvious or not-so-obvious...?
>
>
>
> Objects, obsolete with Map ? “Map” is not meant to replace objects, is it ?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Object.symbols

[Alexander Jones]

Question is why would you actually want this when you have `Map`?

I consider all of the 'get some arbitrary subset of properties from an
object' use cases obsoleted by `Map`. But maybe I'm missing something
obvious or not-so-obvious...?

Cheers

Alex

On Wednesday, 15 June 2016, doodad-js Admin  wrote:

> Hi,
>
>
>
> There is “Object.keys” for enumerable-only own property names of an
> object, and “Object.getOwnPropertyNames” for enumerable and non-enumerable
> own property names of an object. Now we have “Object.getOwnPropertySymbols”
> which returns enumerable and non-enumerable own symbols of an object, but
> we are missing a function “Object.symbols” that returns enumerable-only own
> symbols of an object.
>
>
>
> Thanks,
>
>
>
> Claude Petit
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.includesAll

[Alexander Jones]

There is a precedent here from set theory.

A.includesAll(B)

is really the equivalent of:

A is a superset of B

or otherwise put:

B - A = empty set

Hence, if B is the empty set, then it is indeed true for all sets A.

Cheers

On Tuesday, 14 June 2016, Shahar Or  wrote:

> What's the point of using `reduce` instead of `every`?
>>
>
> Of course. Updated to use `.every`.
>
> I disagree with this test
>>
>> ```js
>> expect([2, 3].includesAll()).toBe(false)
>> ```
>>
>
>> The array `[2,3]` includes all items in `[]`. So it should return `true`.
>>
>
>  There are no items in `[]` so that doesn't seem like a true statement to
> me.
> However, one could argue both ways. So I look at `.includes`:
> ```js
> [].includes() // false
> [1]includes() // false
> // and so on...
> ```
> So, at least consistency pulls towards `false`.
>
> > It'd be nicer if it took an array, rather than being variadic. That also
> preserves the ability to add extra arguments in the future.
>
> I see the point. Updated to use a single array argument.
>
> ---
>
> Here it is: http://codepen.io/mightyiam/pen/PzNLKr/?editors=0012
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Set.prototype methods

[Alexander Jones]

Most of these would be better off as generic iterable-consuming,
iterator-producing functions. You know, Single Responsibility Principle,
and all that.

As for the rest, IMO union, intersect, and the zoo of other missing set
theory operators would probably be better off as multiple dispatch
functions, as either operators or unified call syntax... I think I've seen
proposals for all of those floating around.

On 1 June 2016 at 00:38, Tab Atkins Jr.  wrote:

> On Sun, May 29, 2016 at 6:13 AM, Michał Wadas 
> wrote:
> > I have written proposal for new Set.prototype methods.
> >
> > https://github.com/Ginden/set-methods
> >
> > New methods would be:
> >
> > Set.prototype.filter
> > Set.prototype.map
> > Set.prototype.some
> > Set.prototype.every
> > Set.prototype.find
> > Set.prototype.union
> > Set.prototype.intersect
> > Set.isSet
> >
> >
> > TBA:
> >
> > Set.prototype.difference (or .except)
>
> Yes *please* to all of these.  I've added most of them manually to
> Set.prototype on some of my projects.
>
> One additional request in a related vein - Set.prototype.chain - like
> .map, but the callback's value is iterated and added to the result
> set.  (We need to coordinate this with an identical method on Array;
> .chain just seems to be one of the more common names for this
> operation in JS-land.)  I use this a *lot* to, for example, expand
> items into related terms.
>
> ~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: JavaScript Language feature Idea

[Alexander Jones]

This is why we can't have nice things... Literally anything we do with the
language *at all* can collide with libraries. Introducing new syntax? Code
that was using eval and throwing syntax errors is now behaving differently
and you 'broke the web'... Adding a `Symbol.last` method to `Array#`?
People who were abusing Arrays as property bags might have code that was
adding that key as a property already and you 'broke the web'...

If this is seriously the attitude we're taking as a community, we should
stop wasting our time and just accept that WebAssembly is the only
reasonable way forward. All of these modern nice-to-haves are a crutch and
a distraction from this and obfuscate the need for a real solution.

Of course, we cleaned up parts of the language once already with 'use
strict'. I don't see why we can't do it again once or twice a decade...

Alex

On Tuesday, 19 April 2016, Bob Myers  wrote:

> Please go back and read the existing threads. We've been over this
> territory ad nauseum.
>
> Yes, of course `array[-1]` would break the web and that's why no one is
> seriously proposing that.
>
> As already discussed extensively, `Array#last` may be an option, but it
> could collide with libraries or other code which extends `Array.prototype`,
> and they seem too specialized (why not also `lastButOne`?).
>
> Bob
>
> On Tue, Apr 19, 2016 at 10:47 AM, Bruno Jouhier  > wrote:
>
>> Why new syntax here? This is just a method that's missing:
>> `array.last(n)`.
>>
>> `array[-1]` would break things and it is difficult to find out where.
>> Consider:
>>
>> ``` javascript
>> for (var i = array.length - 1; array[i]; i--) doSomething(array[i]);
>> ```
>>
>> Not the best way to write such a loop but changing `array[-1]` would
>> break it.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Add support for arbitrary code inside template tags without the 'do' keyword

[Alexander Jones]

The two code samples you posted are equivalent (modulo the obvious
mistake). AFAIU there is still only a single parsing pass for template
strings.

On Tuesday, 12 January 2016, /#!/JoePea  wrote:

> The thing with template strings is that they are used at runtime. This
> could be slow if we're compiling things at runtime all the time,
> whereas a server-side templating solution might lead JavaScript
> functions compiled from templates (like in the case with Meteor Blaze
> Spacebars or React JSX), which can be faster at runtime.
>
> What are template strings good for besides the obvious benefit that
> they make things like
>
> ```
> var str = "llo"
> console.log(`he${str} world!`)
> ```
>
> easier to read than
>
> ```
> var str = "llo"
> console.log('he'+'str'+' world!')
> ```
>
> ?
>
> Maybe writing regexes can be nicer with template strings? I gave it a
> try at npmjs.com/regexr.
>
> On Mon, Jan 11, 2016 at 8:43 AM, Manuel Di Iorio  > wrote:
> > Yes Bob, after a personal testing with a complete template engine using
> the
> > ES6 template strings, I realized that their use (in mine use case, of
> > course) is slowest than the approach that I'm using right now (like the
> > Underscore template). Thanks everyone :)
> >
> > ___
> > 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: Re[2]: Operators overriding

[Alexander Jones]

Who would have thought using completely un-semantic idioms such as |0 and
!! would lead to issues down the line? /s

On 28 December 2015 at 14:50, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> This is right, currently code such as "asm js" rely on "a | 0" and
> "+a" to force a type interpretation. Having an override means that we
> would have to guard explicitly against overridden the operator before
> entering these sections of code.
> This will increase the cost of cold calls.  If this is a frequent
> path, then we would have to infer the type as long as possible to
> remove such guards.
>
> Currently, proxies have more important issues in SpiderMonkey, as they
> allow to instrument the lookup of properties (which is still in C++)
> in a side-effectful way.
>
> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi 
> wrote:
> > Generally letting proxies do more things is a good thing, but what would
> be
> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a | 0`
> > more flexible would also make them slower.  Is this incorrect?
> >
> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH  wrote:
> >>
> >> I dislike this proposal.
> >> 1 It is not very good to limit overrideable operators to value classes.
> >> 2 It is not very good to have a lot of custom operators, it will break
> >> code readability and will allow more efficient obfuscration.
> >> 3 I think that most of binary non-assigning operators must return a new
> >> object and thats' why they should be not object methods, but the methods
> >> taking 2 (or more if chained!) objects and return the result usually of
> same
> >> type.
> >>
> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
> >> :
> >>
> >>
> >> IMO, operator overloading is important and different enough to warrant a
> >> separate syntax.
> >>
> >> But the difficulty isn't in defining the operator, but in the ambiguous
> >> cases. Like what to do when there are 2 different types, how to make
> sure
> >> certain relations will stay correct, ...
> >>
> >> There's a nice presentation from Brendan Eich here:
> >> http://www.slideshare.net/BrendanEich/value-objects2
> >>
> >> Regards,
> >> Sander
> >>
> >> 2015-12-18 21:24 GMT+01:00 KOLANICH :
> >>
> >> Hello. What do you think about overriding operators using proxies?
> >>
> >> For example
> >> function A(r=""){
> >> this.rep=r;
> >> return new Proxy(this,{operators:{"+":function(a,b){return new
> >> A(a.rep+"+"+b.rep);}}});
> >> }
> >> let a=new A("a"), b=new A("b");
> >> let c=a+b;
> >> console.log(c.rep);//a+b
> >>
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Nicolas B. Pierron
> ___
> 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: Re[2]: Operators overriding

[Alexander Jones]

Regarding not knowing what `a + b` does: you *already* don't know because
it invokes `.valueOf`. If you already know the operands are typeof
"number", you're good to optimise just as much as with operator overloading.

Aside from that, we're back into arguments about the clarity benefits of

 * paren-free function invocation
 * non-member, postfix function call syntax, aka `::`

And finally, any discussion about the perceived "mental tax" of operators
would be incomplete without a reference to the definition of the `+`
operator in ECMAScript 2016[1]. Ever tried explaining to beginners what the
result of `[] + {}` is, while keeping a straight face?

1.
http://www.ecma-international.org/ecma-262/6.0/#sec-addition-operator-plus

On 28 December 2015 at 17:59, /#!/JoePea <j...@trusktr.io> wrote:

> I'm in favor of no overloading for the reason of the mental tax.
> People could write a program where everything is a mathematical
> operation (in looks, not necessarily functionality), which could
> encourage harder-to-read code. I think `this.plus(that)` is fine for
> objects. With a proper auto-completing editor, this really isn't that
> difficult. Plus, there's Sweet.js if you really want it.
>
> On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <bradley.m...@gmail.com>
> wrote:
> > Who would think not knowing what `a+b` could do as a pitfall? /s
> >
> > I am not a big fan of overloading though, since it presents more mental
> > complexity as they map to functions without looking like function calls.
> >
> > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com> wrote:
> >>
> >> Who would have thought using completely un-semantic idioms such as |0
> and
> >> !! would lead to issues down the line? /s
> >>
> >> On 28 December 2015 at 14:50, Nicolas B. Pierron
> >> <nicolas.b.pier...@mozilla.com> wrote:
> >>>
> >>> This is right, currently code such as "asm js" rely on "a | 0" and
> >>> "+a" to force a type interpretation. Having an override means that we
> >>> would have to guard explicitly against overridden the operator before
> >>> entering these sections of code.
> >>> This will increase the cost of cold calls.  If this is a frequent
> >>> path, then we would have to infer the type as long as possible to
> >>> remove such guards.
> >>>
> >>> Currently, proxies have more important issues in SpiderMonkey, as they
> >>> allow to instrument the lookup of properties (which is still in C++)
> >>> in a side-effectful way.
> >>>
> >>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <
> f.bagna...@gmail.com>
> >>> wrote:
> >>> > Generally letting proxies do more things is a good thing, but what
> >>> > would be
> >>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a
> |
> >>> > 0`
> >>> > more flexible would also make them slower.  Is this incorrect?
> >>> >
> >>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote:
> >>> >>
> >>> >> I dislike this proposal.
> >>> >> 1 It is not very good to limit overrideable operators to value
> >>> >> classes.
> >>> >> 2 It is not very good to have a lot of custom operators, it will
> break
> >>> >> code readability and will allow more efficient obfuscration.
> >>> >> 3 I think that most of binary non-assigning operators must return a
> >>> >> new
> >>> >> object and thats' why they should be not object methods, but the
> >>> >> methods
> >>> >> taking 2 (or more if chained!) objects and return the result usually
> >>> >> of same
> >>> >> type.
> >>> >>
> >>> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
> >>> >> <sander...@gmail.com>:
> >>> >>
> >>> >>
> >>> >> IMO, operator overloading is important and different enough to
> warrant
> >>> >> a
> >>> >> separate syntax.
> >>> >>
> >>> >> But the difficulty isn't in defining the operator, but in the
> >>> >> ambiguous
> >>> >> cases. Like what to do when there are 2 different types, how to make
> >>> >> sure
> >>> >> certain relations will stay correct, ...
> >>> >&g

Re: Propose simpler string constant

[Alexander Jones]

What optimizations?

On Thursday, 17 December 2015, Isiah Meadows <isiahmead...@gmail.com> wrote:

> @Alex Those languages have this thing called static types, which enable
> many of those optimizations.
>
> On Thu, Dec 17, 2015, 04:09 Alexander Jones <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>
>> I think we can do better than to follow C#'s lead, if that's the case. I
>> don't see what the point in `Color.Red - Color.Green` is. Languages like
>> Rust, Swift, OCaml are providing full Algebraic Data Types that approach
>> this whole domain from a better level. Also, I don't like the idea of
>> overloading enum for both sets of combineable flags and sets of distinct
>> values - that seems like a lack of a good abstraction. Look to Qt for IMO a
>> pretty good one: http://doc.qt.io/qt-4.8/qflags.html
>>
>> Alex
>>
>>
>> On Wednesday, 16 December 2015, Ron Buckton <ron.buck...@microsoft.com
>> <javascript:_e(%7B%7D,'cvml','ron.buck...@microsoft.com');>> wrote:
>>
>>> In C#, an enum is a declaration that defines a distinct type consisting
>>> of a set of named constant values of that type. The distinct type of the
>>> enum has an underlying numeric base type, such as byte, int, long, etc. By
>>> default, each constant value is assigned an incrementing integer value
>>> starting from 0, although this sequence can be interrupted by assigning an
>>> explicit integer value:
>>>
>>> ```cs
>>> enum Colors { Red, Green, Blue }
>>> Colors.Red // 0
>>> Colors.Green // 1
>>> Colors.Blue // 2
>>>
>>> enum Days: byte { Sat = 1, Sun, Mon, Tue, Wed, Thu, Fri }
>>> Days.Sat // 1
>>> Days.Sun // 2
>>> ```
>>>
>>> C# enum values can be used with many standard numeric operations, and
>>> are often heavily used with bitwise operators. A C# enum value is a
>>> constant value, and is internally treated as a numeric literal by the
>>> compiler. In any C# enum declaration, only constant numeric values can be
>>> explicitly assigned to an enum member, although constant reduction is
>>> permitted:
>>>
>>> ```cs
>>> enum UriComponents {
>>>   Scheme = 0x1,
>>>   UserInfo = 0x2,
>>>   Host = 0x4,
>>>   Port = 0x8,
>>>   Path = 0x10,
>>>   Query = 0x20,
>>>   Fragment = 0x40,
>>>   AbsoluteUri = Scheme | UserInfo | Host | Port | Path | Query | Fragment
>>> }
>>> ```
>>>
>>> Although C# enum values are converted to numeric literals by the
>>> compiler, their type information is preserved. This allows for an enum type
>>> to have different behavior from a literal numeric type. One example of this
>>> behavior is how ToString is handled on an enum value:
>>>
>>> ```cs
>>> enum Numbers { Zero, One, Two }
>>> (int)Numers.Zero // 0
>>> Numbers.Zero.ToString() // Zero
>>> ```
>>>
>>> The enum type itself has a number of static methods to make it easier to
>>> program against, including: GetName, GetNames, GetUnderlyingType,
>>> IsDefined, Parse, and ToObject. Instance members of an enum type include
>>> HasFlag and CompareTo.
>>>
>>> In TypeScript we treat an enum declaration in a fashion similar to a C#
>>> enum, with respect to how we handle incremental integer values and
>>> explicitly assigned values. We effectively emit an enum as an object
>>> literal:
>>>
>>> ```ts
>>> // TypeScript
>>> enum Colors { Red, Green, Blue }
>>>
>>> Colors.Red // 0
>>>
>>> // JavaScript
>>> var Colors;
>>> (function (Colors) {
>>>   Colors[Colors[0] = "Red"] = 0;
>>>   Colors[Colors[1] = "Green"] = 1;
>>>   Colors[Colors[2] = "Blue"] = 2;
>>> })(Colors || (Colors = {}));
>>>
>>> Colors.Red // 0
>>> ```
>>>
>>> In this way, you can use `Colors.Red` to get the value 0, and
>>> `Colors[0]` to get the value "Red".  As a performance optimization we also
>>> have what we call "const enums". A const enum can be completely erased by
>>> the compiler:
>>>
>>> ```ts
>>> // TypeScript
>>> const enum Colors { Red, Green, Blue }
>>>
>>> Colors.Red // 0
>>>
>>> // JavaScript
>>> 0 /*Colors.Red*/ // 0
>>> ```
>>>
>>> I think a general proposal for ES en

Re: Propose simpler string constant

[Alexander Jones]

I think we can do better than to follow C#'s lead, if that's the case. I
don't see what the point in `Color.Red - Color.Green` is. Languages like
Rust, Swift, OCaml are providing full Algebraic Data Types that approach
this whole domain from a better level. Also, I don't like the idea of
overloading enum for both sets of combineable flags and sets of distinct
values - that seems like a lack of a good abstraction. Look to Qt for IMO a
pretty good one: http://doc.qt.io/qt-4.8/qflags.html

Alex

On Wednesday, 16 December 2015, Ron Buckton 
wrote:

> In C#, an enum is a declaration that defines a distinct type consisting of
> a set of named constant values of that type. The distinct type of the enum
> has an underlying numeric base type, such as byte, int, long, etc. By
> default, each constant value is assigned an incrementing integer value
> starting from 0, although this sequence can be interrupted by assigning an
> explicit integer value:
>
> ```cs
> enum Colors { Red, Green, Blue }
> Colors.Red // 0
> Colors.Green // 1
> Colors.Blue // 2
>
> enum Days: byte { Sat = 1, Sun, Mon, Tue, Wed, Thu, Fri }
> Days.Sat // 1
> Days.Sun // 2
> ```
>
> C# enum values can be used with many standard numeric operations, and are
> often heavily used with bitwise operators. A C# enum value is a constant
> value, and is internally treated as a numeric literal by the compiler. In
> any C# enum declaration, only constant numeric values can be explicitly
> assigned to an enum member, although constant reduction is permitted:
>
> ```cs
> enum UriComponents {
>   Scheme = 0x1,
>   UserInfo = 0x2,
>   Host = 0x4,
>   Port = 0x8,
>   Path = 0x10,
>   Query = 0x20,
>   Fragment = 0x40,
>   AbsoluteUri = Scheme | UserInfo | Host | Port | Path | Query | Fragment
> }
> ```
>
> Although C# enum values are converted to numeric literals by the compiler,
> their type information is preserved. This allows for an enum type to have
> different behavior from a literal numeric type. One example of this
> behavior is how ToString is handled on an enum value:
>
> ```cs
> enum Numbers { Zero, One, Two }
> (int)Numers.Zero // 0
> Numbers.Zero.ToString() // Zero
> ```
>
> The enum type itself has a number of static methods to make it easier to
> program against, including: GetName, GetNames, GetUnderlyingType,
> IsDefined, Parse, and ToObject. Instance members of an enum type include
> HasFlag and CompareTo.
>
> In TypeScript we treat an enum declaration in a fashion similar to a C#
> enum, with respect to how we handle incremental integer values and
> explicitly assigned values. We effectively emit an enum as an object
> literal:
>
> ```ts
> // TypeScript
> enum Colors { Red, Green, Blue }
>
> Colors.Red // 0
>
> // JavaScript
> var Colors;
> (function (Colors) {
>   Colors[Colors[0] = "Red"] = 0;
>   Colors[Colors[1] = "Green"] = 1;
>   Colors[Colors[2] = "Blue"] = 2;
> })(Colors || (Colors = {}));
>
> Colors.Red // 0
> ```
>
> In this way, you can use `Colors.Red` to get the value 0, and `Colors[0]`
> to get the value "Red".  As a performance optimization we also have what we
> call "const enums". A const enum can be completely erased by the compiler:
>
> ```ts
> // TypeScript
> const enum Colors { Red, Green, Blue }
>
> Colors.Red // 0
>
> // JavaScript
> 0 /*Colors.Red*/ // 0
> ```
>
> I think a general proposal for ES enums would be a combination of the
> above approaches, with some additions:
>
> * An enum can be a declaration or an expression.
> * The body of an enum consists of a new lexical scope.
> * Enum members are standard JavaScript identifiers.
> * Enum members are automatically assigned an incrementing integer value,
> starting at zero.
> * Enum members can be explicitly assigned to an integer value, or another
> enum value.
> * Within the body of an enum, Enum members can be accessed in the
> initializer without qualification.
> * Within the body of an enum, Enum members are lexically declared names
> and cannot be accessed before they are defined (TDZ).
> * An enum declaration can be called as a function to convert a string or
> numeric value into the enum value, making enum types distinct from numbers
> and from each other. [1]
> * The result of `typeof` on an enum value is `enum`.
> * Enum values support (at least) the following operators, returning an
> enum value of the same type: + (unary), - (unary), ~, + (binary), -
> (binary), | (binary), & (binary), ^ (binary).
> * Any binary operation between two enums of different types is a
> TypeError. [1]
> * Any binary operation between an enum and a number first converts the
> number to the enum type. If the number is not an integer it is a TypeError.
> * Any binary operation between an enum and a string first converts the
> enum into the string value for that enum based on the enum member's
> JavaScript identifier (if present), or the string representation of its
> integer numeric value. [2]
> * Calling Number() with an enum value as its first argument 

Re: Propose simpler string constant

[Alexander Jones]

TypeScript has this already, so I'm sure we can learn a thing or two from
their implementation.

On 15 December 2015 at 19:56, Andrea Giammarchi  wrote:

> Jordan AFAIK you can't have undefined const declaration so your concern is
> unfounded.
>
> However, I'm pretty sure what Brendan says **is** indeed what developers
> want so I'd +1 that without problems.
>
> Regards
>
> On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband  wrote:
>
>> That seems hazardous - if someone is converting a "var" codebase to
>> "const" and "let", and they convert `var foo;` to `const foo;` expecting it
>> to be undefined, the current TDZ error will be much more helpful to them
>> than a silent change of meaning in their code to `const foo = 'foo';`.
>>
>> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf 
>> wrote:
>>
>>> A common pattern I see is this:
>>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>>
>>> Would it be helpful to allow a shorter version of this to be:
>>> const ADD_ALL_THE_STUFF
>>>
>>> Rather than have that just be forever undefined, it could automatically
>>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>>
>>> ___
>>> 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: The "Pipeline" Operator - Making multiple function calls look great

[Alexander Jones]

I wonder whether we've reach that point in the language where trying to
reuse the same old tokens over and over again in new combinations is
getting untenable. It's a long road to APL...

On 11 December 2015 at 15:23, Gilbert B Garza 
wrote:

> Rick: I would imagine some sort of lookahead is already in the parser,
> considering JavaScript supports both bitwise OR `|` and boolean OR `||` –
> unless this is accomplished some other way?
>
> Gilbert
>
> On Fri, Dec 11, 2015 at 8:52 AM, Felipe Nascimento de Moura <
> felipenmo...@gmail.com> wrote:
>
>> What about a backslash instead?
>> Like escaping a function call, such as:
>>
>> foo("some string")\bar\baz;
>>
>> Or
>>
>> `some ${data}` \ foo \ bar \ console.log;
>>
>>
>>
>>
>> On Fri, Dec 11, 2015 at 12:07 PM, Rick Waldron 
>> wrote:
>>
>>> Has anyone tried writing grammar for this? The "|>" token requires a a
>>> lookahead to disambiguate the bit wise OR operator `|`
>>>
>>>
>>> - Rick
>>>
>>>
>>>
>>>
>>> On Sun, Dec 6, 2015 at 6:38 PM Gilbert B Garza 
>>> wrote:
>>>
 > It doesn’t look like there is any redeeming quality about this
 change, it doesn’t introduce convenience

 I think you may have missed the GitHub repo [1]; it outlines benefits
 and convenience about the change. Also see this user's comment [2] on its
 significance.

 [1] https://github.com/mindeavor/es-pipeline-operator
 [2] https://news.ycombinator.com/item?id=10686596

 I argue that the syntax transformation is so simple that it would not
 introduce any pain points for JavaScript authors. It is arguably more
 intuitive than its alternative. JS programmers who are partial to FP
 certainly agree [3][4].

 [3] https://twitter.com/markdalgleish/status/673581814028492800
 [4]
 https://www.reddit.com/r/javascript/comments/3vox7x/es7_proposal_the_pipeline_operator/

 > Anything involving “placeholders arguments” is especially bad because
 it introduces an extra thing to reason about

 I agree; I still prefer the original proposal.

 > The bind operator may at least have the benefit of providing some out
 of the box support for classic FP style

 It does not, unfortunately. FP devs avoid the keyword `this`, but the
 bind operator requires its use. If I'm not mistaken, the "chaining" part of
 the bind operator is only a minor point, and isn't the main purpose of the
 proposal.



 On Sun, Dec 6, 2015 at 4:56 PM, Caitlin Potter 
 wrote:

>
> >On Dec 6, 2015, at 4:51 PM, Gilbert B Garza 
> wrote:
> >
> >Confusing and horrible are subjective, but I do agree that it's not
> as nice as the original proposal.
> >Although I prefer the original, it's also important to discuss
> objections that people bring up, as well as
> >the alternatives that might solve said objections :)
>
> Even with the original solution, it just creates a new (and less
> obvious) way of writing something that is already possible in the 
> language,
> and easier to understand. There is a narrow scope of times where it
> even makes sense to use the original (or enhanced) version of the
> proposal, and this requires authors to be vigilante about knowing when
> to pick one form over the other. It also requires code reviewers
> to be vigilante in knowing when to say “know, this is a bad idea,
> stop”.
>
> It doesn’t look like there is any redeeming quality about this change,
> it doesn’t introduce convenience, and does introduce new pain points
> for authors. Anything involving “placeholders arguments” is especially
> bad because it introduces an extra thing to reason about, but the issue
> with introducing a new syntax to pick and be aware of for limited
> gains is also problematic, growing the language and increasing complexity
> for a less than substantial reason.
>
> The bind operator may at least have the benefit of providing some out
> of the box support for classic FP style, so it’s got that going for it 
> (but
> really,
> the language doesn’t need three distinct syntaxes/idioms for this
> pattern, the complexity budget is already running thin)
>
>
> Gilbert
>
> On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter  > wrote:
>
>> These examples only make this language extension look like a
>> confusing and horrible thing. How is this an improvement, in any way?
>>
>> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza 
>> wrote:
>>
>> Status update: The JS community has shown [lots of excitement](
>> https://twitter.com/markdalgleish/status/673581814028492800) for the
>> idea of this proposal, but the syntax is still being 

Re: The "Pipeline" Operator - Making multiple function calls look great

[Alexander Jones]

Why not just have a rule that the pipeline operator consumes unary
functions, and reuse existing bind idioms, or a future bind syntax? That
seems like a proper separation of concerns to me.

As with those future bind syntax proposals, the idea of just sticking a
token somewhere within an expression to turn it into a lambda is not
ideal due to the various, obvious ambiguities that can arise. c.f. arrow
functions where the argument is given an explicit name.

On Sunday, 6 December 2015, Caitlin Potter  wrote:

> These examples only make this language extension look like a confusing and
> horrible thing. How is this an improvement, in any way?
>
> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza  > wrote:
>
> Status update: The JS community has shown [lots of excitement](
> https://twitter.com/markdalgleish/status/673581814028492800) for the idea
> of this proposal, but the syntax is still being debated. I outlined two
> alternatives [in this GitHub issue](
> https://github.com/mindeavor/es-pipeline-operator/issues/4), one of which
> I will post here since it is my current favorite:
>
> ## Placeholder Arguments
>
> The alternative is to have a new syntax for "placeholder arguments" –
> basically, slots waiting to be filled by the next function call. For
> example:
>
> ```js
> //
> // Placeholder style
> //
> run("hello") |> withThis(10, #);
> // is equivalent to
> withThis( 10, run("hello") );
>
> //
> // More complicated example
> //
> run("hello") |> withThis(10, #) |> andThis(#, 20);
> // is equivalent to
> andThis( withThis( 10, run("hello") ), 20 );
> ```
>
> ### Pros / Cons
>
> - [pro] Very explicit (no surprises)
> - [pro] Less function calls
> - [pro] Compatible with even more of the JavaScript ecosystem
> - [con] Requires more new syntax
> - [con] Usage of the hash operator (#) would probably be hard to define
> outside coupled use with pipeline operator (this problem could be avoided
> by simply making it illegal)
>
>
> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza  > wrote:
>
>> Ah, sorry for being unclear. You're right, in the case of manual
>> currying, the closure can not and should not be optimized away.
>>
>> I was talking about the case where you have arrow function literals. For
>> example:
>>
>> ```js
>> var bounded = 750
>> |> s => Math.max(100, s)
>> |> s => Math.min(0, s);
>> ```
>>
>> I imagine if the compiler sees arrow functions used in this specific
>> manner, it could automatically optimize to the following:
>>
>> ```js
>> var bounded = Math.min( 0, Math.max(100, 750) )
>> ```
>>
>> Semantically, they are equivalent; no closures nor scopes were
>> effectively used in the intermediary arrow functions.
>>
>>
>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows > > wrote:
>>
>>> Not with your semantics. It has to generate a closure each time, because
>>> of the possibility it can't be used elsewhere. That's impossible to know
>>> ahead of time if the variable is ever used outside of its closure or as a
>>> value. In the case below, it should only log thrice. Otherwise, it's
>>> unexpected behavior.
>>>
>>> ```js
>>> function add(x) {
>>>   console.log("Hit!");
>>>   return y => x + y;
>>> }
>>>
>>> let inc = add(1);
>>>
>>> 1 |> inc |> inc |> add(2) |> add(3);
>>>
>>> // Hit!
>>> // Hit!
>>> // Hit!
>>> ```
>>>
>>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza >> > wrote:
>>>
>>> Normally yes, but since the pipeline operator is a pure function, I
>>> think it's possible for the compiler to optimize away
>>> the intermediate arrow functions. I mention this in the "Functions with
>>> Multiple Arguments" section https
>>> 
>>> ://
>>> 
>>> github.com
>>> 
>>> /
>>> 
>>> mindeavor
>>> 
>>> /
>>> 
>>> ES7-pipeline-operator#functions
>>> 
>>> -with-multiple-arguments
>>> 
>>>
>>>
>>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows >> > wrote:
>>>
>>> Inline
>>>
>>> On Tue, Nov 10, 2015 at 

Re: Map literal

[Alexander Jones]

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.

Re: String.prototype.padLeft / String.prototype.padRight

[Alexander Jones]

I see about as little use case for this as `String.prototype.blink`.
Date/hours is better solved with zero padding formatting, not just padding
out the already stringified number (think negative values -42). Same
applies to filenames for lexicographical sort. Fixed length fields in wire
protocols already need to be converted to bytes first before padding, which
makes the use of this feature impossible.

On Monday, 16 November 2015, Claude Pache  wrote:

> Here are my typical use cases (found by scanning uses of "str_pad" in my
> PHP codebase):
>
> * transferring data through a protocol that uses fix-length fields;
> * formatting things like date/hours, e.g. "08:00" for "8am";
> * generating filenames of fixed length, so that they sort correctly, e.g.
> "foo-00042.txt";
> * generating codes of fixed length (e.g. barcodes).
>
> In all those cases, the set of characters is typically limited to ASCII or
> ISO-8559-1.
> Moreover, the filler string consists always of one ASCII character
> (usually " " or "0").
>
> —Claude
>
> ___
> 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 update on Object.observe

[Alexander Jones]

In my opinion, the fundamental record type we build our JS on should be
getting dumber, not smarter. It feels inappropriate to be piling more
difficult-to-reason-about mechanisms on top before reeling in exotic host
objects. With Proxy out of the bag, I'm not so hopeful for the humble
Object anymore.

On Tuesday, 3 November 2015, Andrea Giammarchi 
wrote:

> Sure thing, meanwhile polymer or other libraries need to pollute getters
> and setters and the rest of the web have been trying to polyfill it for at
> least 6 years now *
>
> The reason is not widely "abused" is that it never made it as standard and
> as it is feels like an outdated spec. Proxy would give us that and much
> more, unfortunately proxies do not play so well cross environment. For
> instance, I've tried to use them in GJS ( Gtk+3 JavaScript bindings ) and
> while Object.prototype.watch always works, proxied GObjects fail to be used
> like these were just GObjects.
>
> That might be a specific env problem though, but having a way to watch
> properties, specially in two ways bindings scenarios, is a very needed
> common thing.
> As example, in DOMClass I'm replacing native getters/setters to be
> notified about changes, it doesn't feel right even if it works.
>
> All this is over-off-topic though, so I might just stop.
>
> Best Regards
>
>
>
> * just few examples since 2009
> https://gist.github.com/eligrey/384583
> https://gist.github.com/adriengibrat/b0ee333dc1b058a22b66
> question in SO
> http://stackoverflow.com/questions/1029241/javascript-object-watch-for-all-browsers
> http://deploytonenyures.blogspot.co.uk/2013/02/objectwatch-polyfill.html
>
> https://code.google.com/p/chtor/source/browse/chtor/chrome/js/object-watch.js?spec=svn2c00820d48169bb678a00447e295fb31dcf448ed=2c00820d48169bb678a00447e295fb31dcf448ed
>
> yes, I've done that too
> in 2009
> http://webreflection.blogspot.co.uk/2009/01/internet-explorer-object-watch.html
> and recently https://gist.github.com/WebReflection/366dc38574dc526308b5
>
>
>
> On Tue, Nov 3, 2015 at 2:11 AM, Boris Zbarsky  > wrote:
>
>> On 11/2/15 4:55 PM, Andrea Giammarchi wrote:
>>
>>> I agree with Benoit and I think there is a reason
>>> `Object.prototype.watch` is still in Firefox and  won't go away any time
>>> soon
>>>
>>
>> As far as I know the only reason it's there and hasn't been removed is
>> because it's used to implement debugger watchpoints [1].  And the only
>> reason it's web-exposed is because SpiderMonkey has not prioritized being
>> able to expose APIs to privileged code but not the web (something that
>> think should get fixed).
>>
>> -Boris
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=934669
>>
>> ___
>> 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

[Alexander Jones]

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.)

Alex


On 29 October 2015 at 22:51, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Why not make it desugar to a direct function call with a single array of
> pairs? It's so parsed as a regular object, so shorthands can still be used.
>
> `Map#{foo: 1, bar: 2, 3: "baz"}`
> `Map[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> `Object#{foo: 1, bar: 2, 3: "baz"}`
> `Object[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> `Object.null#{foo: 1, bar: 2, 3: "baz"}`
> `Object.null[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> (`bar` doesn't have [[Construct]])
> `Object#{foo, bar() {}}`
> `Object[Symbol.fromHash]([[foo", foo], ["bar", function () {}]])`
>
> And as for implementation, use this:
>
> ```js
> extend class Map {
>   static [Symbol.fromHash](pairs) {
> return new this(pairs);
>   }
> }
>
> // etc...
>
> function SetKeys(target, pairs) {
>   for (const [key, value] of pairs) {
>   target[key] = value
> }
> return target
> }
>
> extend class Object {
>   static [Symbol.fromHash](pairs) {
> return SetKeys({}, pairs)
>   }
>
>   static null(pairs) {
> return SetKeys(Object.create(null), pairs)
>   }
> }
> ```
>
> Pretty simple IMHO. A helper decorator could even be made.
>
> On Wed, Oct 28, 2015, 14:34 Alexander Jones <a...@weej.com> wrote:
>
>> Also I would like to reiterate that errors in the shape of the N-by-2
>> array are only caught at runtime. That's really not ideal.
>>
>> On Wednesday, 28 October 2015, Dave Porter <david_por...@apple.com>
>> wrote:
>>
>>> I don’t love any of the specific suggestions so far, but saving 3 + 2n
>>> keystrokes isn't the point – readability and learnability are. Visually,
>>> `new Map([[‘foo’, 42]])` is a mess.
>>>
>>> On Oct 28, 2015, at 9:28 AM, Michał Wadas <michalwa...@gmail.com> wrote:
>>>
>>> Difference between any proposed here syntax and current state ( new
>>> Map([ [1,2], [2,3] ]); ) is..
>>>
>>> 3 characters + 2 characters/entry.
>>>
>>>
>>>
>>>
>>> 2015-10-28 17:22 GMT+01:00 Mohsen Azimi <m...@azimi.me>:
>>>
>>>> When I look at `Map#{"foo": 42}` I don't see much difference with `new
>>>> Map([['foo', 42]])`.
>>>>
>>>> Since you can pass expressions there, it's already possible to do it
>>>&

Re: Map literal

[Alexander Jones]

Hi Herby

Agree with your concerns about symmetry with object literals, but many of
the uses of maps benefit from having non string keys, and in such case
generally everything would involve wrapping in []. Trying to use an Array
as a key would be quite ugly with the extra squares required

```
const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}
vs
const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}
```

Perhaps a middle ground could be that if you want to use an expression that
would otherwise be a bare word, you enclose in parens. The visual binding
of the colon is deceptive anyway, so I tend to do this if the key
expression contains a space:

```
MyMap#{1 + 2 + 3: 6}
vs.
MyMap#{(1 + 2 + 3): 6}
```

But I think I still prefer that the parsing for the key part is just
standard expression evaluation, personally, and the POJSO literal barewords
remain the only special case.

Indeed,

```
Object#{1: "one", Symbol(): "sym"}
```

Could Object-key-ify the keys, i.e. turn them into strings if not
symbols, and Just Work (but a default implementation on the Object
prototype is questionable!). That said I'm not sure we should be using
Object for this kind of thing. At this point I don't know what a raw
`#{}` should produce... There may be a better use case for it in the
future, horrible ASI complexities notwithstanding.

Alex


On Wednesday, 28 October 2015, Herby Vojčík <he...@mailbox.sk> wrote:

>
>
> Alexander Jones wrote:
>
>> Ok, thanks for clarifying. Not only does it preserve order but it also
>> permits non-string keys. You're still missing one detail which is that
>> `bar` would actually be a variable not a string key.
>>
>> Another example to clarify that the key part would be an expression:
>>
>> ```
>> Map#{foo(42) + 7: "bar"}
>> ```
>>
>> I prefer this over the precedent set by object literals which would
>> require that [] are used around a key expression ("computed key") simply
>>
>
> I, on the other hand, think it should match object literals completely. So
> your example would be
>
> ```
> Map#{[foo(42)+7]: "bar"}
> ```
>
> Yes, it's just for consistency and less WTF moment while learning the
> details.
>
> OTOH, there could be consistent contraproposal of:
>
> ```
> Object#{foo(42) + 7: "bar"}
> null#{foo(42) + 7: "bar"}
> #{foo(42) + 7: "bar"}
> ```
>
> where the first is equivalent to {[foo(42)+7]: "bar"}, the second is pure
> container (Object.create(null)) filled with properties, and the third is
> the default case, but I don't know which of the previous two - the first is
> probably less confusing, though the feels more clean.
>
> due to relieving the syntax noise, which is what this idea is all about.
>> Also, this is how it works in Python and I make no apologies about the
>> similarities ;)
>>
>> Alex
>>
>> On Wednesday, 28 October 2015, Viktor Kronvall
>> <viktor.kronv...@gmail.com <mailto:viktor.kronv...@gmail.com>> wrote:
>>
>> 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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','viktor.kronv...@gmail.com');>>
>> wrote:
>>
>>

Re: Map literal

[Alexander Jones]

Ah, there is actually a good case for keeping barewords in object literals
but removing them from map literals, and that's due to objects accessing
string properties as bare words, too. This is almost never the case for
other map types.

```
const o = {foo: 42};
o.foo === 42;
o.bar = 43;

const m = Map#{"foo": 42};
m.get("foo") === 42;
m.set("bar", 43);
```

Would you agree?

On Wednesday, 28 October 2015, Alexander Jones <a...@weej.com> wrote:

> Hi Herby
>
> Agree with your concerns about symmetry with object literals, but many of
> the uses of maps benefit from having non string keys, and in such case
> generally everything would involve wrapping in []. Trying to use an Array
> as a key would be quite ugly with the extra squares required
>
> ```
> const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}
> vs
> const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}
> ```
>
> Perhaps a middle ground could be that if you want to use an expression
> that would otherwise be a bare word, you enclose in parens. The visual
> binding of the colon is deceptive anyway, so I tend to do this if the key
> expression contains a space:
>
> ```
> MyMap#{1 + 2 + 3: 6}
> vs.
> MyMap#{(1 + 2 + 3): 6}
> ```
>
> But I think I still prefer that the parsing for the key part is just
> standard expression evaluation, personally, and the POJSO literal barewords
> remain the only special case.
>
> Indeed,
>
> ```
> Object#{1: "one", Symbol(): "sym"}
> ```
>
> Could Object-key-ify the keys, i.e. turn them into strings if not
> symbols, and Just Work (but a default implementation on the Object
> prototype is questionable!). That said I'm not sure we should be using
> Object for this kind of thing. At this point I don't know what a raw
> `#{}` should produce... There may be a better use case for it in the
> future, horrible ASI complexities notwithstanding.
>
> Alex
>
>
> On Wednesday, 28 October 2015, Herby Vojčík <he...@mailbox.sk
> <javascript:_e(%7B%7D,'cvml','he...@mailbox.sk');>> wrote:
>
>>
>>
>> Alexander Jones wrote:
>>
>>> Ok, thanks for clarifying. Not only does it preserve order but it also
>>> permits non-string keys. You're still missing one detail which is that
>>> `bar` would actually be a variable not a string key.
>>>
>>> Another example to clarify that the key part would be an expression:
>>>
>>> ```
>>> Map#{foo(42) + 7: "bar"}
>>> ```
>>>
>>> I prefer this over the precedent set by object literals which would
>>> require that [] are used around a key expression ("computed key") simply
>>>
>>
>> I, on the other hand, think it should match object literals completely.
>> So your example would be
>>
>> ```
>> Map#{[foo(42)+7]: "bar"}
>> ```
>>
>> Yes, it's just for consistency and less WTF moment while learning the
>> details.
>>
>> OTOH, there could be consistent contraproposal of:
>>
>> ```
>> Object#{foo(42) + 7: "bar"}
>> null#{foo(42) + 7: "bar"}
>> #{foo(42) + 7: "bar"}
>> ```
>>
>> where the first is equivalent to {[foo(42)+7]: "bar"}, the second is pure
>> container (Object.create(null)) filled with properties, and the third is
>> the default case, but I don't know which of the previous two - the first is
>> probably less confusing, though the feels more clean.
>>
>> due to relieving the syntax noise, which is what this idea is all about.
>>> Also, this is how it works in Python and I make no apologies about the
>>> similarities ;)
>>>
>>> Alex
>>>
>>> On Wednesday, 28 October 2015, Viktor Kronvall
>>> <viktor.kronv...@gmail.com <mailto:viktor.kronv...@gmail.com>> wrote:
>>>
>>> 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
>>> complet

Re: Map literal

[Alexander Jones]

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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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

[Alexander Jones]

Ok, thanks for clarifying. Not only does it preserve order but it also
permits non-string keys. You're still missing one detail which is that
`bar` would actually be a variable not a string key.

Another example to clarify that the key part would be an expression:

```
Map#{foo(42) + 7: "bar"}
```

I prefer this over the precedent set by object literals which would require
that [] are used around a key expression ("computed key") simply due to
relieving the syntax noise, which is what this idea is all about. Also,
this is how it works in Python and I make no apologies about the
similarities ;)

Alex

On Wednesday, 28 October 2015, Viktor Kronvall <viktor.kronv...@gmail.com>
wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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

[Alexander Jones]

Also I would like to reiterate that errors in the shape of the N-by-2 array
are only caught at runtime. That's really not ideal.

On Wednesday, 28 October 2015, Dave Porter <david_por...@apple.com> wrote:

> I don’t love any of the specific suggestions so far, but saving 3 + 2n
> keystrokes isn't the point – readability and learnability are. Visually,
> `new Map([[‘foo’, 42]])` is a mess.
>
> On Oct 28, 2015, at 9:28 AM, Michał Wadas <michalwa...@gmail.com
> <javascript:_e(%7B%7D,'cvml','michalwa...@gmail.com');>> wrote:
>
> Difference between any proposed here syntax and current state ( new Map([
> [1,2], [2,3] ]); ) is..
>
> 3 characters + 2 characters/entry.
>
>
>
>
> 2015-10-28 17:22 GMT+01:00 Mohsen Azimi <m...@azimi.me
> <javascript:_e(%7B%7D,'cvml','m...@azimi.me');>>:
>
>> When I look at `Map#{"foo": 42}` I don't see much difference with `new
>> Map([['foo', 42]])`.
>>
>> Since you can pass expressions there, it's already possible to do it with
>> current syntax. There is only a bunch of extra brackets(`[` and `]`) that I
>> don't like.
>>
>>
>> On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones <a...@weej.com
>> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>>
>>> Ah, there is actually a good case for keeping barewords in object
>>> literals but removing them from map literals, and that's due to objects
>>> accessing string properties as bare words, too. This is almost never the
>>> case for other map types.
>>>
>>> ```
>>> const o = {foo: 42};
>>> o.foo === 42;
>>> o.bar = 43;
>>>
>>> const m = Map#{"foo": 42};
>>> m.get("foo") === 42;
>>> m.set("bar", 43);
>>> ```
>>>
>>> Would you agree?
>>>
>>>
>>> On Wednesday, 28 October 2015, Alexander Jones <a...@weej.com
>>> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>>>
>>>> Hi Herby
>>>>
>>>> Agree with your concerns about symmetry with object literals, but many
>>>> of the uses of maps benefit from having non string keys, and in such case
>>>> generally everything would involve wrapping in []. Trying to use an Array
>>>> as a key would be quite ugly with the extra squares required
>>>>
>>>> ```
>>>> const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}
>>>> vs
>>>> const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}
>>>> ```
>>>>
>>>> Perhaps a middle ground could be that if you want to use an expression
>>>> that would otherwise be a bare word, you enclose in parens. The visual
>>>> binding of the colon is deceptive anyway, so I tend to do this if the key
>>>> expression contains a space:
>>>>
>>>> ```
>>>> MyMap#{1 + 2 + 3: 6}
>>>> vs.
>>>> MyMap#{(1 + 2 + 3): 6}
>>>> ```
>>>>
>>>> But I think I still prefer that the parsing for the key part is just
>>>> standard expression evaluation, personally, and the POJSO literal barewords
>>>> remain the only special case.
>>>>
>>>> Indeed,
>>>>
>>>> ```
>>>> Object#{1: "one", Symbol(): "sym"}
>>>> ```
>>>>
>>>> Could Object-key-ify the keys, i.e. turn them into strings if not
>>>> symbols, and Just Work (but a default implementation on the Object
>>>> prototype is questionable!). That said I'm not sure we should be using
>>>> Object for this kind of thing. At this point I don't know what a raw
>>>> `#{}` should produce... There may be a better use case for it in the
>>>> future, horrible ASI complexities notwithstanding.
>>>>
>>>> Alex
>>>>
>>>>
>>>> On Wednesday, 28 October 2015, Herby Vojčík <he...@mailbox.sk> wrote:
>>>>
>>>>>
>>>>>
>>>>> Alexander Jones wrote:
>>>>>
>>>>>> Ok, thanks for clarifying. Not only does it preserve order but it also
>>>>>> permits non-string keys. You're still missing one detail which is that
>>>>>> `bar` would actually be a variable not a string key.
>>>>>>
>>>>>> Another example to clarify that the key part would be an expression:
>>>>>>
>>>>>> ```
>>>>>> Map#{foo(42) + 7: "bar"}

Re: Map literal

[Alexander Jones]

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.

Rather, we have an opportunity to instead devise a syntax for an abstract
map. While we're at it, we might as well do the same for an abstract list.
Why should maps have all the fun?

```
const {List: IList, Map: IMap} = Immutable;
const bar = 43;
const map = IMap#{"foo": 42, bar: 44};  // keys "foo" and 43
const list = IList#[4, 5, 6, 7, Map#{map: "why not?"}];  // 5th element is
a Map with one key, which is the Immutable.Map above
const weakMap = WeakMap#{map: "It's an Immutable", list: "Also Immutable"};
 // WeakMap keys are the objects map and list
```

It could desugar as, for the sake of example:

```
Foo#{key: value, ...}
➔
Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())
```

and

```
Foo#[value, ...]
➔
Foo[Symbol.literalOf]([value, ...][Symbol.iterator]())
```

The nice thing about this is it's extensible and future proofs the language
a little bit. The actual arrays need not exist if engines choose to
implement this more efficiently - the syntax just results in an iterator
which yields the elements of the literal. The only difference between the
`[]` and the `{}` notation ise that the `{}` notation enforces
syntactically valid key-value pairs and are a little less heavy on brackets.

I know literally every proposal ever these days seems to claim the `#`
symbol now, so that's clearly an issue to contend with... :)

Alex


On 27 October 2015 at 22:55, Mohsen Azimi  wrote:

> I'm using Maps a lot now and I was thinking why there is no "easy" way of
> declaring them like objects and arrays.
>
> I'm sure I'm not the first one who came up with the idea of having Map
> literal declaration. There are many ways we can introduce new syntax for
> declaring Maps via a literal syntax such as:
>
> ```
> let map = [window: 'window', document: 'document'];
> ```
> or
> ```
> let map = {{window: 'window', document: 'document'}}
> ```
> and possibly many more.
>
> I searched the discussions  but couldn't find a topic on this. Have you
> discussed this before?
>
> ___
> 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

[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. <jackalm...@gmail.com> wrote:

> On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones <a...@weej.com
> <javascript:;>> 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

Re: Map literal

[Alexander Jones]

Quite verbose, harder to optimize and only supports string keys.

On Wednesday, 28 October 2015, Jordan Harband <ljh...@gmail.com> wrote:

> fwiw, my Object.entries proposal (
> https://github.com/ljharb/proposal-object-values-entries ) would allow
> you to do: `new Map(Object.entries({ a: 'b', b: 'c' }))`.
>
> On Tue, Oct 27, 2015 at 4:36 PM, Alexander Jones <a...@weej.com
> <javascript:_e(%7B%7D,'cvml','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.
>>
>> Rather, we have an opportunity to instead devise a syntax for an abstract
>> map. While we're at it, we might as well do the same for an abstract list.
>> Why should maps have all the fun?
>>
>> ```
>> const {List: IList, Map: IMap} = Immutable;
>> const bar = 43;
>> const map = IMap#{"foo": 42, bar: 44};  // keys "foo" and 43
>> const list = IList#[4, 5, 6, 7, Map#{map: "why not?"}];  // 5th element
>> is a Map with one key, which is the Immutable.Map above
>> const weakMap = WeakMap#{map: "It's an Immutable", list: "Also
>> Immutable"};  // WeakMap keys are the objects map and list
>> ```
>>
>> It could desugar as, for the sake of example:
>>
>> ```
>> Foo#{key: value, ...}
>> ➔
>> Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())
>> ```
>>
>> and
>>
>> ```
>> Foo#[value, ...]
>> ➔
>> Foo[Symbol.literalOf]([value, ...][Symbol.iterator]())
>> ```
>>
>> The nice thing about this is it's extensible and future proofs the
>> language a little bit. The actual arrays need not exist if engines choose
>> to implement this more efficiently - the syntax just results in an iterator
>> which yields the elements of the literal. The only difference between the
>> `[]` and the `{}` notation ise that the `{}` notation enforces
>> syntactically valid key-value pairs and are a little less heavy on brackets.
>>
>> I know literally every proposal ever these days seems to claim the `#`
>> symbol now, so that's clearly an issue to contend with... :)
>>
>> Alex
>>
>>
>> On 27 October 2015 at 22:55, Mohsen Azimi <m...@azimi.me
>> <javascript:_e(%7B%7D,'cvml','m...@azimi.me');>> wrote:
>>
>>> I'm using Maps a lot now and I was thinking why there is no "easy" way
>>> of declaring them like objects and arrays.
>>>
>>> I'm sure I'm not the first one who came up with the idea of having Map
>>> literal declaration. There are many ways we can introduce new syntax for
>>> declaring Maps via a literal syntax such as:
>>>
>>> ```
>>> let map = [window: 'window', document: 'document'];
>>> ```
>>> or
>>> ```
>>> let map = {{window: 'window', document: 'document'}}
>>> ```
>>> and possibly many more.
>>>
>>> I searched the discussions  but couldn't find a topic on this. Have you
>>> discussed this before?
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> <javascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> <javascript:_e(%7B%7D,'cvml','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: Decorators for functions

[Alexander Jones]

OK, appreciate that. Let's explore this problem space: Why not have syntax
to set a property descriptor onto a class or object literal?

In Python, this is implicit. For example (IIRC):

```python
class Foo:
prop = some_descriptor
x = 100
```

Both `Foo.x` and `Foo().x` (instance attribute access) have the value
`100`, but assuming `some_descriptor` has `__get__`, `__set__`,
`__delete__` methods, then accessing `prop` on an instance will magically
use these descriptor methods. Obviously an issue here is that you might
literally have wanted the `prop` attribute's value to be this actual
descriptor object, so IMO something explicit for this is better in JS.

Let's instead imagine that @ is used to activate descriptor setting:

```js
const myObj = {
prop: @someDescriptorExpression,
};

// e.g.
const myObj = {
prop: @{value: whatever, writable: false},
};
```

Now clearly "decorators" like `readonly` are just function application.
Even defining a get/set pair for a property is straightforward:

```js
const readonly = v => {value: v, writable: false};

const myObj = {
prop: @readonly(whatever),
answer: @readonly(42),
x: @{
get() { return this.answer(); }
set(x) { throw new Error("nope"); }
}
};
```

"Decorators" like `memoize` are *still just in terms of functions* and
don't require this syntax -- memoizing something should never be in terms
of descriptors because it has *zero* interest in property descriptors (why
should `memoize` make a call on whether the returned function is an
enumerable, or writable, etc.?)

```js
const fib = memoize(x => {
// ...
});
```

ES6 class issues are IMO an orthogonal issue to be solved:

```js
class Foo {
x: 100  // lots and lots of questions here...
}
```

On 22 October 2015 at 05:34, Jordan Harband  wrote:

> One thing that seems to be missing from this thread is acknowledgement
> that decorators are not just simple function wrappers. They take a property
> descriptor as an argument, and they can return a new property descriptor -
> which allows an object or "class" to have its shape determined at creation
> time, allowing for massive engine optimization, as well as allowing for
> things like enumerability, configurability, writability, getters, setters,
> and various other metadata to be determined *before the object in question
> is mutated, or even exists*.
>
> Decorators are certainly something that can be quasi-polyfilled, but when
> applied to object or "class" properties, it allows access to the property
> descriptor without needing to assign, then reflect, and then define the
> resulting descriptor. `@foo` isn't merely sugar for a function call without
> parens - it's an imperative way to define property descriptors at object
> initialization time, which is something that does not currently exist in
> the language beyond `get foo() {}` and `set foo() {}`.
>
> If this has been mentioned and I missed it, please ignore me, but the
> thread seems to have overlooked this facet of the proposal. Also, if I'm
> reading the proposal incorrectly, please correct me!
>
> - Jordan
>
> On Wed, Oct 21, 2015 at 7:10 PM, Rick Waldron 
> wrote:
>
>> Or just use call constructor:
>>
>> class F {
>> #decorator
>> call constructor() {
>> ...
>> }
>> }
>>
>>
>> Rick
>>
>> On Tue, Oct 20, 2015 at 9:19 AM Matthew Robb 
>> wrote:
>>
>>> Why not just do:
>>>
>>> ```
>>> const {myFunc} = {
>>>   @someDecorator;
>>>   myFunc() {
>>>
>>>   }
>>> };
>>> ```
>>>
>>>
>>> - Matthew Robb
>>>
>>> On Tue, Oct 20, 2015 at 9:00 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 You completely misunderstood me Bob, I don't think there's any valid
 use case for functions at all, including methods and ... .**specially**
 methods!!!

 I was thinking about decorators for classes, when you enrich their
 prototype in case the decorator receives a function instead of an object,
 or you enrich the object in every other case.

 You transform at runtime prototype methods??? Good for you, but that's
 something I'd never do, unless we are talking about lazy evaluation on the
 instance, where I don't see how lazy evaluation for an inherited method has
 anything to do with *functions* decorators.

 The difference is huge, methods will most likely have a `this`
 reference to be promoted on eventually, in  the other case you have a
 function that unless its body has "switches" can cannot really promote much
 by itself and passing it around as higher order function that mutates? ...
 yak!

 As summary: does anyone has a valid use case for a generic function
 decorator? 'cause I still don't see one, and having decorators for any sort
 of function would be problematic in terms of code portability, which is all
 I am saying.

 Regards










 

Re: Decorators for functions

[Alexander Jones]

Why stop at ES3?

Point is this literally saves you two parens in exchange for one @ and a
peculiar logical insertion after the = for the use cases discussed.

Let's please collectively remember and acknowledge that this exists in
Python because *they have no function literal syntax*. We do.

On Wednesday, 21 October 2015, Yongxu Ren <renyon...@gmail.com> wrote:

> I agree with Andrea, basically nothing after es3 is a "must have", if we
> apply the same argument.
>
> I see a lot possibilities of decorator, I think it would be great if it
> can be used on any lvalue, or even statements.
>
> some of the application I can think of:
> ```
> //static type checking
> @type(number,number,number)
> function f(a,b){
> 
> }
>
> @debug(unitTestForFunction)
> let f = (x) => .
>
> @parallel
> for(...){...}
> ```
> I think the best part of decorator is it can be processed by compiler or
> polyfilled, so we can use them to instruct translator such as babel, to do
> extra checking during development and drop them in production. It can also
> be used by JET, if supported. Extra type checking, debugging can be ignored
> by native engine, polyfilled to function that does nothing(as fallback if
> no native support), or optimized as static typed function for performance.
>
> I'd love to see a limitless decorator that also allows browser/compiler to
> receive hints from developers.
>
> On Wed, Oct 21, 2015 at 7:12 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com
> <javascript:_e(%7B%7D,'cvml','andrea.giammar...@gmail.com');>> wrote:
>
>> I agree it's not a "must have", considering what we lose if applied
>> (portability) + you are back to broken portability with @meomize function
>> ... VS meomize(function)
>>
>> So, I think portability is more important than some edge case without
>> parenthesis around and if really wanted as a pattern,there is a workaround.
>>
>> Create an object to unpack it ... why not ... named functions? why not
>> ... I'm used to write `{method:  function method() {}}` for debugging sake
>> and I like named functions but going even more dirty with the workaround
>> maybe an array to unpack would  make it less maintainable but less verbose
>> too.
>>
>> It will still be portable,  which is all it matters to me.
>>
>> Regards
>>
>>
>>
>>
>>
>> On Wed, Oct 21, 2015 at 1:01 PM, Alexander Jones <a...@weej.com
>> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>>
>>> Although this works, it seems like a bit of a violation of
>>> say-what-you-mean and dont-repeat-yourself to me. You have to write the
>>> name of each function twice, and you are defining a shorthand object
>>> literal just for the sake of unpacking it.
>>>
>>> If we must have syntax for this, I'd propose hijacking @ to mean general
>>> paren-free invocation, using the same precedence rules as Coffee:
>>>
>>> ```js
>>> const fibonacci = memoize(function(n) {...});
>>> const fibonacci = @memoize function(n) {...};
>>> const fib100 = @fibonacci 100;
>>> @window.alert "If this syntax works for functions, why not let it work
>>> for anything?";
>>> ```
>>>
>>> But I must ask - why *exactly* do people have a problem with the extra
>>> brackets again? Is it really just because we don't have good paredit or
>>> other tree-based editing for JS yet? (Or do we?)
>>>
>>> On Wednesday, 21 October 2015, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','andrea.giammar...@gmail.com');>> wrote:
>>>
>>>> Again, everything can be defined in a similar way, actually granting
>>>> those function  cannot posibly be declared or redefined differently, being
>>>> constants.
>>>>
>>>> ```js
>>>>
>>>> const {
>>>>   assert,
>>>>   log,
>>>>   add
>>>> } = {
>>>>   @conditional(DEBUG)
>>>>   assert(condition, message = "assertion failed.") {
>>>> if (!condition) throw new Error(message);
>>>>   }
>>>>
>>>>   @conditional(TRACE)
>>>>   log(message) {
>>>> return target => function () {
>>>>console.log(message);
>>>>return target.apply(this, arguments);
>>>> };
>>>>   }
>>>>
>>>>   @metadata("design:paramtypes", () =>

Re: Decorators for functions

[Alexander Jones]

I've become convinced by this thread that we don't need this. Other
languages where decorators are useful and prevalent don't have the
expressivity JS has, particularly regarding dynamism and function
expressions. JS `class` is an awkward case due to not supporting non-method
members, but I think that is one of the actual problems that should
be solved.

Another major point I have is that most of the reasoning for decorator
syntax is actually generic reasoning for paren-free function invocation
à la Perl, Ruby, CoffeeScript, etc. Let's talk about that, instead of
building unilateral syntax extensions into the language.

On Tuesday, 20 October 2015, Jonathan Bond-Caron 
wrote:

> On Tue Oct 20 05:30 AM, Axel Rauschmayer wrote:
> > The decorator proposal does not include decorators for functions,
> > because it isn’t
> > clear how to make them work in the face of hoisting.
> >
>
> What's the obsession with decorators?
>
> Decorators are like saying everyone can decorate their Christmas trees.
> That's nice once a year but not when you start looking at all the
> different Christmas trees and have to maintain that stuff.
>
> Suddenly the single language you thought you understood has many dialects
> & philosophies.
> Aren't embeddable languages more interesting to learn then decorated trees?
>
> ___
> 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: Return value of forEach

[Alexander Jones]

You mean to say you *don't* have

```js
var undefined = [].forEach(Array.prototype.forEach.call);
```

at the top of every file!?

On Friday, 16 October 2015, Niloy Mondal  wrote:

> > That'd be a compatibility break.
>
> Ugh... you mean people actually depend on `forEach` returning `undefined`
> (which it always does) to do further task?
>
> I wonder what that kinda code would look like >.<
>
> On Fri, Oct 16, 2015 at 6:08 PM, Frankie Bagnardi  > wrote:
>
>> That'd be a compatibility break.
>>
>> If we end up getting :: though:
>>
>> ```js
>> function logEach(){
>>   this.forEach((x) => console.log(x));
>>   return this;
>> }
>>
>>
>> const a = [1, 2, 3]
>>   .map(square)
>>   ::logEach()
>>   .map(plus1)
>>   .reduce(add);
>> ```
>>
>> You could make that a global variable so you can sprinkle it around your
>> code in development.
>>
>> Having some developer tools in the language would be nice though. I don't
>> even think console.log is in the spec. A global like Debug.logThis for
>> example would be a more general ::-able.
>>
>>
>> On Fri, Oct 16, 2015 at 5:32 AM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com
>> > wrote:
>>
>>> ```js
>>> const a = [1, 2, 3]
>>>   .map(square)
>>>   .map(x => console.log(x) || x )
>>>   .map(plus1)
>>>   .reduce(add);
>>> ```
>>>
>>> Regards
>>>
>>>
>>> On Fri, Oct 16, 2015 at 10:13 AM, Niloy Mondal >> > wrote:
>>>
 Currently, `Array.prototype.forEach` returns `undefined`. It would be
 more
 useful if it returns the array itself.

 Say I have written some code like this...

 ```js
 const a = [1, 2, 3]
   .map(square)
   .map(plus1)
   .reduce(add);
 ```

 For some reason, I am not getting the expected output. For debugging, I
 would
 like the print the values after each step. My first initial reaction is
 to
 put a `forEach` step in between and print the values like so...

 ```js
 const a = [1, 2, 3]
   .map(square)
   .forEach(x => console.log(x))
   .map(plus1)
   .reduce(add);
 ```

 Unfortunately, this does not work as `forEach` returns `undefined`. I
 now have
 to comment out all the code below it. Having the _plug and play_
 behaviour for
 `forEach` would be very convenient.

 ___
 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: Exporting Symbols

[Alexander Jones]

Unless of course you needed to export a "features" AND support this magic
symbol.

On Thursday, 15 October 2015, Ron Buckton  wrote:

> Wouldn’t this work?
>
>
>
> our-symbols.js:
>
> ```js
>
> export const SpecialSymbol = Symbol("SpecialSymbol");
>
> ```
>
>
>
> their-consumer.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
>
>
> export const features = {
>
> [SpecialSymbol]: true
>
> };
>
> ```
>
>
>
> our-features.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
> import { features } from "their-consumer";
>
>
>
> if (features[SpecialSymbol]) {
>
>   // …
>
> }
>
> ```
>
>
>
> This uses an export named “features”, though in practice it’s pretty much
> the same as using “export default”. While the “features” identifier could
> theoretically be some other “features” with a different meaning, you can
> still detect the presence of your special symbol.
>
>
>
> Ron
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org
> ] *On
> Behalf Of *Francisco Tolmasky
> *Sent:* Thursday, October 15, 2015 10:47 AM
> *To:* Logan Smyth  >
> *Cc:* es-discuss@mozilla.org
> 
> *Subject:* Re: Exporting Symbols
>
>
>
> There are special features we want to expose if a module defines a certain
> key. However, we’d like to not rely on certain names just because there’s
> some chance they came up with it themselves. If it was a symbol that we
> gave them access to, it would be impossible for this to be the case, they
> would have had to grab the symbol from us:
>
>
>
> var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>
>
>
> export { whatever as SpecialSymbol }
>
>
>
> The difficulty I’m having right now is being torn by two competing “best
> practices”: on the one hand, you can’t do what I did above for the runtime
> reasons, on the other hand you CAN actually pull it off using the export
> default strategy, and in that situation it technically is safer for us to
> use our special symbol instead of relying on a string match.
>
>
>
>
>
> On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth  > wrote:
>
> The main issue is that modules are statically analysable and
> imports/exports are processed before the module executes, and the behavior
> of a symbol is by definition a runtime thing. Until the code executes,
> there would be no symbol object, and there would be no way to know what
> thing was being imported imported / exported.
>
>
>
> The primary benefit of symbols is that they are unique, and cannot collide
> unless you have a reference to them. Module exports have full control over
> their names and don't have the same collision issues that objects and
> classes generally do. What is the benefit you are hoping to get from
> exposing these values on symbols instead of string keys?
>
>
>
>
>
>
>
> On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky  > wrote:
>
> Not sure if it isn’t the case, but it seems the only way to export symbols
> right now is:
>
>
>
> ```js
>
> export default { [Symbol(“something”)]: blah }
>
> ```
>
>
>
> It would be nice if “symbol literals” could somehow be supported. In
> particular, I can imagine this sort of thing becoming common:
>
>
>
> export { “5.4” as Symbol(“version”) }
>
>
>
> Or, even better (but harder since its now more expression):
>
>
>
> import VersionSymbol from “symbols"
>
> export { “5.4” as VersionSymbol }
>
>
>
> I’m currently writing an API where there are expected methods stored in
> symbols, but this forces exporting one default object instead of being able
> to lay them out individual.
>
>
>
> Thanks,
>
>
>
> Francisco
>
>
>
> --
>
> Francisco Tolmasky
> www.tolmasky.com
> 
> tolma...@gmail.com 
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> 
> https://mail.mozilla.org/listinfo/es-discuss
> 
>
>
>
>
>
>
>
> --
>
> Francisco Tolmasky
> www.tolmasky.com
> 

Re: Curried functions

[Alexander Jones]

Too late, `add(a)` already returns `a + undefined`.

No reason why `const add = curry((a, b) => a + b)` couldn't work though?
Arrow functions have a length property AFAIK.

On Thursday, 15 October 2015, Yongxu Ren  wrote:

> How about making arrow function curry by default?
>
> const add = a => b => a + b;
>
> this will only works in case
>
> add(a)(b);
>
> But it won’t work if you do this
>
> add(a,b);
>
> If we could let arrow to work for both
>
> add(a)(b) and add(a,b)
>
> it will release the full power of functional programming and allow us to
> write code like in OCaml, F# or Haskell
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Alexander Jones]

Operator.plus? I'd be totally ok with that.

On Monday, 12 October 2015, Jordan Harband <ljh...@gmail.com> wrote:

> For that, the question would arise: is `scores.reduce((a, b) => a + b)`
> and `bools.filter(x => !x)` so troublesome to write that it's worth the
> added complexity to the language? "it would be nice" generally doesn't
> outweigh increased implementation and maintenance cost to implementors,
> learners, tool creators, etc.
>
> On Mon, Oct 12, 2015 at 10:20 AM, Mohsen Azimi <m...@azimi.me
> <javascript:_e(%7B%7D,'cvml','m...@azimi.me');>> wrote:
>
>> > reversed = names.sort(>)
>> > This might actually be possible - I can't think of any ambiguous
>> situations for passing operators as if they were first class functions. If
>> it is possible, I'd like to see this done.
>>
>> Yes, it would be really cool if operators can be used as function. For
>> example in Swift you can do this:
>>
>> ```
>> let scores = [10, 13, 15, 8, 9, 19, 20, 4, 6];
>>
>> let sum = scores.reduce(0, combine: +) // 104
>> ```
>>
>> Or this:
>>
>> ```
>> var bools = [true, false, false, true, true];
>>
>> bools.filter(!) // [false, false]
>> ```
>>
>>
>> On Mon, Oct 12, 2015 at 7:29 AM Andrea Giammarchi <
>> andrea.giammar...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','andrea.giammar...@gmail.com');>> wrote:
>>
>>> for "historical record" sake that silly trick works even in a more
>>> meaningful way with RegExp replacements  :-)
>>>
>>> ```js
>>> // before
>>> 'str'.replace(/(some)(thing)/, function ($0, $1, $2) {
>>>   //  boring $1 $2 like RegExp.$1 and  RegExp.$2
>>> });
>>>
>>> // now
>>> 'str'.replace(/(some)(thing)/, (...$) => {
>>>   // we have $[1], $[2] ... ya
>>> });
>>> ```
>>>
>>> Regards
>>>
>>>
>>>
>>> On Mon, Oct 12, 2015 at 7:40 AM, Isiah Meadows <isiahmead...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','isiahmead...@gmail.com');>> wrote:
>>>
>>>> Interesting trick, Andrea. Never thought of that before.
>>>>
>>>> On Mon, Oct 12, 2015, 02:31 Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','andrea.giammar...@gmail.com');>> wrote:
>>>>
>>>>> ... sort of (no  pun intended)
>>>>>
>>>>> ```js
>>>>> let sorted = names.sort((...$) => $[0] > $[1]);
>>>>> ```
>>>>>
>>>>> Regards
>>>>>
>>>>> On Mon, Oct 12, 2015 at 2:58 AM, Frankie Bagnardi <
>>>>> f.bagna...@gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','f.bagna...@gmail.com');>> wrote:
>>>>>
>>>>>> I don't think there's much value in this. Also sort is a bad example
>>>>>> because it'd look like this, and there's no nifty shortcut answer to it.
>>>>>>
>>>>>> ```js
>>>>>> names.sort((a, b) => a < b ? 1 : a > b ? -1 : 0);
>>>>>> ```
>>>>>>
>>>>>> In most cases you save a couple characters, but you can just use
>>>>>> x/y/a/b/f/g/n/xs/xss for variable names in arrow functions instead of the
>>>>>> $0 (which would likely be \0 in js).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Oct 11, 2015 at 3:26 PM, Caitlin Potter <
>>>>>> caitpotte...@gmail.com
>>>>>> <javascript:_e(%7B%7D,'cvml','caitpotte...@gmail.com');>> wrote:
>>>>>>
>>>>>>> In the case of sorting, are arrow functions not good enough? Or are
>>>>>>> we really asking for full continuation support
>>>>>>>
>>>>>>> On Oct 11, 2015, at 5:51 PM, Alexander Jones <a...@weej.com
>>>>>>> <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote:
>>>>>>>
>>>>>>> IMO this is a good idea. When it's abundantly clear from context,
>>>>>>> I've already been naming my arrow function params _ if singular, and 
>>>>>>> _1, _2
>>>>>>> etc if several. As always, picking some punctuation straight from the
>>>>>>> scarce and sacred set of remaining ASCII symbols is going to be tricky. 
>>&