in Code

Today we’re going to continue along with the All About Auto introduction series and look at building a declarative chatbot using the denotational components from the auto library that is modular and has implicit serialization. Most importantly, we’ll look at the “design process”, and principles of architecture that you can apply to your own projects.

This post assumes some concepts from the tutorial, or at least my last post or the README. If some of these ideas seem completely new, than looking through the tutorial or the docs might refresh your mind…feel free to also leave a comment, stop by #haskell-auto on freenode where I go by jle`, or tweet me

All of the code in this tutorial can be downloaded and run using runghc (with the appropriate dependencies installed). Feel free to play along!

Read more … Comments

Auto: README (with examples) / hackage / tutorial / examples / github

(Before anything, maybe take a quick look at the detailed description in the README for a quick motivating example and explanation of the library)

Today I’m announcing and beginning promotion of my auto library, a denotative and locally stateful programming DSL and platform, now on hackage. auto is suitable when your program involves an input or output that is a discrete stream of things — events, views, etc., like turn based games, GUI’s, numerical computations…; it allows you to state (possibly cyclic) complex relationships between streams of values by composing simple, primitive ones. You can read the README too for a detailed buzz-word laden exposition with nice well-commented short demos and examples, get started with the tutorial, check out the directory of sample projects, and even see a live running todoMVC (source) example!

Over the next week or two I’m going to be breaking down real-world projects written on auto, and even be talking about the design processes of programs written using auto. You can follow along on the series page, follow me on twitter, or just subscribe to the rss feed feed; expect a post on designing, from start to finish,

1. A fully running chat bot
2. A GUI-based todo app on ghcjs
3. A text-based adventure game a la the classic rogue
4. A numerical computation DSL

But enough of that…what is auto, why does it exist, and what are its design principles?

Read more … Comments

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