Re: Re: Proposal: expression mode (=)

[Isiah Meadows]

Not quite. I did some later thinking, and hage found probably a simpler
solution.

On Mon, Oct 31, 2016, 16:10 Yongxu Ren  wrote:

> Isiah,
> The reason for `=` instead of the `do expression` is to write functional
> code without extra syntax. I do not think there are any indistinguishable
> or 'very confusing' case, though I am aware the *Object Property Shorthand`
> that been introduced in ES6 might cause some problems.
>
> Here is what I think that may resolve this problem
> for your concern,
> ```
> var b = 1
> var a = b
> = { c }
> ```
>
> the solution is to make `Object literals` to have higher parsing priority.
>

Actually, the above example should read as this:

```js
a
= { b }
```

First, most linters will complain, anyways.

Second, it could be resolved by requiring no line terminator appears
between the assignee and `=` operator. The Closure Compiler is okay with
emitting such code normally, but no other minifier does by default. And
those can be fixed.


> if `c` is a variable, it will be parsed as `object literal`, otherwise it
> is considered as scope and been parsed as expression block.
>
> ex.
> `var x = { a }` will be parsed as `var x = { a: a }`
> `var x = { a() }` will be parsed as `var x = a()`, under current specs it
> would be syntax error.
>

You missed the original proposal here. Your examples should be this (with
the preceding `=`):

```js
var x = = { a }
var x = = { a() }
```


> In this case, this proposal should not cause any confusion IMO.
>

To clarify, I'm mentioning parser ambiguity, not visual (which does exist
to some extent).

___
> 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: Re: Proposal: expression mode (=)

[Yongxu Ren]

Isiah,
The reason for `=` instead of the `do expression` is to write functional
code without extra syntax. I do not think there are any indistinguishable
or 'very confusing' case, though I am aware the *Object Property Shorthand`
that been introduced in ES6 might cause some problems.

Here is what I think that may resolve this problem
for your concern,
```
var b = 1
var a = b
= { c }
```

the solution is to make `Object literals` to have higher parsing priority.

if `c` is a variable, it will be parsed as `object literal`, otherwise it
is considered as scope and been parsed as expression block.

ex.
`var x = { a }` will be parsed as `var x = { a: a }`
`var x = { a() }` will be parsed as `var x = a()`, under current specs it
would be syntax error.

In this case, this proposal should not cause any confusion IMO.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Isiah Meadows]

Inline.

On Mon, Oct 31, 2016, 10:33 Boris Zbarsky  wrote:

