in Code

Hi! I have to apologize a bit for the long delay; starting grad school and things like that have made me have to scramble to adjust to the new life. But a couple of people have asked me to finish up and wrap up this series, and I think I owe it to them then :) Welcome to the final chapter.

In the last post, we looked deeper into the Auto type, played around with instancing it as familiar typeclasses, saw it as a member of the powerful Category and Arrow typeclasses, and took advantage of this by composing Autos both manually and using proc/do notation, and were freed from the murk and mire of explicit recursion. We observed the special nature of this composition, and saw some neat properties, like local statefulness.

At this point I consider most of the important concepts about working with Auto covered, but now, we are going to push this abstraction further, to the limits of real-world industrial usage. We’re going to be exploring mechanisms for adding effects and, making the plain ol’ Auto into something more rich and featureful. We’ll see how to express denotative and declarative compositions using recursively binded Autos, and what that even means. It’ll be a trip down several avenues to motivate and see practical Auto usage.¹ Basically, it’ll be a “final hurrah”.

A fair bit of warning — if the last post is not fresh in your mind, or you still have some holes, I recommend going back and reading through them again. This one is going to hit hard and fast :) (Also, it’s admittedly kind of long for a single post, but I didn’t want to break things up into two really short parts.)

As always, feel free to leave a comment if you have any questions, drop by freenode’s #haskell, or find me on twitter :)

All of the code in this post is available for download and to load up into ghci for playing along!

Read more … Comments

Just stopping in for a short post before continuing with a long-overdue series or two :) This post is a bit of a short fun one that describes a quest I had, and hopefully some useful extra ideas I found along the way.

Soon after I discovered Haskell, one question has plagued my mind. Day and night, I wondered…

Are there any Haskell types with more than one unique Monad instance?

This was a question that was pretty simple…so simple that I was sure many people had already asked and answered this. But I couldn’t really find any answers and nobody I asked at the time could really give me one either, so this soon embedded itself as a pretty deep mystery to my psyche.

The background?

Read more … Comments

In the tradition of “considered harmful” posts, this post’s title is intentionally misleading and designed to incite controversy — or at least grab your attention. Because of this, please take my exaggerations in this article for what they are :) In following tradition I will try to leave as many quotes and soundbytes as possible that can be easily taken terribly out of context and twisted.

Anyways, I don’t mean that this “IO Monad” is something to be avoid. In fact, there’s a lot I rather like about it. What I mean is that the phrase “IO Monad”…it’s got to go. It has its usages, but 99.9% of times it is used, it is used improperly, with much damaging effects. So let’s go ahead with stopping this nonsense once and for all, okay?

So I’ll say it here:

The phrase “IO monad” considered harmful. Please do not use it.¹²

In most circumstances, an IO action of an IO type³ is the more helpful and more correct answer.

I’m going to say that this is probably the single most harmful and damaging thing in Haskell and the community, with regards to pedagogy, practice, public perception, and kittens. Not even kidding. It’s actually literally the worst and everyone in the world is worse off every time someone says it. Not only is this a problem in and of itself, but it is at the core root of 90% (+/- 80%) of Haskell’s problems.

Read more … Comments

One thing I’ve really always appreciated about Haskell is that all “statements” in Haskell (or at least, what would be statements in other languages) are first-class members of the language. That is, (imperative) statements are literally just normal objects (no different from numbers, or lists, or booleans) — they can be saved to variables, passed to functions, transformed using normal functions, copied, etc. Haskell doesn’t have statements — everything is an expression, representing normal data! This really opens up a whole world of possibilities for not only reasoning about your code, but also for new ways to frame ideas in contexts of parallelism, concurrency, exceptions, DSLs, and more.

To clarify, by “statement”, I mean it in the sense of a “command” from traditional imperative programming that, when control flow reaches it, executes some sort of action or modification to some state. The wikipedia article has a nice explanation. Some typical statements from common imperative languages include:

int a = 4;              // declaration & assignment
a += 5;                 // modification
printf("hello world");  // call
return false;           // exit points

In these languages, whenever control flow reaches these statements, something happens. We do not differentiate the act of evaluating these statements (figuring out what they are) from executing these statements. Something just happens when you see an assignment.

It is clear that in these languages, something about these statements are magical or a special part of the language. They are wholly different than, say, an integer, or a boolean. They aren’t normal “objects” or “data” in your system.

Even if your programming languages have first-class functions, printf might be a first-class value, but the call of it (usually indicated with parentheses, like printf()) is definitely something…different altogether. You can simulate this in languages by creating a sub-language inside the language, but you’re always going to have an interplay between the two. There will always be the dichotomy between statements and data.

Read more … Comments

Welcome back! It’s been a while since the last post, admittedly; sorry! In this post we’ll be continuing on from the previous post. In particular, we’re going to be looking at the Auto type as something that is a part of a pretty powerful pattern of abstraction, and try to exploit it to write concise, expressive code using Auto composition and proc notation. We’ll also see first hands the principles of locally stateful composition, and how much more expressive and safe it makes our code.

One motivating factor that I will eventually write about is that we can use this to implement the semantics of Functional Reactive Programming, yay! But through this, I hope you can actually see that it is useful for much, much more!

As always, feel free to leave a comment if you have any questions, or try to find me on twitter, or drop by the #haskell Freenode IRC channel! (I go by jle`)

Note that all of the code in this post can be downloaded (from Auto.hs for the last post, and Auto2.hs for this post’s new material) so you can play along on GHCi, or write your own code using it the concepts and types here :) You can also run it online interactively.

A fair warning: at times this post might feel a bit fragmented; but remember that we really are just going to be exploring and getting very familiar with the Auto type and building an intuition. Everything comes to a mini-climax at the end, and a final satisfying one at the next post — kind of like every Part 2 in every trilogy ever, you know? :)

Read more … Comments

Let’s finally finish up our Streaming Huffman Compression project by actually implementing the “streaming” part :) In part 1 we looked at the data structures which we used to implement our compression logic; in part 2 we looked at the actual compression/decompression algorithm and implemented it. Finally, let’s wrap it all up and actually implement a streaming interface!

If we were using an imperative approach, this would usually involve some sort of loop — read a byte, process it, write the resulting byte, read the next, process it, write it…it’s a step of instructions that a computer will be able to perform step-by-step.

In Haskell, when we can, we try to look for a pure, declarative approach based on compositions of abstractions. That’s what Haskell does best, after all. So let’s see what we can do!

(All of the code in this article and the ones before can be downloaded from github, so you can download it and try it out yourself!)

Read more … Comments

So a bit of some personal news (which you can safely ignore if you’re not interested in my personal life!) — I’m excited to announce that I have decided to accept an offer to the Computational and Data Science Doctorate Program at Chapman University in California. I came to this decision after a decently long period of deliberation and thinking things over, and weighing opportunities at Chapman against my other offers. However, having just finalized everything this week, I am ready to announce Chapman as my home for my doctoral studies in the upcoming years.

There are two main aspects to my decision — why computational science, and why Chapman?

Read more … Comments

I like Haskell because it lets me live inside my world.

There are a lot of special worlds out there! And Haskell lets me stay in those worlds, and use all of the tools I normally have when I’m not there. I get to transform normal tools into tools that work in my world.

(This post is meant to be approachable by people unfamiliar with Haskell! That being said, if there is a concept you don’t understand, feel free to leave a comment, tweet me, stop by on irc at freenode’s #haskell, or give Learn You a Haskell a quick read!)

Read more … Comments