|There's more than one way to do things|
Sorry Tom, but I'm still not getting it!
Your premise starts by saying that this:
is ...take[ing] the cost down another notch and also to make[ing] clear our intent", when compared with:
But I simply do not see that is true.
Apart from that calling a function log_to_handle() is documenting how the function works, not what the function does; I would either reject, or modify any application server module that required me to give it function for it to call every time it wanted to log a message.
It is just so much easier and more efficient to allow me to configure the heading and destination filehandle as individual parameters at instantiation.
All your curry() is doing, is complicating a very simple piece of code, in order to justify the introduction of the need for autocurrying.
But there is another, more serious problem with the idea of autocurrying.
If AppServer is a class, as implied by the ->new(...) instantiation, then it would be normal practice for me to be able to instantiate two instances. If I pass in a coderef to each instance, then each instance can store those as instance data and will call the appropriate logger function automatically.
But if instantiating an instance of AppServer class is going to blythly export curried functions into the caller's namespace, then there is going to be a conflict between those exported for use with the first instance, and those for the second etc.
I also wonder how this is going to work with OO code where the first parameter is $self?
Namespace pollution will abound, to create lots of autocurrying functions that in all honesty, I cannot remember using a module that might lend itself to their use.
Your example aside, which seems somewhat contrived anyway, I cannot think of a single instance of ever needing or wanting to constantise one or more parameters that I had to pass on many calls to a function.