> On 10/31/16 8:42 AM, Isiah Meadows wrote:
> > When the worker has finished loading, so you can send and receive
> messages
>
> OK, what about a worker that when it loads just starts and infinite loop
> and starts sending you messages (but obviously never expects any
> messages from you, since it's in an infinite loop)?
>

You still add the `onMessage` handler then. The promise is to encapsulate
errors that occur when creating the worker (e.g. the file doesn't exist).

To clarify, the messages sent since the last tick, and returned promises
resolved, are queued after the current tick ends.

Also, both exports from the worker's side are optional.


> Or is the idea to not support this behavior?  If so, I'm a little
> worried about specifying something with totally different behavior from
> DOM Workers and calling it "Worker".
>

It's supported. See above.


> > What if the "result" of the message is a sequence of messages back?
> > This is a common thing to do with web workers: ask it to do
> something,
> > and it sends the answer back in chunks.
> >
> > The result is the value returned from the worker's `onMessage`. This
> > does permit async return values, because it's fairly common (at least in
> > my case) to send a message and expect a response as effectively a return
> > value, and I would like to reify that.
>
> I think we're talking past each other a bit here, but please see above
> about naming.
>

Yeah...I don't think we were on the same page.


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

Re: Cancel Promise pattern (no cancellable promises)

[Herby Vojčík]

Herby Vojčík wrote:



Jan-Ivar Bruaroey wrote:

On 10/28/16 8:39 AM, Bergi wrote:

Jan-Ivar Bruaroey wrote:

If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-cancellable
operations, there'd be a delay if cancel is detected during those.


Yes, that's what I mean. Sure, I could use `Promise.race` to get the
cancellation even if the non-cancellable operation resumes, but that's
quite ugly:

Promise.race([
promise()
…chain…,
cancelToken
]).then(callback);

especially when you'll need to nest that pattern.


To be clear, the non-cancellable operation won't "resume" in the face of
a CancelledError. Only if the cancel happened to trigger during one of
the non-cancellable actions would there be a slight delay until that
non-cancellable operation finished (which I consider a feature) and if a
cancellable operation follows it, cancellation will happen at that point.

In someone can't tolerate that, then Promise.race is well-defined to do
exactly what you show, and works in harmony with this pattern. Why
reinvent the wheel?

And you'd Promise.race against the entire chain, so no need to nest this
pattern typically. This is what I mean with focusing on the minimal
use-case. Most people just want us to solve fetch already, so that
expensive network resources can be freed. To get out of the current
inertia, why not define:

fetch (url, { cancelPromise: token })


OTOH, why not to just use Promise.race directly and promote the pattern
of "specify alternate result".
1. This is more general;
2. This allows creating decorators and use them like
shortcutAfter(5000, Promise.reject())(fetch(url))


Well, "shortCircuitAfter" would be probably better name.


now and use this pattern, and leave the more desirable { cancel } name
for whatever future invention we hope will replace it (or annex it if
nothing better materializes)?

.: Jan-Ivar :.


Herby

___
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: Cancel Promise pattern (no cancellable promises)

[Herby Vojčík]

Jan-Ivar Bruaroey wrote:

On 10/28/16 8:39 AM, Bergi wrote:

Jan-Ivar Bruaroey wrote:

If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-cancellable
operations, there'd be a delay if cancel is detected during those.


Yes, that's what I mean. Sure, I could use `Promise.race` to get the
cancellation even if the non-cancellable operation resumes, but that's
quite ugly:

Promise.race([
promise()
…chain…,
cancelToken
]).then(callback);

especially when you'll need to nest that pattern.


To be clear, the non-cancellable operation won't "resume" in the face of
a CancelledError. Only if the cancel happened to trigger during one of
the non-cancellable actions would there be a slight delay until that
non-cancellable operation finished (which I consider a feature) and if a
cancellable operation follows it, cancellation will happen at that point.

In someone can't tolerate that, then Promise.race is well-defined to do
exactly what you show, and works in harmony with this pattern. Why
reinvent the wheel?

And you'd Promise.race against the entire chain, so no need to nest this
pattern typically. This is what I mean with focusing on the minimal
use-case. Most people just want us to solve fetch already, so that
expensive network resources can be freed. To get out of the current
inertia, why not define:

fetch (url, { cancelPromise: token })


OTOH, why not to just use Promise.race directly and promote the pattern 
of "specify alternate result".

  1. This is more general;
  2. This allows creating decorators and use them like
shortcutAfter(5000, Promise.reject())(fetch(url))


now and use this pattern, and leave the more desirable { cancel } name
for whatever future invention we hope will replace it (or annex it if
nothing better materializes)?

.: Jan-Ivar :.


Herby

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

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/31/16 8:42 AM, Isiah Meadows wrote:

When the worker has finished loading, so you can send and receive messages


OK, what about a worker that when it loads just starts and infinite loop 
and starts sending you messages (but obviously never expects any 
messages from you, since it's in an infinite loop)?


Or is the idea to not support this behavior?  If so, I'm a little 
worried about specifying something with totally different behavior from 
DOM Workers and calling it "Worker".



What if the "result" of the message is a sequence of messages back?
This is a common thing to do with web workers: ask it to do something,
and it sends the answer back in chunks.

The result is the value returned from the worker's `onMessage`. This
does permit async return values, because it's fairly common (at least in
my case) to send a message and expect a response as effectively a return
value, and I would like to reify that.


I think we're talking past each other a bit here, but please see above 
about naming.


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

Re: Re: Proposal: expression mode (=)

[Isiah Meadows]

For what it's worth, if the `=` requires a space before it (I disagree that
the semantic ambiguity must exist at assignment - it could simply require
whitespace), that alone would create sufficient context to differentiate.
Compare these two:

```js
a == {} // loose equals, almost always false
a = = {} // a = undefined
```

Labels would already be unambiguous, because it can only parse statements.

Here's my concern about ambiguity, though:

```js
var b = 1
var a = b
= { c }
```

What's `a`? ASI makes this much less obvious to resolve, and resolving this
by changing assignment to require no line terminator before the `=` is
technically a breaking change. (Oh, and the Closure Compiler can and will
spit out that.)

On Sun, Oct 30, 2016, 23:35 Yongxu Ren  wrote:

> For supporting label, yes that is kinda a problem.
> However, IMO jumping around labels is an anti-pattern in functional
> programming, I don't think it needs to be supported. Syntax error might be
> the most reasonable way in this case.
>
> for 'match', while it is just some thought. I wasn't intended to proposal
> it but just showing potential of  extending `= expression`.
>
> Personally I do not think label would be a problem for implementing this
> pattern.
>
> here are two possible solutions I can think of:
>
> 1. If `[name]:` exist inside the block, just parse it as object and throw
> error if the structure doesn't match.
>
> 2. If `[label]:` does exist inside the block,  only allow in scope jump.
> (label not accessible outside the scope)
>
> ___
> 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: Proposal: expression mode (=) (Caitlin Potter)

[Isiah Meadows]

I'd have to agree that `=` just feels ugly and slightly wrong for this use
case.

On Sun, Oct 30, 2016, 22:05 Caitlin Potter  wrote:

