Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

possible to have both modes, if the parser is >> designed for it. Unfortunately, that's not the case at the moment. >> >> Mozilla has recently started working on a new parser which could be used >> both by VMs and by JS/wasm devs. It might help towards this issue, but >> i

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

ild..beta..travis-ci.org/app/ On Sun, Sep 15, 2019 at 9:08 AM David Teller wrote: > In theory, it should be possible to have both modes, if the parser is > designed for it. Unfortunately, that's not the case at the moment. > > Mozilla has recently started working on a new parser whic

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

In theory, it should be possible to have both modes, if the parser is designed for it. Unfortunately, that's not the case at the moment. Mozilla has recently started working on a new parser which could be used both by VMs and by JS/wasm devs. It might help towards this issue, but it's still early

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Happy to see standard ast in binary ast proposal. For compiler, it can have a "slow" mode when parsing with this parser API and still use fast code generation in other cases. But unfortunately it seems there are much more work than I think to provide such an API. David Teller 于 2019年9月15日周日

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Before you can have a standard parser, you need a standard AST. There is no such thing as the moment, so the v8 parser, the SpiderMonkey parser and the JSCore parser, etc. all use distinct internal ASTs, each of which changes every so often, either because the language changes or because the VM

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

I do want to note a couple things here, as someone familiar with the implementation aspect of JS and programming languages in general: 1. The HTML and CSS parsers (for inline style sheets) have to build a full DOM trees for each anyways just to conform to spec, so they can't just, say, parse

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

I had a few goes with making a JS sandbox. I also created a safe DOM environment that allowed safe manipulation of innerHTML etc JS sandbox with regular expressions http://www.businessinfo.co.uk/labs/jsreg/jsreg.html JS sandbox and safe DOM environment

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

