Re: Could String internalize an ArrayBuffer?

[Coroutines]

On Sat, Dec 5, 2015 at 9:19 PM, Boris Zbarsky  wrote:

> For example, strings typically have a complicated representation that
> involves multiple fragments, ropes, etc, to make string concatenation fast.

Ahh, I'm not sure why I didn't think of that... I come from Lua and
they do something similar.  My favorite data structure has always
been:

https://en.wikipedia.org/wiki/Unrolled_linked_list

Anyway, now my question/proposal seems quite naive.

Conclusion: Just create a duplicate ArrayBuffer from a String and be done. :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

> It doesn’t look like there is any redeeming quality about this change, it
doesn’t introduce convenience

I think you may have missed the GitHub repo [1]; it outlines benefits and
convenience about the change. Also see this user's comment [2] on its
significance.

[1] https://github.com/mindeavor/es-pipeline-operator
[2] https://news.ycombinator.com/item?id=10686596

I argue that the syntax transformation is so simple that it would not
introduce any pain points for JavaScript authors. It is arguably more
intuitive than its alternative. JS programmers who are partial to FP
certainly agree [3][4].

[3] https://twitter.com/markdalgleish/status/673581814028492800
[4]
https://www.reddit.com/r/javascript/comments/3vox7x/es7_proposal_the_pipeline_operator/

> Anything involving “placeholders arguments” is especially bad because it
introduces an extra thing to reason about

I agree; I still prefer the original proposal.

> The bind operator may at least have the benefit of providing some out of
the box support for classic FP style

It does not, unfortunately. FP devs avoid the keyword `this`, but the bind
operator requires its use. If I'm not mistaken, the "chaining" part of the
bind operator is only a minor point, and isn't the main purpose of the
proposal.



On Sun, Dec 6, 2015 at 4:56 PM, Caitlin Potter 
wrote:

