Re: Re: New Set methods - again

I've often found myself re-implementing this functionality and I am a big fan of this proposal, minor reservations that I expressed way back about `Set.prototype.union` vs `Set.union` (etc) aside. Nice work on beginning the formal spec, I really hope this picks up steam. Out of curiosity, what is

Re: A twist on functional operatorsr

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 twist on functional operatorsr

The proposal to write `arr.reduce((+))`, with `(+)` as an alternative to `(a, b) => a + b` is admirably concise, but syntactically challenging. I propose an alternative which is slightly less compact, but hopefully more implementable and general. The idea is a new form of function we'll call a "po

Re: Pattern matching?

For those of you still wanting to follow the current state of things, check out the proposal's repo [1], and the issue tracking my alternate proposal [2]. [1]: https://github.com/tc39/proposal-pattern-matching [2]: https://github.com/tc39/proposal-pattern-matching/issues/17 - Isiah Meadows m

New Set methods - again

Hey. Year ago, I have written proposal for new Set methods . Today I have written most of it's formal spec ( https://ginden.github.io/set-methods/ ) and I would like to know your thoughts. I would especially appreciate verification a formal sp

Re: Quoted map keys (was: Re: JSON5)

On Fri, Jul 14, 2017 at 9:39 AM, Dirk Pranke wrote: > On Fri, Jul 14, 2017 at 6:37 AM, J Decker wrote: > >> >> but; JSON5 is ES5 and will end up staying that way. trailing commas in >> arrays end up making if function diffferently that JS. >> >> So I forked it; and made JSON6 (npm json-6); not

Re: Quoted map keys (was: Re: JSON5)

TOML standardizes the INI format and adds features like nesting. The INI format is just a convention, so saying TOML would be the same thing is missing the point. The lack of standardization or features like nesting also goes to explain why XML and JSON have been more popular as config formats. XML

Re: Operator overloading proposal

You mean this? https://www.slideshare.net/BrendanEich/int64 (slide 12 and following) This would be cool. 2017-07-14 18:03 GMT+02:00 Michał Wadas : > To be honest, I recommend to abandon all ideas of operator overloading for > arbitrary types - that's extremely unlikely to happen. It's heavily aff

Re: Quoted map keys (was: Re: JSON5)

On Fri, Jul 14, 2017 at 6:37 AM, J Decker wrote: > TOML is just INI format. It doesn't even support nesting objects very > well. If that was so great, it wouldn't have been replaced since the 90's. > YAML with required spaces and newlines doesn't make a very good format > for protocol and inte

Re: Operator overloading proposal

To be honest, I recommend to abandon all ideas of operator overloading for arbitrary types - that's extremely unlikely to happen. It's heavily affects optimization possibilities, requires extensive type checks. Moreover, there is no interest from browser vendors to implement it. However, I expect

Re: Quoted map keys (was: Re: JSON5)

TOML is just INI format. It doesn't even support nesting objects very well. If that was so great, it wouldn't have been replaced since the 90's. YAML with required spaces and newlines doesn't make a very good format for protocol and interchange. Neither are > JSON. but; JSON5 is ES5 and will e

Re: Operator overloading proposal

> > No. It is a solution to a problem I have today: arithmetic on decimal values. > would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arith

Re: Operator overloading proposal

overloaded simd-operators is again a solution in search of a problem. complex-arithmetic and matrix-operators has no significant application in the web-industry. also, my experience with numeric javascript apps has been that generic matrix operations never quite do what i want, and the scope of

Re: Naming convention for multi-word identifiers with initialisms

Regarding naming, ES itself is pretty consistent: - Types are PascalCase. Ex: WeakMap - Non-symbol constants are UPPER_SNAKE_CASED. Ex: Number.MAX_SAFE_INTEGER - Initalisms within names are always lower case if first and not part of a type name, upper case otherwise. Ex: JSON, Date.prototype.toJSO

Re: Operator overloading proposal

It would actually be of substantial benefit to readability if you *could* overload operators for numeric, vector, and matrix-like types. In particular, I'd strongly prefer if SIMD types, if added, *did* use overloaded operators similarly to the BigInt proposal - it's honestly ridiculous why people

Re: Quoted map keys (was: Re: JSON5)

YAML is an alternative to JSON in that they're both data serialization formats. YAML lost out in this role to XML in the past, to JSON more recently, and will most likely lose to TOML as a config format (it being a special case of data serialization). YAML simply has a bloated spec with too many wa

Re: operator overloading proposal

Two primary concerns: 1. JS uses proxies for a few similar hooks (like `foo["prop"]` and `foo()`) now. Python uses `__getattr__` and `__call__` for those, but JS doesn't use magic methods for those. 2. Performance is going to be much harder to ensure, especially if you can mutate the operator met

Re: Operator overloading proposal

> No. It is a solution to a problem I have today: arithmetic on decimal values. would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every arithm

Re: Re: Operator overloading proposal

> javascript operator-overloading is a solution in search of a problem. No. It is a solution to a problem I have today: arithmetic on decimal values. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Quoted map keys (was: Re: JSON5)

On Fri, Jul 14, 2017 at 8:38 AM, Isiah Meadows wrote: > ...As for putting it in JS core, I say no. TOML is not a good > *interchange* format, and human-readable data formats...belong as > libraries, not in core. > ^^ this. Too many conflicting, usage-specific requirements and design constraints.

Re: Quoted map keys (was: Re: JSON5)

My one and only complaint about it is that it's still not officially stable (its version is 0.x), but that's the only reason why I'm not using it for everything. As for putting it in JS core, I say no. TOML is not a good *interchange* format, and human-readable data formats (which see endless bike

Re: Naming convention for multi-word identifiers with initialisms

Microsoft said "XMLHttpRequest" in August 1999 [*1], a month before feature request for Mozilla [*2]. [*1] https://web.archive.org/web/19990828184122/http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_Object.asp [*2] https://bugzilla.mozilla.org/show_bug.cgi?id=15119 On 2017/07/