13 ms·

> Functors are basically an Object with a internal state changing method in typical OOP terms. This lets me safely ignore the rest of the article.

by malf 6y ago

newswasboring 6y ago
Care to say why? Or just going to hit and run?
- davorak 6y ago
  I will take a stab at it. > Functors are basically an Object with a internal state changing method in typical OOP terms. If I was writing a functional language, in an oop language, I could implement functors at least partially with an Object with an internal state changing method. I could not model/implement an Object with an internal state changing method in a fp language via a functor. The main issue with the author's statement is that it makes a claim of approximate equivalence and does not back it up with additional evidence or examples.
  - newswasboring 6y ago
    > I could not model/implement an Object with an internal state changing method in a fp language via a functor. I don't think anyone claimed that. > I could implement functors at least partially with an Object with an internal state changing method. Now we are getting somewhere. You said partially, what features are being left out?
    - davorak 6y ago
      >> I could not model/implement an Object with an internal state changing method in a fp language via a functor. > I don't think anyone claimed that. I was not trying to refute the opposite claim. I was giving info on the differences of functors and the referenced oop feature. My points run somewhat counter to the authors claim "Functors are basically an Object with a internal state changing method in typical OOP terms." or at least what I think some reads walk away with. Hard to say what is in the author's head with the provided text. > Now we are getting somewhere. You said partially, what features are being left out? I did not mean to imply features would be left out but rather I would use more than the one oop feature, "an Object with an internal state changing method", to implement functors.
      - newswasboring 6y ago
        > I did not mean to imply features would be left out but rather I would use more than the one oop feature Awesome, we are still getting somewhere. What other oop feature would you be using
        davorak 6y ago
        > Awesome, we are still getting somewhere. What other oop feature would you be using I'm glad you think it was productive so far. I am not convinced it is a productive use of our time to continue/extend the thought exercise though.