>
> >On Dec 6, 2015, at 4:51 PM, Gilbert B Garza 
> wrote:
> >
> >Confusing and horrible are subjective, but I do agree that it's not as
> nice as the original proposal.
> >Although I prefer the original, it's also important to discuss objections
> that people bring up, as well as
> >the alternatives that might solve said objections :)
>
> Even with the original solution, it just creates a new (and less obvious)
> way of writing something that is already possible in the language,
> and easier to understand. There is a narrow scope of times where it even
> makes sense to use the original (or enhanced) version of the
> proposal, and this requires authors to be vigilante about knowing when to
> pick one form over the other. It also requires code reviewers
> to be vigilante in knowing when to say “know, this is a bad idea, stop”.
>
> It doesn’t look like there is any redeeming quality about this change, it
> doesn’t introduce convenience, and does introduce new pain points
> for authors. Anything involving “placeholders arguments” is especially bad
> because it introduces an extra thing to reason about, but the issue
> with introducing a new syntax to pick and be aware of for limited gains is
> also problematic, growing the language and increasing complexity
> for a less than substantial reason.
>
> The bind operator may at least have the benefit of providing some out of
> the box support for classic FP style, so it’s got that going for it (but
> really,
> the language doesn’t need three distinct syntaxes/idioms for this pattern,
> the complexity budget is already running thin)
>
>
> Gilbert
>
> On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter 
> wrote:
>
>> These examples only make this language extension look like a confusing
>> and horrible thing. How is this an improvement, in any way?
>>
>> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza 
>> wrote:
>>
>> Status update: The JS community has shown [lots of excitement](
>> https://twitter.com/markdalgleish/status/673581814028492800) for the
>> idea of this proposal, but the syntax is still being debated. I outlined
>> two alternatives [in this GitHub issue](
>> https://github.com/mindeavor/es-pipeline-operator/issues/4), one of
>> which I will post here since it is my current favorite:
>>
>> ## Placeholder Arguments
>>
>> The alternative is to have a new syntax for "placeholder arguments" –
>> basically, slots waiting to be filled by the next function call. For
>> example:
>>
>> ```js
>> //
>> // Placeholder style
>> //
>> run("hello") |> withThis(10, #);
>> // is equivalent to
>> withThis( 10, run("hello") );
>>
>> //
>> // More complicated example
>> //
>> run("hello") |> withThis(10, #) |> andThis(#, 20);
>> // is equivalent to
>> andThis( withThis( 10, run("hello") ), 20 );
>> ```
>>
>> ### Pros / Cons
>>
>> - [pro] Very explicit (no surprises)
>> - [pro] Less function calls
>> - [pro] Compatible with even more of the JavaScript ecosystem
>> - [con] Requires more new syntax
>> - [con] Usage of the hash operator (#) would probably be hard to define
>> outside coupled use with pipeline operator (this problem could be avoided
>> by simply making it illegal)
>>
>>
>> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza > > wrote:
>>
>>> Ah, sorry for being unclear. You're right, in the case of manual
>>> currying, the closure can not and should not be optimized away.
>>>
>>> I was talking about the case where you have arrow function literals. For
>>> example:
>>>
>>> ```js
>>> var bounded = 750
>>> |> s => Math.max(100, s)
>>> |> s 

Re: Could String internalize an ArrayBuffer?

[Bergi]

Coroutines schrieb:


What I want is to be able to view a String through a typed array
without duplicating the memory/contents of that string.


The largest problem I see with this is that strings are immutable while 
typed arrays / buffers do allow indexed write access. So before using 
strings instead of buffers (or efficiently creating buffers from 
strings), we'd need to introduce something like ConstTypedArrays.


Regards,
 Bergi

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

Re: Reflection to know if executed within a generator/async ?

[Bergi]

Andrea Giammarchi schrieb:


simply adding
async and await and the only change to do in a well known/used
*synchronous* API would be to check if the returned value is held and
behave accordingly?


No, making a consumer of an API asynchronous should not be simple. 
Unless you are only writing pure functions, everything that involves 
states will very likely break. Concurrency is not trivial, it needs a 
lot of consideration.



as soon as you go for
async/await or a generator that function will return a Promise for you.


Please never do that. Functions that sometimes return promises and 
sometimes not are already known to be an antipattern. Making this 
obscurely dependent on some fragile syntactic conditions could only make 
this worse.


If you want to migrate your library to asynchrony, just make it a 
breaking change. Your consumers will thank you for it.


Kind regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

Status update: The JS community has shown [lots of excitement](
https://twitter.com/markdalgleish/status/673581814028492800) for the idea
of this proposal, but the syntax is still being debated. I outlined two
alternatives [in this GitHub issue](
https://github.com/mindeavor/es-pipeline-operator/issues/4), one of which I
will post here since it is my current favorite:

## Placeholder Arguments

The alternative is to have a new syntax for "placeholder arguments" –
basically, slots waiting to be filled by the next function call. For
example:

```js
//
// Placeholder style
//
run("hello") |> withThis(10, #);
// is equivalent to
withThis( 10, run("hello") );

//
// More complicated example
//
run("hello") |> withThis(10, #) |> andThis(#, 20);
// is equivalent to
andThis( withThis( 10, run("hello") ), 20 );
```

### Pros / Cons

- [pro] Very explicit (no surprises)
- [pro] Less function calls
- [pro] Compatible with even more of the JavaScript ecosystem
- [con] Requires more new syntax
- [con] Usage of the hash operator (#) would probably be hard to define
outside coupled use with pipeline operator (this problem could be avoided
by simply making it illegal)


On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza 
wrote:

> Ah, sorry for being unclear. You're right, in the case of manual currying,
> the closure can not and should not be optimized away.
>
> I was talking about the case where you have arrow function literals. For
> example:
>
> ```js
> var bounded = 750
> |> s => Math.max(100, s)
> |> s => Math.min(0, s);
> ```
>
> I imagine if the compiler sees arrow functions used in this specific
> manner, it could automatically optimize to the following:
>
> ```js
> var bounded = Math.min( 0, Math.max(100, 750) )
> ```
>
> Semantically, they are equivalent; no closures nor scopes were effectively
> used in the intermediary arrow functions.
>
>
> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows 
> wrote:
>
>> Not with your semantics. It has to generate a closure each time, because
>> of the possibility it can't be used elsewhere. That's impossible to know
>> ahead of time if the variable is ever used outside of its closure or as a
>> value. In the case below, it should only log thrice. Otherwise, it's
>> unexpected behavior.
>>
>> ```js
>> function add(x) {
>>   console.log("Hit!");
>>   return y => x + y;
>> }
>>
>> let inc = add(1);
>>
>> 1 |> inc |> inc |> add(2) |> add(3);
>>
>> // Hit!
>> // Hit!
>> // Hit!
>> ```
>>
>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza 
>> wrote:
>>
>> Normally yes, but since the pipeline operator is a pure function, I think
>> it's possible for the compiler to optimize away the intermediate arrow
>> functions. I mention this in the "Functions with Multiple Arguments"
>> section https
>> 
>> ://
>> 
>> github.com
>> 
>> /
>> 
>> mindeavor
>> 
>> /
>> 
>> ES7-pipeline-operator#functions
>> 
>> -with-multiple-arguments
>> 
>>
>>
>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows 
>> wrote:
>>
>> Inline
>>
>> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith 
>> wrote:
>> >> - I don't like the requirement to use the keyword `this` to compose
>> >> functions. JS already has many features to support the keyword `this`:
>> >> prototypes, method invocations, function binding, arrow functions, and
>> >> probably others. I prefer a feature that assists the other side of the
>> >> spectrum.
>> >
>> >
>> > Yep - a well documented critique.  It depends on your point of view, I
>> > think.  If you view these things as "extension methods", then using
>> `this`
>> > makes more sense.
>> >
>> >> - The fact that there are new semantics to what looks like a normal
>> >> function call (e.g. `->map(...)`) doesn't set well with me. You could
>> argue
>> >> that it's something to get used to. Even in that case, I would expect
>> the
>> >> first argument I give to `map` to stay the first argument.
>> >
>> >
>> > This is a reasonable objection, I think.
>>
>> Not to mention it's still a point of contention:
>> https
>> 
>> ://
>> 
>> github.com
>> 

Re: The "Pipeline" Operator - Making multiple function calls look great

[Alexander Jones]

Why not just have a rule that the pipeline operator consumes unary
functions, and reuse existing bind idioms, or a future bind syntax? That
seems like a proper separation of concerns to me.

As with those future bind syntax proposals, the idea of just sticking a
token somewhere within an expression to turn it into a lambda is not
ideal due to the various, obvious ambiguities that can arise. c.f. arrow
functions where the argument is given an explicit name.

On Sunday, 6 December 2015, Caitlin Potter  wrote:

> These examples only make this language extension look like a confusing and
> horrible thing. How is this an improvement, in any way?
>
> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza  > wrote:
>
> Status update: The JS community has shown [lots of excitement](
> https://twitter.com/markdalgleish/status/673581814028492800) for the idea
> of this proposal, but the syntax is still being debated. I outlined two
> alternatives [in this GitHub issue](
> https://github.com/mindeavor/es-pipeline-operator/issues/4), one of which
> I will post here since it is my current favorite:
>
> ## Placeholder Arguments
>
> The alternative is to have a new syntax for "placeholder arguments" –
> basically, slots waiting to be filled by the next function call. For
> example:
>
> ```js
> //
> // Placeholder style
> //
> run("hello") |> withThis(10, #);
> // is equivalent to
> withThis( 10, run("hello") );
>
> //
> // More complicated example
> //
> run("hello") |> withThis(10, #) |> andThis(#, 20);
> // is equivalent to
> andThis( withThis( 10, run("hello") ), 20 );
> ```
>
> ### Pros / Cons
>
> - [pro] Very explicit (no surprises)
> - [pro] Less function calls
> - [pro] Compatible with even more of the JavaScript ecosystem
> - [con] Requires more new syntax
> - [con] Usage of the hash operator (#) would probably be hard to define
> outside coupled use with pipeline operator (this problem could be avoided
> by simply making it illegal)
>
>
> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza  > wrote:
>
>> Ah, sorry for being unclear. You're right, in the case of manual
>> currying, the closure can not and should not be optimized away.
>>
>> I was talking about the case where you have arrow function literals. For
>> example:
>>
>> ```js
>> var bounded = 750
>> |> s => Math.max(100, s)
>> |> s => Math.min(0, s);
>> ```
>>
>> I imagine if the compiler sees arrow functions used in this specific
>> manner, it could automatically optimize to the following:
>>
>> ```js
>> var bounded = Math.min( 0, Math.max(100, 750) )
>> ```
>>
>> Semantically, they are equivalent; no closures nor scopes were
>> effectively used in the intermediary arrow functions.
>>
>>
>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows > > wrote:
>>
>>> Not with your semantics. It has to generate a closure each time, because
>>> of the possibility it can't be used elsewhere. That's impossible to know
>>> ahead of time if the variable is ever used outside of its closure or as a
>>> value. In the case below, it should only log thrice. Otherwise, it's
>>> unexpected behavior.
>>>
>>> ```js
>>> function add(x) {
>>>   console.log("Hit!");
>>>   return y => x + y;
>>> }
>>>
>>> let inc = add(1);
>>>
>>> 1 |> inc |> inc |> add(2) |> add(3);
>>>
>>> // Hit!
>>> // Hit!
>>> // Hit!
>>> ```
>>>
>>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza >> > wrote:
>>>
>>> Normally yes, but since the pipeline operator is a pure function, I
>>> think it's possible for the compiler to optimize away
>>> the intermediate arrow functions. I mention this in the "Functions with
>>> Multiple Arguments" section https
>>> 
>>> ://
>>> 
>>> github.com
>>> 
>>> /
>>> 
>>> mindeavor
>>> 
>>> /
>>> 
>>> ES7-pipeline-operator#functions
>>> 
>>> -with-multiple-arguments
>>> 
>>>
>>>
>>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows >> > wrote:
>>>
>>> Inline
>>>
>>> On Tue, Nov 10, 2015 at 

Re: The "Pipeline" Operator - Making multiple function calls look great

[Caitlin Potter]

These examples only make this language extension look like a confusing and 
horrible thing. How is this an improvement, in any way?

> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza  wrote:
> 
> Status update: The JS community has shown [lots of 
> excitement](https://twitter.com/markdalgleish/status/673581814028492800 
> ) for the idea 
> of this proposal, but the syntax is still being debated. I outlined two 
> alternatives [in this GitHub 
> issue](https://github.com/mindeavor/es-pipeline-operator/issues/4 
> ), one of which I 
> will post here since it is my current favorite:
> 
> ## Placeholder Arguments
> 
> The alternative is to have a new syntax for "placeholder arguments" – 
> basically, slots waiting to be filled by the next function call. For example:
> 
> ```js
> //
> // Placeholder style
> //
> run("hello") |> withThis(10, #);
> // is equivalent to
> withThis( 10, run("hello") );
> 
> //
> // More complicated example
> //
> run("hello") |> withThis(10, #) |> andThis(#, 20);
> // is equivalent to
> andThis( withThis( 10, run("hello") ), 20 );
> ```
> 
> ### Pros / Cons
> 
> - [pro] Very explicit (no surprises)
> - [pro] Less function calls
> - [pro] Compatible with even more of the JavaScript ecosystem
> - [con] Requires more new syntax
> - [con] Usage of the hash operator (#) would probably be hard to define 
> outside coupled use with pipeline operator (this problem could be avoided by 
> simply making it illegal)
> 
> 
> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza  > wrote:
> Ah, sorry for being unclear. You're right, in the case of manual currying, 
> the closure can not and should not be optimized away.
> 
> I was talking about the case where you have arrow function literals. For 
> example:
> 
> ```js
> var bounded = 750
> |> s => Math.max(100, s)
> |> s => Math.min(0, s);
> ```
> 
> I imagine if the compiler sees arrow functions used in this specific manner, 
> it could automatically optimize to the following:
> 
> ```js
> var bounded = Math.min( 0, Math.max(100, 750) )
> ```
> 
> Semantically, they are equivalent; no closures nor scopes were effectively 
> used in the intermediary arrow functions.
> 
> 
> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows  > wrote:
> Not with your semantics. It has to generate a closure each time, because of 
> the possibility it can't be used elsewhere. That's impossible to know ahead 
> of time if the variable is ever used outside of its closure or as a value. In 
> the case below, it should only log thrice. Otherwise, it's unexpected 
> behavior.
> 
> ```js
> function add(x) {
>   console.log("Hit!");
>   return y => x + y;
> }
> 
> let inc = add(1);
> 
> 1 |> inc |> inc |> add(2) |> add(3);
> 
> // Hit!
> // Hit!
> // Hit!
> ```
> 
> 
> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza  > wrote:
> 
> Normally yes, but since the pipeline operator is a pure function, I think 
> it's possible for the compiler to optimize away the intermediate arrow 
> functions. I mention this in the "Functions with Multiple Arguments" section 
> https 
> ://
>  
> github.com
>  
> /
>  
> mindeavor
>  
> /
>  
> ES7-pipeline-operator#functions
>  
> -with-multiple-arguments
>  
> 
> 
> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows  > wrote:
> 
> Inline
> 
> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith  > wrote:
> >> - I don't like the requirement to use the keyword `this` to compose
> >> functions. JS already has many features to support the keyword `this`:
> >> prototypes, method invocations, function binding, arrow functions, and
> >> probably others. I prefer a feature that assists the other side of the
> >> spectrum.
> >
> >
> > Yep - a well documented critique.  It depends on your point of view, I
> > think.  If you view these things as "extension methods", then using `this`
> > makes more sense.
> >
> >> - The fact that there are new semantics to what looks 

Re: The "Pipeline" Operator - Making multiple function calls look great

[Caitlin Potter]

>On Dec 6, 2015, at 4:51 PM, Gilbert B Garza  wrote:
>
>Confusing and horrible are subjective, but I do agree that it's not as nice as 
>the original proposal.
>Although I prefer the original, it's also important to discuss objections that 
>people bring up, as well as
>the alternatives that might solve said objections :)

Even with the original solution, it just creates a new (and less obvious) way 
of writing something that is already possible in the language,
and easier to understand. There is a narrow scope of times where it even makes 
sense to use the original (or enhanced) version of the
proposal, and this requires authors to be vigilante about knowing when to pick 
one form over the other. It also requires code reviewers
to be vigilante in knowing when to say “know, this is a bad idea, stop”.

It doesn’t look like there is any redeeming quality about this change, it 
doesn’t introduce convenience, and does introduce new pain points
for authors. Anything involving “placeholders arguments” is especially bad 
because it introduces an extra thing to reason about, but the issue
with introducing a new syntax to pick and be aware of for limited gains is also 
problematic, growing the language and increasing complexity
for a less than substantial reason.

The bind operator may at least have the benefit of providing some out of the 
box support for classic FP style, so it’s got that going for it (but really,
the language doesn’t need three distinct syntaxes/idioms for this pattern, the 
complexity budget is already running thin)

> 
> Gilbert
> 
> On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter  > wrote:
> These examples only make this language extension look like a confusing and 
> horrible thing. How is this an improvement, in any way?
> 
>> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza > > wrote:
>> 
>> Status update: The JS community has shown [lots of 
>> excitement](https://twitter.com/markdalgleish/status/673581814028492800 
>> ) for the idea 
>> of this proposal, but the syntax is still being debated. I outlined two 
>> alternatives [in this GitHub 
>> issue](https://github.com/mindeavor/es-pipeline-operator/issues/4 
>> ), one of which 
>> I will post here since it is my current favorite:
>> 
>> ## Placeholder Arguments
>> 
>> The alternative is to have a new syntax for "placeholder arguments" – 
>> basically, slots waiting to be filled by the next function call. For example:
>> 
>> ```js
>> //
>> // Placeholder style
>> //
>> run("hello") |> withThis(10, #);
>> // is equivalent to
>> withThis( 10, run("hello") );
>> 
>> //
>> // More complicated example
>> //
>> run("hello") |> withThis(10, #) |> andThis(#, 20);
>> // is equivalent to
>> andThis( withThis( 10, run("hello") ), 20 );
>> ```
>> 
>> ### Pros / Cons
>> 
>> - [pro] Very explicit (no surprises)
>> - [pro] Less function calls
>> - [pro] Compatible with even more of the JavaScript ecosystem
>> - [con] Requires more new syntax
>> - [con] Usage of the hash operator (#) would probably be hard to define 
>> outside coupled use with pipeline operator (this problem could be avoided by 
>> simply making it illegal)
>> 
>> 
>> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza > > wrote:
>> Ah, sorry for being unclear. You're right, in the case of manual currying, 
>> the closure can not and should not be optimized away.
>> 
>> I was talking about the case where you have arrow function literals. For 
>> example:
>> 
>> ```js
>> var bounded = 750
>> |> s => Math.max(100, s)
>> |> s => Math.min(0, s);
>> ```
>> 
>> I imagine if the compiler sees arrow functions used in this specific manner, 
>> it could automatically optimize to the following:
>> 
>> ```js
>> var bounded = Math.min( 0, Math.max(100, 750) )
>> ```
>> 
>> Semantically, they are equivalent; no closures nor scopes were effectively 
>> used in the intermediary arrow functions.
>> 
>> 
>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows > > wrote:
>> Not with your semantics. It has to generate a closure each time, because of 
>> the possibility it can't be used elsewhere. That's impossible to know ahead 
>> of time if the variable is ever used outside of its closure or as a value. 
>> In the case below, it should only log thrice. Otherwise, it's unexpected 
>> behavior.
>> 
>> ```js
>> function add(x) {
>>   console.log("Hit!");
>>   return y => x + y;
>> }
>> 
>> let inc = add(1);
>> 
>> 1 |> inc |> inc |> add(2) |> add(3);
>> 
>> // Hit!
>> // Hit!
>> // Hit!
>> ```
>> 
>> 
>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza > > wrote:
>> 
>> Normally yes, but 

Re: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

Confusing and horrible are subjective, but I do agree that it's not as nice
as the original proposal. Although I prefer the original, it's also
important to discuss objections that people bring up, as well as the
alternatives that might solve said objections :)

Gilbert

On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter 
wrote:

> These examples only make this language extension look like a confusing and
> horrible thing. How is this an improvement, in any way?
>
> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza 
> wrote:
>
> Status update: The JS community has shown [lots of excitement](
> https://twitter.com/markdalgleish/status/673581814028492800) for the idea
> of this proposal, but the syntax is still being debated. I outlined two
> alternatives [in this GitHub issue](
> https://github.com/mindeavor/es-pipeline-operator/issues/4), one of which
> I will post here since it is my current favorite:
>
> ## Placeholder Arguments
>
> The alternative is to have a new syntax for "placeholder arguments" –
> basically, slots waiting to be filled by the next function call. For
> example:
>
> ```js
> //
> // Placeholder style
> //
> run("hello") |> withThis(10, #);
> // is equivalent to
> withThis( 10, run("hello") );
>
> //
> // More complicated example
> //
> run("hello") |> withThis(10, #) |> andThis(#, 20);
> // is equivalent to
> andThis( withThis( 10, run("hello") ), 20 );
> ```
>
> ### Pros / Cons
>
> - [pro] Very explicit (no surprises)
> - [pro] Less function calls
> - [pro] Compatible with even more of the JavaScript ecosystem
> - [con] Requires more new syntax
> - [con] Usage of the hash operator (#) would probably be hard to define
> outside coupled use with pipeline operator (this problem could be avoided
> by simply making it illegal)
>
>
> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza 
> wrote:
>
>> Ah, sorry for being unclear. You're right, in the case of manual
>> currying, the closure can not and should not be optimized away.
>>
>> I was talking about the case where you have arrow function literals. For
>> example:
>>
>> ```js
>> var bounded = 750
>> |> s => Math.max(100, s)
>> |> s => Math.min(0, s);
>> ```
>>
>> I imagine if the compiler sees arrow functions used in this specific
>> manner, it could automatically optimize to the following:
>>
>> ```js
>> var bounded = Math.min( 0, Math.max(100, 750) )
>> ```
>>
>> Semantically, they are equivalent; no closures nor scopes were
>> effectively used in the intermediary arrow functions.
>>
>>
>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows 
>> wrote:
>>
>>> Not with your semantics. It has to generate a closure each time, because
>>> of the possibility it can't be used elsewhere. That's impossible to know
>>> ahead of time if the variable is ever used outside of its closure or as a
>>> value. In the case below, it should only log thrice. Otherwise, it's
>>> unexpected behavior.
>>>
>>> ```js
>>> function add(x) {
>>>   console.log("Hit!");
>>>   return y => x + y;
>>> }
>>>
>>> let inc = add(1);
>>>
>>> 1 |> inc |> inc |> add(2) |> add(3);
>>>
>>> // Hit!
>>> // Hit!
>>> // Hit!
>>> ```
>>>
>>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza 
>>> wrote:
>>>
>>> Normally yes, but since the pipeline operator is a pure function, I
>>> think it's possible for the compiler to optimize away
>>> the intermediate arrow functions. I mention this in the "Functions with
>>> Multiple Arguments" section https
>>> 
>>> ://
>>> 
>>> github.com
>>> 
>>> /
>>> 
>>> mindeavor
>>> 
>>> /
>>> 
>>> ES7-pipeline-operator#functions
>>> 
>>> -with-multiple-arguments
>>> 
>>>
>>>
>>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows 
>>> wrote:
>>>
>>> Inline
>>>
>>> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith 
>>> wrote:
>>> >> - I don't like the requirement to use the keyword `this` to compose
>>> >> functions. JS already has many features to support the keyword `this`:
>>> >> prototypes, method invocations, function binding, arrow functions, and
>>> >> probably others. I prefer a feature that assists the other side of the
>>> >> spectrum.
>>> >
>>> >
>>> > Yep - a well documented critique.  It depends on your point of view, I

Re: Reflection to know if executed within a generator/async ?

[Andrea Giammarchi]

I've asked for opinions and if in 2 days I haven't replied means I got it
my idea is not welcome which is OK and fair enough.

However, I'm curious to know about this "Functions that sometimes return
promises and sometimes not are already known to be an antipattern" because
I have a library that does that in somehow explicit way (if you pass a
callback it doesn't return  a promise, it invokes such callback once
resolved) and it works without any real-world problem.

Mind pointing me at the library that failed returning Promises arbitrarily?


On Mon, Dec 7, 2015 at 12:48 AM, Bergi  wrote:

> Andrea Giammarchi schrieb:
>
> simply adding
>> async and await and the only change to do in a well known/used
>> *synchronous* API would be to check if the returned value is held and
>> behave accordingly?
>>
>
> No, making a consumer of an API asynchronous should not be simple. Unless
> you are only writing pure functions, everything that involves states will
> very likely break. Concurrency is not trivial, it needs a lot of
> consideration.
>
> as soon as you go for
>> async/await or a generator that function will return a Promise for you.
>>
>
> Please never do that. Functions that sometimes return promises and
> sometimes not are already known to be an antipattern. Making this obscurely
> dependent on some fragile syntactic conditions could only make this worse.
>
> If you want to migrate your library to asynchrony, just make it a breaking
> change. Your consumers will thank you for it.
>
> Kind regards,
>  Bergi
>
> ___
> 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