Skip to main content


This is Derek Lam's personal site.
Let's get personal.
Scroll, I'll tell you a bit about myself.
Or just enjoy the Shard demo shown above

Spending time

There isn't much about any circuit that is uninteresting to me, so I took up work as a device engineer at Microchip's FPGA division designing next-generation non-volatile memories.

On my own, I develop Haskell program analysis tools. If you're interested, feel free to look through this symbolic execution engine and typesafe random program generator for Haskell.

Projects on this site

Presence Elsewhere

<my name>
everything here, but smaller

Recent Work

All Projects

Recent Projects

  • Feb 2022

    Drag-sensitive Sequential Wave Imprinting Machines - 23rd annual WaterHCI DECONference

      I had the chance to put together something small and interesting for WaterHCI DECONference, a conference all about water and electronics, centering especially around AR/VR tech that elevate the underwater experience as opposed to becoming a sopping-wet Oculus-brand paperweight.

      Flashback to a couple months earlier, where I threw together a small visualizer for motor waveforms to test out a 3-phase commutation algorithm for a reaction wheel. This visualizer was near and dear to my heart, based on the motor Sequential Wave Imprinting Machine (SWIM) out of MannLab that I had gotten to build on in some of my academic work. Given its lengthy name it can be explained in almost less space: just a light, modulated by the voltage or current energizing the motor. The light spins with the motor, and since over short times the motor waveforms are steady, your eye sees a stationary radial wave showing the motor's performance against true angle, and how it is affected by its environment.

    • Jan 2022

      XKCD's phrase-to-units at high m·s-1

        In the previous installment of bastardizing the English language fun wordplay with Randall, we made a sentence-to-map-directions solver based on XKCD 2260. This time, we're in for something a little more scientific: a sentence-to-units solver based on the recent XKCD 2312. This time with unit symbols, we've got much smaller puzzle pieces to pack into phrases than we used to with towns, so we can aim for exact solutions. It turns out that people have made a lot of units, sometimes very weird ones, so we also shouldn't have much trouble getting at least the matching done.

        The real fun question is how to do good matching. Undoubtedly, the best solution is short and sweet, one that can take some crazy complicated rap and find that it's got units of flow [m3/s]. These units we give names to are generally simple in base unit terms, so a good proxy for an elegant algorithm is one that makes small base-unit terms.

      • Jun 2021

        Home is where the heart is. But is it Hart, Maryland, USA or Hart, Bayburt, Turkey? (XKCD 2480)

          XKCD 2480

          XKCD 2480, "No, the Other One". © Randall Monroe, 2021

        • Jul 2020

          A basic acrobatic tail - Process


            Last summer, I worked at MannLab: a University of Toronto lab in wearable technology, signal processing and media headed by Prof. Steve Mann. Since Prof. Mann was a very early and arguably pioneering proponent of the maker movement, the lab and lab work was almost entirely done with a solder iron in hand. This environment attracted some exceptional builders to work full-time at the lab, pumping out prototypes and spanning really all manners of hand manufacturing.

          • Jul 2020

            A basic acrobatic tail — Control and mechanics

              I've been working on a 3-DOF arm for the last few months to use as a robotic tail. I was initially going to have it completed for Tomorrowland 2020 in mid-July, but when that was cancelled, the parts were already on the way here so I got it functional anyways and thought the design was worth sharing. It's no hyper-redundant manipulator (yet), but it's perfect for a cheap, strong and forgiving hand-build. See below for a preliminary demo:

            • Jul 2020

              A basic acrobatic tail - Electronics

                Compared to the control and mechanical build, the electronics are straightforward enough. To put the simplicity of the circuitry in perspective, it would be trivial to pull out the main controller and hook everything into a radio receiver. Only lights and the safety control loop would be cut out of that design.

                Therefore, the only peripherals excluding the PWM for the actuators are the lights (an I2C line into a charlieplex driver and array) and an SPI line for servo monitoring, which will be described shortly.

              • Jul 2020

                A basic 3DOF acrobatic tail — Build overview

                  The mechanical build of this tail was designed so that the hand drill I had access to would be the only power tool, along with 3D-printed motor holders from Treatstock. I'm no machinist, whatsoever. If you have the budget, the design is pretty accessible!

                  The build for this tail prototype could be broken into a few distinct stages:

                • Jun 2020

                  XKCD's Reaction Maps with n-gram matching

                    I got a good laugh out of this recent XKCD strip, partly because I love puns, and partly because it's pretty hypocritical for Cueball to express his disdain for a one with 9 more:

                    XKCD 2260

                  • Dec 2018

                    Linear Tubular Motors

                      Research on the efficiency and positioning abilities of these types of linear motors for the Extended Essay in Physics.

                    • Nov 2018

                      Procedural roadmap generation & SAE AutoDrive 2018 Competition Shirt

                      As part of victory spoils, UofT's success in 2017 came with control over the competition shirt. I volunteered and inherited the responsibility, then promptly hot-potato'd it onto my computer to make most of the visually-interesting material. This emphasis on form was spurred by constraints on the color palette when only two tones are possible on top of the shirt's base color. In a similar vein but somewhat more timid on my processor than the goliath that is actual localization and mapping on Zeus, I built a simple tile-based procedural roadmap generator for an ornamental border, which I relate to ornamental vines on medieval texts. And OpenTTD.

                    All Writing


                    1. XKCD 2585 Implemented: Round the world ⏹ ⏺

                      © Randall Monroe, 2022

                    2. Using lambda term statistics to show how hard we try to declutter programs

                      There are a couple of [a]symmetries in programming that really grip me, lifting my hands off the keyboard and pushing me deep into a mind vortex for some time. I'm especially entranced by the flows of control, data and abstraction it seems. When arguments and returns are treated differently (in a symmetry sense I mean... outside of the fact that they're polar opposites), my evening plans start clearing out. Some examples uphold this ying-yang but in an initially unintuitive way, like co- and contravariance of subtyping rules. Sometimes a dichotomy should be symmtric but is skewed by the forces of developer experience, like the gaping divide in popularity between ReactiveX and InteractiveX. Recently, I've come across another asymmetry of this sort that I thought was interesting enough to study a bit.

                    3. Condensed Asterius quickstart

                      Here's an Asterius quickstart that aims to be a little more make-it-work-oriented than the official docs.


                    4. deepseq for Data

                      Here's a very short but useful snippet I recently started using to force Data instances deeply:

                      {-# LANGUAGE Rank2Types #-}
                      import Data.Functor.Identity
                      import Data.Generics ( Data(..), GenericT )
                      gmapT' :: GenericT -> GenericT
                      gmapT' f x0 = runIdentity (gfoldl k Identity x0)
                          k :: Data d => Identity (d->b) -> d -> Identity b
                          k (Identity c) x = Identity $! c $! f x -- let the user control strictness in `f`
                      strictify :: GenericT
                      strictify = gmapT' strictify
                    5. Reified types in Hack

                      Hack is beginning to support reified types in their latest 4.17 release, which adds a very interesting dimension to Hack's type system. Its interactions with Hack's unique medley of type features can be quite subtle, and when any new type feature emerges, I always like to learn how and where it interacts with other features. To be more specific, I like to find this out by trying to break the new type system. So let's try together!

                    6. Simplifying reactive operators

                      I've argued that I have reason to believe that ReactiveX (Rx) is backwards. At first I promoted InteractiveX (Ix), which inverts the control, swapping callbacks for await. If you follow the road of trying to simplify Ix and its iterator acrobatics, I believe you'll arrive where I was, reimplementing Reagent. Originally built to shim all of JVM/JS's reactive interfaces into Kotlin's concurrency framework, the result ends up suiting async-await languages better than both Rx and Ix. For many details, see "Reagent is theoretically the best…", but in short, Reagent approaches an exact equivalence to natural code — an isomorphism to what you would write in that situation without the library. In particular, Reagent provides expressive and natural features to implement all aspects of an asynchronous loop to chomp away at a data source.

                    7. Reagent is theoretically the best of ReactiveX

                      This extended article discusses the merits of Jake Wharton's Reagent framework for Kotlin which has deep theoretical advantages standing in for ReactiveX. I've stripped away any class definitions to make a lightweight functional version that I'll derive and justify from first principles here, with implementations for Hacklang, Javascript and Kotlin. Jake Wharton has put the project on hiatus, and while I agree that it's hard to fight the massive mindshare of ReactiveX, Reagent is at least a powerful lens to the semantics of streaming and the minimum that we require of our languages to make them reactive. At least I hope to convey that if one feels ReactiveX is wasteful on top of an async-await language, their feeling isn't wrong.

                      The maximum is in the middle

                    8. Tracing values with state

                      The development of ra.hs has called for an interesting task in the domain of symbolic programming. ra.hs is a Haskell linter for reactive programs, the first implementation I'm undertaking to identify possible race conditions in reactive code. The violation to look for is a subtle one: if two threads consume the same stream and read and write these values to the same shared memory, the ordering rules of the stream might be violated [citation to come]. To decide this, it's necessary to trace the flow of values through the program to see which stream they come from, if any.

                      The degree of sophistication of analysis against the program could be incredibly varied, bounded above only by the undecideability of the halting problem (fun fact: with probability 1, halting can actually be decided). I believe that it's meaningfully bounded below by a type analysis, where the conditional nature of branches is ignored and all values that are the correct type that could flow to a call site are considered. This allows for a perfectly sensitive result that sacrifices specificity (i.e. it may report many false positives).

                    9. Guide to InteractiveX in Kotlin

                      I was just peeking at Kotlin to see if they supported asynchronous generators. I wasn't expecting much, because when I was making InteractiveX implementations for PHP and Hack last year, Kotlin coroutines weren't publicly documented. Man, I got way more than I bargained for. I knew even just looking at this title to this guide in kotlinx.coroutines:

                      Guide to reactive streams with coroutines

                    10. How to make a ReactiveX

                      I was tipped off to Reactive Frameworks from @Robert Harvey on a long-winded StackExchange question of mine for what "reactive databases" were called. I was infatuated with Hack's elegant async API and let me tell you it absolutely expanded my world in all the right ways.