3 ms·

> it's probably not very useful in the context of programming This puzzles me. It turns out it's very useful in the context of programming in practice (i.e. Ha

by the_af 5y ago

> it's probably not very useful in the context of programming This puzzles me. It turns out it's very useful in the context of programming in practice (i.e. Haskell programmers use it and find it useful), so what do you mean? I don't know CT so I wouldn't know how well it maps (pun intended) with the Math concept, but regardless, whatever abstraction is there in Haskell that programmers call "functors" is tremendously useful.

loopz 5y ago
CT may be appropriate to further evolve Haskell as a language, but for programming implementations; mathematical categories aren't directly useful. There Haskell is more like any other programming language, just that it's FP.
- the_af 5y ago
  I'm not debating that; instead, I'm arguing functors are immediately useful in languages like Haskell. Don't know enough about CT to debate that point.
  - loopz 5y ago
    They are. Abstractions like functors makes the language more similar to other structured languages. Otherwise, the same would've needed explicit recursion all over the place, which is more error-prone.
creata 5y ago
`Functor` instances need to exist: they're obviously useful. You'll see a million `map` methods in every programming language.[0] What you won't see is a unification of them all under one interface. And the point, in my view, is that this unification doesn't really buy you much. I can't think of a single algorithm that starts with "let T be a mappable type". [0]: https://doc.rust-lang.org/std/?search=map https://doc.rust-lang.org/std/?search=map
- rssoconnor 5y ago
  I mostly agree with what you are getting at here. However occasionally it is useful to abstract over all Functor or all Monads, etc. For example, when using the Van Laarhoven free monad[0] implementation, I'll quantify over all monads. While, there is a simple data type definition for free monads[1], it suffers from a well-known issue that the bind operation has quadratic complexity. The Van Laarhoven free monad circumvents this problem (at least in the common case where you are not trying to "execute" the intermediate monadic constructions). There are also continuation-based approaches for free monad implementations as well. The benefits of free monad are the typical ones described in "Data types à la carte" where you can, for example, instantiate your free monad in the IO monad for production, but use a pure monad instance for (parts of) your test harness. (Generic implementations of free monads and their operations is another example of quantifying over all Functors, but I'm assuming for the sake of argument that you'd prefer to repeat that boilerplate over and over again for all your specific free monad instances.) [0] http://r6.ca/blog/20140210T181244Z.html http://r6.ca/blog/20140210T181244Z.html [1] https://hackage.haskell.org/package/free-5.1.7/docs/Control-Monad-Free-Ap.html#t:Free https://hackage.haskell.org/package/free-5.1.7/docs/Control-... [2] http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCa...
chobytes 5y ago
The concrete instances are demonstrably useful, since theyre... actually used! However in Haskell theyre basically one kind of very concrete object. Invoking the abstract machinery of CT to explain list concatenation just has the hierarchy backward. Its like telling someone that inner-product induced norms on hilbert spaces are extremely useful when youre talking about taking the absolute value.

by the_af 5y ago

loopz 5y ago

CT may be appropriate to further evolve Haskell as a language, but for programming implementations; mathematical categories aren't directly useful. There Haskell is more like any other programming language, just that it's FP.

the_af 5y ago
I'm not debating that; instead, I'm arguing functors are immediately useful in languages like Haskell. Don't know enough about CT to debate that point.
- loopz 5y ago
  They are. Abstractions like functors makes the language more similar to other structured languages. Otherwise, the same would've needed explicit recursion all over the place, which is more error-prone.

creata 5y ago

`Functor` instances need to exist: they're obviously useful. You'll see a million `map` methods in every programming language.[0] What you won't see is a unification of them all under one interface. And the point, in my view, is that this unification doesn't really buy you much. I can't think of a single algorithm that starts with "let T be a mappable type". [0]: https://doc.rust-lang.org/std/?search=map https://doc.rust-lang.org/std/?search=map

rssoconnor 5y ago
I mostly agree with what you are getting at here. However occasionally it is useful to abstract over all Functor or all Monads, etc. For example, when using the Van Laarhoven free monad[0] implementation, I'll quantify over all monads. While, there is a simple data type definition for free monads[1], it suffers from a well-known issue that the bind operation has quadratic complexity. The Van Laarhoven free monad circumvents this problem (at least in the common case where you are not trying to "execute" the intermediate monadic constructions). There are also continuation-based approaches for free monad implementations as well. The benefits of free monad are the typical ones described in "Data types à la carte" where you can, for example, instantiate your free monad in the IO monad for production, but use a pure monad instance for (parts of) your test harness. (Generic implementations of free monads and their operations is another example of quantifying over all Functors, but I'm assuming for the sake of argument that you'd prefer to repeat that boilerplate over and over again for all your specific free monad instances.) [0] http://r6.ca/blog/20140210T181244Z.html http://r6.ca/blog/20140210T181244Z.html [1] https://hackage.haskell.org/package/free-5.1.7/docs/Control-Monad-Free-Ap.html#t:Free https://hackage.haskell.org/package/free-5.1.7/docs/Control-... [2] http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCa...

chobytes 5y ago

The concrete instances are demonstrably useful, since theyre... actually used! However in Haskell theyre basically one kind of very concrete object. Invoking the abstract machinery of CT to explain list concatenation just has the hierarchy backward. Its like telling someone that inner-product induced norms on hilbert spaces are extremely useful when youre talking about taking the absolute value.