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

[Florian Bösch]

On Mon, Feb 12, 2018 at 11:27 AM, Алексей  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
>

You could also have the IDE automatically insert await automatically
whenever it a codeline calls out to an async function. To make it more
convenient, the IDE could then also automatically insert an async/await
into any intermediary call-stack. You could also detect whenever a built-in
async function is called, and do the same, so you don't need to designate
it extra. Then make the async/await invisible and just color it.

Or, you know, just implement greenlets.
___
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

[Florian Bösch]

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 <naveen.c...@gmail.com> 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 <pya...@gmail.com> wrote:
>
>> On Thu, Dec 7, 2017 at 2:34 PM, Naveen Chawla <naveen.c...@gmail.com>
>> 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

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

[Florian Bösch]

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

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

[Florian Bösch]

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 transpiler that inserts await/async into all
calls/funcdefs

On Sun, 3 Dec 2017 at 12:01, Steven Mascaro  wrote:

> Sorry for making this request now (rather than when async/await was first
> being formulated), but real-world use has led me to think some things could
> benefit from a slightly different syntax. I also apologise if this has been
> raised/discussed before, I wasn't able to find it. The proposal is most
> quickly explained with an example.
>
> Current:
>
> class RemoteService {
> async init() { ... }
> async setProp(id, val) { ...; return this }
> async getProp(id) { return ... }
> async runInBackground() { ... }
> }
>
> async function remoteExample() {
> let remote = new RemoteService();
> await remote.init();
> await (await remote.setProp('a', 1)).setProp('b', 2);
> remote.runInBackground();
> let val = await remote.getProp('a');
> return val;
> }
>
> Proposed:
>
> class RemoteService {
> await init() { ... }
> await setProp(id, val) { ...; return this }
> await getProp(id) { return ... }
> await runInBackground() { ... }
> }
>
> await function remoteExample() {
> let remote = new RemoteService();
> remote.init();
> remote.setProp('a', 1).setProp('b', 2);
> async remote.runInBackground();
> let val = remote.getProp('a');
> return val;
> }
>
> Why:
>
> Running things in a genuinely asynchronous way is actually *unusual*. The
> current async/await syntax (which I think should still stay) is the exact
> reverse of what fits the probable use cases. Missing the 'await' keyword
> (particularly on functions/methods that don't return a value) causes all
> sorts of hard to track down bugs. I myself didn't realise this until I (and
> others I work with) started making intense use of async/await.
>
> The new proposed syntax above is obviously much simpler and would be very
> hard to get wrong. By contrast, the original syntax has proven surprisingly
> difficult to get consistently right. Even now with quite a lot of practice,
> I'm occasionally forgetting an await here and there. In addition, patterns
> like chaining get ugly *very* quickly. (Although I guess that could also be
> fixed with a method-friendly async call syntax.)
>
> If the proposed syntax were available in addition to the current syntax,
> you could apply whichever keyword in the function declaration is most
> likely applicable at call sites. e.g. runInBackground could be declared
> 'async' rather than 'await', if you normally expect it to be run in the
> background.
>
> ___
> 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 vision thing

[Florian Bösch]

On Thu, Nov 2, 2017 at 4:43 AM, kai zhu  wrote:

> > the primary reason is because traditional oop skills gained from
> c#/c++/java/python/etc translate poorly to javascript.
>
I've never found that to be the case.

>in javascript, class-instantiated objects are inferior to plain-objects,
> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
> classes require needless extra serialization/deserialization routines which
> can easily double your codebase or more (as real-world javascript-code is
> heavily i/o based). i would say many people burn-out from
> frontend-programming because they can’t cope with debugging all the i/o
> edge-cases serializing/deserializing their custom classes.
> >
> >javascript and frontend-programming is essentially about efficiently
> managing the program-state like a baton, constantly passing it
> back-and-forth between the browser’s ui and various backend-servers /
> persistent-storage. plain json-objects utilizing idiot-proof
> JSON.stringify/JSON.parse, are naturally better at this baton-passing
> business than writing classes with custom serializers.
>
I dislike many things about JS, and I've been writing JS since 2002. It
never occured to me, not once, until 3 minutes ago, that this was in any
way, shape or form some significant JS disadvantage, primary concern of
anything or even any sort of impediment.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How it feels to learn JavaScript in 2016

[Florian Bösch]

I use a simple build script/requirement/module system I wrote myself in a
few dozen lines that does things the way I like it. I find the permanent
churn of pointless new flavors of the same thing annoying and distracting,
whatever happened to writing code and be done with it, programming isn't
spending time tweaking your super hip setup so long by the time you're done
something new is now the new hotness.

On Fri, Oct 27, 2017 at 12:38 AM, 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

Re: FW: Removal of language features

[Florian Bösch]

On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich 
wrote:

> The solution is not to hate JS. It's not going to change incompatibly.
> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
> subsets -- all possible today.
>

So basically "the best way to use JS is to not use JS". Awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich 
wrote:
>
> Those languages forked and some modernized (I remember Fortran 77). Those
> are all quite a bit older than JS. I would also suggest they are for the
> most part stunning successes. We've learned a lot from them.
>

Yes, but we'll also want people to *want* to use a language. Not just use
it because eons ago something has been written in them and now there is no
way out. JS has to keep pace or it will end up like those languages, some
relic from the past that nobody uses if they can possibly avoid it. I don't
think the mission brief of JS can be "The best language you hate using but
can't avoid using anyway."
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
>
> keeping it alive and healthy beyond its browser-limited existence.
>

Many languages (including Python and Perl)  concluded that at some point
things have to be "cleaned up". The track record of languages that never
cleaned up isn't... great. You could consider things like RPG, Cobol,
Fortran, etc. "alive" because they're still used. But in any other sense of
the word they aren't.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Florian Bösch]

On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich 
wrote:
>
> Core language changes are different in kind from sync touch events. It's
> very hard to plan to remove anything on a practical schedule or
> order-of-work basis. Engine maintainers likely still hate more modes, and
> users should too. New syntax as its own opt-in still wins, although this
> obligates TC39 to work on future-proofing, e.g., : after declarator name in
> declaration for type annotation syntax.
>

There's a point at which you cannot add anything new meaningful because of
the broken things. And you can't remove the broken things because you're
committed to eternal backwards compatibility. And you can't add modes
because nobody likes them. That's just planned obsolescence. This means JS
is not a living language, or won't be much longer in any case. It's
probably best if whatever you run on the web ships its own interpreter that
runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Florian Bösch]

On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband  wrote:

> There's lots of other threads on why no new modes are likely to ever be
> introduced.
>

And here we see the language evolution committee in its natural habitat
setting itself the impossible goal to support everything every introduced,
still introduce new things, and do it all without versioning, forever. In a
thousand or a million or a billion years, JS will still be JS as it was set
into stone in the late 20th century.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

[Florian Bösch]

A proper test would do this on a few hundred million elements interrupted
every 16.6ms with a RAF so as to give the GC a chance to run and run about
30 seconds so as to trigger at least a couple GC cycles.

On Thu, Jun 29, 2017 at 10:49 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:

> On Thu, Jun 29, 2017 at 9:19 AM, Florian Bösch <pya...@gmail.com> wrote:
> > > Improve performance
> >
> > I doubt that this sequence of calls:
> >
> > min = Math.min(min, value)
> > max = Math.max(max, value)
> >
> >
> > Is slower than this:
> >
> > [min,max] = Math.minmax([min,max,value])
> >
> > Because while the former can get inlined by JIT, the latter can't,
> > and on top, it allocates 2 objects which then have to be GC'ed.
>
> I was going to make that very point, backed by a jsPerf, but the jsPerf
> doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array
> It says the minmax is faster on a 10-entry array (it reports the separate
> calls as 46-48% slower on V8 and SpiderMonkey).
>
> Now, that's comparing making calls to functions defined in userland, not
> ones provided by the engine, so that's an important difference. And there's
> basically no memory pressure, whereas in real life there may be. And it's a
> synthetic benchmark. But there we are.
>
> -- T.J. Crowder
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

[Florian Bösch]

>
>
>- Improve performance
>
>
I doubt that this sequence of calls:

min = Math.min(min, value)
max = Math.max(max, value)


Is slower than this:

[min,max] = Math.minmax([min,max,value])


 Because while the former can get inlined by JIT, the latter can't, and on
top, it allocates 2 objects which then have to be GC'ed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.sincos(x)?

[Florian Bösch]

On Thu, Jun 22, 2017 at 8:02 PM, Robert Poor  wrote:
>
>function sincos(theta) {
>   return { sin: sin(theta), cos: cos(theta) };
>}
>

Allocating, filling, accessing and GC'ing the return object will take more
time than calling the underlying C library function which emits the machine
code for the processor to consult his trigonometric functions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Float16Array

[Florian Bösch]

On Wed, May 17, 2017 at 2:05 PM, Leo Balter 
wrote:

> Why?
>
Adding just because it's cool is not enough to make it through the staging
> process.
>

Because Float16 is a widely used format present on nearly all computers
GPUs sold the last 10 years. It's widely used to improve performance and
memory impact, which is of particular importance on mobiles. The format
interacts with the host space when during vertex data upload, texture data
upload, uniform data upload, transform & feedback readback and texture data
readback.


> The current spec is based on IEEE 754 and matches the floating point
> specs. What would Float16 be based on?
>

IEEE 754-2008 binary16
 (which is
what GPUs universally implement).
___
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.

[Florian Bösch]

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

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

[Florian Bösch]

await/async are de-facto co-routines. await/async will infect all code by
necessity of software engineering. At which point they're actual
co-routines, implemented badly, without a proper API.

On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen 
wrote:

> Florian,
>
> You sure you're not just adding more complexities to a language with
> features that were _meant_ to remove such complexity?
>
> Codefined's solution to me seems to be the one with the least amount of
> added techniques in order to learn.  Although I understand how co-rountines
> are awesome, they can quickly get very confusing when you switch contexts.
>
___
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.

[Florian Bösch]

On Sun, Feb 26, 2017 at 2:51 PM, Codefined 
wrote:

> What I feel we need is some way of making an asynchronous function
> "appear" to be synchronous.
>
That's what co-routines are. Best practices for co-routines is usually to
have some sort of API to spawn them (like new Routine(somefunction)), to be
able to switch to them (like someroutine.switch(funargs)) and to throw
exceptions into them (like someroutine.throw(error)) as well as a way to
obtain the currently used routine (like Routine.current).
___
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.

