Thoughts on Partial Application
# Алексей (7 years ago)
There is already an issue on that rbuckton/proposal-partial-application#13
2017-12-04 15:03 GMT+02:00 Michael Rosefield <rosyatrandom at gmail.com>:
Hi There is already an issue on that https://github.com/rbuckton/proposal-partial-application/issues/13 2017-12-04 15:03 GMT+02:00 Michael Rosefield <rosyatrandom at gmail.com>: > I was looking through the notes on the last meeting, in particular the bit > about Partial Application: http://rwaldron.github.io/tc39-notes/2017-09_ > sep-28.html#13i-partial-application > > The current sticking point was that the syntax looked like a function call > instead of function definition, but my first thought was that this could be > fixed by using a simple token either before the function name, or between > it and the brackets. > > For example, given a current function foo, the current proposal would have > > const bar = foo(1, ?) // roughly: bar = x => foo(1,x) > > While the choice of token is arbitrary, I'll go with '@' (Because I've got > to pick something, and it kind of suggests application. It's not important! > ). I would suggest having one of these two as Partial Application syntax: > > const bar = @foo(1, ?) > const bar = foo@(1, ?) // my preferred version > > Are there any issues with solving the issue in this manner? I know that > adding new syntax unnecessarily should be avoided, but this is for clarity. > > Another that's occurred to me is to allow a shorthand for arrow functions: > > const baz1 = (x, 1, ...y) => foo(x, 1, ...y) > const baz2 = (?, 1, ...) => foo // shorthand for above > > This would require parsing to check the RHS is just a function identifier, > but does suggest the intent of a function that passes arguments to a > function. > > Michael > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171204/a697cc31/attachment.html>
# Michael Rosefield (7 years ago)
Ha! So there is....
Ha! So there is.... On Mon, 4 Dec 2017 at 13:23 Алексей <agat00 at gmail.com> wrote: > Hi > > There is already an issue on that > https://github.com/rbuckton/proposal-partial-application/issues/13 > > 2017-12-04 15:03 GMT+02:00 Michael Rosefield <rosyatrandom at gmail.com>: > >> I was looking through the notes on the last meeting, in particular the >> bit about Partial Application: >> http://rwaldron.github.io/tc39-notes/2017-09_sep-28.html#13i-partial-application >> >> The current sticking point was that the syntax looked like a function >> call instead of function definition, but my first thought was that this >> could be fixed by using a simple token either before the function name, or >> between it and the brackets. >> >> For example, given a current function foo, the current proposal would have >> >> const bar = foo(1, ?) // roughly: bar = x => foo(1,x) >> >> While the choice of token is arbitrary, I'll go with '@' (Because I've >> got to pick something, and it kind of suggests application. It's not >> important! ). I would suggest having one of these two as Partial >> Application syntax: >> >> const bar = @foo(1, ?) >> const bar = foo@(1, ?) // my preferred version >> >> Are there any issues with solving the issue in this manner? I know that >> adding new syntax unnecessarily should be avoided, but this is for clarity. >> >> Another that's occurred to me is to allow a shorthand for arrow functions: >> >> const baz1 = (x, 1, ...y) => foo(x, 1, ...y) >> const baz2 = (?, 1, ...) => foo // shorthand for above >> >> This would require parsing to check the RHS is just a function >> identifier, but does suggest the intent of a function that passes arguments >> to a function. >> >> Michael >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171204/85ace01c/attachment.html>
I was looking through the notes on the last meeting, in particular the bit about Partial Application: rwaldron.github.io/tc39-notes/2017-09_sep-28.html#13i-partial-application
The current sticking point was that the syntax looked like a function call instead of function definition, but my first thought was that this could be fixed by using a simple token either before the function name, or between it and the brackets.
For example, given a current function foo, the current proposal would have
const bar = foo(1, ?) // roughly: bar = x => foo(1,x)
While the choice of token is arbitrary, I'll go with '@' (Because I've got to pick something, and it kind of suggests application. It's not important! ). I would suggest having one of these two as Partial Application syntax:
const bar = @foo(1, ?) const bar = foo@(1, ?) // my preferred version
Are there any issues with solving the issue in this manner? I know that adding new syntax unnecessarily should be avoided, but this is for clarity.
Another that's occurred to me is to allow a shorthand for arrow functions:
const baz1 = (x, 1, ...y) => foo(x, 1, ...y)
const baz2 = (?, 1, ...) => foo // shorthand for above
This would require parsing to check the RHS is just a function identifier, but does suggest the intent of a function that passes arguments to a function.
Michael