# in Code

## Justin Le

Welcome! My name is Justin Le. I’m a PhD student at Chapman University in California, studying Computational Science & Applied Maths; I studied Physics and Computer Science at University of California, San Diego :)

This is just my weblog covering my various adventures in programming and explorations in the vast worlds of computation, physics, engineering, mathematics, and knowledge. Expect a healthy curiosity and an only slightly unhealthy obsession for finding new ways to marvel, wonder, and create. Join me if you wish!

Check out my most popular articles: Inside My World (Ode to Functor and Monad) and “IO Monad” Considered Harmful!

## Recent Entries

• ### Blog Rewrite with Hakyll and Purescript

It’s been almost a year since my last post! Things have been a bit hectic with research and related things, and with the unrelenting academia publishing cycle, any time I can get to write or explore has been a nice escape.

Admittedly, I’ve also run into some friction updating my blog because it was a compiled web server with some delicate dependencies and required environment configuration to build/deploy. It was written/built at a time when a lot of the infrastructure we have now in the Haskell ecosystem either wasn’t there, or wasn’t mature. We didn’t have easy Heroku deployment, and we didn’t have great tools like stack to let us create reproducible builds. One of my first posts in 2013 was actually about hoops to jump through just to get a simple Heroku deployment. I’ve had to maintain a virtual machine just to compile and push changes!

My blog was one of my first Haskell projects ever, and if I had started it now, in 2016, things would definitely be a bit different. By this point, it’s been long enough and the slight inconveniences have been building up enough that I thought it’d be time to sit down and finally migrate my “first large-ish Haskell project” and bring it into modern times, by using hakyll and purescript. Here are my thoughts and observations on how the migration went, with insight on Haskell migrations in general!

My blog engine is open-source, and the source for this specific instance is up on github, for those interesting in checking it out!

• ### Introducing the “Prompt” library

Prompt: README / hackage / github

Have you ever wanted to specify a computation involving some limited form of IO — like querying a database, or asking stdio — but didn’t want a computation in the `IO` monad, opening the entire can of worms that is arbitrary `IO`? Have you ever looked at complicated `IO a` you wrote last week at 4am and prayed that it didn’t launch missiles if you decided to execute it? Do you want to be able to run an effectful computation and explicitly say what IO it can or cannot do?

Introducing the prompt library! It’s a small little lightweight library that allows you to specify and describe computations involving forms of effects where you “ask” with a value and receive a value in return (such as a database query, etc.), but not ever care about how the effects are fulfilled — freeing you from working directly with IO.

``````data Foo = Foo { fooBar :: String
, fooBaz :: Int
} deriving Show

promptFoo :: Prompt String String Foo
promptFoo = Foo
<\$> prompt "bar"
<*> fmap length (prompt "baz")``````
• ### mtl is Not a Monad Transformer Library

mtl is not a monad transformer library — contrary to popular conception. I believe that this commonly spread myth is due in part to some rather peculiar branding choices (the name of the library) and in part to some historical accidents (mtl was, in the distant and pre-historic past, indeed a monad transformer library).

What is mtl? It is a library of interfaces you can provide to your own types, in the form of typeclasses. It abstracts over different design patterns for different types, in the form of typeclasses. Just like Functor abstracts over “things that can be fmapped”. mtl provides typeclasses abstracting over many useful patterns that many types satisfy — patterns involving different sorts of “effects”.

• ### Fixed-Length Vector Types in Haskell, 2015

Fixed-length vector types (vector types that indicate the length of the vector in the type itself) are one of the more straightforward applications of the “super-Haskell” GHC type extensions. There’s a lot of magic you can do with GHC’s advanced type mechanisms, but I think fixed length vectors are a good first step to beginning to understand several extensions, including (potentially):

• ConstraintKinds
• DataKinds
• KindSignatures
• TypeFamilies
• TypeOperators

And using type system plugins. (And of course the usual `UndecidableInstances` etc.) We’ll be discussing two different ways to implement this — using type-level nats, and using the GHC.TypeLits model to actually be able to use numeric literals in your types. These things are seen in the wild like with the popular linear package’s `V` type.

There are a few great tutorials/writeups on this topic, but many of them are from the time before we had some of these extensions, or only discuss a few. I hope to provide a nice comprehensive look about the tools available today to really approach this topic. That being said, I am no expert myself, so I would appreciate any tips/edits/suggestions for things that I’ve missed or done not-the-best :) This post has a lot of open questions that I’m sure people who know more about this than me can answer.

• ### Unique sample drawing & searches with List and StateT — “Send more money”

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!

• ### Auto: A Todo GUI application with Auto (on GHCJS, etc.)

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!)

• ### Auto: Building a Declarative Chatbot with Implicit Serialization

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!

• ### Introducing: the Auto library!

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?