[Florian Bösch]

On Sun, Feb 26, 2017 at 2:17 PM, Codefined 
wrote:

> Because `d()` is no longer an asynchronous function, you can call it like
> normal, surely?
>

Only async functions can await. Only await pauses execution to wait on
async.
___
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.

[Florian Bösch]

On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen 
wrote:

> (although, at the moment, I fail to see why one can't just use a normal
> "return").
>

You're probably unaware of this, but there is a fixation in this community,
and many adjacent ones, that if you sprinkle syntax magic dust atop
co-routines, it fixes issues of concurrency (it doesn't). But in a
nutshell, that's why you can't just use a normal "return".
___
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.

[Florian Bösch]

To illustrate that, I went to Github
<https://github.com/search?l=JavaScript=await=simplesearch=Repositories=%E2%9C%93>,
I looked for repositories that match "await" and are JS (471 repositories).
The first few hits where microframeworks with minimal code or language
parser, but then comes:

Starhackit
<https://github.com/FredericHeem/starhackit/tree/master/client/src> (3rd
search result hit) some kind of full-stack application framework):

   - client/src/app/index.js
   
<https://github.com/FredericHeem/starhackit/blob/master/client/src/app/index.js#L16>:
   async function run(), defers to await app.start
   - client/src/app/app.js
   
<https://github.com/FredericHeem/starhackit/blob/master/client/src/app/app.js#L76>:
   async start(), defers to Promise.all of ii18nInit and preAuth
  - async i18nInit, defers to await intl
  - async preAuth, defers to await parts.auth.stores().me.fetch()

And so on. I could go through most of these non minimal code repositories,
and show you how every single one of them has async/await proliferated
through their entire call chain top to bottom.

I hope you can understand that my "theory" on actual use is therefore not
just idle speculation, it's actual use reality, and you should consider
that.


On Sun, Feb 26, 2017 at 1:43 PM, Florian Bösch <pya...@gmail.com> wrote:

> It would be nice if there even was an argument, but there isn't. There
> isn't because async/await naturally devolves into implicit coroutines, so
> any argument would be moot.
>
> To illustrate, suppose you have these 4 functions:
>
> let a = function(){
>   return b();
> }
>
> let b = function(){
>   return c();
> }
>
> let c = function(){
>return d();
> }
>
> let d = function(){
>   return whatever();
> }
>
>
> Call chains like this are typical. It's the staple of software engineering
> (for reasons of proper separation of concerns, reuse of utility code,
> etc.). If you believe that there is an argument about this being exemplary,
> it would be impossible to have an argument with you about software
> engineering at all. Of course real-world examples are more complex and
> don't just return whatever the underlying function produced, but as a
> control flow example it suffices. These chains are often much deeper than 4
> levels, it's not uncommon to encounter call chains 10, 15, 20 or 30 layers
> deep.
>
> Now let's suppose you figure that function d wants to do something
> asynchronous.
>
> So you go and do:
>
> let d = function(){
>   return xhr();
> }
>
>
> But of course that doesn't work, because d is not async. So you go and do:
>
> let d = async function(){
>   return await xhr();
> }
>
> Of course that doesn't work because c is not async, and so forth, so
> eventually your code looks like that.
>
> let a = async function(){
>   return await b();
> }
>
> let b = async function(){
>   return await c();
> }
>
> let c = async function(){
>return await d();
> }
>
> let d = async function(){
>   return await xhr();
> }
>
>
> In essence, you've applied to following two regular expression:
> s/function/await function/g and s/.+?\(\)/await ()/ . Of course that'd be
> horrid to do, so in reality you'd please use a proper JS parser. How did
> your code look before you applied these regular expressions? Well, it looks
> exactly like at the start.
>
> let a = function(){
>   return b();
> }
>
> let b = function(){
>   return c();
> }
>
> let c = function(){
>return d();
> }
>
> let d = function(){
>   return xhr();
> }
>
>
> But it isn't like at the start, because now it can trigger race conditions
> and is asynchronous. It is in fact now idempotent with true co-routines,
> except some unnecessary code transmoglification.
>
> This conclusively proves that await/async is an inconvenient clutch that
> naturally devolves into true co-routines. Now you might try to argue, that
> real-world code isn't just going to prefix every function call with await
> and every function body with async and stay that way.
>
> However, this would be in invalid argument for actual real-world code,
> because. People don't just constantly switch back and forth and re-engineer
> their code just because they want something async to happen underneath. You
> don't go and bicycle repair every call and function definition if you
> should decide to toggle synchronous or asynchronous. Therefore, since
> prefixing everything works no matter if it is asynchronous or synchronous,
> you will stay with the prefixes once you've added them. Which not only
> guarantees that async/await devolves into true co-routines, but it also
> gurantees that they p

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

[Florian Bösch]

It would be nice if there even was an argument, but there isn't. There
isn't because async/await naturally devolves into implicit coroutines, so
any argument would be moot.

To illustrate, suppose you have these 4 functions:

let a = function(){
  return b();
}

let b = function(){
  return c();
}

let c = function(){
   return d();
}

let d = function(){
  return whatever();
}


Call chains like this are typical. It's the staple of software engineering
(for reasons of proper separation of concerns, reuse of utility code,
etc.). If you believe that there is an argument about this being exemplary,
it would be impossible to have an argument with you about software
engineering at all. Of course real-world examples are more complex and
don't just return whatever the underlying function produced, but as a
control flow example it suffices. These chains are often much deeper than 4
levels, it's not uncommon to encounter call chains 10, 15, 20 or 30 layers
deep.

Now let's suppose you figure that function d wants to do something
asynchronous.

So you go and do:

let d = function(){
  return xhr();
}


But of course that doesn't work, because d is not async. So you go and do:

let d = async function(){
  return await xhr();
}

Of course that doesn't work because c is not async, and so forth, so
eventually your code looks like that.

let a = async function(){
  return await b();
}

let b = async function(){
  return await c();
}

let c = async function(){
   return await d();
}

let d = async function(){
  return await xhr();
}


In essence, you've applied to following two regular expression:
s/function/await function/g and s/.+?\(\)/await ()/ . Of course that'd be
horrid to do, so in reality you'd please use a proper JS parser. How did
your code look before you applied these regular expressions? Well, it looks
exactly like at the start.

let a = function(){
  return b();
}

let b = function(){
  return c();
}

let c = function(){
   return d();
}

let d = function(){
  return xhr();
}


But it isn't like at the start, because now it can trigger race conditions
and is asynchronous. It is in fact now idempotent with true co-routines,
except some unnecessary code transmoglification.

This conclusively proves that await/async is an inconvenient clutch that
naturally devolves into true co-routines. Now you might try to argue, that
real-world code isn't just going to prefix every function call with await
and every function body with async and stay that way.

However, this would be in invalid argument for actual real-world code,
because. People don't just constantly switch back and forth and re-engineer
their code just because they want something async to happen underneath. You
don't go and bicycle repair every call and function definition if you
should decide to toggle synchronous or asynchronous. Therefore, since
prefixing everything works no matter if it is asynchronous or synchronous,
you will stay with the prefixes once you've added them. Which not only
guarantees that async/await devolves into true co-routines, but it also
gurantees that they proliferate everything and once they're in, they're
never going out.

And that's why it isn't an argument.

On Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones <a...@weej.com> wrote:

> 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 <pya...@gmail.com> wrote:
>
>> On Sat, Feb 25, 2017 at 11:55 PM, Codefined <codefi...@debenclipper.com>
>> 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: Enable async/await to work on functions that don't just return promises.

[Florian Bösch]

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

Re: Module-based parallel JS strawman

[Florian Bösch]

On Sun, Nov 6, 2016 at 9:29 PM, Isiah Meadows 
wrote:

> My main focus on this was CPU scheduling and time sharing. Most runtimes
> already shove most outside I/O to another thread, so I wasn't that
> concerned about that. (You could use some indirection and deferral to
> implement cooperative multitasking.)
>
The problem isn't that the platform can't execute this in another thread.
The problem is that you can't write synchronous code anymore to do
synchronous code, this comes at a considerable cost of complexity to
programs.


>
>> Please note that efficiency in scheduling is always a function of how
>> well the scheduler matches the use-case in question. Thus it is important
>> to have a low level concept like coroutines upon which user-code can exist
>> that implements the scheduling. Examples of scheduling problems may include:
>>
>>- wait for user-input arrives (i.e. wait for input)
>>
>>
>>- wait for network actcivity (download or upload) has finished (i.e.
>>wait for xhr)
>>- wait for a WebWorker has finished processing (i.e. wait for
>>worker.postMessage)
>>- wait for GPU activity (i.e. query results, texImage2D, bufferData,
>>shader compile etc.)
>>
>> These could be handled by simply returning a promise. Each thread has its
> own event loop which runs within that thread. So just not doing it
> synchronously would be the solution.
>
Promises are a very bad model to handle cooperative multitasking and
quasi-synchronous code (I believe I don't have to illustrate that).

>
>>- evaluation of a dependency graph
>>- evaluation finite state machines (without resorting to state
>>transition methods)
>>- etc.
>>
>> I believe it would be much better to introduce true coroutines to JS,
>> than to try to introduce preemptive threading.
>>
>
> Cooperative multithreading and coroutines can be done with async
> iterators. When those get standardized, it'll become easy to use
> cooperative multitasking. (I need to make well-known symbols identical
> cross-realm to make it work, though.)
>
> ```js
> export atomic async function *sync(file) {
>   while (true) {
> if (await yield) await updateFile(file)
>   }
> }
> ```
>

More random line noise atop a broken model of co-routines, isn't going to
fix the lack of proper co-routines (in fact, I think this just exasperates
it).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module-based parallel JS strawman

[Florian Bösch]

On Sun, Nov 6, 2016 at 6:57 AM, Isiah Meadows 
wrote:

> TL;DR: I'm proposing a completely different threading model,
> supporting lightweight and cooperative multitasking while allowing
> synchronous, thread-safe communication and inspection. Apologies for
> the length.
>

Cooperative multitasking is a mode of operation where a thread once started
continues to run until it yields control. What you are describing isn't
cooperative multitasking since it lacks the ability to yield. Therefore
your suggestion is preemptive multitasking where tasks timeshare CPU time
(presumably switching at random/scheduled intervals at the interpreter
level).

It's widely acknowledged that preemptive multitasking (however you
implement it be that via interpreter level granularity, or as OS native
threads etc.) is difficult to control and often results in incorrect code,
race conditions, data corruption, mutex proliferation and deadlocks. It
also routinely fails to efficiently address I/O scheduling concerns,
because it is effectively just trying to timeshare a single strand of
processing across disjoint threads of execution. However, preemptive
multitasking is an effective strategy to timeshare CPU time if that is the
bottleneck. It could be argued though that WebWorkers already fill that
role more effectively.

