The use of `class` for things that should be simple free functions

Re:The use of `class` for things that should be simple free ... by throwaway894345 on Thursday May 28, 2020 @08:55PM (#23345087)

If you have a function `foo(a, b, c)` and you find yourself passing the same a and b all the time, you can curry it into a function that only takes c: `f = curry(foo, a, b)` such that you can just call `f(c)`. The OO alternative would be to create a class:

    class Foo:
        def __init__(self, a, b):
            self.a = a
            self.b = b

        def f(c):
            return foo(self.a, self.b, c)

And then you create an instance `obj = Foo(a, b)` and when you need to call `foo`, you call it via `obj.f(c)`. This is a long winded way of saying an object is a poor man's closure.

[ Parent | on HN ]

Re:The use of `class` for things that should be simple free ... by quietbritishjim on Friday May 29, 2020 @05:12AM (#23347892)

Ah I see, I believe you've mixed up currying with partial function application, that's what confused me (but, again, I'm not an expert on functional languages so it could be me that's mixed up). I believe that currying doesn't take any arguments except the function itself:

    # Signature of f is (a, b, c) -> r
    g = curry(f)
    # Signature of g is a -> (b -> (c -> r))
    #    i.e. g is a -> blah, 
    #    where blah itself is a function taking b, etc.

Admittedly you can get partial function application out of currying (but only with parameters at the start of the parameter list):

    g = curry(f)
    h = g(a)(b)
    # Signature of h is c -> r

But, although they're related, they're different procedures overall: sometimes you'll really want the curried function without immediately applying some arguments to it.

Anyway, replacing "currying" with "partial function application" in your earlier comment: I suppose you're right to some extent, but the "this" parameter usually isn't that hidden and in Python you even pass the "self" parameter explicitly. I suppose the real major thing is you've put a bunch of parameters into a single class/tuple/struct rather than spelling them out individually; if you had a weird language that didn't support structs etc. then some partial function application would certainly be a very useful alternative to writing the same argument list out many times. But once you've got the struct, making your utility functions be methods is just minor syntactic sugar on top of that.

[ Parent | on HN ]

Re:The use of `class` for things that should be simple free ... by throwaway894345 on Friday May 29, 2020 @09:53AM (#23349973)

Yeah, you’re probably right. I don’t understand all the tedious, annoying functional jargon; I just know there is a function in Racket called “curry” which does what I described above. Sorry for my error.

> I suppose the real major thing is you've put a bunch of parameters into a single class/tuple/struct rather than spelling them out individually

Yes, this is the mechanic, ultimately. Partial application vs structs/objects/tuples are just two different solutions for the same problem. Arguably they may even reduce down to the same underlying solution (to the extent that closures are objects behind the scenes).

[ Parent | on HN ]