What are some resources for learning theory which can relate to Haskell? Type theory, category theory, etc
I have a joint bachelors in CS and math, and I've taken courses on group theory, ring theory, programming languages, and cryptography. As such, I'm confident I have the background to jump in to some theory. I could just grab a category theory book and start reading, but since I'm mostly interested in applying this knowledge to my Haskell programming, I'm hoping I can get some direction from you guys. What can I read to enhance my understanding of lenses, comonads, important typeclasses like Applicative and how they relate to each other?
What if someone wants to learn some theory, but they don't have an academic background in mathematics? Where should they start?
Thanks!submitted by trolox
[link] [14 comments]
I could find only one dedicated json-rpc client library, hs-json-rpc. It does seem abandoned, though, and has problems (only using HTTP's simpleHTTP transport, throwing exceptions whithout properly exporting the exception type). Other packages apparently focus on the server side.
What do people use when they need json client? Just implement the protocol by hand, using Aeson and any http library they fancy? Any advice for an unexperienced haskeller what to try?
edit: thank you all for the advice. I guess the protocol is indeed simple enough to just handle it locally with aeson.submitted by lukewarm
[link] [4 comments]
One odd thing about the Haskell community is that we don’t use debuggers. We don’t even use stack traces. I think for several reasons:
- Haskell code goes wrong less often.
- Due to that, people are content with once in a while sticking in printf statements.
- Lazy evaluation is known to make debugging tricky.
- Haskell has no decent editor support for debugging.
It’s at least my experience that when my Haskell code goes wrong, I don’t fret too much because I put my code into small functions. If something’s not working as expected then I run that function in GHCi with typical inputs and check that the result is as desired.
If I’m in a codebase that makes it hard to do that, then I’ll insert some error or trace calls and re-run the whole program.
It’s also my experience that I don’t care about GHCi’s debugging support if I have to manually set breakpoints myself and step through things manually. Who wants to bother doing that? It’s like running git commands manually instead of using magit.
So, I thought, as an experiment, I’d whip up a simple magit-like interface to GHCi’s debugging facilities, based upon my (limited) understanding from the manual and the tutorials about it, which should help me answer the following questions:
- Is GHCi’s debugger any good? I.e. it’s useful, not quirky or obtuse.
- Is it practical? I.e. it works on real project code.
- Is lazy evaluation as problematic as suspected for real code?
- Does Haskell lend itself to debugging with GHCi enough that I’d reach for it as part of my problem-solving workflow?
By removing the “it’s hard to use” impedance from the debugger, that puts me in a good position to evaluate the above questions. Is it that we as a community are missing out on sweet tooling because we just don’t have a convenient way to use it?
Here is a video demonstrating a trivial usage of it, i.e. the one that I’ve been testing with. I was too lazy to commentate it, but you can pause the video to see the display. I just set a breakpoint on fib and step into the main function and keep stepping until evaluation is complete. At one point I go to the REPL to inspect the local binding x and then go back to stepping.
In the display you can see the current expression being evaluated, and the values of the local bindings and their types below. I think there’s room for in-place expansion of values, here. But I need to experiment with more interesting data structures.
I invite overenthusiastic early adopters to try pulling from the haskell-mode repo to play around with it and patch up obvious deficiencies. You have to be using haskell-interactive-mode’s REPL, (require 'haskell-debug) and then run M-x haskell-debug from a Haskell file or the REPL, like I do in the video. The rest should be fairly obvious from the buffer’s helpful messages. But if it doesn’t work as you expected because I don’t know the first thing about how debuggers are supposed to be used, don’t blame me. Just fix it.
I’m completely ambivalent about whether a debugger is really useful, I’ve never really used one properly. So I’ll try to use it to solve some problems—once I can find some decent use-cases—and report back in a few weeks. For science!
Breaking a list into chunks is an unfold:
list_chunks :: Int -> [a] -> [[a]];
list_chunks chunk_size = unfoldr $ \l -> if null l then Nothing else Just $ splitAt chunk_size l;
The output tuple of splitAt is conveniently just the right format for input to unfoldr. Is there a more elegant way to write if null l then Nothing else Just ...? The function listToMaybe doesn't quite work, as it assumes a single-element list.
> list_chunks 3 "hello world"
Here is a ByteString version:
import qualified Data.ByteString.Lazy as BS;
bytestring_blocks :: Int64 -> BS.ByteString -> [BS.ByteString];
bytestring_blocks block_size = unfoldr $ \b -> if BS.null b then Nothing else Just $ BS.splitAt block_size b;
After getting recursion beat into our skulls in introductory computer science courses, there's a feeling in functional programming to eschew explicit recursion in favor of higher-order functions like unfoldr which capture the recursive computational structure.