Re: async/await -> await/async: a simpler, less error-prone async syntax

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

Re: Identifying pure (or "pure within a scope") JavaScript functions?

apologies. reading the github issue more closely, i'm not an expert on this matter. -kai > On Dec 8, 2017, at 3:23 AM, Alex Vincent wrote: > > TLDR: -1 is much more useful in mathematics than in expressing an opinion. > > Mr. Zhu, > > In this case I am the

Re: Identifying pure (or "pure within a scope") JavaScript functions?

TLDR: -1 is much more useful in mathematics than in expressing an opinion. Mr. Zhu, In this case I am the implementer, and I generally know what I'm doing after well over fifteen years of working with the language, including the membrane library we're talking about, and including writing an

Re: Identifying pure (or "pure within a scope") JavaScript functions?

> This led down a long, rambling path [1] where I then realized: if the > callback function is a pure function, then for the purposes of that callback, > the arguments probably do not need to be wrapped in proxies at all. The big > catch is that the callback can't store any of the arguments

Re: Identifying pure (or "pure within a scope") JavaScript functions?

On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent wrote: > OK, OK, clearly, pure functions are a fantasy in JavaScript. Once again, a > great idea and a lengthy essay of a post falls to a real-world situation. > Nuts. > > What if there's a middle ground? In the case I was

Re: Identifying pure (or "pure within a scope") JavaScript functions?

Seems like you're asking for a check for if the function is a closure. If it maintains references to variables outside the scope of the function. So would an `isClosure` function work for at least a little of what you want? On Dec 7, 2017 11:11, "Alex Vincent" wrote: > OK,

Re: Identifying pure (or "pure within a scope") JavaScript functions?

OK, OK, clearly, pure functions are a fantasy in JavaScript. Once again, a great idea and a lengthy essay of a post falls to a real-world situation. Nuts. What if there's a middle ground? In the case I was originally talking about, the developer calling on my membrane controls how the callback

Re: Identifying pure (or "pure within a scope") JavaScript functions?

Relevant discussions: < https://groups.google.com/d/msg/mozilla.dev.tech.js-engine/aSKg4LujHuM/2Y9ORBwCIQAJ > and: < https://mail.mozilla.org/pipermail/es-discuss/2012-November/thread.html#26657 > On Thu, Dec 7, 2017 at 11:15 AM, Michał Wadas wrote: > Only extremely

Re: Identifying pure (or "pure within a scope") JavaScript functions?

Only extremely small subset of functions can be proven to be pure. And I suppose that these functions are already optimized by engines. eg. notPure = (a,b) => a + b; // implicit conversion with side effects can happen notPure = (a) => a && a.b; // getter can be called notPure = (foo, bar) =>

Re: Identifying pure (or "pure within a scope") JavaScript functions?

So… is the following function pure? let env = 1; function tryMe() { if (false) { env = 2; } } On Thursday, December 7, 2017 5:22:37 PM CET Alex Vincent wrote: > TLDR: I'm asking for the group to consider adding a Function.isPure(func) > or isPureWithinScope() to

Identifying pure (or "pure within a scope") JavaScript functions?

TLDR: I'm asking for the group to consider adding a Function.isPure(func) or isPureWithinScope() to the ECMAScript specification, to help code detect pure functions. This morning, I had a thought experiment about membranes, and in particular, callback functions passed into them. If the callback

Re: async/await -> await/async: a simpler, less error-prone async syntax

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

Re: async/await -> await/async: a simpler, less error-prone async syntax

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

Re: async/await -> await/async: a simpler, less error-prone async syntax

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

Re: async/await -> await/async: a simpler, less error-prone async syntax

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 On Thu, 7 Dec 2017 at 16:15 Florian Bösch wrote: > as I predicted once you use it, await/async infests all calls/funcdefs, > and has now become

Re: async/await -> await/async: a simpler, less error-prone async syntax

> On Dec 7, 2017, at 5:50 PM, Isiah Meadows wrote: > > The real solution to that would be stackful coroutines, but those are tricky > to implement and are substantially slower at lower nesting levels. (Go's > goroutines are built from this under the hood.) There's

Re: async/await -> await/async: a simpler, less error-prone async syntax

The real solution to that would be stackful coroutines, but those are tricky to implement and are substantially slower at lower nesting levels. (Go's goroutines are built from this under the hood.) There's tradeoffs to be made. On Thu, Dec 7, 2017, 05:45 Florian Bösch wrote: >

Re: async/await -> await/async: a simpler, less error-prone async syntax

as I predicted once you use it, await/async infests all calls/funcdefs, and has now become pointless line-noise that you need to remember to write or you will get into trouble, but serves no discernable semantic, syntactic or logical function other than making you type more. solution: write a