in Code


Justin Le

Welcome! My name is Justin Le. I’m a final-year undergraduate student at University of California, San Diego, studying Computational Physics and Computer Science.

This is just my weblog covering my various adventures in programming and explorations in the vast worlds of computation, physics, 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 article: The Compriseless Reconciliation of Purity and I/O!

Recent Entries

  • Streaming Huffman Compression in Haskell (Part 2: Binary and Searches)

    Continuing on this series of beginner/intermediate projects for newer Haskell users, let’s look back at our Huffman encoding project.

    In our last post we went over two types of binary trees implemented as algebraic data structures in Haskell, and also a scheme for assembling a Huffman encoding tree using the State monad.

    Now let’s look at serializing and unserializing our prefix trees for easy storage, and then at actually using them to encode and decode!

    Read more … Comments

  • A (Dead End?) Arrowized Dataflow Parallelism Interface Attempt

    So I’ve been having several ‘dead end’ projects in Haskell recently that I’ve sort of just scrapped and move from, but I decided that it might be nice to document some of them :) For reading back on it later, for people to possibly help/offer suggestions, for people to peruse and possibly learn something, or for people to laugh at me. Here is my most recent semi-failure — implicit dataflow parallelism through an Arrow interface.

    tl;dr:

    1. Compose parallelizable computations using expressive proc notation.
    2. Consolidate and join forks to maintain maximum parallelization.
    3. All data dependencies implicit; allows for nice succinct direct translations of normal functions.
    4. All “parallelizable” functions can also trivially be typechecked and run as normal functions, due to arrow polymorphism.

    The main problem:

    • Consider ParArrow a c, ParArrow b d, ParArrow (c,d) (e,f), ParArrow e g, and ParArrow f h. We execute the first two in parallel, apply the third, and execute the second two in parallel. Basically, we want two independent ParArrow a g and ParArrow c h that we can fork. And this is possible, as long as the “middle” arrow does not “cross-talk” — that is, it can’t be something like arr (\(x,y) -> (y,x)).

    Read more … Comments

  • Streaming Huffman Compression in Haskell (Part 1: Trees and State)

    So you’re learning Haskell and are looking for some projects that aren’t super trivial, are familiar enough that you can use what you already know, and are difficult enough to maybe help you learn new things. Hey, maybe this is for you :)

    Let’s take a go at Huffman encoding in Haskell. We will look at two types of binary trees, which we use to implement immutable/persistent priority queues and prefix trees. We’ll play around with the State monad a bit, explore some useful typeclasses, learn how to serialize, marshal, and unmarshal data structures using the binary library, and also look at how to load data from a file and write to another in a pure way, avoiding lazy IO using the ever-more-popular pipes library. And hopefully we learn some neat Haskell idioms!

    We’re going to be assuming some basic Haskell knowledge, like algebraic data types, higher order functions, basic monad usage, and some basic familiarity with the functions in Prelude/base, the standard library. If you have any questions, feel free to leave a comment, drop by on #haskell on freenode, throw me a tweet, or give the great Learn You A Haskell a quick read!

    Read more … Comments

  • Intro to Machines & Arrows (Part 1: Stream and Auto)

    So I’m going to be running a series soon on computation and (physical) simulations using AFRP (Arrowized Functional Reactive Programming) principles.

    I consider (A)FRP to actually be a pretty game changing paradigm. It provides us with semantics by which to compose and build time-varying, reactive behaviors and completely changes the way we approach any sort of simulation/state-like project.

    AFRP has its own elegant way of approaching problems, but to be able to properly use it for simulations, we’re going to have to start by learning about the fundamental abstraction behind its implementation: machines.1

    (This post will assume a somewhat basic knowledge of Haskell. I’ll try explaining concepts here and there if I feel that they might not be very commonly known. But if you have any questions, feel free to leave a comment or stop by freenode’s #haskell on irc!)

    (A short disclaimer: this article has not too much to do with the great machines library by Rúnar Bjarnason and Edward Kmett)


    1. It is somewhat important to note here that the semantics of FRP do not inherently involve machines. We’ll learn more about this later. For now, remember that this series will chiefly study the low-level implementation of AFRP, which may or may not be related to the semantics/abstractions of FRP — in an ideal world we wouldn’t even have to worry about implementation and just work on the level of the abstractions. Unfortunately, we don’t live in an ideal world :(

    Read more … Comments

  • Blog engine updates: Markdown Preprocessor & Fay Scripts

    I spent some time over the past week writing a preprocessor for the entry copy markdowns and getting Fay to deploy some simple scripts.

    The need for a preprocessor was sparked by a post I’m writing that sort of necessitated the features. I write all of my posts in markdown, and it all integrated well with the preprocessor. In addition I needed some javascript scripting to make the preprocessor actions worthwhile, so I buckled down and wrestled with getting Fay to work in a production environment. So I guess this post is to show off some new features of the blog engine?

    Read more … Comments

  • Code 2013

    It’s a bit late, but, inspired by my own admittedly egregious tweet in participation of the awesome #code2013 hashtag, here is a review of 2013 in terms of the programming languages I’ve worked on and a general wrap-up of the adventures that 2013 had to offer me. It was quite surely the most productive/adventurous year of programming of my entire life.

    Read more … Comments

  • Wolf, Goat, Cabbage: The List MonadPlus & Logic Problems

    Today we’re going to learn to solve the classic and ageless logic problems without any data structures besides List’s monadic properties as a MonadPlus!

    We are going to be solving this old-as-time logic puzzle, which Wikipedia claims dates back to the 9th century:

    A farmer has a wolf, a goat, and a cabbage that he wishes to transport across a river. Unfortunately, his boat can carry only one thing at a time with him. He can’t leave the wolf alone with the goat, or the wolf will eat the goat. He can’t leave the goat alone with the cabbage, or the goat will eat the cabbage. How can he properly transport his belongings to the other side one at a time, without any disasters?

    We’re going to assume a somewhat basic familiarity with functional programming concepts and a basic understanding of monads (if you don’t know that much, check out adit’s great concice guide). If you aren’t familiar with MonadPlus/Alternative (and how they work as monads) check out Part 1 and Part 2, which should provide all the background and most of the syntax. Most Haskell syntax is either be explained here as we get to it or in the previous parts. Still, if you have any questions, feel free to leave a comment, give Learn You A Haskell a quick read, or stop by freenode’s friendly #haskell!

    Read more … Comments

  • The List MonadPlus — Practical Fun with Monads (Part 2 of 3)

    Part two of an exploration of a very useful design pattern in Haskell known as MonadPlus, a part of an effort to make “practical” monads less of a mystery and fun to the good peoples of this earth.

    When we last left off on the MonadPlus introduction, we understood that there are times when you want to chain functions on objects in a way that “resembles” a failure/success process. We did this by exploring the most simple of all MonadPlus’s: a simple “dumb” container for a value is either in a success or a failure. We looked at how the MonadPlus design pattern really “behaved”.

    This time we’re going to look at another MonadPlus — the List. By the end of this series we’re going to be using nothing but the list’s MonadPlus properties to solve this classic logic problem:

    A farmer has a wolf, a goat, and a cabbage that he wishes to transport across a river. Unfortunately, his boat can carry only one thing at a time with him. He can’t leave the wolf alone with the goat, or the wolf will eat the goat. He can’t leave the goat alone with the cabbage, or the goat will eat the cabbage. How can he properly transport his belongings to the other side one at a time, without any disasters?

    Let’s get to it!

    Read more … Comments