Structured coroutines is a concept that allows switching between strands of
execution by "yielding" control to another strand. This isn't necessarily
related to multitasking, but it can be. If the coroutines are managed by a
scheduler, which is trivial to implement and customize in the presence of
coroutine functionalty, then coroutines can be used to implement
cooperative multitasking. It's widely acknowledged that cooperative
multitasking is not an effective strategy to address CPU timesharing,
however it is an extremely efficient method to address all other forms of
scheduling problems (such as I/O scheduling).

Please note that efficiency in scheduling is always a function of how well
the scheduler matches the use-case in question. Thus it is important to
have a low level concept like coroutines upon which user-code can exist
that implements the scheduling. Examples of scheduling problems may include:

   - wait for user-input arrives (i.e. wait for input)
   - wait for network actcivity (download or upload) has finished (i.e.
   wait for xhr)
   - wait for a WebWorker has finished processing (i.e. wait for
   worker.postMessage)
   - wait for GPU activity (i.e. query results, texImage2D, bufferData,
   shader compile etc.)
   - evaluation of a dependency graph
   - evaluation finite state machines (without resorting to state
   transition methods)
   - etc.

I believe it would be much better to introduce true coroutines to JS, than
to try to introduce preemptive threading.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck  wrote:

> I'm fine with co-routines, just explicit ones (which we currently have via
> generators and async functions). Implicit ones make it hard to reason about
> if a variable needs to place guards prior to performing any action if
> actions pop the stack in order to do a co-routine pause/resume.
>
As I've illustrated, the natural tendency of explicit tagged asynchronous
code combined with proper software engineering (separation of concerns,
modularity, reuse, interfaces, encapsulation etc.) will be to infect most
code with it, until the distinction of "explicit" becomes entirely
meaningless.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck  wrote:

> Multiple threads are fine, but the "seamless" shared mutable variables are
> a no go on my end.
>
You already have concurrent threads of execution accessing shared mutable
variables with either Promises or async/await. OS level threads are a
particularly nasty variant of multitasking which I'd rather like JS to stay
away from, but I don't see how that'd be an argument against co-routines.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

There's a fairly good implementation of co-routines called greenlets for
python. It depends on a few basic API calls, these are:

   1. g = greenlet.greenlet(fun) // makes a new greenlet pointing to the
   given function
   2. g.switch(args) // switches to that function
   3. g.switch(value) // once started delivers value inside that functions
   switch call
   4. g.throw(error) // raises an exception into the function
   5. greenlet.getcurrent() // returns the currently running greenlet

With these API primitives, you can implement any flavor of
asynchronous/concurrent scheduler on top if you wish to do so.

On Wed, Nov 2, 2016 at 4:25 PM, Florian Bösch <pya...@gmail.com> wrote:

> On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck <bradley.m...@gmail.com>
> wrote:
>
>> Florian, one of the great aspects of generators and async functions in
>> ECMAScript is that they are explicit. It makes understanding where
>> synchronization might need to occur very easy to find. I am unsure what
>> your proposal to prevent infection as you call it would look like if it is
>> explicit.
>>
>
> The theory that await/async are explicit is nice, but flawed, and here's
> why.
>
> If you have a call stack of say A -> B -> C -> D, and you change D to
> async D, you have a problem. C isn't awaiting D, so it needs to do C await
> -> async D, but now C isn't async and B isn't awaiting C, and so forth. So
> you'll end up with an "infection": A await -> async B await -> async C
> await -> async D.
>
> The infection spreads from down the call-stack upwards, and in doing so,
> it spreads sideways as well. If you have say a routine that calls a bunch
> of functions in succession:
>
> A(); B(); C(); D(); and for some reason or other (because your lower level
> framework code became async) all of them now become awaitable as well, you
> end up with await A(); await B(); await C(); await D();
>
> So eventually most calls end up being prefixed by await and most
> functions/methods end up being async, except for low-level code deep down.
>
> It might surprise you that co-routine schedulers work exactly like that.
> Except without all the not needed line-noise. In fact, it could be argued
> that instead of liberally strewing await/async randomly through your code,
> you could simply do a preprocessor that converts every call to an await and
> every closure to an async, that way at least you don't need to type it out
> everytime. Of course you'd also get functionally true co-routines via a
> fairly mindless application of preprocessing.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck  wrote:

> Florian, one of the great aspects of generators and async functions in
> ECMAScript is that they are explicit. It makes understanding where
> synchronization might need to occur very easy to find. I am unsure what
> your proposal to prevent infection as you call it would look like if it is
> explicit.
>

The theory that await/async are explicit is nice, but flawed, and here's
why.

If you have a call stack of say A -> B -> C -> D, and you change D to async
D, you have a problem. C isn't awaiting D, so it needs to do C await ->
async D, but now C isn't async and B isn't awaiting C, and so forth. So
you'll end up with an "infection": A await -> async B await -> async C
await -> async D.

The infection spreads from down the call-stack upwards, and in doing so, it
spreads sideways as well. If you have say a routine that calls a bunch of
functions in succession:

A(); B(); C(); D(); and for some reason or other (because your lower level
framework code became async) all of them now become awaitable as well, you
end up with await A(); await B(); await C(); await D();

So eventually most calls end up being prefixed by await and most
functions/methods end up being async, except for low-level code deep down.

It might surprise you that co-routine schedulers work exactly like that.
Except without all the not needed line-noise. In fact, it could be argued
that instead of liberally strewing await/async randomly through your code,
you could simply do a preprocessor that converts every call to an await and
every closure to an async, that way at least you don't need to type it out
everytime. Of course you'd also get functionally true co-routines via a
fairly mindless application of preprocessing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

What I meant to illustrate is that concurrency always leads to race
conditions, and that neither promises nor async/await are free of them, and
so it's silly to argue against co-routines on that basis, because of all
the continuation mechanisms, they're the most convenient to use with the
least drawbacks (no infectiveness).

On Wed, Nov 2, 2016 at 4:08 PM, Leo Dutra  wrote:

> Bösch, this is the legacy of callbacks.
>
> ECMA does a great job with specs, but JS does every step to solve the last
> step.
>
> Callback became a promise for modularity. Promise is hidden in async await
> for simplicity. Common constructs, but in JS they came in being adapted for
> JS world.
>
> As I said, immutability is not strong in JS as it is not a PURE functional
> programming language.
>
> Weird or not, this led us to the possibility of multithreading with total
> share and mutability.
>
> If we wanna multithread in here, we have to respect all the JavaScript
> legacy. And the JavaScript legacy hurts Java/C#/whatever feelings cause IT
> IS DIFFERENT.
>
> As said in my first argumentation, we have race condition problems and
> total share of scope and none died because of it. Multithread can be used
> to run these callbacks, functions and promises seamlessly and if we want it
> different... that's a huge bad conversation about foundations of JavaScript
> and a total change that would wreck the JS world and let us to anything
> that is not JS.
>
> We have to decide if we stick with scope sharing and mutability or look
> for another language. JS is what it is.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Florian Bösch]

I'd like to quickly point out that Promises, async/await are actually
implementations of co-routines. Unlike true co-routines however they're
infective (once something down the call stack becomes a promise or an
async, it infects upwards). They have none of the conveniences of actual
co-routines (non infective, control flow/structural semantic is preserved),
while sharing all of the drawbacks of any other cooperative multitasking
scheme (data corruption).

Racing in promises:

xhr().then(function(){a.text = 'foo'})
xhr().then(function(){a.text += 'bar'})


Racing in async/await:


async function foo(){ a.text = await xhr(); }
async function bar(){ a.text += await xhr(); }
await* [foo(), bar()]


Racing with cooperative multitasking (assuming greenlet semantics and a
trampoline I/O scheduler):

scheduler.spawn(function(){
  a.text = xhr();
});
scheduler.spawn(function(){
  a.text += xhr();
});


None of these examples is really representative of what people would
actually do, which is:

Promises:

xhr()
  .then(function(){
a.text = 'foo';
return xhr();
  })
  .then(function(){
a.text += 'bar';
  })


async/await

a.text = await xhr();
a.text += await xhr();


Co-routines:

a.text = xhr();
a.text += xhr();


However we can see how actual co-routines would have a marked advantage in
simplicity and conciseness.

All forms of cooperative multitasking would eventually have to evolve a
barrier mechanism to deal with data corruption. Promises are severely
handycapped in that regard as they cannot create barriers at all.
Async/await barriers are conceivable, but awkward. Co-routine barriers are
relatively straightforward to implement if you control your scheduler
implementaiton.

It should be noted that controlling what kind of scheduler you use would be
kinda important, which is one convenient aspect of co-routines, they can
easily implement a custom one fit for your needs.

On Wed, Nov 2, 2016 at 3:27 PM, Bradley Meck  wrote:

> Consider:
>
> ```
> let a = {};
>
> alpha: parallel {
>   a.text = 'hello';
> }
> beta: parallel {
>   a.text += ' world';
> }
> console.log(a);
> ```
>
> This has racing:
> * around `a.text` between `alpha:` and `beta:`.
> * around `console.log` since `a` could be 1 of 3 values depending on how
> threads are scheduled.
>
> I am stating that such racing/shared mutation should be prevented. Workers
> do this by message passing and ownership of transferable data. There could
> be other mechanics for synchronization, but I don't see a simplistic
> solution. Things like having a read-only view of data partially helps, but
> atomics are most likely the proper way to do this if you don't want message
> passing and ownership semantics.
>
> On Wed, Nov 2, 2016 at 9:09 AM, Leo Dutra  wrote:
>
>> ​There's nothing about threading that is not problem with Event loop.
>> I'd say there's even less problems.
>>
>> The proposal is a seamless behaviour, equals to what we have now.
>>
>> Message passing is not a problem of JS developer in the case, but a
>> V8/WhateverMonkey problem.
>>
>> Changing a value inside a multithread async MUST behave in the same way
>> of a change inside a single threaded async. The same way, non-referenced
>> variables SHALL NOT be scoped in the thread. This is not Java with
>> volatiles. This is the plain old JS with clojures, openess and loose bare
>> metal control.
>>
>> Thread interruption is a bad practice anyway. And we could have a Mutex
>> class for the specific case or another idea.
>>
>> Workers are evented and started, not pooled and easy to use.
>> ​
>>
>>
>> *Leo Dutra, **on **Facebook  **and 
>> LinkedIn
>> *
>>
>> 2016-11-02 11:57 GMT-02:00 Bradley Meck :
>>
>>> We need to be careful about this, I would never condone adding threading
>>> that could share variables that were not intended to be multi-threaded, as
>>> such variable access outside of your `parallelize` construct/syntax would
>>> need to be message passing when talking to something that is not already
>>> written as a parallel structure. A notable thing here is that Shared Memory
>>> and Atomics that are in ECMA Stage 2 : https://github.com/tc39/ecma
>>> script_sharedmem which would probably need to land prior to me
>>> condoning any shared mutable state.
>>>
>>> Historically, all JS implementations are based upon a job queueing
>>> system described by the Event Loop. This is very different from parallelism
>>> which could have shared mutable state. All code is guaranteed to have
>>> exclusive access to variables in scope until it finishes running, and that
>>> the content of those variables will not change from preemption (there are
>>> cases where this is not true in the browser with a live DOM). There are
>>> alternative discussion recently on Workers :
>>> https://esdiscuss.org/topic/standardize-es-worker . I might look there
>>> first.
>>>
>>> 

