in reply to Near-free function currying in Perl

I'd like to second the comment about allowing a user-defined suffix. But, I'd like to see the ability to use a prefix instead of/in addition to a suffix. For example, I work with some people whose Perl skills are ... well ... lacking. Instead of forcing them to look at the end, I may prefer to have them look at the beginning. So, instead of log_handle_c(), I may like to have CURRY_log_handle(), or somesuch.

So, I would say allow for both a suffix and a prefix, if desired. If nothing is specified, default to suffix=>'_c'. If a suffix is specified, use it instead. If a prefix is specified, but no suffix, just use the prefix. If both are specified, use both. Someone may want to see CURRIED_log_handle_CURRIED() as their name, for readability.

Remember - you're providing low cost as the default. But, maybe I want to pay a higher typing cost in order to achieve a lower overall maintenance cost. Your module should allow that, otherwise its adoption rate may not be as high as you would like.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: Near-free function currying in Perl

Replies are listed 'Best First'.
Re^2: Near-free function currying in Perl
by tmoertel (Chaplain) on Nov 17, 2004 at 14:21 UTC
    First, thanks for reading the meditation and providing feedback.

    Second, I like your idea of being able to provide a prefix and suffix. I think that I'll probably let users provide a template. Maybe: 

        template => "${_}_c"

    [download]
    Nevertheless, in the docs I will try to discourage using anything but the default. While you are no doubt correct that using a more explicit prefix/suffix may reduce the cost of maintenance locally for some settings, not having a common usage across the community may increase cost globally.

    For what it's worth, in programming languages with support for real currying, there is no notation whatsoever for currying – curried calls and regular calls are look the same (because underneath they are the same) – and it's not confusing once you get the hang of it. (In fact, it's liberating.)

    Thanks, again!

    Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]
[d/l]
      Just out of curiousity, is it because standard Perl functions do not specify how many parameters they need at a minimum, so the compiler cannot tell if a function is satisfied? Because, if it is, couldn't we just use prototypes? For example: 
      sub foo ($$;$) { ... }

my $curried_foo = foo( 1 );
my $return_value = foo( 1, 2 );

      [download]

      I'm thinking a source filter would be needed to convert 

      sub foo ($$;$) { ... }

to

sub foo
{
    if (@_ < 2) {
      my $arg = shift;
      return sub { foo($arg, @_) };
    }

    ...
}

      [download]
      Wouldn't that work?

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]
[select]

        This is a good question:

        Just out of curiousity, is it because standard Perl functions do not specify how many parameters they need at a minimum, so the compiler cannot tell if a function is satisfied? Because, if it is, couldn't we just use prototypes?

        The reason that my "currying" doesn't do real currying isn't so much because it's a technical challenge but because real currying doesn't mesh with Perl's (powerful and cool) calling semantics. Let me explain why I don't like real currying in Perl (5).

        First, and most important, it requires a programmer to make a design-time decision to support currying. Currying hits its stride only when it is pervasive, and I don't want to limit its use to the functions that have been made "curry ready" ahead of time by having been anointed with the right prototypes or annotations. I want to be able to use currying with existing code bases.

        Second, there are many useful Perl functions for which we don't have any way to differentiate among arguments. What is "curriable" for these functions is solely at the discretion of the caller. I want a currying solution that works well for these functions, too.

        Third, I think that currying is best when it is free. Having to make annotations just raises its cost. In languages where you already must make such annotations, the currying comes at no additional charge. But for Perl, the charge isn't necessary and (as I have argued above) doesn't buy us much.

        Ultimately, I'm not concerned that we don't have "real" currying. I would rather we have a useful currying-like concept that makes sense for Perl.

        Thanks for the question!

        Cheers,
        Tom

        Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]

        My experience with function attributes is limited but what about something like this: 

        sub foo ($$$) : curry {
    ...
}

        [download]
        or if the prototypes and attributes dont get along as they should. 
        sub foo : curry($$$) {
    ...
}

        [download]
        That would be my prefered notation, it is was possible.

        -stvn
[reply]
[d/l]
[select]

In Section Meditations