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
-~----------~----~----~----~------~----~------~--~---