>
>
> > On Oct 30, 2016, at 9:33 PM, David Baldwin <
> david.chris.bald...@gmail.com> wrote:
> >
> > So just to clarify would the non-labeled statements be required to be
> before the labeled statements in the object?
>
> if you wanted this to be compatible with code on the web (eg foo = { key:
> value }), yes (and, you do). But that would be a confusing caveat, so I'd
> go with a different strategy (new operators or keywords).
>
> >
> > May it would be better to have a "code" key that would contain all
> runnable code statements. It wouldn't be aa elegant but at least it would
> be clear
>
> I'm not entirely sure what this means. Something like objc/swift blocks?
>
> >
> >
> >> On Oct 30, 2016, 08:09 -0700, es-discuss-requ...@mozilla.org, wrote:
> >> Send es-discuss mailing list submissions to
> >> es-discuss@mozilla.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://mail.mozilla.org/listinfo/es-discuss
> >> or, via email, send a message with subject or body 'help' to
> >> es-discuss-requ...@mozilla.org
> >>
> >> You can reach the person managing the list at
> >> es-discuss-ow...@mozilla.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of es-discuss digest..."
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Proposal: expression mode (=) (Caitlin Potter)
> >> 2. Re: Proposal: expression mode (=) (Caitlin Potter)
> >>
> >> ___
> >> 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
> ___
> 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: Standardize ES Worker

[Isiah Meadows]

I just specified some basic semantics. That sounds like a good idea, but I
feel it should just remain a WHATWG extension for now. Technically, you can
still manage ids to ensure it ends up properly coordinated (you already had
to do this when working at scale).

On Sun, Oct 30, 2016, 23:44 Park Hyeonu  wrote:

+1 for `import.fork()`, especially for deep integration with module syntax.

Anyway I think we still need to create Independent message channel which
can be transferable, for use cases like returning sequence of messages,
central worker manager, etc.

I agree with your approach to avoid new global variable as much as
possible. To respect this, how about `Channel#createChannel` method?

```
const [chan, remoteChan] = worker.createChannel()
worker.send('newchan', remoteChan [remoteChan])
```

2016. 10. 28. 오전 7:18에 "Isiah Meadows" 님이 작성:

Here's my idea for a new API, leveraging ES modules and the proposed (stage
2) dynamic `import()` proposal. It also supports the shared memory proposal.

1. Add a new `import.fork(script): Promise` method-like expression
that loads the worker and resolves when done/rejects if it couldn't for
some reason.

  - `receive` is a function that accepts a message and may optionally
return a value or thenable to it, which is cloned and returned to the
worker's `send` call.

2. Add the following methods/properties:

  - `worker.terminate()` - Terminate the worker
  - `worker.send(message, sharedBuffers?)` - Send a message and return a
Promise to its result.
  - `worker.receive(message)` - A setter for a function that accepts a
message and may optionally return a value or thenable to it, which is
cloned and returned to the worker's `send` call.

3. Load the worker as a module. The following exports are used specially,
and they're both optional:

  - `initialize(parent)` - A function that accepts a `parent` with two
methods: `parent.terminate()` to terminate the worker's own thread and
`parent.send` being equivalent to `worker.send` above (except in the other
direction). This is called immediately after the parent's wrapping promise
resolves.
  - `receive(message)` - Receive messages from the parent, and works
similarly to `worker.receive`.

I chose syntax for similar reasons Domenic chose syntax for his dynamic
import proposal, for example, the modules can be statically resolved, which
enables prefetching.

I also chose modules to leverage themodule system to my advantage, in
particular to avoid adding new globals.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Isiah Meadows]

Inline

On Thu, Oct 27, 2016, 21:42 Boris Zbarsky  wrote:

> On 10/27/16 6:18 PM, Isiah Meadows wrote:
> > 1. Add a new `import.fork(script): Promise` method-like
> > expression that loads the worker and resolves when done/rejects if it
> > couldn't for some reason.
>
> What does "done" mean in this case?
>

When the worker has finished loading, so you can send and receive messages


> >   - `worker.send(message, sharedBuffers?)` - Send a message and return a
> > Promise to its result.
>
> What if the "result" of the message is a sequence of messages back?
> This is a common thing to do with web workers: ask it to do something,
> and it sends the answer back in chunks.
>

The result is the value returned from the worker's `onMessage`. This does
permit async return values, because it's fairly common (at least in my
case) to send a message and expect a response as effectively a return
value, and I would like to reify that.


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

Proposal: Expose offsets for capturing groups in regular expression matches

[Sebastian Zartner]

Hello together,

for advanced processing of capturing groups in regular expression, I'd like
to propose to expose their offsets within the results of executing an
expression on a string.

The complete proposal can be found at
https://github.com/SebastianZ/es-proposal-regexp-capturing-group-offsets.

I'd like it to be added to the Stage 0 proposals
 and
I'm asking for feedback and a champion to help me bring it into shape and
get it into the standard.

Thank you in advance,

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