Re: GC/Compile requests, with 3D engine demonstration

[Florian Bösch]

On Sun, Mar 13, 2016 at 10:18 PM, Boris Zbarsky  wrote:
>
> Adding some more flexible ways to deal with GC'ing beyond "just making
>> it better" would be highly welcome.
>>
>
> Yes, this I agree on.


Maybe some kind of API to 1) inform the GC about what strategy of GC'ing
you would prefer and 2) indicate to the GC when's a good time to fulfill
that strategy. For instance, for realtime rendering you'll want to spend
say a maximum of 4ms/frame on GC'ing, you'd indicate
gc.setStrategy('realtime'); and then at the end of a frame gc.now(4);
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Florian Bösch]

I'd like to chime in here on the GC. I make my living writing WebGL code
for a living. JS'es stop-the-world mark for however long it takes
approach to GC'ing is very troublesome.

A new frame has to be produced every 16.6ms (and in some cases as in the
merging WebVR implementations every 11.1ms or even 8.3ms). And if that is
delayed in any way, what occurs is jitter. One or several frames are missed
to be drawn until a new frame can be drawn, this is a noticeable effect to
many users. But it's even worse for VR usage because jitter is much more
readily apparent in the case that your head movement no longer produces a
new picture.

But the pernicious effects of GC'ing are already readily apparent even
without strict realtime requirements. Pretty much every JS library (like
jQuery UI) produces very unsmooth animations among other things, because of
this.

Writing code to get around JS'es GC is possible, but it complicates
everything quite a lot (effectively your drawing loop cannot allocate
anything, ever).

The GC-needs of different applications might differ a lot. Some might
prefer a GC that's using as little time as possible, but might occasionally
stop the world for long periods of time. Other applications might be happy
to cede as much as 1/4 of their CPU time to the GC at a clip of 60hz, 90hz
or 120hz but be guaranteed that the GC is never going to occupy more time
than that.

Adding some more flexible ways to deal with GC'ing beyond "just making it
better" would be highly welcome. Provided that incremental/realtime GCs are
probably never gonna happen for JS, the next best thing would probably be
to at least be able to select a GC strategy and set its parameters that
suit your use-case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [ small request - Javascript for javaing]

[Florian Bösch]

On Fri, Jan 1, 2016 at 3:51 PM, Norbert Korodi 
wrote:
>
> As I reread my letter I have to admit that I might sound arrogant /
> offensive (and I am sorry for that , at least I am honest ) but I am really
> tired of reading about "new"-ish es features which are only new to this
> platform.
>

While strictly not new features, object literals, anonymous functions and
proper closure are fairly important features of Javascript. To my knowledge
Java still doesn't have those... Not sure which language has some catching
up to do there.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Gamepad API assumes you aren't using the gamepad.

[Florian Bösch]

There is an API called "pointerlock" whose purpose is to allow you to
capture the mouse. An equivalent API is (as of yet) lacking in the gamepad
API, but it is requested as a feature:
https://github.com/w3c/gamepad/blob/gh-pages/FeatureRequests.md

On Sun, Oct 25, 2015 at 2:13 AM, Carl Smith  wrote:

> I've been looking at the Gamepad API. It's a nice API, and the scope is
> sensibly narrow, but I think it is just too limited.
>
> With smart TVs, games consoles, Android boxes and so on, lots of users
> are using joypads and remote controls to browse the Web. It's pretty
> clumsy, but when you only want to find an album on YouTube, it works.
>
> On the OUYA, buttons and axes are mapped to browser controls. FireFox
> on Android maps the shoulder buttons to Back and Forward, and the
> left axes pan the page. Chromium is similar. I'm not sure the
> vendors intended for that, but still.
>
> The issue is that the browser, extensions and webapps all want to use
> the same pad, but the API provides no way to 'take' or 'free' a pad.
>
> Once an app has access to a joypad, the browser will (must) just ignore
> the state of the pad for so long as the app can reference that pad. It
> can be difficult for the user to exit an app when the only input device
> they have to hand must be completely ignored by the browser. Users often
> want to keep the app open too.
>
> The problem is a lot like the problem of pages using bindings that
> conflict​ ​with the browser, only here, you have less keys, and the browser
> must let​ ​the page take over all the bindings.
>
> The Gamepad API should allow each pad to be 'taken' and 'dropped'.
>
> I'd suggest using a stack, with the browser always on the bottom. If an
> app calls `gamepad.take` it goes on the stack. It gets popped when it
> calls `gamepad.drop`. Whoever's on the top of a pad's stack has the
> pad all to itself.
>
> With a stack, for example, a browser extension could take the pad from
> the browser, and a game could then take the pad from the extension. The
> game could drop the pad once it was done, automatically returning the pad
> to the extension. The game wouldn't need to expect the extension.
>
> There'd need to be some place to attach two callbacks, so programs could
> handle the pad being taken and returned to them.
>
> No app *should* ever try and take the pad in the callback for when it's
> taken from them, but bad code might hog a pad or get into a fight over it.
> In any case, I think there should have always been a required, reserved
> 'menu' button on every mapping that the user can use open the browser
> menu. From there, they could close tabs etc.
>
> If something like this were to happen, browsers would need to support pads
> properly, at least allowing gamepad configs to be added by the user that
> would map ​'​​actions' to browser controls.​​
>
> The browser would ideally abstract actions - stuff like taps, double-taps,
> long-presses and combos (hold X and do Left, Right, Left)​, though
> ​extensions
> could handle that stuff if the ​Gamepad ​API ​were better (and all the
> browser
> actions are exposed to extensions).
>
> I tried building something with the Gamepad API and couldn't, so just
> wanted to offer some feedback really.
>
> One other thing: The inability of apps and extensions to grab the mouse
> ​prevents using an analogue stick to point and click.​ ​That's​ ​another​
> ​thing that can only be fixed at the browser level.
>
> ___
> 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 Gamepad API assumes you aren't using the gamepad.

[Florian Bösch]

On Sun, Oct 25, 2015 at 10:13 AM, Carl Smith  wrote:

> ​Thanks for the link, Florian. I hadn't seen that. I don't think you can
> emulate the mouse with pointerlock. It works differently.​
>
You cannot emulate the mouse for two reasons:

   - You can't synthesize the necessary events to make it work (or some of
   the events synthesized aren't picked up correctly)
   - The mouse pointer is deep in the OS and is drawn at much higher
   frequency/lower latency than other things, at an interval of 60fps and
   given the latencies that browsers introduce, a smooth pointer emulation is
   impossible.

However that does not mean that pointerlock is a pointless API. UAs/OSes
can work on getting the latency down, and it is a useful API for some kinds
of content.


> The thing is, I don't think the Gamepad API needs extending. It needs
> removing from ES6​.
>

ES6 is not responsible for the APIs that UAs offer. ES is administrated by
ECMA whereas the APIs are administred by W3C and WhatWG. As such ES6 has
little say in what API is supported or not.


> It will never work without breaking everything
> that uses it.
>

> Currently, no extension can use the Gamepad API without conflicting with
> any other extension that uses it, and the entire Web. And the browser
> can never offer first-class support for pads for the same reason.
>
> To the extent that we can't break the Gamepad API, we can't use pads in
> extensions or to control the browser. As we go into a SmartTV era, that
> will probably be pretty bad.
>

There is a host of content that uses the Gamepad API just fine. There are
some improvements that should be made to the API for platforms whose
primary interaction with the UA happens trough HIDs other than a mouse and
keyboard.

Regardless, the Gamepad API exists because it satisfies a need that (some)
web applications do in reality have. I don't think the proper solution to
solve gamepads is not to have gamepads.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Florian Bösch]

I'm a python user and I dislike using **, it just becomes rather noisy.

Expressing formulas in text based programming languages has always been
kind of a drag. On the other hand, often the mathematical expression of a
formula would be quite inefficient because they lack the ability to keep
temporary results in some variable. Picking a formula apart to isolate
those temporaries the expressiveness vanishes naturally.

On Tue, Aug 25, 2015 at 7:25 PM, Mark S. Miller erig...@google.com wrote:

 It also does not work. x ** y ** z, if we allow it at all, must be right
 associative. It must parse as x ** (y ** z).


 On Tue, Aug 25, 2015 at 10:08 AM, Mark S. Miller erig...@google.com
 wrote:

 It does not work as well as simply omitting ** entirely.


 On Tue, Aug 25, 2015 at 9:42 AM, Isiah Meadows isiahmead...@gmail.com
 wrote:

 I like this. It works very well.

 On Tue, Aug 25, 2015, 12:38 Claude Pache claude.pa...@gmail.com wrote:


 I think the following grammar could work.
 Replace the current (ES2015) PostfixExpression production with:

 ```
 IncrementExpression:
 LeftHandSideExpression
 LeftHandSideExpression [no LineTerminator here] ++
 LeftHandSideExpression [no LineTerminator here] --
 ++ LeftHandSideExpression
 -- LeftHandSideExpression
 ```

 And define UnaryExpression as:

 ```
 UnaryExpression:
 IncrementExpression
 delete UnaryExpression
 void UnaryExpression
 typeof UnaryExpression
 ++ UnaryExpression
 + UnaryExpression
 -- UnaryExpression
 - UnaryExpression
 ~ UnaryExpression
 ! UnaryExpression
 IncrementExpression ** UnaryExpression
 ```

 where the following production (which exists only to avoid to
 confusingly interpret, e.g., `++x++` as `+ +x++`):

 ```
 UnaryExpression:
 ++ UnaryExpression
 -- UnaryExpression
 ```

 yields a static SyntaxError (or a static ReferenceError if we want to
 be 100% compatible ES2015).


 That way, we have the following expected behaviour:
 * in/decrement operators bind most tightly;
 * unary and exponentiation operators are applied from right to left.


 —Claude


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




 --
 Cheers,
 --MarkM




 --
 Cheers,
 --MarkM

 ___
 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: Float16Array

