Another "pipeline" operator idea

2017-03-13 Thread J?r?my Jud?aux 
I'd like to (re-)propose a "pipeline" operator. In fact, it has already been 
seen in some other places.

There are already some discussions and proposals:

- https://github.com/mindeavor/es-pipeline-operator
- 
https://esdiscuss.org/topic/the-pipeline-operator-making-multiple-function-calls-look-great
- https://github.com/tc39/proposal-bind-operator

This email is mostly to refresh the discussions on "pipeline" operators, I saw 
the two other proposals are still looking for Champions.
There have been a lot of benefits already listed; chaining functions, not 
having to extend prototypes, reusability on data of different types, ...
I have a personal use case about chain of Promises, which is not usable without 
a pipeline operator (no matter which one). Like `promise %%% 
token.then(handler)`.
And I suspect there are more useful ideas/libraries to be developed, just 
waiting for a(any) more advanced operator proposal.


For this "new proposal":
Let's have a `LeftExpression OPERATOR Thing ( OptionalArgumentList )` to be the 
equivalent of `Thing ( LeftExpression, OptionalArgumentList)`.
Where the ensemble `Thing ( OptionalArgumentList )` is a valid expression, and 
`Thing` is not a call expression, or is a call expression in parentheses. I'm 
not sure how it translates into actual grammar.

So, in practice:
- `v OP f()` is `b(v)` // like `v |> f`
- `v OP f(a)` is `f(v, a)`
- `v OP f.call()` is `f.call(v)` // like `v::f()`
- `v OP f.bind()` is `f.bind(v)` // like `v::f`
And more:
- `v OP f(a)(b)` is `f(v, a)(b)`
- `v OP (f(a))(b)` is `(f(a))(v, b)`
- `v OP (f())()` is `f()(v)`
- `v OP (f())` is not valid
- `(v OP f)()` is not valid
- `v OP o.f()` is `o.f(v)`
- `v OP ((_) => f(_))()` is `((_) => f(_))(v)`
- `v OP (_ => f(a, _))` is `(_ => f(a, _))(v)` // improved with placeholder
- `v OP new F()` is `new F(v)`
- `v OP await f()` is `await f(v)`
- `v OP (await f)()` is `(await f)(v)`
- `v OP _=>_()` is `(_=>_)(v)` // not sure
And maybe that:
- `v OP yield f()` is `yield f(v)`
- `v OP super()` is `super(v)`

How it compares with `a::b()`: a bit more verbose, open more possibilities, 
doesn't solve the binding member access `::a.b`.
How it compares with `a|>b`: depends on situation. Doesn't require a temporary 
function, more verbose with inlined arrow functions, can be improved with 
placeholder, opens more possibilities (`yield`, maybe a bad thing).
About placeholders: placeholders can improve readability (`v OP f(a)` doesn't 
show that `v` will be the first argument, `v OP f(#,a)` does) and reduce the 
necessity for inlined arrow functions. But I don't think any pipeline operator 
should be delayed by that improvement.


It may not be wise to post "yet another operator proposal" when I'm waiting for 
an existing one to get advanced. Hopefully it will draw some attention back to 
the other proposals.

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

Re: Proposal of Multithread JavaScript

2017-03-13 Thread Wes Garland 
If anybody wants to play with MT ES (I'm not saying I think this is a good
idea) -- you might want to dig up a ~ten-year old version of Spidermonkey,
perhaps the JS 1.7 release (MT "safety" broke with Array Extras).   Then
add this code, which implements a basic Thread class:
https://github.com/wesgarland/gpsee/blob/master/modules/thread/
(hopefully that code builds without too much effort...I stopped using
it as soon as it was finished, I did not find the paradigm useful in my
work).

The result is lock-free property access (anarchy!) on a global object
shared across operating system threads.

You might be able to then prototype a smarter API in ES3 and see how you
like it.

I think you might also be able to try similar experiments with Rhino using
Java threads.

Wes

On 13 March 2017 at 00:19, Isiah Meadows  wrote:

> For prior discussion on a fairly similar concept, see my proposal [1]
> and related thread [2].
>
> [1]: https://gist.github.com/isiahmeadows/a01799b4dc9019c55dfcd809450afd24
> [2]: https://esdiscuss.org/topic/module-based-parallel-js-strawman
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Sun, Mar 12, 2017 at 10:14 PM, /#!/JoePea  wrote:
> >
> > On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea  wrote:
> >>
> >> Leo's idea that JavaScript code as it is today won't be impacted when
> >> async functions are run in separate threads is interesting.
> >
> >
> > I meant, "Leo's idea that JavaScript code as it is today can work exactly
> > the same (f.e. async functions) while behind the scenes be threaded
> without
> > impacting end JS-devs is interesting."
> >
> >
> > /#!/JoePea
> >
> > ___
> > 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
>



-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss