Update: This post was written by me when I was just starting to learn about type-level things in Haskell, and reflects my own inexperience at the time of writing it. I have released an update, which presents what I hope to be an introduction that is more grounded in modern Haskell and dependent type idioms.
Nothing too crazy today, just a cute (basic/intermediate) haskell trick as a response to Mark Dominus’s excellent Universe of Discourse post on Easy exhaustive search with the list monad intended for people new or unfamiliar with haskell demonstrating the common “list monad as a constraint solver” approach that is standard fare for learning Haskell. I myself have literally done an entire series of blog posts on this usage.
Mark’s use case however incorporates a bit of an extra pattern not typically discussed. The list monad is good for taking “independent samples” of things (looking at different samples from a list):
ghci> do x <- "abc"
y <- "abc"
z <- "abc"
return [x,y,z]
["aaa","aab","aac","aba","abb" ... ]However, what if you wanted to instead “draw” from a pool, and represent different drawings? Traditionally, the answer was something like:
ghci> do x <- "abc"
y <- filter (/= x) "abc"
z <- filter (/= y) . filter (/= x) $ "abc"
return [x,y,z]
"abc","acb","bac","bca","cab","cba"]This is a little bit awkward…and it definitely gets a lot worse (\(O(n^2)\)) when you have more items. Also, it relies on an Eq constraint — what if our thing doesn’t have an Eq instance? And this also falls apart when our list contains duplicate items. If we had used "aabc" instead of "abc", the result would be the same — despite having more 'a's to pick from!
Continuing along with All About Auto, let’s look at another exciting and useful application of the auto library: GUI’s. We’re going to look at the canonical “hello world” of GUI apps these days — the todo app. We’re going to be using the specs of todoMVC to build a todoMVC “candidate” that follows the specs…and along the way see what auto offers in its tools of managing isolated state components and modeling GUI logic. We’re really going to be focusing on application logic — “control” and “model” — and not looking too close on “views”, which auto doesn’t quite try to offer and where you can really pick your own view rendering system, making this adaptable to really any platform — javascript/web, desktop, command line, etc.
A live version of our end-product is hosted and online.
This post does assume some concepts from the tutorial…if not all, then at least those in the introductory post or the README. If you ever find yourself thinking that these concepts are completely new and crazy, you might want to try looking through the tutorial or docs to refresh your mind. As always, comments are welcome, and I’m also usually on #haskell-auto as jle`, and also on twitter
(Fair warning…this is not quite a “ghcjs tutorial”, if that’s what you’re looking for; it’s an auto tutorial that uses some rudimentary ghcjs. Hopefully you can learn from that too!)
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!
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,
But enough of that…what is auto, why does it exist, and what are its design principles?
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.1 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!
Some of you might recall an earlier plan for this post that would include FRP. Unfortunately, I’ve refactored FRP into a completely new topic, because I’ve realized that the two aren’t exactly as related as I had led you all to believe. Still, most if not all of these techniques here are used in actual arrowized FRP libraries today. So, look out for that one soon!↩︎
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
Monadinstance?
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?
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.12
In most circumstances, an IO action of an IO type3 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.
In any case, ever, for any circumstance or reason.↩︎
Just kidding. Only a sith deals in absolutes.↩︎
Note here, I am referring to the IO type, not the IO type constructor. The actual abstract data type, and not the IO :: * -> * type constructor that you use in type signatures. When we talk about the “Map type”, we talk about the abstract data type, the underlying binary search tree, and the API that it offers…we don’t really talk about the Map :: * -> * -> * type constructor.↩︎