[Florian Bösch]

Float16 isn't a legacy format to Float32 much in the same way that
unsigned int16 isn't a legacy format to unsigned int32.

Float16 is a mandatorily supported format in OpenGL ES 3.0 textures and
vertex attributes.

If more precision than byte is required, but less than float32 precision is
acceptable, benefits include all of:

   - Using half as much network bandwidth
   - Using half as much RAM
   - Getting half as many GPU cache misses
   - Using half as much GPU upload bandwidth
   - Using half as much GPU download bandwidth
   - Using half as much VRAM
   - Using half as much GPU vertex streaming bandwidth
   - Using half as much texel lookup bandwidth
   - Using half as much fillrate
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Eval, literal eval, safe eval

[Florian Bösch]

A proper solution really is a separate VM, that isolates the complete
environment watertight and by default denies all interaction except for
those which have been defined as interaction points (alas it would also see
to it a DOS attack with a while(1){} appropriately times out).

Anything else is really just a hack with security holes waiting to be
discovered.

On Mon, Dec 1, 2014 at 10:35 AM, Michał Wadas michalwa...@gmail.com wrote:

 Creating secure implementation of eval without creating your own
 interpreter (or sophisticated operations on AST) is almost impossible - it
 would require to copy whole environment and provide mocks to any possibly
 dangerous function.
 At least O(n^2) complexity without ES6 Map.

 ___
 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: Eval, literal eval, safe eval

[Florian Bösch]

well, just because you don't DOS the main thread, doesn't mean making a
machine 800% busy isn't a DOS.

On Mon, Dec 1, 2014 at 10:43 AM, Michał Wadas michalwa...@gmail.com wrote:

 WebWorker with blocked XHR, importScript, WebSockets, creating new
 WebWorkers should be appropriate and secure against while(true) ;

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

Re: Eval, literal eval, safe eval

[Florian Bösch]

Ah and don't forget that allocating ram till the machine swaps is also a
DOS.

On Mon, Dec 1, 2014 at 10:49 AM, Florian Bösch pya...@gmail.com wrote:

 well, just because you don't DOS the main thread, doesn't mean making a
 machine 800% busy isn't a DOS.

 On Mon, Dec 1, 2014 at 10:43 AM, Michał Wadas michalwa...@gmail.com
 wrote:

 WebWorker with blocked XHR, importScript, WebSockets, creating new
 WebWorkers should be appropriate and secure against while(true) ;



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

Re: Eval, literal eval, safe eval

[Florian Bösch]

On Sun, Nov 30, 2014 at 1:41 AM, Thaddee Tyl thaddee@gmail.com wrote:

 You can do a lot more. You can prevent the issues you point out (and

many others) by mocking all built-in object's prototypes that you want
 to feed the sandbox (so that modifications are actually performed on a
 throwaway prototype), and by removing all new properties that weren't
 there before and replacing those that were there before.

It was exemplary. Securing code is actually quite tricky unless you control
the VM it runs in. I believe a previous comment pointed this fact out.


 For all purposes, it is a safe eval. I really wish that Chrome would
 use it in their DevTools; I broke them so many times while writing
 this library that I have lost count. They actually use no sandbox at
 all in their [js console].

Could you elaborate on that point with some examples how you broke it?


 Most of that is (laborious but) easy. The thorny bit in localeval is
 passing values to the sandbox. While it obviously works in the version
 without a timeout (although infinite loops aren't protected against),
 the version with a timeout, which relies on web workers (or processes
 in node), doesn't pass non-JSON-serializable values fine.

You don't really want to serialize/deserialize everything. It is imminently
useful to be able to pass an object or function to a sandbox or receive one
out of it. Again, this is possible to do, but it's nearly impossible if
you're not in control of the VM (as is evidenced by your own
implementation).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal for new floating point and integer data types

[Florian Bösch]

On Mon, Nov 24, 2014 at 9:00 AM, Brandon Andrews 
warcraftthre...@sbcglobal.net wrote:

 float32/64


   - float16: common name: half, IEEE 754-2008: binary16, often used on GPUs
   - float32: common name: float, IEEE 754-2008: binary32
   - float64: common name: double, IEEE 754-2008: binary64
   - float128: common name: quad, IEEE 754-2008: binary 128, often used in
   scientific computing
   - float80: common name: x86 extended precision, IEEE 754-2008
   permissible extended percision format, often used instead of float128
   because speed on x86



 decimal


   - decimal32: IEEE 754-2008: decimal32
   - decimal64: IEEE 754-2008: decimal64
   - decimal128: IEEE 754-2008: decimal128

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

Re: Eval, literal eval, safe eval

[Florian Bösch]

On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas michalwa...@gmail.com
wrote:

 literal_eval description:
 The string or node provided may only consist of the following Python
 literal structures: strings, numbers, tuples, lists, dicts, booleans, and
 None.

Also known as JSON.parse.


 My proposition is safe eval.
 Safe eval ( eval.safe(string: code, callback) ) should perform theses
 steps:
 - Create isolated realm without capabilities to perform almost any IO
 (implementation dependant - no XHR, no importScript, no require)
 - evaluate code in context of created realm
 - post result of last evaluated expression back to creator realm using
 structured-clone algorithm
 - call callback with returned data

 Pros:
 + sandbox offered by language
 + easy to run in other thread
 + quite easy to polyfill
 + servers can send computations to users
 +
 Cons:
 - Realm creation can be costly (but implementations can solve this
 problem in many ways)
 - proposal does not include support for asynchronous operations

evalSandboxed would perhaps be a better term.

Btw. you can do a sort of sandboxed eval today by overriding all names
found in window. There are some caveats however. The so sandboxed code can
still access (and change) object internals, such as
mystring.constructor.prototype.asdf = function(){ console.log(gotcha);
}.

A sandboxes primary purpose isn't just to restrict access to global
symbols, it's also to prevent it from corrupting the surrounding codes
internals. One way to do that of course would be to have the so sandboxed
code run in total isolation on a separate VM instance, however there's some
issues with that too.

It would often be the case that you'd want to provide an interface to the
sandboxed code. So sandboxing alone isn't quite sufficient, you'd also need
to have a suitable API/syntax to describe interfaces, safe to pass to the
sandboxed code, such that the sanboxed code cannot corrupt any piece of
those interfaces.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Float16Array

[Florian Bösch]

Typed arrays today are specified with support for Float32Array,
Float32Array.

A useful additional data type would be Float16Array. It's useful because
GPUs (particularly mobiles) have support for it, and because VRAM and
bandwidth limits are a legitimate concern (particularly for mobiles).

GPU support for it appears in the following forms:

   - Desktop OpenGL ARB_half_float_pixel: support for half-float textures
   - Desktop OpenGL ARB_half_float_vertex: support for half-float vertex
   data
   - Desktop OpenGL 2.1 core specification, extended support in 3.0
   - Mobile OES_texture_float: support for half-float textures
   - Mobile OES_vertex_half_float: support for half-float vertex data
   - Mobile EXT_color_buffer_half_float: support to render to half-float
   render targets
   - Mobile OpenGL ES 3.0 core specification.
   - WebGL OES_texture_half_float: support for half-float textures
   - WebGL OES_texture_half_float_linear: support for half-float texture
   linear filtering
   - WebGL EXT_color_buffer_half_float: support for half-float render
   targets
   - WebGL 2.0 core specification

These types are defined per IEEE 753-2008

   - binary16, common: half
   - binary32, common: single
   - binary64, common: double

It is possible today to service half-float data types trough JS, by
performing the conversion in JS. The code for this is however rather
complex and it's difficult to implement all of IEEE 753-2008 correctly (my
version doesn't support rounding quite correctly
http://codeflow.org/experiment/half-float/main.js). It may also be
unnecessarily slow. Convenience is also an issuebecause JS can't override
the array access [] operator to do the job.

I'd like to propose adding Float16Array to the typed array specification.
If JS accesses arrays like these, appropriate conversion is applied (as is
the case for any other non JS-native numerical type)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

typed array filling convenience AND performance

[Florian Bösch]

The usecases:

*1) Filling with custom data*

When writing WebGL or physics or many other things todo with large
collections of data, it's not unusual to have to fill arrays with custom
data of some kind.

someArray.set([
 x0, y0, 1, 0, 0,
 x1, y0, 0, 1, 0,
 x1, y1, 0, 0, 1,
   x0, y0, 1, 0, 0,
   x1, y1, 0, 1, 0,
   x0, y1, 0, 0, 1
 ], i);


*2) Copying in data from another array*

Some data resides in another array and needs to be copied in. A feature
frequently in use by emscripten.

someArray.set(otherArray.subarray(srcOffset, srcSize), dstOffset)


*3) Initializing an existing array with a repeated numerical value*

For audio processing, physics and a range of other tasks it's important to
initialize an array with the same data.

for(var i=0; isize; i++){ someArray[i] = 0; }


*The problem:* Doing all of these things is slow and/or unsuitable for
realtime code.

   1. someArray.set from a new list is slow due to set being slow, and
   constructing the list is slow. It's not realtime friendly because it'll
   construct a new list, which will have to be GCed.
   2. someArray.set is slow due to the new array view construction and it's
   not realtime friendly due to GCing.
   3. Filling an array one element at a time is slow.

*The test: *http://jsperf.com/typed-array-fast-filling/4 (screenshot here
http://codeflow.org/pictures/typed-array-test.png and attached)

*The status quo:*

The fastest way to fill an array with custom data across browsers is:

r[i] = x0;
 r[i + 1] = y0;
 r[i + 2] = 1;
 r[i + 3] = 0;
 r[i + 4] = 0;
 r[i + 5] = x1;
 r[i + 6] = y0;


