5 ms·

Maybe I'm missing something, but what does implicit "this" arguments have to do with functional programming? > public String getName() { return this.name; } >

Maybe I'm missing something, but what does implicit "this" arguments have to do with functional programming? > public String getName() { return this.name; } > How would we purify this call? Well, this is the hidden input, so all we have to do is lift it up to an argument: > public String getName(Person this) { return this.name; } > Now getName is a pure function. Isn't that just syntactic sugar? I would say that a real functional programming language enforces that functions cannot have side effects, not just that you have the ability to write such functions.

typon 11y ago
How is it syntactic sugar? In the second version the function is now accessing an argument rather than something outside its scope. That's pretty much the definition of a pure function (besides having no side effects).
- seanwilson 11y ago
  I would agree if getName was accessing a global variable but I don't see how getName(person) is any more functional than person.getName(). OCaml features objects with similar syntax for example: http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.html http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.ht...
  - typon 11y ago
    Because you can write person.getName() like this: def getName(): . . this.setName('foo') . . return this.name There's nothing in principle preventing you from doing that in the "functional" approach but if your data is immutable then you can't do it.
    - Someone 11y ago
      def getName(person): person.setName('foo') return person.name The problem, from a functional viewpoint, isn't the implicit argument, it is the fact that you can write setName.
      - typon 11y ago
        Really? I thought implicit arguments were a strict no-no in functional programming.
        Someone 11y ago
        Implicit arguments are still arguments. It is just syntactic sugar, and I think syntax changes cannot change a functional language into a non-functional one.
  - chchrutuch 11y ago
    It's not and anyone arguing to the contrary is wrong. The article is way off base on this. You could argue it's purely syntactic sugar, but really, it's barely even: it's just alternate syntax. People arguing against this are failing to understand that different languages have different syntaxes. person.getName() is the same as getName(person). In the former it's an implicit parameter, in the latter it's explicit. Or, looking at it differently, one is a syntax for functional calls that prepends the first argument as a target, and one is a syntax that accepts the target as the first argument. With Java 8 method references, you can see this a bit more clearly. You could, for instance, do this to get a function without the implicit this: Function<Person, String> getName = Person::getName; getName.apply(new Person());
- chchrutuch 11y ago
  It's alternate syntax, or, if you want to go there, you can say it's syntactic sugar. Take a few minutes to go read the bytecode Java generates on something like person.getName() to see how this is being handled at that level. Further, purity is about expectations, not scope. Expecting something to be pure means I can reliably call it with the same arguments and always get the same result, with the additional expectation that it will change nothing about the world. A function that accepts no arguments can be pure but must always return the same thing. If the person's name is indeed immutable, then person.getName(), provided it performs no side effects, is perfectly pure. In concept, other than brevity, invoking a constructor on an immutable object is not much different than the function returned by a higher order function such as this: (defn name-getter [{name :name}] (fn [] name)) (def get-name (name-getter {:name "John"})) (get-name)
lmm 11y ago
Objects are arguably just syntactic sugar for passing a bag of state around (where some of that state might be function values). This becomes very clear if you've ever done OO in C (with a manual virtual function table). A lot of the argument for "composition over inheritance", SOLID etc. is separating the pieces of state that specific object methods depend on. I don't think the Python approach helps that much in practice (since method calls look exactly the same), but it does make it much clearer where anything referenced in a method body has to be coming from.
virmundi 11y ago
I think this mental exercise from Lamda the Ultimate holds true: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. Source http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent
tome 11y ago
> Maybe I'm missing something, but what does implicit "this" arguments have to do with functional programming? They're implicit mutable state. Whether you think that has anything to do with functional programming is another matter, I suppose.

typon 11y ago

How is it syntactic sugar? In the second version the function is now accessing an argument rather than something outside its scope. That's pretty much the definition of a pure function (besides having no side effects).

seanwilson 11y ago
I would agree if getName was accessing a global variable but I don't see how getName(person) is any more functional than person.getName(). OCaml features objects with similar syntax for example: http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.html http://caml.inria.fr/pub/docs/manual-ocaml/objectexamples.ht...
- typon 11y ago
  Because you can write person.getName() like this: def getName(): . . this.setName('foo') . . return this.name There's nothing in principle preventing you from doing that in the "functional" approach but if your data is immutable then you can't do it.
  - Someone 11y ago
    def getName(person): person.setName('foo') return person.name The problem, from a functional viewpoint, isn't the implicit argument, it is the fact that you can write setName.
    - typon 11y ago
      Really? I thought implicit arguments were a strict no-no in functional programming.
      - Someone 11y ago
        Implicit arguments are still arguments. It is just syntactic sugar, and I think syntax changes cannot change a functional language into a non-functional one.
- chchrutuch 11y ago
  It's not and anyone arguing to the contrary is wrong. The article is way off base on this. You could argue it's purely syntactic sugar, but really, it's barely even: it's just alternate syntax. People arguing against this are failing to understand that different languages have different syntaxes. person.getName() is the same as getName(person). In the former it's an implicit parameter, in the latter it's explicit. Or, looking at it differently, one is a syntax for functional calls that prepends the first argument as a target, and one is a syntax that accepts the target as the first argument. With Java 8 method references, you can see this a bit more clearly. You could, for instance, do this to get a function without the implicit this: Function<Person, String> getName = Person::getName; getName.apply(new Person());
chchrutuch 11y ago
It's alternate syntax, or, if you want to go there, you can say it's syntactic sugar. Take a few minutes to go read the bytecode Java generates on something like person.getName() to see how this is being handled at that level. Further, purity is about expectations, not scope. Expecting something to be pure means I can reliably call it with the same arguments and always get the same result, with the additional expectation that it will change nothing about the world. A function that accepts no arguments can be pure but must always return the same thing. If the person's name is indeed immutable, then person.getName(), provided it performs no side effects, is perfectly pure. In concept, other than brevity, invoking a constructor on an immutable object is not much different than the function returned by a higher order function such as this: (defn name-getter [{name :name}] (fn [] name)) (def get-name (name-getter {:name "John"})) (get-name)

lmm 11y ago

Objects are arguably just syntactic sugar for passing a bag of state around (where some of that state might be function values). This becomes very clear if you've ever done OO in C (with a manual virtual function table). A lot of the argument for "composition over inheritance", SOLID etc. is separating the pieces of state that specific object methods depend on. I don't think the Python approach helps that much in practice (since method calls look exactly the same), but it does make it much clearer where anything referenced in a method body has to be coming from.

virmundi 11y ago

I think this mental exercise from Lamda the Ultimate holds true: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. Source http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

tome 11y ago

> Maybe I'm missing something, but what does implicit "this" arguments have to do with functional programming? They're implicit mutable state. Whether you think that has anything to do with functional programming is another matter, I suppose.