- kryptiskt 6y ago
  Functor is a typeclass, which is the equivalent of an interface in Java, it's very basic, providing the ability to lift a function and execute it in the context of the functor (whatever that is, this is the interface, remember), a generalization of map. So a lot of types have an implementation of Functor. In theory one of those implementations could be guilty of using hidden state and all that, but in practice all of them are just straightforward functions transforming values into a new value, not mutating them. In short, not a single word of the description is correct.
  - newswasboring 6y ago
    Now I'm more confused. If there is no hidden internal state what is the difference between a function and a Functor? If it's just taking input and giving output without any internal state, that's just a function isn't it? Edit: ok I did some more refreshing of memory. So Functor is an interface with some properties like identity[1] and distributive morphism (I think I'm wording that right). That's just an interface. I can implement that in Java or F# if I want. How is haskell helping here? [1] https://wiki.haskell.org/Functor#Minimal_Complete_Definition https://wiki.haskell.org/Functor#Minimal_Complete_Definition
    - tome 6y ago
      > How is haskell helping here? Haskell's functions are pure which make the typeclass laws more meaningful.
    - momentoftop 6y ago
      You can't define the interface in either language. Implementations of Functor consist, in part, of type-level functions. In Haskell terms, these are "higher-kinded types". The standard example is the list type "[]" which, as a type-level function, takes an element type and gives back the type of lists whose elements are drawn from that element type. In Java and F#, the only way to talk about the List type is in its fully applied context, where you've attached the element type. So maybe you've got "List<Int>", or you've got "List<String>" or you may have a generic "List<A>". What you don't have is the type-level function that's not been applied to anything. So there's no equivalent to the Haskell Functor implementation: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap f xs This is barely half the story. What makes this useful in Haskell is the typeclass overloading, which makes it effortless to write functions that abstract over arbitrary Functors, and use "fmap" multiple times locally for different Functor instances, letting the type system figure out what implementation is needed to map over the particular type you're working with. And in such abstract code, where you may know very little about the Functor instance you're working with, it's extremely important that they all be absolutely law-abiding: in many cases, the laws are all you have to work with. These two features, higher-kinding and typeclass polymorphism, make it worth talking about Functors, and I don't think you can appreciate Functors in Haskell without seeing the interaction of these features and just how much it impacts the code style of the average Haskeller.
fooker 6y ago
That’s a pretty reasonable colloquial description for anyone who does not grok functional programming.
- davorak 6y ago
  If the author was using the description to explain Functors to someone who only knew oop it's a reasonable start. I got the impression the author was implying that is basically all you need to understand Functors and is not the case.
evincarofautumn 6y ago
Wow, I honestly wonder if this was caused by mixing up “functor” in the C++ and Haskell senses… To expand on that, for those in the audience: In Haskell, a functor is a type constructor (like “list”, “optional”, “future”, “I/O request”, &c.) with a way to map a function over it, covariantly, in a way that preserves its structure—i.e. without changing the shape of the container or structure of the action represented by the constructor, just the contained elements or produced result. This is based on the more general notion of a functor in mathematics, which is a mapping between categories. The Haskell version is much more constrained, though: it only maps between Haskell types, and it’s parametric (iow completely generic), not just any old mapping. While in C++, a functor is a completely different thing: an object that can be called like a function. It’s thus equivalent to a closure, where the object fields are the captured values. And that sounds like the description being used here.

> Functors are basically an Object with a internal state changing method in typical OOP terms. This lets me safely ignore the rest of the article.

by malf 6y ago

> Functors are basically an Object with a internal state changing method in typical OOP terms. This lets me safely ignore the rest of the article.

newswasboring 6y ago

Care to say why? Or just going to hit and run?

davorak 6y ago
I will take a stab at it. > Functors are basically an Object with a internal state changing method in typical OOP terms. If I was writing a functional language, in an oop language, I could implement functors at least partially with an Object with an internal state changing method. I could not model/implement an Object with an internal state changing method in a fp language via a functor. The main issue with the author's statement is that it makes a claim of approximate equivalence and does not back it up with additional evidence or examples.
- newswasboring 6y ago
  > I could not model/implement an Object with an internal state changing method in a fp language via a functor. I don't think anyone claimed that. > I could implement functors at least partially with an Object with an internal state changing method. Now we are getting somewhere. You said partially, what features are being left out?
  - davorak 6y ago
    >> I could not model/implement an Object with an internal state changing method in a fp language via a functor. > I don't think anyone claimed that. I was not trying to refute the opposite claim. I was giving info on the differences of functors and the referenced oop feature. My points run somewhat counter to the authors claim "Functors are basically an Object with a internal state changing method in typical OOP terms." or at least what I think some reads walk away with. Hard to say what is in the author's head with the provided text. > Now we are getting somewhere. You said partially, what features are being left out? I did not mean to imply features would be left out but rather I would use more than the one oop feature, "an Object with an internal state changing method", to implement functors.
    - newswasboring 6y ago
      > I did not mean to imply features would be left out but rather I would use more than the one oop feature Awesome, we are still getting somewhere. What other oop feature would you be using
      - davorak 6y ago
        > Awesome, we are still getting somewhere. What other oop feature would you be using I'm glad you think it was productive so far. I am not convinced it is a productive use of our time to continue/extend the thought exercise though.
kryptiskt 6y ago
Functor is a typeclass, which is the equivalent of an interface in Java, it's very basic, providing the ability to lift a function and execute it in the context of the functor (whatever that is, this is the interface, remember), a generalization of map. So a lot of types have an implementation of Functor. In theory one of those implementations could be guilty of using hidden state and all that, but in practice all of them are just straightforward functions transforming values into a new value, not mutating them. In short, not a single word of the description is correct.
- newswasboring 6y ago
  Now I'm more confused. If there is no hidden internal state what is the difference between a function and a Functor? If it's just taking input and giving output without any internal state, that's just a function isn't it? Edit: ok I did some more refreshing of memory. So Functor is an interface with some properties like identity[1] and distributive morphism (I think I'm wording that right). That's just an interface. I can implement that in Java or F# if I want. How is haskell helping here? [1] https://wiki.haskell.org/Functor#Minimal_Complete_Definition https://wiki.haskell.org/Functor#Minimal_Complete_Definition
  - tome 6y ago
    > How is haskell helping here? Haskell's functions are pure which make the typeclass laws more meaningful.
  - momentoftop 6y ago
    You can't define the interface in either language. Implementations of Functor consist, in part, of type-level functions. In Haskell terms, these are "higher-kinded types". The standard example is the list type "[]" which, as a type-level function, takes an element type and gives back the type of lists whose elements are drawn from that element type. In Java and F#, the only way to talk about the List type is in its fully applied context, where you've attached the element type. So maybe you've got "List<Int>", or you've got "List<String>" or you may have a generic "List<A>". What you don't have is the type-level function that's not been applied to anything. So there's no equivalent to the Haskell Functor implementation: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap f xs This is barely half the story. What makes this useful in Haskell is the typeclass overloading, which makes it effortless to write functions that abstract over arbitrary Functors, and use "fmap" multiple times locally for different Functor instances, letting the type system figure out what implementation is needed to map over the particular type you're working with. And in such abstract code, where you may know very little about the Functor instance you're working with, it's extremely important that they all be absolutely law-abiding: in many cases, the laws are all you have to work with. These two features, higher-kinding and typeclass polymorphism, make it worth talking about Functors, and I don't think you can appreciate Functors in Haskell without seeing the interaction of these features and just how much it impacts the code style of the average Haskeller.

fooker 6y ago

That’s a pretty reasonable colloquial description for anyone who does not grok functional programming.

davorak 6y ago
If the author was using the description to explain Functors to someone who only knew oop it's a reasonable start. I got the impression the author was implying that is basically all you need to understand Functors and is not the case.

evincarofautumn 6y ago

Wow, I honestly wonder if this was caused by mixing up “functor” in the C++ and Haskell senses… To expand on that, for those in the audience: In Haskell, a functor is a type constructor (like “list”, “optional”, “future”, “I/O request”, &c.) with a way to map a function over it, covariantly, in a way that preserves its structure—i.e. without changing the shape of the container or structure of the action represented by the constructor, just the contained elements or produced result. This is based on the more general notion of a functor in mathematics, which is a mapping between categories. The Haskell version is much more constrained, though: it only maps between Haskell types, and it’s parametric (iow completely generic), not just any old mapping. While in C++, a functor is a completely different thing: an object that can be called like a function. It’s thus equivalent to a closure, where the object fields are the captured values. And that sounds like the description being used here.