*Things that are not faster: *

   - pushing to a list: ~93% slower
   - a helper function filling from a list: 57-70% slower
   - array.set: ~73% slower
   - a helper function filling from arguments: 65% - 93% slower
   - asm.js: 69-81% slower (even in firefox)

*Suggestions:*

   1. Browser engines should get a lot better at arguments handling so that
   non sized arguments can be quickly iterated by native code. Firefox is
   already pretty good at unboxing a specified argument list (chrome not so
   much), but I think that test shows that there's ample room for improvement.
   2. *someArray.memcpy*: Add a method to typed arrays that can shuffle
   bytes from array A to array B like so: dst.memcpy(dstOffset, src,
   srcOffset, size). This is to avoid having to allocate an object to do the
   job.
   3. *someArray.memset*: Add a method to typed arrays that can initialize
   them with a value like so: dst.memset(dstOffset, value, size)
   4. *someArray.argcpy*: Add a (fast) method to typed arrays that can copy
   the arguments like so: dst.argcpy(dstOffset, 1, 2, 3, 4)
   5. Drastically improve the set method.

(naming and semantic don't matter to me, long as the methods do it
efficiently, conveniently and fast what's suggested).

*Related discussion:*

   - https://bugzilla.mozilla.org/show_bug.cgi?id=936168
   -
   https://www.khronos.org/webgl/public-mailing-list/archives/1410/msg00105.html

*Consequence of failure to rectify:*

Fast code will be unreadable and unmaintainable. Sophisticated and speed
requiring code will not be written in ecmascript. Emscripten and asm.js
with its hermetic nature will crowd out ecmascript driven developments.
Other alternatives such as on GPU transformfeedback and compute shaders
will be preferred to solve the problem.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: typed array filling convenience AND performance

[Florian Bösch]

On Thu, Oct 30, 2014 at 1:41 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:

 Performance optimizatiuon in an implementation issues.  That’s where you
 should apply performance pressure.

That's true, but if there's only bad APIs to do certain tasks, it doesn't
help.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: typed array filling convenience AND performance

[Florian Bösch]

On Thu, Oct 30, 2014 at 6:44 PM, Steve Fink sph...@gmail.com wrote:

 Now there is %TypedArray%.prototype.fill. But I've become generally
 skeptical about it as an answer to performance concerns. I would rather
 see engines hyperoptimize

   for(var i=0; isize; i++){ someArray[i] = 0; }

 based on observed type information. Which is not to say that we wouldn't
 want to make TA#fill fast too, but the above seems more generally useful.

While useful, it's not a substitute for a convenient and fast method. Also,
I presented severe usuability issues with that approach if you need more
than one value (such as computed values). Usability issues which can be
resolved by using set + a new list for every assignment, which,
unfortunately, is also quite slow. It's slow because say, for a loop that's
running a million times, it makes a million lists.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does async/await solve a real problem?

[Florian Bösch]

On Fri, Sep 12, 2014 at 8:00 AM, Tom Van Cutsem tomvc...@gmail.com wrote:

 While this refactoring may be tedious (no disagreement there), it forces
 you to review all affected code, which is good, because the dependencies of
 that code may have changed (i.e. side-effect the client previously thought
 would execute atomically may now no longer be atomic).


It's often the case that the code which uses the async code, uses other
code, which isn't authored by the author, and isn't documented for await
compatibility. For instance:

$.each(somelist, async function(item){
await Foobar(item);
});

Suppose $ is jQuery, is this async safe? Google for jQuery documentation
and/or read code.

somelist.each(async function(item){
  await Foobar(item);
});

Has the browser made his each function async safe? Google for JS API
documentation of the browser and/or start reading the source code of the
browser (really?).

This is kind of a pervasive problem. It's not only that the
refactoring/hunting for references is tedious. It's that sometimes, you
might not have the plain source (some proprietary/minified/obfuscated
library anybody?), or that the implementation is quite complex, and
frankly, you just don't have the time to hunt around its millions of lines
of code to figure out if it'll work.

Now to be fair, the same problem applies to co-routines as well. You can't
know if a given piece of code is co-routine safe unless you dig it up. But
at least it doesn't make you type forwards/backwards await/async each time
you decide it didn't work out, trough hundreds, or thousands, or maybe even
tens of thousands of lines. In fact, doing this will become an utter
impossibility fairly quickly anyway, and the only way to do it would be
some kind of automated tool that can insert the async/awaits for you trough
the code (pray that it's inferrable, or you're screwed). Ohyeah, it'd be
nice if that tool could insert some invisible code so you don't just
clutter lines with stuff you don't hand-manage anyway. Wait, no, that was
co-routines again wasn't it? silly me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does async/await solve a real problem?

[Florian Bösch]

await has also another problem in that if somewhere, deep down the call
stack, something is intending to do async, then up the entire call stack
everywhere you've got to insert await. It's a bit of a headache for code
maintenance (hello bicycle repair man jam session), and it's also fairly
unfriendly for library authors.

There is a solution to that problem, which is not using generators if you'd
want co-routines. If you want co-routine like behavior, please implement
co-routines (and you can prop whatever scheduling/managing on top of that).

An argument has been made in earlier discussions on that topic, that JS VMs
can't deal with co-routines (garbage collection, DOM, whatever). But
surely, if the VM can support generators/continuations, it could support
full co-routines.

I'd recommend python's greenlet as an outstanding implementation of a
co-routine interface that includes basically everything one could wish from
it. I'd not consider python 3's asyncio a proper co-routine
implementation (i.e. it's the same generator/await hack as is being
discussed here).

On Thu, Sep 11, 2014 at 3:05 PM, Kevin Smith zenpars...@gmail.com wrote:

 Also, see https://github.com/lukehoban/ecmascript-asyncawait/issues/14
 for previous discussion.

 On Thu, Sep 11, 2014 at 8:42 AM, Domenic Denicola 
 dome...@domenicdenicola.com wrote:

 There are several problems solved by async/await instead of twisting
 generators:

 1. What if you wanted to use generators for lazy sequences (iterables),
 instead of asynchronicity? If your framework assumes all generators are for
 async, you lose the original use case of generators.

 2. Say what you mean. `function*` and `yield` mean something very
 different from `async function` and `await`, similar to how
 `Subclass.prototype = Object.create(Superclass.prototype);
 Subclass.prototype.constructor = Subclass` is different from `class
 Subclass extends Superclass`.

 3. Operator precedence. You can do `await a + await b` to mean `(await a)
 + (await b)`, but `yield a + yield b` means `yield (a + (yield b))`.

 4. Ability to produce promise-returning functions without buying into a
 specific framework that interprets generators in a certain way. E.g., you
 could use `async function f() { return 5; }` to return a promise for 5,
 which people can consume with `f().then(v = ...)`. If you try to do
 `function* f() { return 5; }` you will get an iterable, which is not
 understood to be asynchronous. (Hopefully my use of `return 5` for brevity
 instead of more complex code does not confuse this point for you.)

 As for stack traces, long stack trace support is a debugging feature, and
 the fact that `yield*` gets them right now doesn't mean that `await` won't
 get them in the future.

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
 Jeswin Kumar
 Sent: Thursday, September 11, 2014 11:46
 To: es-discuss@mozilla.org
 Subject: Does async/await solve a real problem?

 Looking at my project (in which asynchronous calls are entirely done via
 generators), I can't see how async/await would simplify code for end-users
 like me (application programmers).

 End users write the spawn()/Q.async()/co() wrapper *at most* one single
 time in an application:
 1. When using a framework like say koajs, you don't have to write it even
 once.
 2. While not using a framework, you'd have to use the wrapper one single
 time in say, the main.js file.

 To use the example at
 http://wiki.ecmascript.org/doku.php?id=strawman:async_functions

 async function chainAnimationsAsync(elem, animations) { CODE; } is just
 function chainAnimationsAsync*(elem, animations) { same CODE; } when flow
 control is done by a framework or at the entry point to your application.
 spawn() isn't needed.

 I can't see how this will reduce application's code even a little. So my
 question is, is async/await needed?


 One more question
 --
 1. yield is practically very difficult to use in a project because you
 don't get proper stack traces (at least with the current flow control
 libraries). You'd only see the last call which threw the error, and then
 functions from the flow control library immediately below that. I suppose
 the generators leading up to the erring generator are all suspended and
 wouldn't be on the stack frame chain.

 2. yield* generator delegation solves this problem, you get real stack
 traces. I was able to get full stack traces simply by replacing all yield
 X() with yield* X()

 example code as in: https://github.com/chopachom/syncio

 So if there are valid use-cases for adding async/await to JS, shouldn't
 it be based on how yield* works rather than yield?

 -- Jes

 The Fora Project is coming...
 https://github.com/jeswin/fora
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 ___
 es-discuss mailing list
 

Re: Does async/await solve a real problem?

[Florian Bösch]

A - B - C - D - E changes to

A - B - C - D - async E and causes

A await - B await - C await - D await - async E

And of course if A, B, C or D is used anywhere else it percolates trough
the entire call graph.

Trying to protect people from interlaved code execution effects is noble.
But doing so by introducing a rote thing to type everytime you change the
code somewhere underneath is wrong. It's wrong because it breaks logic
isolation, it becomes impossible to change part of the library/utiity code
without this change affecting all code that uses it. This guarantees that
it doesn't happen in practice, because it's too painful to do. It requires
the code, that uses other code, to know about the internal behavior of that
code.

If say, I'd propose a semantic that required you to write foo in the
code, but just for those pieces of code that contain mentions of bar, or
that reference code that contains bar to the Nth degree, you'd accuse me
of trying to introduce a purposefully unusable feature. How is await/async
not an unusable feature?