This proposal is not a part of the binary AST proposal. Because that proposal wants a binary representation and will not generate AST directly from the ecmascript spec. Because run those parsers in browser is pretty slow. Since the JS engine can already parse the JavaScript code, just expose those

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Out of curiosity, what is the expected benefit wrt Esprima, Babel or Shift? In particular since there is no standard AST for ECMAScript yet [1]? Cheers, David [1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast, which is in the pipes. On 14/09/2019 07:46, Jack Works wrote: >

A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Just like DOMParser in HTML and Houdini's parser API in CSS , a built-in parser for ECMAScript itself is quite useful in many ways. Check out https://github.com/Jack-Works/proposal-ecmascript-parser for

Re: Proposal: Add new 'Matrix' object

un, May 12, 2019 at 05:51 Ed Saleh wrote: > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and > AI. I am proposing a new object type of `Matrix([ []... ])` which would > make working with matrices easier, easily doing operations such matrices > `m

Re: Proposal: Add new 'Matrix' object

this is wishful thinking, but i've wondered whether [wasm] sqlite3 has better potential for general-purpose multidimensional vector-operations than whatever gets spec'ed out in javascript. probably not, but there's been research on sql "dot-product-joins" [1]. [1] Dot-Product Join: Scalable

Re: Proposal: Add new 'Matrix' object

A matrix could be viewed as an array of arrays or sets or maps or other values. How the values in the arrays or indexes are mapped is dependent upon the requirement. The requirement could be to map the networks of this entire planet earth; create sets of permutations; create cross word puzzles.

Re: Proposal: Add new 'Matrix' object

is that a tentative "no" as in tc39 can't easily spec some low-level linear-algebra primitives that would be useful for both dommatrix, and [gpu-accelerated] tensoflow? i do find value to industry for enhancing client-side performance of 3d visualization and ML. and i'm starting to see @Ed's

Re: Proposal: Add new 'Matrix' object

According to the specs, DOMMatrix is limited to 4d matrices. They can be used to emulate 1d-3d matrices trivially. However, many applications (e.g. in graph theory) require arbitrary numbers of dimensions. I'm not really familiar with Tensorflow, but if I read the API correctly, it seems to be

Re: Proposal: Add new 'Matrix' object

: >> >>> Hello, >>> >>> Matrices are widely used today in in Computer Science, Engineering, and >>> AI. I am proposing a new object type of `Matrix([ []... ])` which would >>> make working with matrices easier, easily doing operations such matrices >>

Re: Proposal: Add new 'Matrix' object

1 AM Ed Saleh wrote: > >> Hello, >> >> Matrices are widely used today in in Computer Science, Engineering, and >> AI. I am proposing a new object type of `Matrix([ []... ])` which would >> make working with matrices easier, easily doing operations

Re: Proposal: Add new 'Matrix' object

Is this proposal different from ```DOMMatrix()``` https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix ? On Sun, May 12, 2019 at 9:51 AM Ed Saleh wrote: > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and > AI. I am proposing a new object typ

Re: Proposal: Add new 'Matrix' object

On Sun, May 12, 2019 at 2:51 AM Ed Saleh wrote: > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and > AI. I am proposing a new object type of `Matrix([ []... ])` which would > make working with matrices easier, easily doing operation

Re: Proposal: Add new 'Matrix' object

n-specific. it ends up more cost-efficient for me to write custom for-loops, with malformed-data checks embedded in them. > On 12 May 2019, at 04:50, Ed Saleh wrote: > > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and AI. I > am proposing

Proposal: Add new 'Matrix' object

Hello, Matrices are widely used today in in Computer Science, Engineering, and AI. I am proposing a new object type of `Matrix([ []... ])` which would make working with matrices easier, easily doing operations such matrices `multiplication` and `addition`. Thank you

Re: Re: New Proposal: Number.range (Yes, range again)

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

Re: Proposal For A New Alternative Keyword To “this” For Classes

100%; >> } >> textarea { >> font-family: Consolas, Menlo, monospace; >> font-size: smaller; >> overflow: auto; >> width: 100%; >> } >> >> >> >> >> ajax-request >> { >> "metho

Re: Proposal For A New Alternative Keyword To “this” For Classes

t": "application/vnd.github.v3+json" > }, > "data": "hello world!" > } > > submit ajax-request > > ajax-response > > > > /*jslint browser*/ > (function () { > "use strict"; > var loc

Re: Proposal For A New Alternative Keyword To “this” For Classes

> today for private data). Private methods could be implemented in terms of >> weak sets/maps and an object with methods outside the class's scope. >> Private static properties could just verify `this === Type`. >> >> So no, those don't quite reify classes, either. (If something c

Re: Proposal For A New Alternative Keyword To “this” For Classes

```class RequestManager { __THIS__(method) { return new Proxy(method, { apply: (target, thisArg, argumentsList) => { return method.apply(thisArg, [...argumentsList, { THIS: this }]) } }) } constructor() { this.successMessage = "Xhr su

Re: Proposal For A New Alternative Keyword To “this” For Classes

t; So no, those don't quite reify classes, either. (If something can be fully > transpiled or polyfilled, it doesn't create or reify any new primitives.) > > On Tue, Mar 12, 2019 at 09:51 Ranando King wrote: > >> I get what you're after. I touched on the same things when creating m

Re: Proposal For A New Alternative Keyword To “this” For Classes

static properties could just verify `this === Type`. So no, those don't quite reify classes, either. (If something can be fully transpiled or polyfilled, it doesn't create or reify any new primitives.) On Tue, Mar 12, 2019 at 09:51 Ranando King wrote: > I get what you're after. I touched on the s

Re: Proposal For A New Alternative Keyword To “this” For Classes

@John May I suggest you play around a little with Lua? That language is prototype-based like JS, with several similar idioms, but it's a lot simpler, without `new`, property descriptors, or the like. Like JS, it also has a keyword `self` equivalent to JS `this` and inheritance is purely prototype

Re: Proposal For A New Alternative Keyword To “this” For Classes

t would >>> > be already there. The run-time will know which instance the invoked >>> > method belongs to. >>> >>> Well no, you're wrong here: the runtime does not have this information >>> at hand. In your example (simplified) >>> ``` >>

Re: Proposal For A New Alternative Keyword To “this” For Classes

it would >> > be already there. The run-time will know which instance the invoked >> > method belongs to. >> >> Well no, you're wrong here: the runtime does not have this information >> at hand. In your example (simplified) >> ``` >

Re: Proposal For A New Alternative Keyword To “this” For Classes

would > > be already there. The run-time will know which instance the invoked > > method belongs to. > > Well no, you're wrong here: the runtime does not have this information > at hand. In your example (simplified) > ``` > var reqManager = new RequestManager(); >

Re: Proposal For A New Alternative Keyword To “this” For Classes

belongs to. Well no, you're wrong here: the runtime does not have this information at hand. In your example (simplified) ``` var reqManager = new RequestManager(); function addEventListener(f) { console.log(f); f(event); } addEventListener(reqManager.responseHandler

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

Whatever the implementation, I'd be surprised to learn that the browser *does* have the information automatically and wouldn't need to store additional memory similar to .bind(). But I'm also not a browser engine expert, so there's that. Le lun. 11 mars 2019 11 h 55, john larson a écrit : >

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

Well, actually this is the same discussion we had with *@Jordan Harband. *I think the js run-time already has that information at hand, so as long as we don't implement this as pure syntactical sugar, there would not be a need to keep an extra reference to anything, because it would be already

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

The main issue here is that you're sort of asking for something too late. If you reference the "notThis" keyword inside a callback method that has been separated from "its own" class instance, you're now saying "could you please do this all in the context of your instance", but your method

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

*@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the proposal and as far as I understand, it is just another way to create a bound enclosing function. What I am proposing is just the opposite, no binding should take place in the enclosing function. A method call or usage of a

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

I would imagine that this can be achieved with bind operator proposal, which already has Babel support, despite no examples showing usage inside a class. Something like: `oReq.addEventListener("load", ::this.responseHandler);` seems to be the syntax that will de-sugar to

Re: Proposal For A New Alternative Keyword To “this” For Classes

First of all, thank you all for taking the time to review the proposal and sharing your valuable opinions. I would like to note that the proposal aims not to add a new capability that was not possible to do before but rather move the standard forward on the way for a modern, better and easier

Re: Proposal For A New Alternative Keyword To “this” For Classes

This is probably not the pattern that is being proposed though outputs the expected result ```class RequestManager { constructor() { this.successMessage = "Xhr successful."; RequestManager.THIS = this; } makeRequest() { var oReq = new XMLH

Re: Proposal For A New Alternative Keyword To “this” For Classes

>>> <#m_4773041203224270933_m_6849901573705770350_m_-8660865756228832385_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >>> On Sun, Mar 10, 2019 at 12:27 AM Jordan Harband >>> wrote: >>> >>>> An additional keyword like this would require

Re: Proposal For A New Alternative Keyword To “this” For Classes

reference back to the instance. However, especially for `class` >>> methods, but also for ES5-style inheritance, or even for `class Foo {} >>> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a >>> billion instances, but only one function that

Re: Proposal For A New Alternative Keyword To “this” For Classes

tional keyword like this would require a function to have a hidden >> reference back to the instance. However, especially for `class` methods, >> but also for ES5-style inheritance, or even for `class Foo {} >> Foo.prototype.bar = function () {}`, methods are *shared*. You might have a &

Re: Proposal For A New Alternative Keyword To “this” For Classes

s are *shared*. You might have a > billion instances, but only one function that uses your new keyword - how > would the engine know which instance you were referring to? > > On Sat, Mar 9, 2019 at 7:50 AM Bergi wrote: > >> Hi John, >> >> > I believe that it would be

Re: Proposal For A New Alternative Keyword To “this” For Classes

instances, but only one function that uses your new keyword - how would the engine know which instance you were referring to? On Sat, Mar 9, 2019 at 7:50 AM Bergi wrote: > Hi John, > > > I believe that it would be a trivial task for > > current static code analyzers

Re: Proposal For A New Alternative Keyword To “this” For Classes

Hi John, I believe that it would be a trivial task for current static code analyzers to restrict usage of "this" for anyone opting in to use this new keyword exclusively. Static tooling, like the TypeScript compiler, can detect problematic method usage already today. Sure, having a

Re: Proposal For A New Alternative Keyword To “this” For Classes

Hi Bergi, Thanks for your input. I believe that it would be a trivial task for current static code analyzers to restrict usage of "this" for anyone opting in to use this new keyword exclusively. But the same does not hold true for other work-arounds such as arrow functions. And i

Re: Proposal For A New Alternative Keyword To “this” For Classes

Hi John, I don't think we do need another keyword for this. People would forget to use that new keyword instead of using this, just like they currently forget to use arrow functions. That said, your desired "behind-the-scenes implementation" can already be achieved easily with the cl

Proposal For A New Alternative Keyword To “this” For Classes

.bind(this) syntax Just assuming we forgot to use an arrow function or a .bind(), the IDE will not be able to raise an error and we will encounter the error in run-time. *What I propose:* I am proposing a new keyword that will be the alternative of "this" and will always point to th

Re: New Proposal: Number.range (Yes, range again)

number, end: number, step: number): >>>>> IterableIterator; >>>>> export function* range(start: number, end?: number, step?: number): >>>>> IterableIterator { >>>>> // overload #1 >>>>> if (end === undefined) { >>>>

Re: New Proposal: Number.range (Yes, range again)

gt;>>> IterableIterator; >>>> export function* range(start: number, end?: number, step?: number): >>>> IterableIterator { >>>> // overload #1 >>>> if (end === undefined) { >>>> [start, end, step] = [0, start, 1]; >>>

Re: New Proposal: ES Call Stack

Isiah, that works when you're in full control of all the code. However, when you're writing B, and A is 3rd party (or the reverse in DI cases) then the API is out of your control. In cases like that, it's better if the data itself knew the restrictions. That keeps dependencies low. On Mon, Jan

Re: New Proposal: ES Call Stack

We agree trying to learn about the caller should not affect how the caller works. That's why I was thinking more on the lines of an "id" carried around by every function object. As long as that "id" uniquely identified the function without providing any access to the function itself, it would

Re: New Proposal: ES Call Stack

You could substitute a function parameter accepting an object here or a class instance for globals to dodge this. Doesn't change my point. Here's how you deal with permissions like that: have A know what data B is allowed to access, then pass B an object with only that data. If necessary, make

Re: New Proposal: ES Call Stack

"who calls function B" has, and must have, no bearing on how function B behaves. Every single call site that passes identical (`Object.is`) arguments must behave the same. Am I misunderstanding what you mean? On Sun, Jan 13, 2019 at 9:50 PM Ranando King wrote: > That's all fine and dandy until

Re: New Proposal: ES Call Stack

That's all fine and dandy until you're dealing with a project that has a "no globals" mandate. The problem that I'd want to be able to solve is one of gaining and losing control during a single function's execution. For example: say function A is privileged, but function B is not. Function A calls

Re: New Proposal: ES Call Stack

As for security, scope control is usually the more important thing to monitor. That's covered in realms for the most part, but also a few other things. Stack traces don't play a major part here, and whenever untrusted calls need made and tracked through the stack, it's not that hard to just save

Re: New Proposal: ES Call Stack

You may be interested in this: https://github.com/tc39/proposal-error-stacks On Sun, Jan 13, 2019 at 22:02 Ranando King wrote: > ES used to have Function.caller for traversing the call stack, but > apparently this was very problematic for engine development and prevented > various optimizations.

New Proposal: ES Call Stack

ES used to have Function.caller for traversing the call stack, but apparently this was very problematic for engine development and prevented various optimizations. So now it doesn't work in strict mode which makes it useless for code involving `"use strict"` or `class`. One of the main use cases

Re: New Proposal: Placeholder syntax

thank you all for the feedback, I appreciate those who pointed out the flaws in the logic. I can see that this is an ambiguous proposal. Though I did not realize it at the time, this proposal is competing with https://github.com/tc39/proposal-partial-application, as the two syntax's cannot exist

Re: New Proposal: Placeholder syntax

On 11/28/2018 10:17 AM, Andrew Kaiser wrote: Hi all, I have created a short proposal to introduce syntactic sugar for anonymous functions in a 'scala-like' manner, linked here https://github.com/andykais/proposal-placeholder-syntax. I am hoping to hear feedback on whether or not this is

Re: New: proposal-class-modifiers

you please keep this extremely condescending tone out of these discussions? I don't know how you expect people to get on board with your proposals when you constantly imply that those that disagree with you don't know what they are talking about. > The constructor only comes into play after a new

Re: New: proposal-class-modifiers

@Logan > It would not be good if you could sidestep `abstract` by taking the prototype from the class and making a new constructor for it. That's precisely why it's a prototype test and not a constructor test. Everything that defines the initial "shape" of the class is on

Re: New: proposal-class-modifiers

is the class constructor itself. It would not be good if you > could sidestep `abstract` by taking the prototype from the class and making a > new constructor for it. > > For `final` is it worth throwing an `extends` time vs just throwing when the > class is instantiated? It seems l

Re: New: proposal-class-modifiers

and making a new constructor for it. For `final` is it worth throwing an `extends` time vs just throwing when the class is instantiated? It seems like `final` would otherwise require new private state on the constructor itself, where otherwise it would essentially just be the negation of the check

Re: New: proposal-class-modifiers

at I'm targeting. I can conceive of a means to make even these functions > respect these tokens. However, if I were going to do that, I'd want these > tokens to be applicable to objects and functions directly. > Reflect.construct is essentially part of the process for `new` and would be > r

Re: New: proposal-class-modifiers

. Reflect.construct is essentially part of the process for `new` and would be required to respect these tokens. I'm still open on how far the effect of these tokens should extend. On Sun, Dec 2, 2018 at 3:20 PM Isiah Meadows wrote: > How would this interop with `Object.create`, `Reflect.constr

Re: New: proposal-common-member-modifiers

ine them now? > > In my opinion this is not how things should be done, in my opinion we > actually should follow user-land patterns and help modifying/extending > the language in this patterns pain points. We saw that in almost every > new feature in the language since Harmo

Re: New: proposal-class-modifiers

How would this interop with `Object.create`, `Reflect.construct`, and `Object.setPrototypeOf`? On Sun, Dec 2, 2018 at 16:16 Ranando King wrote: > This proposal is intended to add `abstract` and `final` to `class` > definitions so as to modify the inheritability of a class. > >

Re: New: proposal-common-member-modifiers

Decorators are stage 2. No major implementation implements them, and Babel dropped them and had to completely reimplement their semantics after a major semantic overhaul in the proposal. https://github.com/tc39/proposal-decorators/ On Sun, Dec 2, 2018 at 15:15 Ranando King wrote: > I get that

New: proposal-class-modifiers

This proposal is intended to add `abstract` and `final` to `class` definitions so as to modify the inheritability of a class. https://github.com/rdking/proposal-class-modifiers ___ es-discuss mailing list es-discuss@mozilla.org

Re: New: proposal-common-member-modifiers

ending the language in this patterns pain points. We saw that in almost every new feature in the language since Harmony (not a coincidence, it's was actually decided to be this way), community agreement is a important factor in the process (I really don't know why it's not in the TC39 process docum

Re: New Proposal: Placeholder syntax

I find the "receiver" usage actually pretty useful. I know how I like to be able to do something like Smalltalk packages do: #commit in Amber Smalltalk (even if it would be only a few chars longer Smalltalk packages do: [ :each | each commit ] but readability is different, b/c the spirit

Re: New: proposal-common-member-modifiers

I just want to make it perfectly clear to everyone that neither I am a member of TC39 Best regards /p On 2 December 2018 09:31:23 Isiah Meadows wrote: For one token (+ an import) more, you could use decorators instead. And BTW, it's been suggested already that a standard decorator library

Re: New: proposal-common-member-modifiers

I get that decorators "can" perform the same task, but these are features that are standard in the language today. Once we start defining data properties on classes, there will be an immediate need to define the attributes of those properties. Yes, decorators can fill the need, but unless a

Re: New: proposal-common-member-modifiers

For one token (+ an import) more, you could use decorators instead. And BTW, it's been suggested already that a standard decorator library should exist, just IIUC (I'm not part of TC39) it's not yet determined what should be in it. - Isiah Meadows cont...@isiahmeadows.com

Re: New: proposal-common-member-modifiers

I'm of the opinion this is what decorators are for. On Sun, Dec 2, 2018, 01:49 Ranando King Since some form of data is going to land in ES class syntax, it would be a > good idea if the capabilities of a property descriptor were also exposed > for all public properties. > >

New: proposal-common-member-modifiers

Since some form of data is going to land in ES class syntax, it would be a good idea if the capabilities of a property descriptor were also exposed for all public properties. https://github.com/rdking/proposal-common-member-modifiers ___ es-discuss

Re: New Proposal: Number.range (Yes, range again)

or; >>>> export function* range(start: number, end?: number, step?: number): >>>> IterableIterator { >>>> // overload #1 >>>> if (end === undefined) { >>>> [start, end, step] = [0, start, 1]; >>>> } >>>> >>>

Re: New Proposal: Number.range (Yes, range again)

t;>> if (step === undefined) { >>> step = Math.sign(end - start); >>> } >>> >>> // ensure we have the appropriate types >>> if (typeof start !== 'number' || typeof end !== 'number' || typeof >>> step !== 'number') { >>&

Re: New Proposal: Number.range (Yes, range again)

;> if (step === undefined) { >> step = Math.sign(end - start); >> } >> >> // ensure we have the appropriate types >> if (typeof start !== 'number' || typeof end !== 'number' || typeof step >> !== 'number') { >> throw new Type

Re: New Proposal: Number.range (Yes, range again)

> } > > // overload #2 > if (step === undefined) { > step = Math.sign(end - start); > } > > // ensure we have the appropriate types > if (typeof start !== 'number' || typeof end !== 'number' || typeof step > !== 'number') { > throw new TypeError('

Re: New Proposal: Number.range (Yes, range again)

start !== 'number' || typeof end !== 'number' || typeof step !== 'number') { throw new TypeError('all parameters must be of type number'); } while ((start < end && step > 0) || (start > end && step < 0)) { yield start; start += step; } } ``` IMO, we

RE: New Proposal: Placeholder syntax

argument list. Ron From: es-discuss On Behalf Of Andrew Kaiser Sent: Wednesday, November 28, 2018 11:57 AM To: ljh...@gmail.com Cc: es-discuss@mozilla.org Subject: Re: New Proposal: Placeholder syntax This proposal also works with simple math operations and for accessing fields on objects. Th

Re: New: proposal-safe-prototype

afe-prototype; var b = Object.getPrototypeOf(a).foo; b.bar = 3; ``` This would skip the new behavior, causing the prototype to be modified directly. > Unless you have deep knowledge of the internal state and/or the implementation of the modified object (which you don’t have in case of a user-impleme

Re: New: proposal-safe-prototype

= { __proto__: proto } with safe-prototype; var b1 = a1.foo; var b2 = a2.foo b1 === b2; // true b1.bar = 3; b1 === b2; // ??? ``` -- 2. Object mutations unrelated to the value of its properties: ```js var a = { __proto__: { foo: new Map([ [ 'bar', 2 ] ]) } } with safe-prototype; a.foo.set('bar', 3

Re: New Proposal: Number.range (Yes, range again)

I end up writing a range function in virtually every project I use, so yeah, I think this is worthwhile. My own preferences, based on Python precedence: Number.range(end) === Number.range(0, end, 1) Number.range(start, end) === Number.range(start, end, Math.sign(end-start)) Number.range(start,

Re: New Proposal: Placeholder syntax

> Le 28 nov. 2018 à 19:17, Andrew Kaiser a écrit : > > Hi all, > > I have created a short proposal to introduce syntactic sugar for anonymous > functions in a 'scala-like' manner, linked here > https://github.com/andykais/proposal-placeholder-syntax >

Re: New Proposal: Placeholder syntax

Aside from the fact that this "placeholder" proposal addresses the "receiver" and "operator" cases that partial-application explicitly omits, the two proposals are exactly identical. They're not "complementary", they're the same thing, just making a different decision wrt complexity of some of the

Re: New Proposal: Placeholder syntax

offer that partial application > does not? > > On Wed, Nov 28, 2018 at 11:23 AM Andrew Kaiser > wrote: > >> Do you see a way these proposals can work together? I believe they are >> solving different needs. Both proposals produce a new anonymous function, >> but partial

Re: New Proposal: Placeholder syntax

eve they are > solving different needs. Both proposals produce a new anonymous function, > but partial application deals with currying, while the placeholder proposal > tries to prevent writing a function at all. I can actually see the two > working together: > > ```js > const filenames =

Re: New Proposal: Placeholder syntax

Do you see a way these proposals can work together? I believe they are solving different needs. Both proposals produce a new anonymous function, but partial application deals with currying, while the placeholder proposal tries to prevent writing a function at all. I can actually see the two

Re: New Proposal: Placeholder syntax

You may be interested in the partial application proposal: https://github.com/tc39/proposal-partial-application On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser wrote: > Hi all, > > I have created a short proposal to introduce syntactic sugar for anonymous > functions in a 'scala-like' manner,

New Proposal: Placeholder syntax

Hi all, I have created a short proposal to introduce syntactic sugar for anonymous functions in a 'scala-like' manner, linked here https://github.com/andykais/proposal-placeholder-syntax. I am hoping to hear feedback on whether or not this is interesting to people, as well as feedback on the

New Proposal: Number.range (Yes, range again)

Hello everyone. I've searched for the mailing list, there are some discussions add `new Range` or `a ... b` into the language but not become a formal proposal. I've made a full demo(polyfill) these days. Anyone interested? Preview: `for (let i of Number.range(1, 5)) console.log(i

Re: New: proposal-safe-prototype

Ok. I just updated the proposal. Since T.J. felt so strongly about the use of the word "template", I removed it from the proposal. No need to raise unnecessary ire. Since using `new` to trigger the behavior is a no-go just like pragmas, I introduced 2 new well known Symbols. * `Symbol

Re: New: proposal-safe-prototype

Correct, existing code *used with* existing code can't break. It's totally fine for existing code that works with objects produced by new code to break. On Tue, Nov 27, 2018 at 11:05 AM Ranando King wrote: > Is this to say that no new feature is allowed to introduce breaking > c

Re: New: proposal-safe-prototype

What if, instead of having `new` introduce a flag on an internal slot, we define a new "well known" Symbol: Symbol.SafeProto = new Symbol("SafeProto"); such that if this Symbol is a property of an object being used as a prototype (regardless of its value), then that proto

Re: New: proposal-safe-prototype

Is this to say that no new feature is allowed to introduce breaking changes in existing code? On Tue, Nov 27, 2018 at 1:00 PM Jordan Harband wrote: > What I meant by "preserve existing behavior" is that *all current code* > must retain the footgun. Any chance must only a

Re: New: proposal-safe-prototype

What I meant by "preserve existing behavior" is that *all current code* must retain the footgun. Any chance must only apply to new code that explicitly opts in to it. On Tue, Nov 27, 2018 at 10:55 AM Ranando King wrote: > > Not something you'd want to do often... > > Or

  1   2   3   4   5   6   7   8   9   10   >