in reply to Near-free function currying in Perl

I assume you'll be uploading this to CPAN. Where's the test suite? Could you accomodate using some other namespace other than '_c'? I use that when referring to a column attribute when using Alzabo. I'd opt to be verbose and just use the '_curry' namespace instead.

# the first argument to import may be some configuration
use AutoCurry ( { namespace => '_curry' }, LIST );

[download]

Also note that your INIT block won't run when your module is loaded during runtime and from common mod_perl configurations. You'll need to expose that block in a named subroutine to give those other people a chance to run that code. You could also just run that from your import() function so your users won't need to care about that detail.

Replies are listed 'Best First'.
Re^2: Near-free function currying in Perl
by tmoertel (Chaplain) on Nov 17, 2004 at 04:15 UTC
    Thanks for taking the time to read the meditation and respond. Your views are always welcomed.

    Yes, I'll put this up on CPAN once I flesh it out. This meditation is my first opportunity for feedback, and so I expect a round of revision (including a test suite) before I upload.

    Could you accomodate using some other namespace other than '_c'?

    Yes.

    That said, I'm reluctant to increase the length of the currying suffix because it increases the usage cost beyond the point where it seems like a mere notational convention. Nevertheless, I can see the opportunity for conflict with existing naming schemes, and tastes do vary, and so I ought to make the suffix configurable.

    Also note that your INIT block won't run when your module is loaded during runtime and from common mod_perl configurations. You'll need to expose that block in a named subroutine to give those other people a chance to run that code.
    It is exposed already via curry_named_functions and curry_package, although the latter isn't documented yet.
    You could also just run that from your import() function so your users won't need to care about that detail.
    That would prevent the most common usage from working: 
        use AutoCurry ':all';
    sub one { }
    sub two { }

    [download]
    The import function would be called before one and two were even parsed, and so it couldn't possibly load them from the symbol table. That's why the import function must queue up operations to until INIT time.

    Thanks again for your response.

    Cheers,
    Tom

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

[reply]
[d/l]
Re^2: Near-free function currying in Perl
by tmoertel (Chaplain) on Mar 11, 2005 at 03:17 UTC
[reply]

      You have still neglected to leave the user with the ability to use a different suffix. This suffix is already used by Alzabo::MethodMaker (for row columns) though it is configurable. If I intended to use both Alzabo and AutoCurry, I'd have to do some fancy footwork with the symbol table to rename all the curried functions before other _c functions were installed (or is it the other way, I forget).

      Your accomodation may be as simple as providing an overridable package scalar.

      BEGIN { $AutoCurry::Suffix = '_not_c'; }
use AutoCurry ':all';

      [download]
[reply]
[d/l]
        Thanks for the friendly reminder.

        I just uploaded version 0.1003 to CPAN. It includes the following addition: 

        =head2 Using another suffix

Do not change the suffix unless you truly must.

If for some reason you cannot use the standard C<_c> suffix, you
can override it by changing C<$AutoCurry::suffix> I<for the duration
of your calls to AutoCurry>.  Use C<do> and C<local> to limit the
scope of your changes:

    use AutoCurry;  # suffix changing is not compatible with ':all'

    my @curried_fns = do {
        local $AutoCurry::suffix = "_curry";
        AutoCurry::curry_package();
    };
    # result: ( "main::foo_curry" )

    sub foo { ... };
    # foo_curry will be created by call to curry_package, above

        [download]

        I cannot use the BEGIN approach that you suggested because that would override the suffix for all subsequent users of AutoCurry, not just the current package.

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

[reply]
[d/l]

In Section Meditations