Re: Additional Math functions

Note that the theoretical O(n) isn't always a good unit of measurement for practical speed. Having to keep extra precision variables, or having extra operations inside the loop will seriously slow down the computation, while keeping it O(n). I'd prefer that Math.sum(a, b, c) == a + b + c. In

Re: Alternative to Promise

There are no problems with reusability that I can think of as a result of the internal state machine. The functions passed to `.then` are just plain functions, so they are perfectly reusable. I don't think there is a significant overhead to promises once properly optimised. I don't see how

Look-behind proposal in trouble

Apparently my proposal for adding the look-behind assertions to RegExp has been in trouble. I would like to ask anyone for help. The following story is what I know about the proposal after my previous post: I created a pull request for the proposal in July and sent an email to Brendan Eich

Re: Alternative to Promise

On Sat, Oct 3, 2015 at 5:37 PM, 韩冬 wrote: > > This is exactly where i’m getting puzzled, suppose we have thread in > javascript(or whatever to run different things on different cores), > consider following code: > > We don't have threads in JavaScript, and there is no

Re: Alternative to Promise

On Sat, Oct 3, 2015 at 6:00 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > well > > > In fact, oftentimes the way people code uses closures which tend to be > more expensive than creating promises anyway. > > you pass "closures" to create a promise, a then and a catch, not sure >

Function.prototype.partial

It'd be nice to add Function.prototype.partial, which is exactly like `.bind` without the `this`-setting first argument. Adding it would have benefits: - `.bind(null, ...` is newbie confusing and ugly in functional code[1] - `.bind(null, ...` is a very common idiom[2] - `.partial` is intention

Re: Alternative to Promise

Sorry i messed up with the code format in previous mail, this one should work: > There are no problems with reusability that I can think of as a result of the > internal state machine. The functions passed to `.then` are just plain > functions, so they are perfectly reusable. Sorry, i should

Re: Alternative to Promise

> There are no problems with reusability that I can think of as a result of the > internal state machine. The functions passed to `.then` are just plain > functions, so they are perfectly reusable. Sorry, i should be more clear about reusability i’m referring are not the functions you passed,

Re: Re: Additional Math functions

On Thu, Oct 1, 2015 at 6:52 PM Eli Perelman wrote: > Reviving this thread, doing any type of simple statistics is more verbose > than it probably needs to be as calculating sums, averages, etc. makes most > resort to Array reduction. I understand the need for methods such

Re: Function.prototype.partial

I think his point was that in the functional programming way he is thinking about, you don't care about `this` at all so you can shim `partial` like: ```js Object.defineProperty( Function.prototype, 'partial', { writable: true, configurable: true, value: function partial() {

Re: Function.prototype.partial

for code sake, the dynamic should copy and push, not just push ```js Object.defineProperty( Function.prototype, 'partial', { writable: true, configurable: true, value: function partial() { for (var f = this, a = [], i = 0; i < arguments.length; a[i] = arguments[i++]);

Re: Function.prototype.partial

(note, it couldn't be a direct proxy to `bind` because `bind(null)` permanently sets the "this" value (ie, `(function () { return this }).bind(null).call([])` will return null or the global object, not the empty array. the polyfill would be a bit trickier, and couldn't use "bind" under the hood