On Thu, Sep 11, 2014 at 4:00 PM, Mark S. Miller erig...@google.com wrote:

 On Thu, Sep 11, 2014 at 6:20 AM, Florian Bösch pya...@gmail.com wrote:

 await has also another problem in that if somewhere, deep down the call
 stack, something is intending to do async, then up the entire call stack
 everywhere you've got to insert await. It's a bit of a headache for code
 maintenance (hello bicycle repair man jam session), and it's also fairly
 unfriendly for library authors.

 There is a solution to that problem, which is not using generators if
 you'd want co-routines. If you want co-routine like behavior, please
 implement co-routines (and you can prop whatever scheduling/managing on top
 of that).

 An argument has been made in earlier discussions on that topic, that JS
 VMs can't deal with co-routines (garbage collection, DOM, whatever). But
 surely, if the VM can support generators/continuations, it could support
 full co-routines.


 VM issues are not the argument against coroutines or deep generators. The
 issue is that unpredictable interleaving makes reasoning about invariants
 much too difficult. Without these, we have an important guarantee: When f
 synchronously calls g, the only side effects that might have occurred by
 the time g returns to f are those g might have caused. Thus, these are the
 only side effect possibilities that f must worry about.

 See section 18.3 of http://www.erights.org/talks/thesis/markm-thesis.pdf
 and replace postfix diagonal uparrow with prefix await. In ES7 the
 example would be

 async function foo() { return bar(await getint(), y()); }
 ... await foo() ...

 The net effect is like co-routines, except that the placement of async
 and await -- like the diagonal uparrow in the text -- marks the places
 where interleaving might occur. This is as close to coroutine support as we
 should ever come.



 I'd recommend python's greenlet as an outstanding implementation of a
 co-routine interface that includes basically everything one could wish from
 it. I'd not consider python 3's asyncio a proper co-routine
 implementation (i.e. it's the same generator/await hack as is being
 discussed here).

 On Thu, Sep 11, 2014 at 3:05 PM, Kevin Smith zenpars...@gmail.com
 wrote:

 Also, see https://github.com/lukehoban/ecmascript-asyncawait/issues/14
 for previous discussion.

 On Thu, Sep 11, 2014 at 8:42 AM, Domenic Denicola 
 dome...@domenicdenicola.com wrote:

 There are several problems solved by async/await instead of twisting
 generators:

 1. What if you wanted to use generators for lazy sequences (iterables),
 instead of asynchronicity? If your framework assumes all generators are for
 async, you lose the original use case of generators.

 2. Say what you mean. `function*` and `yield` mean something very
 different from `async function` and `await`, similar to how
 `Subclass.prototype = Object.create(Superclass.prototype);
 Subclass.prototype.constructor = Subclass` is different from `class
 Subclass extends Superclass`.

 3. Operator precedence. You can do `await a + await b` to mean `(await
 a) + (await b)`, but `yield a + yield b` means `yield (a + (yield b))`.

 4. Ability to produce promise-returning functions without buying into a
 specific framework that interprets generators in a certain way. E.g., you
 could use `async function f() { return 5; }` to return a promise for 5,
 which people can consume with `f().then(v = ...)`. If you try to do
 `function* f() { return 5; }` you will get an iterable, which is not
 understood to be asynchronous. (Hopefully my use of `return 5` for brevity
 instead of more complex code does not confuse this point for you.)

 As for stack traces, long stack trace support is a debugging feature,
 and the fact that `yield*` gets them right now doesn't mean that `await`
 won't get them in the future.

 -Original Message-
 From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf

Re: Does async/await solve a real problem?

[Florian Bösch]

Furthermore, since await is call graph infectious, for those really wanting
to use it, it means that before long, await is written before every single
function call. Which makes no sense.

On Thu, Sep 11, 2014 at 4:22 PM, Florian Bösch pya...@gmail.com wrote:

 A - B - C - D - E changes to

 A - B - C - D - async E and causes

 A await - B await - C await - D await - async E

 And of course if A, B, C or D is used anywhere else it percolates trough
 the entire call graph.

 Trying to protect people from interlaved code execution effects is noble.
 But doing so by introducing a rote thing to type everytime you change the
 code somewhere underneath is wrong. It's wrong because it breaks logic
 isolation, it becomes impossible to change part of the library/utiity code
 without this change affecting all code that uses it. This guarantees that
 it doesn't happen in practice, because it's too painful to do. It requires
 the code, that uses other code, to know about the internal behavior of that
 code.

 If say, I'd propose a semantic that required you to write foo in the
 code, but just for those pieces of code that contain mentions of bar, or
 that reference code that contains bar to the Nth degree, you'd accuse me
 of trying to introduce a purposefully unusable feature. How is await/async
 not an unusable feature?



 On Thu, Sep 11, 2014 at 4:00 PM, Mark S. Miller erig...@google.com
 wrote:

 On Thu, Sep 11, 2014 at 6:20 AM, Florian Bösch pya...@gmail.com wrote:

 await has also another problem in that if somewhere, deep down the call
 stack, something is intending to do async, then up the entire call stack
 everywhere you've got to insert await. It's a bit of a headache for code
 maintenance (hello bicycle repair man jam session), and it's also fairly
 unfriendly for library authors.

 There is a solution to that problem, which is not using generators if
 you'd want co-routines. If you want co-routine like behavior, please
 implement co-routines (and you can prop whatever scheduling/managing on top
 of that).

 An argument has been made in earlier discussions on that topic, that JS
 VMs can't deal with co-routines (garbage collection, DOM, whatever). But
 surely, if the VM can support generators/continuations, it could support
 full co-routines.


 VM issues are not the argument against coroutines or deep generators. The
 issue is that unpredictable interleaving makes reasoning about invariants
 much too difficult. Without these, we have an important guarantee: When f
 synchronously calls g, the only side effects that might have occurred by
 the time g returns to f are those g might have caused. Thus, these are the
 only side effect possibilities that f must worry about.

 See section 18.3 of http://www.erights.org/talks/thesis/markm-thesis.pdf
 and replace postfix diagonal uparrow with prefix await. In ES7 the
 example would be

 async function foo() { return bar(await getint(), y()); }
 ... await foo() ...

 The net effect is like co-routines, except that the placement of async
 and await -- like the diagonal uparrow in the text -- marks the places
 where interleaving might occur. This is as close to coroutine support as we
 should ever come.



 I'd recommend python's greenlet as an outstanding implementation of a
 co-routine interface that includes basically everything one could wish from
 it. I'd not consider python 3's asyncio a proper co-routine
 implementation (i.e. it's the same generator/await hack as is being
 discussed here).

 On Thu, Sep 11, 2014 at 3:05 PM, Kevin Smith zenpars...@gmail.com
 wrote:

 Also, see https://github.com/lukehoban/ecmascript-asyncawait/issues/14
 for previous discussion.

 On Thu, Sep 11, 2014 at 8:42 AM, Domenic Denicola 
 dome...@domenicdenicola.com wrote:

 There are several problems solved by async/await instead of twisting
 generators:

 1. What if you wanted to use generators for lazy sequences
 (iterables), instead of asynchronicity? If your framework assumes all
 generators are for async, you lose the original use case of generators.

 2. Say what you mean. `function*` and `yield` mean something very
 different from `async function` and `await`, similar to how
 `Subclass.prototype = Object.create(Superclass.prototype);
 Subclass.prototype.constructor = Subclass` is different from `class
 Subclass extends Superclass`.

 3. Operator precedence. You can do `await a + await b` to mean `(await
 a) + (await b)`, but `yield a + yield b` means `yield (a + (yield b))`.

 4. Ability to produce promise-returning functions without buying into
 a specific framework that interprets generators in a certain way. E.g., 
 you
 could use `async function f() { return 5; }` to return a promise for 5,
 which people can consume with `f().then(v = ...)`. If you try to do
 `function* f() { return 5; }` you will get an iterable, which is not
 understood to be asynchronous. (Hopefully my use of `return 5` for brevity
 instead of more complex code does not confuse this point

Re: Does async/await solve a real problem?

[Florian Bösch]

The problem of code interleaving isn't on a fundamental level (like with
threads). Threads are a very different best, that interlave at random
points in time, and hence require some heavy lifting by the environmnet/OS
to not immediately fall flat.

Cooperative multitasking between I/O primitives is much friendlier. But
still, you can wreck some havoc if you have multiple tasklets running that
modify the same data structure. You won't get a race condition in the
classical sense, but you can still produce garbage data (like say call out
to async inside a loop over an array of which you've cached the length).

However, the exact same breakage applies to await/async, because if you
await inside a loop, of which you've cached the length, and have some other
code modify the array in the meantime... So not really an argument.

On Thu, Sep 11, 2014 at 4:55 PM, Mark S. Miller erig...@google.com wrote:

 On Thu, Sep 11, 2014 at 7:22 AM, Florian Bösch pya...@gmail.com wrote:

 A - B - C - D - E changes to

 A - B - C - D - async E and causes

 A await - B await - C await - D await - async E

 And of course if A, B, C or D is used anywhere else it percolates trough
 the entire call graph.

 Trying to protect people from interlaved code execution effects is noble.


 Exactly. Good to see we agree on the implications even if we value these
 outcomes differently.



 But doing so by introducing a rote thing to type everytime you change the
 code somewhere underneath is wrong. It's wrong because it breaks logic
 isolation, it becomes impossible to change part of the library/utiity code
 without this change affecting all code that uses it. This guarantees that
 it doesn't happen in practice, because it's too painful to do. It requires
 the code, that uses other code, to know about the internal behavior of that
 code.

 If say, I'd propose a semantic that required you to write foo in the
 code, but just for those pieces of code that contain mentions of bar, or
 that reference code that contains bar to the Nth degree, you'd accuse me
 of trying to introduce a purposefully unusable feature. How is await/async
 not an unusable feature?


 On Thu, Sep 11, 2014 at 7:25 AM, Florian Bösch pya...@gmail.com wrote:

 Furthermore, since await is call graph infectious, for those really
 wanting to use it, it means that before long, await is written before every
 single function call. Which makes no sense.


 In a purely functional system without side effects of any form (i.e.,
 ignoring even strictness and exceptions), interleaving is harmless, so this
 conclusion is valid. You would indeed safely get better code reuse if you
 placed async/await everywhere, so that instead should have been the default
 in such a language. In fact, since interleaving is harmless, you can
 schedule all computation as you like, including in parallel, lazily,
 eagerly, whatever, without harming correctness. In the absence of side
 effects, we should indeed not have placed a notational burden on
 interleaving points.

 But in an imperative system with synchronous side effects that co-exists
 with interleaving hazards, we also needs a way to protect against such
 hazards. The economy of the communicating event loop model is that each
 turn is implicitly a mutually exclusive atomic transaction -- without
 needing extra notation for synchronization or transaction boundaries.

 The cost of making atomicity cheap is that interleaving points must be
 made explicit. With callbacks, this cost is quite high. Promises reduce
 this cost substantially. async/await further reduces this cost about as far
 as it can be reduced, while still leaving an explicit marker.

 --
 Cheers,
 --MarkM

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

Re: Strawman proposal: new `is` operator

[Florian Bösch]

Python, Coffeescript and VB use the is operator for object identity, not
for instanceof like functionality. Dart uses the is operator analogous to
instanceof. It would seem to me it'd be beneficial to pick a different
operator name, in order to avoid the fuddled meaning this operator has
taken to mean in a variety of languages.


On Mon, Aug 25, 2014 at 12:39 AM, Ian Hickson i...@hixie.ch wrote:

 On Sun, 24 Aug 2014, Isiah Meadows wrote:
 
  One big question I have is whether a different keyword should be used
  (`isa`, etc), given its use as a keyword synonym to `===` in many
  compile-to-JS languages, most notably CoffeeScript.

 is is used to mean is an instance of or an instance of a subclass of
 in C# and modern Pascals, FWIW. Perl uses isa for this.

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL
 http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
 ___
 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: Thread about ES6 on reddit

[Florian Bösch]

I'd like to point out a example where using different sources (from older
and newer versions of a language) inside one runtime environment is used
fairly successfully.

