3 ms·

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

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.
  - newswasboring 6y ago
    Man nothing against your dedication of explaining this to me, but everytime I talk about haskell it feels like a jargon salad. I very, very humbly ask you, so what? Like you wrote a short essay on this, and I still can't grok even in the slightest why this matters. Every other language I talk about, can at least tell me why certain feature is helpful, even if I don't get it. What I got from this is this allows abstracting mapping over types. But what does that give you? Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers.
    - momentoftop 6y ago
      > Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers. Maybe a user isn't supposed to. I believe that's the premise of Paul Graham's Blub Paradox [1]. I certainly didn't learn, say, Common Lisp, because I was doing a feature comparison. I had no idea what a lexical closure was at the time, and a couple of toy examples wouldn't have convinced me of their worth. I'd been programming quite happily without them for some time by then. [1] https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox
      - newswasboring 6y ago
        That is an excellent point. Haskell is such a fundamental shift in thinking, perhaps the only way to learn real application is to make something with it. But I would still maintain every language at least has a highly simplistic example of why certain features work well. In fact, my curiosity reignited by this discussion, I found this video series[1] on youtube which somehow made is 100x more clear where Functors, Applicatives and Monads are to be used. The tree example is pretty abstract, but it helped me connect these features to my work. I still don't know how to get most use out of it, but I think I get the USP. Still have the question about how haskell is helping here, because I can write a hidden state changing function in Julia if I want. But one step at a time [1] https://www.youtube.com/watch?v=xCut-QT2cpI https://www.youtube.com/watch?v=xCut-QT2cpI

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.
- newswasboring 6y ago
  Man nothing against your dedication of explaining this to me, but everytime I talk about haskell it feels like a jargon salad. I very, very humbly ask you, so what? Like you wrote a short essay on this, and I still can't grok even in the slightest why this matters. Every other language I talk about, can at least tell me why certain feature is helpful, even if I don't get it. What I got from this is this allows abstracting mapping over types. But what does that give you? Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers.
  - momentoftop 6y ago
    > Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers. Maybe a user isn't supposed to. I believe that's the premise of Paul Graham's Blub Paradox [1]. I certainly didn't learn, say, Common Lisp, because I was doing a feature comparison. I had no idea what a lexical closure was at the time, and a couple of toy examples wouldn't have convinced me of their worth. I'd been programming quite happily without them for some time by then. [1] https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox
    - newswasboring 6y ago
      That is an excellent point. Haskell is such a fundamental shift in thinking, perhaps the only way to learn real application is to make something with it. But I would still maintain every language at least has a highly simplistic example of why certain features work well. In fact, my curiosity reignited by this discussion, I found this video series[1] on youtube which somehow made is 100x more clear where Functors, Applicatives and Monads are to be used. The tree example is pretty abstract, but it helped me connect these features to my work. I still don't know how to get most use out of it, but I think I get the USP. Still have the question about how haskell is helping here, because I can write a hidden state changing function in Julia if I want. But one step at a time [1] https://www.youtube.com/watch?v=xCut-QT2cpI https://www.youtube.com/watch?v=xCut-QT2cpI