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