Each OpenGL version comes with a new version of the GLSL language, which
may break things. On top of my head this was the case in:

   - varying - in/out
   - gl_FragColor - gl_FragData[n]
   - removal of builtins (such as gl_ModelView)

The first version of GLSL for a platform does not require marking up with a
version (as in OpenGL 2.0, OpenGL ES 2.0). Subsequent versions required the
version directive #version XXX on top of the source file, if they wanted
to use later iterations of GLSL.

The advantage of that was that all engines/libraries/snippets you might've
used keep working, even as you start using the newer version and gradually
fade out support/development/dependencies for older versions.


On Tue, Aug 12, 2014 at 2:05 AM, Brendan Eich bren...@mozilla.org wrote:

 Andrea Giammarchi wrote:

 I read that and still not convinced this is good for the web or
 developers.


 Well, forget me. What did you think of Florian's argument citing Python 3
 vs. 2 uptake problems? I see Perl 6 (full of great ideas that required a
 compat break) vs. 5 in the same light. Evolution is hard to beat.


 /be
 ___
 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: Bytecode

[Florian Bösch]

On Fri, May 16, 2014 at 10:18 PM, C. Scott Ananian ecmascr...@cscott.netwrote:

 On Fri, May 16, 2014 at 12:49 PM, Mameri, Fred (HBO) 
 fred.mam...@hbo.comwrote:

  maintaining performance and debuggability would be nice. But for me,
 the main benefit of the bytecode is having my engineering team be able to
 adopt newer versions of the language at our convenience (instead of waiting
 10 years until some ancient client updates their script engine)…


 You may want to look into the following:  coffeescript, traceur, dart,
 es6-shim (etc).
   --scott


Far as I see it, the discussion isn't really about bytecode. It's about
that you can't quickly/easily tack onto JS everything that's required to
make it a good virtual machine you can target from another language. asm.js
is certainly trying, but it's also so far unsupported everywhere but
Firefox. asm.js does have this problem that it it can't express available
native types (byte, short, float, long etc.) because it's running in JS,
which only knows doubles, or ints (appending bit or). And that ain't gonna
change, because if asm.js starts to rely on functionality (such as type
annotations for asm.js) that other JS engines don't have, the asm.js code
won't run anywhere else anymore.

So the discussion really is about a Web-VM that's got all the trimmings of
being a good compile target. What intermediary format you deliver to it is
quite a secondary question.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bytecode

[Florian Bösch]

Well, if you're simply going to come up with a bytecode to match JS, then
you're gonna have the same kinds of issues that typescript, asm.js, dart,
etc. have to target it as a compile target. So if you want to make a VM
that's a good compile target, ye're gonna have to eventually discuss what
that actually means.


On Mon, May 19, 2014 at 3:43 PM, Till Schneidereit 
t...@tillschneidereit.net wrote:

 On Mon, May 19, 2014 at 3:32 PM, Florian Bösch pya...@gmail.com wrote

 Far as I see it, the discussion isn't really about bytecode. It's about
 that you can't quickly/easily tack onto JS everything that's required to
 make it a good virtual machine you can target from another language. asm.js
 is certainly trying, but it's also so far unsupported everywhere but
 Firefox. asm.js does have this problem that it it can't express available
 native types (byte, short, float, long etc.) because it's running in JS,
 which only knows doubles, or ints (appending bit or). And that ain't gonna
 change, because if asm.js starts to rely on functionality (such as type
 annotations for asm.js) that other JS engines don't have, the asm.js code
 won't run anywhere else anymore.

 So the discussion really is about a Web-VM that's got all the trimmings
 of being a good compile target. What intermediary format you deliver to it
 is quite a secondary question.


 This discussion is about nothing of the sort: it's purely about where one
 can find good arguments against the needs for a bytecode for the web.
 Please please please keep it that way: the discussion you and Fred want to
 engage in has been had too many times and really isn't a good topic for
 this mailing list in any case.


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

Re: Bytecode

[Florian Bösch]

So just so I get this straight. You're talking about a bytecode format,
which implies some kind of revamped features/VM to run it, but you won't be
discussing anything other than ECMAScript as the targeting semantic. Sorry
to say, but then that's a pretty useless discussion entirely.


On Mon, May 19, 2014 at 3:53 PM, Till Schneidereit 
t...@tillschneidereit.net wrote:

 On Mon, May 19, 2014 at 3:46 PM, Florian Bösch pya...@gmail.com wrote:

 Well, if you're simply going to come up with a bytecode to match JS, then
 you're gonna have the same kinds of issues that typescript, asm.js, dart,
 etc. have to target it as a compile target. So if you want to make a VM
 that's a good compile target, ye're gonna have to eventually discuss what
 that actually means.


 Yes. But then this list would still not be the right venue, as that
 bytecode wouldn't be EcmaScript. So this is off-topic regardless of what
 you think of the merits of such a discussion.

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

Re: Bytecode

[Florian Bösch]

Well, it is a thread on bytecode, that had a discussion on bytecode, but
sure, whatever.


On Mon, May 19, 2014 at 4:07 PM, Till Schneidereit 
t...@tillschneidereit.net wrote:

 On Mon, May 19, 2014 at 3:55 PM, Florian Bösch pya...@gmail.com wrote:

 So just so I get this straight. You're talking about a bytecode format,
 which implies some kind of revamped features/VM to run it, but you won't be
 discussing anything other than ECMAScript as the targeting semantic. Sorry
 to say, but then that's a pretty useless discussion entirely.


 No, I don't want to talk about a bytecode format *at all*. At least not on
 this list, as this list is about ECMAScript, and nothing else. If you want
 to make the case for a bytecode format for the web, take it to some other
 forum.

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

Re: Native base64 utility methods

[Florian Bösch]

I'd like highlight the fact that binary data handling in JS these days is
mainly done via ArrayBuffers and TypedArrayViews. To that end, I've written
a base64 to Uint8Array decoder like so:
https://gist.github.com/pyalot/4530137

I don't quite see how atob/btoa without a usable binary type (indexable by
byte, get the byte values out) should work.


On Mon, May 5, 2014 at 8:22 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 @john I don't really care about the namespace/module as long as this
 matter moves from W3C spec to ES one.

 @mathias didn't mean to change atob and btoa rather add two extra methods
 such encode/decode for strings (could land without problems in the
 String.prototype, IMO) with less silly names whatever definition of silly
 we have ^_^

 Also interesting the @claude info on ISO strings ... yes, any UTF-8
 compatible support is what I meant, doing in JS land
 unescape(encodeURIComponent(str)) feels very hacky, and it's slow, indeed

 take care


 On Mon, May 5, 2014 at 8:16 AM, John Barton johnjbar...@google.comwrote:




 On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 +1 and as generic global utility it would be also nice to make it
 compatible with all strings.


 A language with modules does not need nor should it rely on stuff more
 favorite features onto global.  We need standard modules for all new
 features.
 jjb



 ___
 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: Multiline Strings

[Florian Bösch]

On Fri, Mar 7, 2014 at 8:52 PM, Peter van der Zee e...@qfox.nl wrote:

 I think you want to take a look at source maps. They're specifically
 designed to deal with this problem.


The problem is that a function like compileShader would look like this:

var compileShader(source){
   var shader = gl.createShader(gl.VERTEX_SHADER);
   gl.shaderSource(shader, source);
   gl.compileShader(shader);
   if(!gl.getShaderParameter(GL_COMPILE_STATUS)){
 var error = glGetShaderInfoLog(shader);
 // now what?

 // need file of source

 // need lines # of source

   }
}

And you'd do things like:

var source = 
   void main(){
  #{someSnippet}
  gl_FragColor = whatever;
   }

compileShader(source);

I don't see how source maps help either.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Multiline Strings

[Florian Bösch]

On Sat, Mar 8, 2014 at 6:10 PM, John Barton johnjbar...@google.com wrote:

 You may like to take a look at how the traceur compiler (
 https://github.com/google/traceur-compiler) works. It allows one to write
 code like
 var statement = parseStatement `${result}[${index}++] =
 ${expression};`;
 where the ${} syntax surrounds variables from the caller that are
 substituted into the string.  In our case the result 'statement' is an AST
 but it could source code just as well. And source maps work fine for our
 code. Well as fine a source maps ever work ;-)


That's a fine approach, and I'm not against preprocessing in any flavor if
that's your cup-o-tea. The problem rather is that one explicit usecase of
multiline strings (aka templates) is to make it easier to write DSLs. But
if you write DSLs and embedd the strings in your JS source somewhere,
you're gonna have to deal with debugging of any kind.

For example, WebGL implementations return errors strings like these:

ERROR: 0:1: 'foobar' : syntax error

You can imagine that being confronted with a string like that, out of
thousands of shader code lines in your application, isn't very useful.
You'll also realize that, not all errors can actually be detected with a
validator.

In order to make this a useful piece of error message, you'll need to
translate whatever WebGL throws back at you, to a sourceline and filename.
And unless you instrumented this beforehand with a preprocessor, you're not
gonna get it.

So my question is this, is everybody happy with the state of affairs that a
preprocessor is the only viable way to use templates/multiline strings for
DSLs, or am I the only one who thinks that could somehow be better?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Multiline Strings

[Florian Bösch]

I'm sorry if that's been asked before (I looked trough the archives trough
to 2012 and couldn't find a thread on it).

Are there any plans on adding multiline strings?

Some examples of multiline strings below.

Lua:
foo = [[A
Multiline
String]]

Python:
foo = '''A
Multiline
String'''

Coffeescript:
foo = '''A
Multiline
String'''

Dart:
foo = A
Multiline
String'''

C++11:
foo = Rbar(A
Multiline
String)bar;

Ruby:
foo = 'A
Multiline
String'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss