I played around tonight trying to come up with a better way, but instead I came up with 2 decidedly worse ways (particularly considering readability/maintenance is the primary concern of the question). I think they're novel enough to share!
https://play.golang.org/p/w9YxsEFlF8 1) Original 2) Defining types with a consistent naming scheme - less typing, more obscurity! 3) Make a function that auto-currys - Like a curry-compiler... except requires you to type a whole auto-curry function along with some magic types to compile every possible combination of params and outputs! MAGIC! I think if you lift the burden of pure currying (one argument always) and use closures with multiple arguments unless you specifically need to be able to pass around partial functions with one argument you will free yourself from producing cumbersome code like this. That said, if each single argument partial function has a purpose as understood by its users, then you should be able to come up with a type name for each nested function and use that in your definition to clarify the intent of each "layer". It's pretty standard in Go to give type names to functions make explicit what you need. I parody this in my second example, but with proper names I think it could be quite readable code--it's really hard to say without seeing your specific use-case. If you can't come up with adequate names for each layer, you may want to ask yourself: If each of your partial functions doesn't have a purpose on its own, then why are you doing it? Just my 2 cents. On Thursday, June 16, 2016 at 10:59:56 PM UTC-7, Henrik Johansson wrote: > > Note the _excessive_ caveat. Used with some restraint I think it is a very > powerful construct. > > On Fri, Jun 17, 2016, 03:42 adonovan via golang-nuts < > golan...@googlegroups.com <javascript:>> wrote: > >> On Thursday, 16 June 2016 18:00:43 UTC-4, Zauberkraut wrote: >>> >>> would an extended usage of this paradigm be considered unidiomatic in Go? >>> >> >> Short answer: yes. Excessive use of function values as arguments and >> results of other functions can make the flow of control hard to follow. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
