4 ms·

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.

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.