Syntax sugar for partial application

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Sun Apr 12 15:39:34 UTC 2015


On Sat, Apr 11, 2015 at 4:54 AM, liorean <liorean at gmail.com> wrote:

> On 9 April 2015 at 16:11, Jussi Kalliokoski <jussi.kalliokoski at gmail.com>
> wrote:
> > On Thu, Apr 9, 2015 at 4:04 PM, liorean <liorean at gmail.com> wrote:
> >>
> >> Do we really need it?
> >> Your «foo(1, ?, 2);» is equivalent to «a=>foo(1,a,2)».
> >> Your «foo(?, 1, ???);» is equivalent to «(a,...b)=>foo(a,1,...b)».
> >> Your «foo(1, ???, 2);» is equivalent to «(...a)=>foo(...[1,...a,2])».
> >
> >
> > Not exactly. Using the placeholder syntax, `this` remains context
> dependent,
> > whereas with your examples you get `null` as `this`.
>
> No, «this» is lexically bound to be that of the enclosing lexical
> scope in arrow functions, so it would be whatever that is. But that
> doesn't really matter as the function call to «foo» doesn't use the
> «this» of the arrow function.
>

Exactly why you get `null` as `this`.


> Now, if we were to say your «foo» were actually «foo.bar», and you did
> the same replacement in the arrow function, the «this» value of the
> «bar» call would be «foo», so that's pretty much what is wanted as
> well. The case where this breaks is if you were to replace only the
> «bar» method with the arrow function, in which case it would use the
> lexical «this» instead of «foo», but that's obviously not the right
> transformation to use.
>
> > This might not seem like such a big deal until you consider it in
> > combination with the proposed bind syntax [1].
> >
> > Also in your examples, redefining `foo` will lead to different results.
> The
> > placeholder syntax has a lot more room for optimization in the JIT
> compiler
> > (the partially applied result is guaranteed to have no side effects for
> > example, so the compiler can create a version of the original function
> where
> > it can inline the specified arguments; less moving parts, easier to
> > optimize).
>
> Yeah, it's susceptible to that problem, yes. Do you want me to fix
> that for you if you really want it?
>
> Your «foo(1, ?, 2);» is equivalent to «((f,a)=>f(1,a,2))(foo)».
>
Your «foo(?, 1, ???);» is equivalent to «((f,a,...b)=>f(a,1,...b))(foo)».
> Your «foo(1, ???, 2);» is equivalent to
> «((f,...a)=>f(...[1,...a,2]))(foo)».
>

Your new examples directly execute the function instead of creating a new
function. :) Which goes to show how it would be nice to have specific
syntax for this to make it more obvious what's happening.



> I guess I didn't think of these cases though, because I only use
> explicit arguments to my functions these days, I never use the «this»
> keyword. If I want a function to operate on an object, I pass that
> object into the function.
> I also try to not reuse my variables unless they are part of an
> iteration, in which case they are always local variables that are only
> handled in the iteration process itself. But that's a side issue, as
> it's about my code rather than precepts of the language.
>

I write my code pretty much the same way. However, it's hard for the
compiler to trust that you're not changing things, regardless of style.

Also because most of the standard library of the language operates on
`this` instead of a separate argument, combining standard library methods
with methods that have their data as an explicit argument often lead to
awkward reading order issues, e.g.

foo(x
  .filter(...)
  .map(...)
  .reduce(...)
)

whereas with the bind operator you get

x
  .filter(...)
  .map(...)
  .reduce(...)
  ::foo()


Which is where this proposal shines, if foo is a partially applied function.

But anyway, seems that this is not something people want, at least yet, so
I'll rest my case. :)


> --
> David "liorean" Andersson
> _______________________________________________
> 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/20150412/7152ba86/attachment.html>


More information about the es-discuss mailing list