3 ms·

Sure, look at most Haskell libraries. A lot of them expose some of their APIs as monads, arrows, functors, and kleisli categories. Some good examples: hakyll,

by freyrs3 14y ago

Sure, look at most Haskell libraries. A lot of them expose some of their APIs as monads, arrows, functors, and kleisli categories. Some good examples: hakyll, Pandoc, pipes, conduits, warp, scotty, or anything by Edward Kmett ( https://github.com/ekmett/ https://github.com/ekmett/ )

skybrian 14y ago
Thanks, but that's far too much to take in at once. How about just one simple example? I did skim through them, so to be specific: hakyll, Pandoc, warp, and scotty are what I'd call practical programs, though they approximate more popular programs written in other languages, so there's the question of why someone who wasn't already a Haskell programmer should choose them. Pipes, conduits, and most of the stuff by Kmett appear to be libraries implementing other abstractions that themselves would have be justified by use in a practical program.
- freyrs3 14y ago
  > Pipes, conduits, and most of the stuff by Kmett appear to be libraries implementing other abstractions that themselves would have be justified by use in a practical program. I'm not sure I understand what you mean by "practical programming". This may just be a cultural difference but one of the big ideas of Haskell is using a library whose "core calculus" is provably correct and then combining them in ways that preserve that correctness. So I would argue that the justification of the libraries is not in the practical ( if I understand your usage of the word?) usage but in the thoroughness and compositional semantics that they provide. That's where the category theory inspired patterns ( zippers, monads, arrows, etc ) become important.
  - skybrian 14y ago
    Okay, let's define "practical programming" as creating programs that will be of use to someone who doesn't know the programming language that the program was written in. So in this case, this means writing Haskell programs that will be used by people who don't know Haskell. This isn't the only reason to write a program of course. You can do it just for fun or to explore the mathematics. But I'm mostly interested in abstractions that might be useful for solving problems outside mathematics.
    - freyrs3 14y ago
      None of the libraries or patterns I mentioned above are designed for the purpose of exploring category theory. Though some people do do that, but they tend to live in their own world. A lot of Haskellers just happen to exploit bits of CT it because its a great framework for writing and reasoning about code. Some people do use Haskell as a way to explore category theory but for example Tekmo isn't writing pipes as a means to explore the theory of free monads, they've been well studied since the 80s. I believe he just happens to find that they are an excellent way of chaining together bits of control flow. At that heart of the problem he's tackling is very practical problem that's tied to data flow and resource management. For example, I've written a library against pipes which handles resource management of ZeroMQ sockets for a large distributed system and find that my code under pipes is much more manageable.
      - skybrian 14y ago
        Okay, sure, resource management is what I'd call a practical problem, and pipelines are familiar from Unix (and Go). It looks like this pipe library has a nice practical example: enforcing the category laws means that it handles terminating pipelines consistently: http://hackage.haskell.org/packages/archive/pipes/1.0.1/doc/html/Control-Pipe.html http://hackage.haskell.org/packages/archive/pipes/1.0.1/doc/...

by freyrs3 14y ago

skybrian 14y ago

Thanks, but that's far too much to take in at once. How about just one simple example? I did skim through them, so to be specific: hakyll, Pandoc, warp, and scotty are what I'd call practical programs, though they approximate more popular programs written in other languages, so there's the question of why someone who wasn't already a Haskell programmer should choose them. Pipes, conduits, and most of the stuff by Kmett appear to be libraries implementing other abstractions that themselves would have be justified by use in a practical program.

freyrs3 14y ago
> Pipes, conduits, and most of the stuff by Kmett appear to be libraries implementing other abstractions that themselves would have be justified by use in a practical program. I'm not sure I understand what you mean by "practical programming". This may just be a cultural difference but one of the big ideas of Haskell is using a library whose "core calculus" is provably correct and then combining them in ways that preserve that correctness. So I would argue that the justification of the libraries is not in the practical ( if I understand your usage of the word?) usage but in the thoroughness and compositional semantics that they provide. That's where the category theory inspired patterns ( zippers, monads, arrows, etc ) become important.
- skybrian 14y ago
  Okay, let's define "practical programming" as creating programs that will be of use to someone who doesn't know the programming language that the program was written in. So in this case, this means writing Haskell programs that will be used by people who don't know Haskell. This isn't the only reason to write a program of course. You can do it just for fun or to explore the mathematics. But I'm mostly interested in abstractions that might be useful for solving problems outside mathematics.
  - freyrs3 14y ago
    None of the libraries or patterns I mentioned above are designed for the purpose of exploring category theory. Though some people do do that, but they tend to live in their own world. A lot of Haskellers just happen to exploit bits of CT it because its a great framework for writing and reasoning about code. Some people do use Haskell as a way to explore category theory but for example Tekmo isn't writing pipes as a means to explore the theory of free monads, they've been well studied since the 80s. I believe he just happens to find that they are an excellent way of chaining together bits of control flow. At that heart of the problem he's tackling is very practical problem that's tied to data flow and resource management. For example, I've written a library against pipes which handles resource management of ZeroMQ sockets for a large distributed system and find that my code under pipes is much more manageable.
    - skybrian 14y ago
      Okay, sure, resource management is what I'd call a practical problem, and pipelines are familiar from Unix (and Go). It looks like this pipe library has a nice practical example: enforcing the category laws means that it handles terminating pipelines consistently: http://hackage.haskell.org/packages/archive/pipes/1.0.1/doc/html/Control-Pipe.html http://hackage.haskell.org/packages/archive/pipes/1.0.1/doc/...