BTW. Interesting to read what others have done in this area:
http://osteele.com/sources/javascript/functional/
http://ejohn.org/blog/partial-functions-in-javascript/
Cheers,
/Per
On Thu, Dec 18, 2008 at 9:32 PM, Per Cederberg <cederb...@gmail.com> wrote:
> Thanks for the clarification, Bob!
>
> Regarding the functions in questions I think other names might be in
> place, to avoid misleading interpretations. What we're really doing
> here is attempting to patch the poor JavaScript syntax and/or standard
> library for function calls (i.e. call, apply, arguments and others).
>
> The current MochiKit work-around for this is the excellent bind()
> function (in its many incarnations). But it still has weaknesses,
> since it doesn't allow us to do any of the following cool things:
>
> 1. Use the call-time 'this' object as an argument to the function (can
> only be used as the object). If we had this, the "currying" mentioned
> here would strictly be a version of bind().
>
> 2. Leaving gaps for call-time arguments in the list arguments set at
> bind-time. Currently call-time arguments can only be appended to the
> argument list.
>
> 3. Perform reordering of arguments. Typically inverse two arguments,
> like in the startsWith discussion.
>
> 4. Perform random argument transformation. Using an array as the
> argument list or vice versa. Or adding automatic flattening to
> arguments.
>
> The more I think about this, I tend to come to the conclusion that we
> need something powerful enough to allow both the current bind() and
> all of the above. Perhaps the syntax needn't be trivial, since we
> could then add simplifying aliases for whatever common use-cases we
> can identify.
>
> One option, for example, would be a bind-version that would actually
> map each function argument:
>
> caller(func, self, { value: "123" }, { arg: 3 }, { arg: 1 }, { arg: -1 });
>
> Another might be to create higher order argument-mapping functions:
>
> var flip = function (func, self, args) { return args.reverse(); };
> caller(func, self, flip);
>
> These were just two ideas off the top of my head. But I think we
> should discuss more options here before plunging ahead and adding yet
> another variant of bind to MochiKit. Although they might all be very
> useful. It will slowly get too confusing for the average user.
>
> Thanks for reading this far! :-)
>
> Cheers,
>
> /Per
>
> On Thu, Dec 18, 2008 at 5:25 PM, Arnar Birgisson <arna...@gmail.com> wrote:
>> Hi all,
>>
>> On Thu, Dec 18, 2008 at 16:07, Bob Ippolito <b...@redivi.com> wrote:
>>> I'm not a real big fan of currying in languages where it's not
>>> built-in. It's easy to make a mistake by calling a function with too
>>> few arguments and you get a harder to track down bug. It also doesn't
>>> work well with languages that have default arguments or the equivalent
>>> (e.g. using the arguments object) because you don't know exactly when
>>> to stop currying.
>>
>> Actually, the functions I proposed (curry and uncurry, stolen form
>> Haskell) do not describe this kind of currying.
>>
>> curry takes a function of one argument, a tuple, and returns a
>> modified function that instead takes N arguments (the elements of the
>> tuple). The reason for the name curry is that it basically performs
>> the translation you (Bob) mentioned in Haskell, i.e. it transforms an
>> N argument function to a nesting of N one-argument functions, i.e. it
>> "curries" the function.
>>
>> uncurry takes a function of N arguments and returns a modified
>> function that instead takes one argument, a tuple of N elements.
>> Obviously the naming comes from this being the reverse of curry.
>>
>> The absolute main use case is mapping functions over a list of tuples
>> (in js list=tuple). This uses uncurry to change a function f(a,b) to
>> f(t) where t is a tuble of a and b. That way you can simply map (or
>> filter) the function over the outer list and arguments get placed in
>> the correct spot.
>>
>> Currying is a convenience for changing a function that takes a tuple
>> (i.e. a list in js) and apply it with the tuple elements as arguments
>> -- i.e. exactly what Function.apply does in js. I'd still include it
>> if uncurry is included, for the sake of symmetry.
>>
>> I do realize this might be a bit too eccentric -- but it is the kind
>> of thing that becomes very useful to grab when you do a lot of
>> functional-style programming in any language.
>>
>> Per provided bind("apply", operator.add, null) as equivalent to
>> uncurry. This is true, except that the context (this) is not
>> maintained.. but yes, maybe it is my weird style but I'd give an alias
>> to this.
>>
>> Dunno.. I'm happy to keep it in my personal library of helper functions :)
>>
>> cheers,
>> Arnar
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
