Re: New Proposal: Placeholder syntax

thank you all for the feedback, I appreciate those who pointed out the flaws in the logic. I can see that this is an ambiguous proposal. Though I did not realize it at the time, this proposal is competing with https://github.com/tc39/proposal-partial-application, as the two syntax's cannot exist in

Re: New Proposal: Placeholder syntax

On 11/28/2018 10:17 AM, Andrew Kaiser wrote: Hi all, I have created a short proposal to introduce syntactic sugar for anonymous functions in a 'scala-like' manner, linked here https://github.com/andykais/proposal-placeholder-syntax. I am hoping to hear feedback on whether or not this is inter

Re: New Proposal: Placeholder syntax

I find the "receiver" usage actually pretty useful. I know how I like to be able to do something like Smalltalk packages do: #commit in Amber Smalltalk (even if it would be only a few chars longer Smalltalk packages do: [ :each | each commit ] but readability is different, b/c the spirit

RE: New Proposal: Placeholder syntax

argument list. Ron From: es-discuss On Behalf Of Andrew Kaiser Sent: Wednesday, November 28, 2018 11:57 AM To: ljh...@gmail.com Cc: es-discuss@mozilla.org Subject: Re: New Proposal: Placeholder syntax This proposal also works with simple math operations and for accessing fields on objects. Th

Re: New Proposal: Placeholder syntax

> Le 28 nov. 2018 à 19:17, Andrew Kaiser a écrit : > > Hi all, > > I have created a short proposal to introduce syntactic sugar for anonymous > functions in a 'scala-like' manner, linked here > https://github.com/andykais/proposal-placeholder-syntax >

Re: New Proposal: Placeholder syntax

Aside from the fact that this "placeholder" proposal addresses the "receiver" and "operator" cases that partial-application explicitly omits, the two proposals are exactly identical. They're not "complementary", they're the same thing, just making a different decision wrt complexity of some of the

Re: New Proposal: Placeholder syntax

This proposal also works with simple math operations and for accessing fields on objects. The partial application lists these expressions as invalid. ```js // invalid f(x + ?) // `?` not in top-level Arguments of call x + ? // `?` not in top-level Arguments of call ?.f()

Re: New Proposal: Placeholder syntax

It seems like the partial application proposal covers all of the use cases of yours, at a first glance. What does yours offer that partial application does not? On Wed, Nov 28, 2018 at 11:23 AM Andrew Kaiser wrote: > Do you see a way these proposals can work together? I believe they are > solvin

Re: New Proposal: Placeholder syntax

Do you see a way these proposals can work together? I believe they are solving different needs. Both proposals produce a new anonymous function, but partial application deals with currying, while the placeholder proposal tries to prevent writing a function at all. I can actually see the two working

Re: New Proposal: Placeholder syntax

You may be interested in the partial application proposal: https://github.com/tc39/proposal-partial-application On Wed, Nov 28, 2018 at 10:17 AM Andrew Kaiser wrote: > Hi all, > > I have created a short proposal to introduce syntactic sugar for anonymous > functions in a 'scala-like' manner, lin