<div dir="ltr">I wonder whether we've reach that point in the language where trying to reuse the same old tokens over and over again in new combinations is getting untenable. It's a long road to APL...</div><div class="gmail_extra"><br><div class="gmail_quote">On 11 December 2015 at 15:23, Gilbert B Garza <span dir="ltr"><<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Rick: I would imagine some sort of lookahead is already in the parser, considering JavaScript supports both bitwise OR `|` and boolean OR `||` – unless this is accomplished some other way?<span class="HOEnZb"><font color="#888888"><div><div><br></div><div>Gilbert</div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 8:52 AM, Felipe Nascimento de Moura <span dir="ltr"><<a href="mailto:felipenmoura@gmail.com" target="_blank">felipenmoura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What about a backslash instead?<div>Like escaping a function call, such as:</div><div><br></div><div>foo("some string")\bar\baz;</div><div><br></div><div>Or</div><div><br></div><div>`some ${data}` \ foo \ bar \ console.log;</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 12:07 PM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Has anyone tried writing grammar for this? The "|>" token requires a a lookahead to disambiguate the bit wise OR operator `|`</div><span><font color="#888888"><br><br>- Rick</font></span><div><div><br><br><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 6, 2015 at 6:38 PM Gilbert B Garza <<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> <span style="font-size:12.8px">It doesn’t look like there is any redeeming quality about this change, it doesn’t introduce convenience</span></div><div dir="ltr"><div><span style="font-size:12.8px"><br></span><div>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.<div><br></div><div>[1] <a href="https://github.com/mindeavor/es-pipeline-operator" target="_blank">https://github.com/mindeavor/es-pipeline-operator</a></div><div>[2] <a href="https://news.ycombinator.com/item?id=10686596" target="_blank">https://news.ycombinator.com/item?id=10686596</a></div><div><br></div><div>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].</div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[3] <a href="https://twitter.com/markdalgleish/status/673581814028492800" target="_blank">https://twitter.com/markdalgleish/status/673581814028492800</a></span></div><div><span style="font-size:12.8px">[4] <a href="https://www.reddit.com/r/javascript/comments/3vox7x/es7_proposal_the_pipeline_operator/" target="_blank">https://www.reddit.com/r/javascript/comments/3vox7x/es7_proposal_the_pipeline_operator/</a></span></div></div></div></div><div dir="ltr"><div><div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div>> Anything involving “placeholders arguments” is especially bad because it introduces an extra thing to reason about<div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div></div></div></div><div dir="ltr"><div><div><div style="font-size:12.8px"><span style="font-size:12.8px">I agree; I still prefer the original proposal.</span></div></div></div></div><div dir="ltr"><div><div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div>> The bind operator may at least have the benefit of providing some out of the box support for classic FP style<div class="gmail_extra"><span style="font-size:12.8px"><br></span></div></div></div></div><div dir="ltr"><div><div><div class="gmail_extra"><span style="font-size:12.8px">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.</span></div></div></div></div><div dir="ltr"><div><div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 6, 2015 at 4:56 PM, Caitlin Potter <span dir="ltr"><<a href="mailto:caitpotter88@gmail.com" target="_blank">caitpotter88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><div>>On Dec 6, 2015, at 4:51 PM, Gilbert B Garza <<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>> wrote:</div>><br><div><div dir="ltr">>Confusing and horrible are subjective, but I do agree that it's not as nice as the original proposal.</div><div dir="ltr">>Although I prefer the original, it's also important to discuss objections that people bring up, as well as</div><div dir="ltr">>the alternatives that might solve said objections :)</div></div><div dir="ltr"><br></div></span><div dir="ltr">Even with the original solution, it just creates a new (and less obvious) way of writing something that is already possible in the language,</div><div dir="ltr">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</div><div dir="ltr">proposal, and this requires authors to be vigilante about knowing when to pick one form over the other. It also requires code reviewers</div><div dir="ltr">to be vigilante in knowing when to say “know, this is a bad idea, stop”.</div><div dir="ltr"><br></div><div dir="ltr">It doesn’t look like there is any redeeming quality about this change, it doesn’t introduce convenience, and does introduce new pain points</div><div dir="ltr">for authors. Anything involving “placeholders arguments” is especially bad because it introduces an extra thing to reason about, but the issue</div><div dir="ltr">with introducing a new syntax to pick and be aware of for limited gains is also problematic, growing the language and increasing complexity</div><div dir="ltr">for a less than substantial reason.</div><div dir="ltr"><br></div><div dir="ltr">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,</div><div dir="ltr">the language doesn’t need three distinct syntaxes/idioms for this pattern, the complexity budget is already running thin)</div><div><div><div dir="ltr"><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Gilbert</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter <span dir="ltr"><<a href="mailto:caitpotter88@gmail.com" target="_blank">caitpotter88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">These examples only make this language extension look like a confusing and horrible thing. How is this an improvement, in any way?<div><div><div><br><div><blockquote type="cite"><div>On Dec 6, 2015, at 3:13 PM, Gilbert B Garza <<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Status update: The JS community has shown [lots of excitement](<a href="https://twitter.com/markdalgleish/status/673581814028492800" target="_blank">https://twitter.com/markdalgleish/status/673581814028492800</a>) for the idea of this proposal, but the syntax is still being debated. I outlined two alternatives [in this GitHub issue](<a href="https://github.com/mindeavor/es-pipeline-operator/issues/4" target="_blank">https://github.com/mindeavor/es-pipeline-operator/issues/4</a>), one of which I will post here since it is my current favorite:<div><br></div><div><div>## Placeholder Arguments</div><div><br></div><div>The alternative is to have a new syntax for "placeholder arguments" – basically, slots waiting to be filled by the next function call. For example:</div><div><br></div><div>```js</div><div>//</div><div>// Placeholder style</div><div>//</div><div>run("hello") |> withThis(10, #);</div><div>// is equivalent to</div><div>withThis( 10, run("hello") );</div><div><br></div><div>//</div><div>// More complicated example</div><div>//</div><div>run("hello") |> withThis(10, #) |> andThis(#, 20);<br></div><div>// is equivalent to</div><div>andThis( withThis( 10, run("hello") ), 20 );</div><div>```</div><div><br></div><div>### Pros / Cons</div><div><br></div><div>- [pro] Very explicit (no surprises)</div><div>- [pro] Less function calls</div><div>- [pro] Compatible with even more of the JavaScript ecosystem</div><div>- [con] Requires more new syntax</div><div>- [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)</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza <span dir="ltr"><<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Ah, sorry for being unclear. You're right, in the case of manual currying, the closure can not and should not be optimized away.<div><br></div><div>I was talking about the case where you have arrow function literals. For example:<div><br></div><div>```js</div><div>var bounded = 750</div><div>    |> s => Math.max(100, s)</div><div>    |> s => Math.min(0, s);</div><div>```</div><div><br></div><div>I imagine if the compiler sees arrow functions used in this specific manner, it could automatically optimize to the following:</div><div><br></div><div>```js</div><div>var bounded = Math.min( 0, Math.max(100, 750) )</div><div>```</div><div><br></div><div>Semantically, they are equivalent; no closures nor scopes were effectively used in the intermediary arrow functions.</div><div><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">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. </p><p dir="ltr">```js<br>
function add(x) {<br>
  console.log("Hit!");<br>
  return y => x + y;<br>
}</p><p dir="ltr">let inc = add(1);</p><p dir="ltr">1 |> inc |> inc |> add(2) |> add(3);</p><p dir="ltr">// Hit!<br>
// Hit!<br>
// Hit!<br>
```</p><div><div><div><br></div><p dir="ltr">On Tue, Nov 10, 2015, 15:08 Gilbert B Garza <<a href="mailto:gilbertbgarza@gmail.com" target="_blank">gilbertbgarza@gmail.com</a>> wrote:</p>
<blockquote><blockquote><blockquote><p dir="ltr">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 <a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">https</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">://</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">github.com</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">/</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">mindeavor</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">/</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">ES7-pipeline-operator#functions</a><a href="https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments" target="_blank">-with-multiple-arguments</a><br>
</p>
</blockquote>
</blockquote>
</blockquote>
<blockquote><blockquote><p dir="ltr"><br></p><p dir="ltr">On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:</p>
</blockquote>
</blockquote>
<blockquote><blockquote><p dir="ltr">Inline</p><p dir="ltr">On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith <<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>> wrote:<br>
>> - I don't like the requirement to use the keyword `this` to compose<br>
>> functions. JS already has many features to support the keyword `this`:<br>
>> prototypes, method invocations, function binding, arrow functions, and<br>
>> probably others. I prefer a feature that assists the other side of the<br>
>> spectrum.<br>
><br>
><br>
> Yep - a well documented critique.  It depends on your point of view, I<br>
> think.  If you view these things as "extension methods", then using `this`<br>
> makes more sense.<br>
><br>
>> - The fact that there are new semantics to what looks like a normal<br>
>> function call (e.g. `->map(...)`) doesn't set well with me. You could argue<br>
>> that it's something to get used to. Even in that case, I would expect the<br>
>> first argument I give to `map` to stay the first argument.<br>
><br>
><br>
> This is a reasonable objection, I think.</p><p dir="ltr">Not to mention it's still a point of contention:<br>
<a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">https</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">://</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">github.com</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">/</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">zenparsing</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">/</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">es-function-bind</a><a href="https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932" target="_blank">/issues/26#issuecomment-154130932</a><br>
(from here, down)</p><p dir="ltr">><br>
>> With the pipeline operator, partial application is left to the developer.<br>
>> They can choose to use arrow functions, or to curry their functions. I think<br>
>> this is the best option since it keeps things simple (no new semantics), and<br>
>> remains readable – see the "Function with Multiple Arguments" section in the<br>
>> GitHub link <a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">https</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">://</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">github.com</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">/</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">mindeavor</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">/</a><a href="https://github.com/mindeavor/ES7-pipeline-operator" target="_blank">ES7-pipeline-operator</a><br>
><br>
><br>
> I agree that your proposal wins points for simplicity (both semantic and<br>
> syntactic), but having to create an arrow function to pass more than one<br>
> argument feels a bit awkward and seems to defeat some of the readability<br>
> benefit.</p><p dir="ltr">Not to mention it would be pretty slow. That's going to be creating a<br>
closure each call. Engines still struggle with making closures fast.<br>
It's non-trivial at runtime to create a closure that's performant.<br></p><p dir="ltr">><br>
><br>
><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">://</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">mail.mozilla.org</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">/</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">listinfo</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">/</a><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">es-discuss</a><br>
><br><br></p><p dir="ltr"><font color="#888888">--</font><br>
<font color="#888888">Isiah Meadows</font><br>
</p>
</blockquote>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote><p dir="ltr"><br>
</p>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div></div></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span><div><div dir="ltr"><div><div dir="ltr"><b><span style="font-family:arial,helvetica,sans-serif;color:rgb(51,51,51)">Felipe N. Moura</span></b><br style="font-family:arial,helvetica,sans-serif;color:rgb(51,51,153)"><span style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,153)">Senior Web Developer and System Analyst.</span><br style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,153)"><br style="color:rgb(0,0,153)"><span style="color:rgb(0,0,153)">
Website:  </span><span style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,153)"><a href="http://felipenmoura.com/" target="_blank">http://felipenmoura.com</a></span><br style="color:rgb(0,0,153)"><span style="color:rgb(0,0,153)">
Twitter:    </span><span style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,153)"><a href="http://twitter.com/felipenmoura" target="_blank">@felipenmoura</a><span style="padding-right:16px;width:16px;min-height:16px"></span></span><div style="color:rgb(0,0,153)"><span style="font-family:arial,helvetica,sans-serif"></span>LinkedIn: <a href="http://goo.gl/qGmq" target="_blank">http://goo.gl/qGmq</a><span style="padding-right:16px;width:16px;min-height:16px"></span></div><div style="color:rgb(0,0,153)"><br></div><div style="color:rgb(0,0,153)">Meet some of my projects:<br><a href="http://braziljs.com.br/" target="_blank">BrazilJS Conference</a>  |  <a href="http://braziljs.org" target="_blank">BrazilJS Foundation</a></div><div><span style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,153)">---------------------------------</span><br style="font-family:arial,helvetica,sans-serif;color:rgb(51,51,153)"><b>Changing  the  world</b>  is the least I expect from  myself!</div></div></div></div></div>
</span></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>