Re: [go-nuts] Re: Currying in Go

[Tyler Compton]

Thank you, Jesper, that's very interesting.

On Sunday, June 19, 2016 at 8:15:13 AM UTC-7, Jesper Louis Andersen wrote:
>
>
> On Sat, Jun 18, 2016 at 5:32 AM, Tyler Compton  > wrote:
>
>> I don't pretend to be proficient in this realm of functional programming, 
>> but I would be very surprised if this is valuable in a language like Go 
>> that can and does hold state.
>
>
> In functional languages, it is often used as a way to "configure" a 
> function. I.e., the function is defined as 
>
> let f conf x = ...
>
> where 'f' is the function name, 'conf' a parameter of configuration and 
> 'x' the "real" argument to the function. Now, partial application such a (f 
> c) for some configuration 'c', yields another function which has been 
> configured, or specialized, to the particular use case.
>
> Usually it allows you to define a generic function and then specialize it 
> in some context by "plugging in" a configuration. The configuration is 
> often a constant value which means the compiler will typically 
> constant-propagate that value into the closure. Many functional compilers 
> understand that closures with static data can be eliminated at compile time 
> by replacing them with a normal function. In other words, you have a 
> generic variant of your function, but when run it is specialized and 
> instantiated into an optimized variant.
>
> You *can* get the same with a function such as 'f(conf, x)' but in this 
> case, the compiler usually has some more work to do before it can apply the 
> above transformation.
>
>
>
> -- 
> J.
>

-- 
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.

Re: [go-nuts] Re: Currying in Go

[Jesper Louis Andersen]

On Sat, Jun 18, 2016 at 5:32 AM, Tyler Compton  wrote:

> I don't pretend to be proficient in this realm of functional programming,
> but I would be very surprised if this is valuable in a language like Go
> that can and does hold state.


In functional languages, it is often used as a way to "configure" a
function. I.e., the function is defined as

let f conf x = ...

where 'f' is the function name, 'conf' a parameter of configuration and 'x'
the "real" argument to the function. Now, partial application such a (f c)
for some configuration 'c', yields another function which has been
configured, or specialized, to the particular use case.

Usually it allows you to define a generic function and then specialize it
in some context by "plugging in" a configuration. The configuration is
often a constant value which means the compiler will typically
constant-propagate that value into the closure. Many functional compilers
understand that closures with static data can be eliminated at compile time
by replacing them with a normal function. In other words, you have a
generic variant of your function, but when run it is specialized and
instantiated into an optimized variant.

You *can* get the same with a function such as 'f(conf, x)' but in this
case, the compiler usually has some more work to do before it can apply the
above transformation.



-- 
J.

-- 
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.

[go-nuts] Re: Currying in Go

[Christoph Berger]

> this seems like an eyesore and maintenance concern. (...) it does cause 
me to hear code review sirens going off in the distance. 

Then why would you want to use currying in Go at all? What's the point of 
being able to write f(1)(2)(3) instead of f(1,2,3) *in a non-functional 
language?* Especially if the price you pay is code that is hard to read and 
difficult to maintain. 

As a Go proverb says, "Clear is better than 
clever".


On Friday, June 17, 2016 at 12:00:43 AM UTC+2, Zauberkraut wrote:
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. Thanks!
>

-- 
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.

[go-nuts] Re: Currying in Go

[Tyler Compton]

I would also like to hear from somebody about a real world use-case. I 
don't pretend to be proficient in this realm of functional programming, but 
I would be very surprised if this is valuable in a language like Go that 
can and does hold state. That said, this is very cool and I would love to 
be proven wrong.

On Friday, June 17, 2016 at 7:34:04 AM UTC-7, Evan Digby wrote:
>
> Currying is translating the evaluation of a function with multiple 
> arguments into evaluating a sequence of functions with one argument. Not 
> sure how this doesn't qualify, even if a closure was used to accomplish 
> this.
>
> As for the value, at the very least there is the same value as using 
> closures in general. The rest (why converting to single argument functions 
> for pure Currying was necessary) would have to be use-case specific. The 
> example given doesn't speak to why it's valuable. 
>
> I would be curious to understand the value by exploring more real-world 
> use-cases myself!
>
>

-- 
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.

[go-nuts] Re: Currying in Go

[paraiso . marc]

What is the point of doing that in a language that doesn't support auto 
currying ? There is none. You are not currying anything by the way, you 
just wrote 3 closures. 

Le vendredi 17 juin 2016 00:00:43 UTC+2, Zauberkraut a écrit :
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. Thanks!
>

-- 
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.