Interactive counter — view on the website

The thing is, adding these "islands" of interactivity to an otherwise static site is still annoyingly difficult today. So I set off on a journey to explore how to add interactive content to this site while maintaining a simple authoring experience, a code base and pipelines that I can understand, and a minimal set of rock solid dependencies.

Granted, frameworks like Astro are built for this; I didn't have the appetite for a full site migration off of Next.js.

Enter MDX?

MDX is billed as "Markdown for the component era." It allows you to write Markdown files, sprinkle in imported components, and export metadata. This sounds great! If I have a Markdown file, I could write something like this:

---
title: 'Hello, MDX!'
---

import Counter from './components/Counter'

blah blah interesting prose

<Counter />

blah blah more interesting prose

With Next's app routing and the new-ish @next/mdx package, this seemed like a great opportunity to use a first-party framework package to introduce some nice new features to the blog. In practice, I ran into several issues.

Obstacle 1: Dynamic routes to MDX pages

My site is configured to render each post at a dynamic URL based on its ID. If you hit /p/[id], and a matching file exists, you get the page. If you enter some other unknown slug, you get a 404 error. This is important to me, as it allows me to create a new page by dropping in a single markdown file. (While you can't avoid markup, my goal is minimal overhead.)

It turns out that Turbopack can't handle this with MDX files. While the site is primarily statically built, that build still happens in two phases:

1. Turbopack detects and bundles all routes.
2. Next.js runs those bundles to create server-rendered static builds.

MDX support comes in only in the second phase, so the first phase fails. The workaround is to add a build step to convert the MDX files to TSX beforehand. That's doable, but it increases the complexity of the build process. The dev server also requires a separate file watcher to run that build step outside of next dev, introducing further complexity.

Instead of adding a build step, I sidestepped the issue by reading the MDX files from the filesystem and evaluating them semi-manually with @mdx-js/mdx and @mdx-js/mdx-react. (These files are trusted content written by yours truly, so evaluating them does not pose a security risk.) This ends up using React's renderToStaticMarkup under the hood. A similar process is also used for the index page's list of posts and the site's new RSS feed.

Obstacle 2: Excluding Islands from the RSS feed

As part of my desire to Publish on my Own Site, Syndicate Elsewhere (POSSE), I added an RSS feed to my site. RSS feeds use XML, which looks a lot like HTML but has a few different behaviors. One major limitation is that you can't use JavaScript and CSS. That means no interactive widgets in the RSS feed. That left me with two options: include only the descriptions of posts in the feed, or find a way to replace any interactive islands with fallback content. Since including the full text is best practice, that was my preference.

For a while, I explored whether we could have components that rendered their own fallback content. However, I hit a bigger obstacle: any attempt to import the island components failed. Islands are inherently client-side components. Take the Counter for example:

'use client'

import { useState } from 'react'
import Island from './island'

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <p>
      Count: <strong>{count}</strong>
    </p>
    <button onClick={() => setCount((c) => c + 1)}>Increment</button>
  )
}

'use client' tells Next that this component has to be rendered on the client. It cannot be statically rendered on the server. And yet, renderToStaticMarkup is inherently a server-side rendering environment. Any attempt to import Counter will fail with a loud error message. Including <noscript> content doesn't matter if the server will never get to render it.

I still ended up using fallback content within the islands anyways, for when folks visit the live site with JavaScript disabled.

Obstacle 3: Rendering Islands from the Server

This same renderToStaticMarkup limitation actually affected the live pages, too. Because I was rendering MDX files manually in my dynamic route, even the live website was generating build-time errors when including client-side components. The solution to both issues: ditch the direct imports and maintain a mapping of components to use during evaluation.

Here's what the mapping code looks like today:

import { compiler } from 'markdown-to-jsx'
import { ComponentType, createElement } from 'react'
import Counter from './islands/counter'

type IslandName = 'Counter'
type IslandMap = Record<IslandName, ComponentType>

const liveIslands: IslandMap = { Counter }
const rssIslands: IslandMap = {
  Counter: () => (
    <p>
      <em>Interactive counter — view on the website</em>
    </p>
  ),
}

export default function NextMarkdown({
  children,
  rss = false,
}: {
  children: string
  rss?: boolean
}) {
  return (
    <>
      {compiler(children, {
        createElement,
        wrapper: null,
        overrides: rss ? rssIslands : liveIslands,
      })}
    </>
  )
}

This adds overhead when adding an island to a post. Instead of importing directly into my blog post file, I need to separately add the component to the mappings. I spent a long time looking for alternatives here. The only other viable approach was to use script tags to hand off islands using vanilla JS. That seemed significantly worse from a developer experience perspective, although it may come in handy for non-React islands in the future.

In the end, maintaining the maps is overhead that I can tolerate. After all, I don't use interactive islands very often, and when I do I need to define RSS fallback content anyways. Maintaining a live map and RSS map in the same file is not so bad.

What has MDX ever done for me?

At this point, everything was working. I could write posts in single files like I did before, and adding interactive widgets had only a small amount of overhead. The pipelines for the live posts, home page listing, and RSS feed were very similar and maintainable.

Then I realized MDX wasn't helping with any of it.

Without imports in the files, all I had was plain old Markdown with a worse metadata syntax!

export const metadata = {
title: 'Hello, MDX!'
}

blah blah interesting prose

<Counter />

blah blah more interesting prose

Rolling back to roll forward

In the end, I (asked Claude to) roll back all of the posts to their previous format. I kept the new pipelines and component maps, using markdown-to-jsx and graymatter to extract the content instead of @mdx-js/mdx. It's a bit anticlimactic, but in the end it's still fewer dependencies.

This was definitely an interesting exploration, and I learned a lot more detail about Next, Turbopack, and server-side component rendering. Having been in the Angular world at work for some time, it was a good refresher. It does leave me feeling like the ideal solution is still out there somewhere. (Or maybe, it's just Astro after all.)

I have been thinking a lot about AI-driven software development workflows lately, what bottlenecks they address and what bottlenecks they don't. I use Claude constantly throughout my day, and it has changed how I work as an Engineering Manager. Claude helps me review product specs, brainstorm team strategy, and understand our team's spend over time. And when I do get time to code, it looks very different in 2026 compared to 2016. Unrecognizably different! And yet, I still do my best work when I limit myself to one in-progress task at a time.

Coding Today Has New Wait Times

When I sit down to code today, I usually have both Claude Code and VS Code open. Six months ago, I would largely be working in VS Code, identifying next steps and shooting off small tasks to Claude to implement. It was an accelerant to typing the code I could already envision. Recently, models and tooling have gotten increasingly more powerful, and I have been using Claude to drive more of the exploration and planning process, much like I would with a junior engineer. Checking in, tweaking plans, raising additional concerns, and eventually approving the plan. After approval, Claude goes off and implements it step by step. Afterwards, I walk through reviewing the changes until I understand them thoroughly. Oftentimes, I'll be making other edits here and there (e.g. fewer mutations, more functional style) until I feel confident taking ownership over the code. Push a branch, write a PR description (still by hand today!), and we're good to go. This process works amazingly well for me today, and I'm routinely impressed by how well Claude explores, identifies key concerns, and plans the task, especially with the latest Opus model.

In this post, I primarily mention Claude and Claude Code. You can substitute these for the models and tools of your choice. I'm most familiar with Claude and don't want to clutter this post by repeatedly saying "...and other tools."

This process, though, does break up what used to be a single session of deep focus with a few wait times. Depending on the complexity of the task, the initial exploration and implementation times can each take minutes. And if either needs to be iterated significantly, that adds additional waits. These wait times are killer for productivity—UX studies have shown time and again how delays in response times can cause humans to drop off from tasks. For a deeper dive into this, check out the science behind Core Web Vitals.

OK, so we multitask?

My first response to this wait time was to multitask. If Claude is doing a lot of this work autonomously, I could use the wait times to kick off more Claude Code agents, and then review them one by one as they are ready. Spin up some git worktrees so they don't conflict, and suddenly you're the 10x rock star you always dreamed of.

The issue is that you're still context switching across all of these tasks. The more related the tasks are, the more likely they are to legitimately conflict. And the less related they are, the more context switching you need to do to hop between them. That's very draining! And for me, it started leading to one of these results:

1. Pure exhaustion and zero joy. Suddenly in addition to my regular set of interruptions throughout the day, coding was also an endless game of whack-a-mole.
2. Don't try to grok all of the context for each task, and trust Claude more on the results. This undermined my feeling of ownership over the code, and resulted in more bugs escaping, higher maintenance burden, and less understanding.
3. Don't try to continue each task immediately. This creates the liability of work in progress: the task sits delivering zero user value, accumulating merge conflicts, context decay, and integration risk. Claude only reduced the sunk cost in creating it.

It's possible that everybody has a different level of multitasking that feels natural to them. For me, I was learning it was one task at a time.

Hold the context, embrace the wait

In my role, I do have much less focus time than an individual contributor—escalations of urgent questions or bug reports, questions for our team from across the org, and of course meetings. It used to be very hard to find focus time around these. AI agents do help with this, as I can pause and resume them as needed or let them work asynchronously while I'm on a call. In these cases, the wait time is a feature.

But when I do have focus time? What I've actually found gets me the best results is to...just wait. Grab a coffee, stretch, listen to music. I don't pay the cost of context switching, and I still get more, higher quality coding done than I did before. I still feel strong ownership over the results, and the joy of having built something. And at the end of the day, I feel satisfied, not stressed.

My org adopted AI tools across Engineering, Product, and Design. One of our teams had each engineer ship a full service, end-to-end, in a single week. Everyone's faster. So why aren't we shipping more of the right things?

One idea to address this that has been gaining mindshare in our org is an AI-driven Development Lifecycle (AI-DLC). It was introduced by a solutions architect at AWS and promises to rebuild the software development process from the ground up for the age of AI agents. But when reading about AI-DLC, something didn't resonate with me. It doesn't address the real bottlenecks that our team is facing today, despite everybody across Engineering, Product, and Design using AI tools daily.

The Premise

The AI-DLC narrative typically follows a pattern: teams adopt AI tools, developers go dramatically faster at writing code, they find themselves idle waiting for direction, and so the process expands to let developers drive more of the lifecycle end-to-end with minimal product intent. It's pitched as a necessary reimagining of our software development process from first principles, to unlock the full potential of AI agents. "We need automobiles and not the faster horse chariots." Ditch the old methods, which have "product owners, developers, and architects spending most of their time on...SDLC rituals."

Now, I am all for first principles thinking here. But every meaningful change in how we build software has been an evolution, even from waterfall to agile principles. "You can't retrofit current processes because AI changed the world" is a thought-terminating cliché. It prevents meaningful inspection of the real bottlenecks in how we develop software today, and it's a recipe for unlearning past lessons. In the end, all software goes through the basic steps of Scope -> Build -> Ship at some level. That's a real foundation we can build on.

And I definitely need to call this out: if you as a software engineer are spending most of your time in SDLC rituals, something is deeply wrong! The majority of your day should include focus time for deep work. If AWS is solving for that as part of the AI-DLC, it's possible that any process reset would be a beneficial excuse to wipe the meeting load and start fresh. (Hey, maybe try Kanban!)

Where is the bottleneck?

So let's go ahead and use first principles, but also look at our processes today and find the real bottlenecks. Can we adapt our current Scope -> Build -> Ship cycles to fit the age of AI?

We can definitely generate code faster today. Let's assume for now that this code is all the same high-quality, well-understood, maintainable code that we'd get using traditional methods. (The jury is out on that; topic for another post.) To move faster, we want to pull more implementation-ready ideas into developers' hands. For my team, that's where we are currently running dry. AI-DLC responds to this by loosening the definition of implementation-ready: give developers intents rather than fully scoped specs.

But did we ask why that source is drying up? Product and Design are also using AI tools every day. Why is that not resulting in more scoped ideas for development? On our team, it's not because Product and Design are failing to move quickly. Just like developers, Product and Design have access to a sliding scale of speed vs quality when using AI assistance. So far, we've seen outputs that are faster and higher quality. I believe the bottleneck is further upstream. Now that code is fast, that upstream constraint is suddenly visible.

The Bottlenecks are Still Human

If Engineering, Product, and Design are all using AI tools to compress our cycle time, the bottlenecks shift to the inherently asynchronous, human-heavy parts of the process: user understanding, user validation, and stakeholder alignment. Together, these processes help to ensure the team is building the right thing (for the user, for the company). And yet, these are the hardest to speed up because they depend on external feedback loops and human judgement. AI-DLC attempts to address this through Mob Elaboration, but this runs into challenges. Let's look at each one and how we might solve it.

A Pipeline for Proactive User Understanding

AI-DLC relies on Mob Elaboration to make quick decisions in real time. What happens if you need additional user discovery? Traditionally, Product would take that question, go off and do some discovery, and come back with an answer later. If this is going to happen in real time, there needs to be a ready repository of user insights. A continuous background process can support this through, e.g., regular user interviews, support ticket analysis, tools like Productboard. When it's time to build, you pull from this pool first rather than starting research from scratch.

However, there will still be times when the answer is not readily available. At that point, you're left with a choice between making an uninformed decision in the moment or delaying the work. Since cycle times are very low, the cost of the uninformed decision may not be so high. (That's one reason why Scrum uses timeboxes, after all.) The specifics of that tradeoff will vary from company to company and product to product.

If user understanding and discovery is difficult, the risk is that teams will bias towards work that requires little discovery, like bug fixes or performance optimizations. Your team will feel very productive while delivering less overall value.

Decouple Validation Choices

After shipping something, how do you validate whether it's delivering on its goals? AI-DLC doesn't address this. Validated learning takes time to collect, as real users interact with the product. This doesn't need to run at the same speed as the development cycle. A feature can ship on Monday, another on Tuesday, and validation results from last week's feature come back on Thursday (and feed into the insight reservoir). The build cycle is daily but the learn cycle might be weekly. That's OK, as long as it's actually happening and feeding back in.

If we're not routinely validating what we build with real users, we risk building the wrong things; we ship a lot of features that nobody uses.

Lightweight Stakeholder Alignment

Smaller batch sizes should make stakeholder alignment faster and easier; there's less to disagree about when each unit of work is small. However, without a regular inspection point, ten individually reasonable daily decisions can add up to strategic drift that nobody intended. AI-DLC doesn't address where the "intents" are coming from either, so presumably there is still some cadence for gathering those from stakeholders. It's almost certainly not daily (there's too much cross-functional collaboration needed), but maybe weekly or biweekly.

Evolution, Not Revolution

If we take this all into account, what are we left with?

• Daily cycle: Scope -> Build -> Ship, agent-heavy execution on well-understood work drawn from a prioritized backlog.
• Continuous discovery: User research pipeline feeding an insight reservoir. Human-driven, async, running on its own natural cadence.
• Weekly cadence: Direction check and validation review, feeding learnings back into the reservoir and adjusting priorities.

The process overall has recognizable components of Scrum (a weekly inspect-and-adapt loop), Kanban (a focus on flow and limiting work in progress), and Lean Startup (validated learning) methodologies. This makes sense: those processes arrived at their structures by solving fundamental coordination problems under uncertainty. AI didn't eliminate those problems.

Instead of throwing out the old, if we want to squeeze the most productivity out of our new AI colleagues, we need to drill down to the true bottlenecks. That might mean focusing on a support system for the human-oriented, naturally asynchronous parts of the system today.

A Custom Ordering

The challenge today is largely to define a custom ordering for a recursive Packet data type. Our Packet data type captures the shape:

data Packet = Leaf Int | ListOf [Packet] deriving (Show, Eq)

parsePacket :: GenParser Char u Packet
parsePacket = try parseLeaf <|> parseList
  where
    parseLeaf = Leaf <$> parseInt
    parseList = between (char '[') (char ']') $ do
      packets <- sepBy parsePacket (char ',')
      return $ ListOf packets

To define the ordering of Packets, we instanciate an Ord class for the type. The minimal definition is a compare function which can take 2 Packets and return LT, EQ, or GT. The code follows the problem description closely:

instance Ord Packet where
  compare :: Packet -> Packet -> Ordering
  compare (Leaf a) (Leaf b) = compare a b
  compare (Leaf a) bs = compare (ListOf [Leaf a]) bs
  compare as (Leaf b) = compare as (ListOf [Leaf b])
  compare (ListOf []) (ListOf []) = EQ
  compare (ListOf []) (ListOf _) = LT
  compare (ListOf _) (ListOf []) = GT
  compare (ListOf (a : as)) (ListOf (b : bs)) = case compare a b of
    EQ -> compare (ListOf as) (ListOf bs)
    x -> x

Instance Signature?

Now, the code for our Ord instance is actually not valid Haskell! Instance declarations are not allowed to have type signatures in them. That's the line with compare :: Package -> Packet -> Ordering. The instance should be able to infer all of this information.

However, sometimes providing the type signature is useful, especially for novices like me! It's possible to enable this via the {-# LANGUAGE InstanceSigs #-} language extension.

By putting such a language extension pragma at the top of the file, we ask the compiler to enable additional language features. In this case it's a simple and safe rule, but extensions can get pretty complex!

Part 1 - Parsing the List of Pairs

In Part 1, we want to process each pair of Packets together, and then count whether they are in the correct order. To parse them together, I wrote a helper classlistToPair:

listToPair :: Show a => [a] -> (a, a)
listToPair [a, b] = (a, b)
listToPair l = error $ "listToPair: invalid input: " ++ show l

We first split the list into sub-lists containing two elements, then convert those sublists into tuples. Since the parsing returns an Either, we provide a default Leaf 0 fallback, although this should not be hit with our real input data.

input :: IO [(Packet, Packet)]
input =
  let rawPairs = splitOn [""] . lines <$> readDay 2022 13
   in fmap (listToPair . fmap (fromRight (Leaf 0) . parse parsePacket "")) <$> rawPairs

Now that we have our list of pairs, we can find our answer to Part 1. If we were going to count the correctly ordered pairs, we could apply our compare function, filter out any incorrectly ordered pairs, and then take the length of the remaining list:

countOrdered :: [(Packet, Packet)] -> Int
countOrdered =
  length
    . filter (== LT)
    . fmap (uncurry compare)

However, we need the index of the resulting pairs, so let's attach that to our items first. Then at the end, instead of counting, we will sum the index:

part1 :: [(Packet, Packet)] -> Int
part1 =
  sum
    . fmap fst
    . filter (\(_, o) -> o == LT)
    . fmap (fmap (uncurry compare))
    . zip [1 ..]

Part 2

For Part 2, we are asked to sort the full list of Packets, ignoring the pairings. Additionally, we will sort our two divider packets, [[2]] and [[6]]. With our Ord instance, sorting is as simple as passing the list of Packets to sort!

Rather than parse our input again, I opted to start with the list of pairs, flattening it back into a single list:

part2 :: [(Packet, Packet)] -> Int
part2 pairs = undefined -- TODO
  where
    dividers = [ListOf [ListOf [Leaf 2]], ListOf [ListOf [Leaf 6]]]
    sortedPackets = sort $ dividers ++ concatMap (\(a, b) -> [a, b]) pairs

Once we have our sorted list, we look for the indexes of our two dividers and multiply them together to get our final answer:

part2 :: [(Packet, Packet)] -> Int
part2 pairs = product $ (+ 1) <$> mapMaybe (`elemIndex` sortedPackets) dividers
  where
    dividers = [ListOf [ListOf [Leaf 2]], ListOf [ListOf [Leaf 6]]]
    sortedPackets = sort $ dividers ++ concatMap (\(a, b) -> [a, b]) pairs

Do you need to fully sort?

Instead of sorting the full list, we could take a more target approach to finding the indexes of our dividers. The index of an element is only dependent on how many Packets sort lower than it, not the internal ordering of those packets.

Sorting the list is O(n log n). Sometimes Haskell's laziness will allow us to skip some sorting in these cases. However, it must fully sort each item up until our dividers, so our Big O time is unchanged.

Counting how many Packets are less than a given divider is O(n), as it can be done in a single pass through the list. We have 2 dividers, adding a constant factor.

I didn't end up implementing this approach, but it should have faster runtime characteristics on large lists (which frankly, is not our input).

Full Code

{-# LANGUAGE InstanceSigs #-}

module AOC2022.Day13 (spec) where

import Data.Either
import Data.List (elemIndex, sort)
import Data.List.Split (splitOn)
import Data.Maybe (mapMaybe)
import Input
import Test.Hspec
import Text.ParserCombinators.Parsec

listToPair :: Show a => [a] -> (a, a)
listToPair [a, b] = (a, b)
listToPair l = error $ "listToPair: invalid input: " ++ show l

input :: IO [(Packet, Packet)]
input =
  let rawPairs = splitOn [""] . lines <$> readDay 2022 13
   in fmap (listToPair . fmap (fromRight (Leaf 0) . parse parsePacket "")) <$> rawPairs

data Packet = Leaf Int | ListOf [Packet] deriving (Show, Eq)

parsePacket :: GenParser Char u Packet
parsePacket = try parseLeaf <|> parseList
  where
    parseLeaf = Leaf <$> parseInt
    parseList = between (char '[') (char ']') $ do
      packets <- sepBy parsePacket (char ',')
      return $ ListOf packets

instance Ord Packet where
  compare :: Packet -> Packet -> Ordering
  compare (Leaf a) (Leaf b) = compare a b
  compare (Leaf a) bs = compare (ListOf [Leaf a]) bs
  compare as (Leaf b) = compare as (ListOf [Leaf b])
  compare (ListOf []) (ListOf []) = EQ
  compare (ListOf []) (ListOf _) = LT
  compare (ListOf _) (ListOf []) = GT
  compare (ListOf (a : as)) (ListOf (b : bs)) = case compare a b of
    EQ -> compare (ListOf as) (ListOf bs)
    x -> x

spec :: IO ()
spec = hspec $ do
  describe "Day 13" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        myInput <- input
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` 0 -- redacted

part1 :: [(Packet, Packet)] -> Int
part1 =
  sum
    . fmap fst
    . filter (\(_, o) -> o == LT)
    . fmap (fmap (uncurry compare))
    . zip [1 ..]

part2 :: [(Packet, Packet)] -> Int
part2 pairs = product $ (+ 1) <$> mapMaybe (`elemIndex` sortedPackets) dividers
  where
    dividers = [ListOf [ListOf [Leaf 2]], ListOf [ListOf [Leaf 6]]]
    sortedPackets = sort $ dividers ++ concatMap (\(a, b) -> [a, b]) pairs

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Previous: Day 12: Hill Climbing Algorithm

Dijkstra's in Haskell

Dijkstra's Algorithm is an algorithm for finding the shortest distance between any two points on a graph. I'm not going to explain it much here, as there are many better resources for that.

In implementing Dijkstra's, there are two pieces of state we care about: our queue of upcoming nodes to visit, and our set of nodes already visited (which we do not want to waste time revisting). With today's simple problem, I used a Sequence and a Set (Haskell's Set is tree-based). There are better data types for this! But these were simple and efficient enough.

Dijkstra's is a recursive function, so we can keep track of our state by passing it from one recursive call to the next. Here is the meat of the algorithm:

go :: Array (Int, Int) Char -> Set (Int, Int) -> Seq ((Int, Int), Int) -> Int
go g v q = case Seq.viewl q of
  (i, d) :< q' ->
    if i `elem` v
      then go g v q'
      else
        if i == goal g
          then d
          else go g (i `Set.insert` v) $ q' >< fromList (map (,d + 1) (filter (`notElem` v) (neighbors g i)))
  Seq.EmptyL -> error "empty queue"

We have our grid, our visited set, and our upcoming queue. Each iteration, we look at the first item in our queue. If it's already visited, we ditch it and continue with the rest of the queue. If it's the goal, we return its distance. If it's any other node, we add it to our visited set, add its neighbors (with +1 distance) to our queue, and recurse.

Is that really Dijkstra's?

Now wait a minute, we aren't even using a priority queue here! Is this Dijkstra's, or is it just a breadth-first search? To that I have two things to say:

1. Every 'edge' in our grid has a weight of 1, so this is equivalent to using a priority queue in this particular scenario.
2. We could use a priority queue if we want to, I was just being lazy.

The Nitty Gritty of Goals and Neighbors

In the above code, goal is a helper function that finds the location of the 'E' in our grid. I wrote a similar helper for 'S':

findCoord :: Ix a => Char -> Array a Char -> a
findCoord c = fst . head . filter (\(_, c') -> c == c') . assocs

start :: Ix a => Array a Char -> a
start = findCoord 'S'

goal :: Ix a => Array a Char -> a
goal = findCoord 'E'

Neighbors finds the indices to the north, south, east, and west, making sure that they remain in the grid and at an accessible elevation:

elev :: Char -> Int
elev 'S' = elev 'a'
elev 'E' = elev 'z'
elev c = fromEnum c - fromEnum 'a'

neighbors :: Array (Int, Int) Char -> (Int, Int) -> [(Int, Int)]
neighbors g i@(x, y) = do
  i' <- [(x, y + 1), (x, y - 1), (x + 1, y), (x - 1, y)]
  guard $ inRange (bounds g) i'
  guard $ elev (g ! i') <= elev (g ! i) + 1
  return i'

Part 1 then kicks off go with an empty visited set and our start node.

part1 :: Array (Int, Int) Char -> Int
part1 g = go g Set.empty $ fromList [(start g, 0)]

Part 2

In Part 2, we are looking for the shortest path from any 'a' to 'E'. There are two ways we could do this. First, we could store all of our 'a' locations as our initial set and run the code again. Perhaps more cleanly, though, we can reverse our search. We'll start at 'E' and look backwards until land on any 'a'. We'll need a new function for downhill neighbors:

downhill :: Array (Int, Int) Char -> (Int, Int) -> [(Int, Int)]
downhill g i@(x, y) = do
  i' <- [(x, y + 1), (x, y - 1), (x + 1, y), (x - 1, y)]
  guard $ inRange (bounds g) i'
  guard $ elev (g ! i') >= elev (g ! i) - 1
  return i'

We can abstract out our neighbors and goal functions, to reuse the logic from Part 1:

go :: ((Int, Int) -> Bool) -> ((Int, Int) -> [(Int, Int)]) -> Array (Int, Int) Char -> Set (Int, Int) -> Seq ((Int, Int), Int) -> Int
go isGoal n g v q = case Seq.viewl q of
  (i, d) :< q' ->
    if i `elem` v
      then go isGoal n g v q'
      else
        if isGoal i
          then d
          else go isGoal n g (i `Set.insert` v) $ q' >< fromList (map (,d + 1) (filter (`notElem` v) (n i)))
  Seq.EmptyL -> error "empty queue"

part1 :: Array (Int, Int) Char -> Int
part1 g = go (== goal g) (neighbors g) g Set.empty $ fromList [(start g, 0)]

part2 :: Array (Int, Int) Char -> Int
part2 g = go ((== 0) . elev . (g !)) (downhill g) g Set.empty $ fromList [(goal g, 0)]

Full Code

There are aspects of this implementation that are not very efficient. Typically, I believe 'go isGoal neighbors' is bound once, so that the function isn't evaluated fresh every single iteration. Check out the aStar package for more professional examples. I'll likely use that on future days as needed.

{-# LANGUAGE TupleSections #-}

module AOC2022.Day12 (spec) where

import Control.Monad (guard)
import Data.Array
  ( Array,
    Ix (inRange),
    assocs,
    bounds,
    listArray,
    (!),
  )
import Data.Sequence (Seq, ViewL ((:<)), fromList, (><))
import qualified Data.Sequence as Seq
import Data.Set (Set)
import qualified Data.Set as Set
import Input (readDay)
import Test.Hspec (describe, hspec, it, shouldBe)

input :: IO (Array (Int, Int) Char)
input = listArray ((-20, 0), (20, 160)) . filter (/= '\n') <$> readDay 2022 12

spec :: IO ()
spec = hspec $ do
  describe "Day 12" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        myInput <- input
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` 0 -- redacted

findCoord :: Ix a => Char -> Array a Char -> a
findCoord c = fst . head . filter (\(_, c') -> c == c') . assocs

start :: Ix a => Array a Char -> a
start = findCoord 'S'

goal :: Ix a => Array a Char -> a
goal = findCoord 'E'

elev :: Char -> Int
elev 'S' = elev 'a'
elev 'E' = elev 'z'
elev c = fromEnum c - fromEnum 'a'

neighbors :: Array (Int, Int) Char -> (Int, Int) -> [(Int, Int)]
neighbors g i@(x, y) = do
  i' <- [(x, y + 1), (x, y - 1), (x + 1, y), (x - 1, y)]
  guard $ inRange (bounds g) i'
  guard $ elev (g ! i') <= elev (g ! i) + 1
  return i'

go :: ((Int, Int) -> Bool) -> ((Int, Int) -> [(Int, Int)]) -> Array (Int, Int) Char -> Set (Int, Int) -> Seq ((Int, Int), Int) -> Int
go isGoal n g v q = case Seq.viewl q of
  (i, d) :< q' ->
    if i `elem` v
      then go isGoal n g v q'
      else
        if isGoal i
          then d
          else go isGoal n g (i `Set.insert` v) $ q' >< fromList (map (,d + 1) (filter (`notElem` v) (n i)))
  Seq.EmptyL -> error "empty queue"

part1 :: Array (Int, Int) Char -> Int
part1 g = go (== goal g) (neighbors g) g Set.empty $ fromList [(start g, 0)]

downhill :: Array (Int, Int) Char -> (Int, Int) -> [(Int, Int)]
downhill g i@(x, y) = do
  i' <- [(x, y + 1), (x, y - 1), (x + 1, y), (x - 1, y)]
  guard $ inRange (bounds g) i'
  guard $ elev (g ! i') >= elev (g ! i) - 1
  return i'

part2 :: Array (Int, Int) Char -> Int
part2 g = go ((== 0) . elev . (g !)) (downhill g) g Set.empty $ fromList [(goal g, 0)]

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 13: Distress Signal Previous: Day 11: Monkey in the Middle

In the end, the code is pretty straight forward. We define a data type for our monkeys. We need indexed access to them, so we store them in an Array. Since we're appending a lot of items to the end of lists, I used Data.Sequence instead of a plain list.

Parsing this input seemed like a waste of time, so you'll see the hard-coded list of monkeys in the code below.

Wait But Part 2?

The key insight in Part 2 is to use modular arithmetic to keep the numbers small. Each of the inspect operations checks whether a result is divisible by a small prime number, and addition and squaring preserve that test when taken modulo that same number.

Since all of our test functions use different numbers, we take the least common multiple as our worst case. This is somewhere around 10 million (or 223 million if you want the example to work!)

Full Code

module AOC2022.Day11 (spec) where

import Data.Array
  ( Array,
    accum,
    elems,
    indices,
    listArray,
    (!),
    (//),
  )
import Data.Foldable (toList)
import Data.List (foldl', sortOn)
import Data.Ord (Down (Down))
import Data.Sequence (Seq, empty, fromList, length, (|>))
import Test.Hspec (describe, hspec, it, shouldBe)
import Prelude hiding (length)

spec :: IO ()
spec = hspec $ do
  describe "Day 11" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        part1 exampleMonkeys `shouldBe` 10605
        part1 myMonkeys `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        part2 exampleMonkeys `shouldBe` 2713310158
        part2 myMonkeys `shouldBe` 0 -- redacted

data Monkey = Monkey
  { items :: Seq Int,
    operation :: Int -> Int,
    test :: Int -> Int,
    throwCount :: Int
  }

exampleMonkeys :: Array Int Monkey
exampleMonkeys =
  listArray
    (0, 3)
    [ Monkey (fromList [79, 98]) (* 19) (\x -> if x `mod` 23 == 0 then 2 else 3) 0,
      Monkey (fromList [54, 65, 75, 74]) (+ 6) (\x -> if x `mod` 19 == 0 then 2 else 0) 0,
      Monkey (fromList [79, 60, 97]) (\x -> x * x) (\x -> if x `mod` 13 == 0 then 1 else 3) 0,
      Monkey (fromList [74]) (+ 3) (\x -> if x `mod` 17 == 0 then 0 else 1) 0
    ]

maxmod :: Int
maxmod = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23

myMonkeys :: Array Int Monkey
myMonkeys =
  listArray
    (0, 7)
    [ Monkey (fromList [63, 84, 80, 83, 84, 53, 88, 72]) (* 11) (\x -> if x `mod` 13 == 0 then 4 else 7) 0,
      Monkey (fromList [67, 56, 92, 88, 84]) (+ 4) (\x -> if x `mod` 11 == 0 then 5 else 3) 0,
      Monkey (fromList [52]) (\x -> x * x) (\x -> if even x then 3 else 1) 0,
      Monkey (fromList [59, 53, 60, 92, 69, 72]) (+ 2) (\x -> if x `mod` 5 == 0 then 5 else 6) 0,
      Monkey (fromList [61, 52, 55, 61]) (+ 3) (\x -> if x `mod` 7 == 0 then 7 else 2) 0,
      Monkey (fromList [79, 53]) (+ 1) (\x -> if x `mod` 3 == 0 then 0 else 6) 0,
      Monkey (fromList [59, 86, 67, 95, 92, 77, 91]) (+ 5) (\x -> if x `mod` 19 == 0 then 4 else 0) 0,
      Monkey (fromList [58, 83, 89]) (* 19) (\x -> if x `mod` 17 == 0 then 2 else 1) 0
    ]

catchItem :: Monkey -> Int -> Monkey
catchItem monkey item = monkey {items = items monkey |> item}

step :: (Int -> Int) -> Array Int Monkey -> Int -> Array Int Monkey
step worryReducer monkeys i = monkeys'
  where
    m = monkeys ! i
    itemThrows = (\item -> (test m item, item)) . worryReducer . operation m <$> items m
    m' = m {items = empty, throwCount = throwCount m + length itemThrows}
    monkeys' = accum catchItem monkeys (toList itemThrows) // [(i, m')]

oneRound :: (Int -> Int) -> Array Int Monkey -> Array Int Monkey
oneRound worryReducer monkeys = foldl' (step worryReducer) monkeys $ indices monkeys

monkeyBusiness :: Array Int Monkey -> Int
monkeyBusiness = product . take 2 . sortOn Down . elems . fmap throwCount

part1 :: Array Int Monkey -> Int
part1 monkeys = monkeyBusiness $ foldl' (const . oneRound (`div` 3)) monkeys [1 .. 20]

part2 :: Array Int Monkey -> Int
part2 monkeys = monkeyBusiness $ foldl' (const . oneRound (`mod` maxmod)) monkeys [1 .. 10000]

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 12: Hill Climbing Algorithm Previous: Day 10: Cathode-Ray Tube

Catching strong 2019 vibes...

Parsing the instructions

Parsing this input line by line is typical of most days. We split it into lines, and then create a small Parsec parser that can convert those lines to a data type. The data type then allows us to do pattern matching in our other "business logic" functions.

There are two small notes today:

1. I unwrapped the result with fromRight [] so that my tests don't need to operate on Eithers. This did, however, cause me to miss a parsing error for some time, as it was silently replaced with a valid-but-empty list of instructions.
2. Our parseInt function needed to be expanded to handle negative numbers. Whoops! parseInt = read <$> many1 (char '-' <|> digit)

Here's the rest of the parsing code:

import Data.Either
import Input
import Text.ParserCombinators.Parsec

data Instruction = Noop | Addx Int
  deriving (Show, Eq)

parseInstruction :: GenParser Char u Instruction
parseInstruction = parseNoop <|> parseAddx
  where
    parseNoop = try $ string "noop" >> return Noop
    parseAddx = try $ string "addx " >> Addx <$> parseInt

input :: IO [Instruction]
input = fromRight [] . traverse (parse parseInstruction "") . lines <$> readDay 2022 10

Running Instructions With State

We have a list of instructions and a register, and our goal is to simulate "cycles." We need a way to keep track of the result of each cycle and the state of the register for the next cycle. We can do that with the State monad!

With the State monad, we define each computation as a function from some previous state, to both a value and an updated state. We can chain these computations together, and each will receive the state from the previous computation.

Since we need to know the value of the register at any arbitrary cycle, let's have each instruction return a list of those values. The noop instruction takes one cycle to complete, so it will return a list with just one of the register value in it. The addx instruction takes two cycles, so it will return a list of length 2.

noop :: State Int [Int]
noop = do
  x <- get
  return [x]

addx :: Int -> State Int [Int]
addx v = do
  x <- get
  put (x + v) -- Update the register for the next instruction
  return [x, x] -- Takes 2 cycles to complete

step :: Instruction -> State Int [Int]
step Noop = noop
step (Addx v) = addx v

Part 1 - Compute and inspect

For part 1, we want to run our computation and inspect the value at particular cycles. We'll use a function compute to calculate a list of Int pairs. Let's look at the code first:

compute :: [Instruction] -> [(Int, Int)]
compute = zip [1 ..] . flip evalState 1 . fmap concat . traverse step

What is this doing?

1. traverse step: Look at the type of traverse:

   traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

   Step is our function from Instruction to State Int [Int]. Our second argument comes from compute and is a list of Instructions. Our return type is then a State Int [[Int]]. In other words, a computation that can be given an initial state and result in a list of lists of register values.

2. fmap concat: Flatten our list-of-lists into a single list of register values. We use fmap to concatenate the value inside the State monad (which is also a Functor).

3. flip evalState 1: Run our stateful computation with the initial register value of 1.

4. zip [1 ..]: Attach the cycle count to each register value. This will make it easier to find the 20th, 60th, etc.

Part 1 - Signal Strength

With all that in place, the only remaining piece of Part 1 is to compute the signal strength:

part1 :: [Instruction] -> Int
part1 = sum . fmap signalStrength . compute
  where
    signalStrength (i, x)
      | i `mod` 40 == 20 && i <= 220 = i * x
      | otherwise = 0

Part 2 - Rendering Sprites

Part 2 sounds much more complicated than it turns out to be. We have our computation all ready to go, so we just need to see if the cycle instruction and register value correspond to painting a pixel or not. The cycle instruction is 1-indexed, so we need to subtract 1 and modulo the length of the line (40). If that's within 1 of the register value, we paint a pixel.

Advent of Code examples use . and # to represent dark and light squares. I've learned my lesson over the years, and will use the much clearer '⬛' and '🟩'.

part2 :: [Instruction] -> String
part2 = unlines . chunksOf 40 . fmap render . compute
  where
    render (i, x) = if abs (x - ((i - 1) `mod` 40)) <= 1 then '🟩' else '⬛'

Full Code

module AOC2022.Day10 (spec) where

import Control.Monad.State.Lazy
import Data.Either
import Data.List.Split
import Input
import Test.Hspec
import Text.ParserCombinators.Parsec hiding (State)

input :: IO [Instruction]
input = fromRight [] . traverse (parse parseInstruction "") . lines <$> readDay 2022 10

spec :: IO ()
spec = hspec $ do
  describe "Day 10" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        myInput <- input
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` "" --redacted

data Instruction = Noop | Addx Int
  deriving (Show, Eq)

parseInstruction :: GenParser Char u Instruction
parseInstruction = parseNoop <|> parseAddx
  where
    parseNoop = try $ string "noop" >> return Noop
    parseAddx = try $ string "addx " >> Addx <$> parseInt

noop :: State Int [Int]
noop = do
  x <- get
  return [x]

addx :: Int -> State Int [Int]
addx v = do
  x <- get
  put (x + v) -- Update the register
  return [x, x] -- Takes 2 cycles to complete

step :: Instruction -> State Int [Int]
step Noop = noop
step (Addx v) = addx v

compute :: [Instruction] -> [(Int, Int)]
compute = zip [1 ..] . flip evalState 1 . fmap concat . traverse step

part1 :: [Instruction] -> Int
part1 = sum . fmap signalStrength . compute
  where
    signalStrength (i, x)
      | i `mod` 40 == 20 && i <= 220 = i * x
      | otherwise = 0

part2 :: [Instruction] -> String
part2 = unlines . chunksOf 40 . fmap render . compute
  where
    render (i, x) = if abs (x - ((i - 1) `mod` 40)) <= 1 then '🟩' else '⬛'

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 11: Monkey in the Middle Previous: Day 9: Rope Bridge

The Ways Ropes Move

Unusually, today I didn't start with parsing! Instead, I jumped right into modeling the rules of motion. There are two that we care about: the head following steps directly from our input file, and the tail being lazily tugged along behind it.

-- Tugs the first argument towards the second argument
tug :: (Int, Int) -> (Int, Int) -> (Int, Int)
tug (x, y) (a, b)
  | isTouching = (x, y)
  | x < a && y < b = (x + 1, y + 1)
  | x > a && y > b = (x - 1, y - 1)
  | x < a && y > b = (x + 1, y - 1)
  | x > a && y < b = (x - 1, y + 1)
  | x < a = (x + 1, y)
  | x > a = (x - 1, y)
  | y < b = (x, y + 1)
  | y > b = (x, y - 1)
  | otherwise = (x, y)
  where
    isTouching = abs (x - a) <= 1 && abs (y - b) <= 1

data Direction = North | South | East | West deriving (Show, Eq)

step :: (Int, Int) -> Direction -> (Int, Int)
step (x, y) North = (x, y + 1)
step (x, y) South = (x, y - 1)
step (x, y) East = (x + 1, y)
step (x, y) West = (x - 1, y)

The tug function isn't pretty, but it works!

Parsing The Input

We have a list of commands in our input. Each line can represent several individual motions, but we really want to simulate them one by one. Let's expand them out.

strToDir :: Char -> Direction
strToDir 'U' = North
strToDir 'D' = South
strToDir 'R' = East
strToDir 'L' = West
strToDir c = error $ "Invalid direction: " ++ show c

input :: IO [Direction]
input = concatMap parseMotions . lines <$> readDay 2022 9
  where
    parseMotions (d : ' ' : n) = replicate (read n) (strToDir d)
    parseMotions _ = error "Invalid motion"

Simulating the Rope

How do we simulate the rope? Well, the head of the rope moves according to the direction, and the tail of the rope follows. I had a hunch (read: saw on Reddit) that Part 2 may involve a longer rope, so I structured it as a recursive function:

stepRope :: [(Int, Int)] -> Direction -> [(Int, Int)]
stepRope (h : t) dir = step h dir : follow (step h dir) t
  where
    follow prev (next : rest) = tug next prev : follow (tug next prev) rest
    follow _ [] = []

This pretty closely matches how we'd describe it in English, which is one thing I love about the expressiveness of Haskell.

Now we want to fold our list of steps over our rope to simulate its motion. But wait! We care about each state along the way, so instead of fold we use scan. Tracking the tail locations is as simple as getting the last item from each scan result, filtering to only unique coordinates, and counting them up.

part1 :: [Direction] -> Int
part1 = length . nub . fmap last . scanl stepRope [(0, 0), (0, 0)]

Part 2 is a longer rope, with 10 knots, but looks precisely the same:

part2 :: [Direction] -> Int
part2 = length . nub . fmap last . scanl stepRope (replicate 10 (0, 0))

Full Code

module AOC2022.Day09 (spec) where

import Data.List
import Input
import Test.Hspec

data Direction = North | South | East | West deriving (Show, Eq)

strToDir :: Char -> Direction
strToDir 'U' = North
strToDir 'D' = South
strToDir 'R' = East
strToDir 'L' = West
strToDir c = error $ "Invalid direction: " ++ show c

input :: IO [Direction]
input = concatMap parseMotions . lines <$> readDay 2022 9
  where
    parseMotions (d : ' ' : n) = replicate (read n) (strToDir d)
    parseMotions _ = error "Invalid motion"

spec :: IO ()
spec = hspec $ do
  describe "Day 9" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        myInput <- input
        stepRope [(1, 1), (0, 0)] North `shouldBe` [(1, 2), (1, 1)]
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` 0 -- redacted

-- Tugs the first argument towards the second argument
tug :: (Int, Int) -> (Int, Int) -> (Int, Int)
tug (x, y) (a, b)
  | isTouching = (x, y)
  | x < a && y < b = (x + 1, y + 1)
  | x > a && y > b = (x - 1, y - 1)
  | x < a && y > b = (x + 1, y - 1)
  | x > a && y < b = (x - 1, y + 1)
  | x < a = (x + 1, y)
  | x > a = (x - 1, y)
  | y < b = (x, y + 1)
  | y > b = (x, y - 1)
  | otherwise = (x, y)
  where
    isTouching = abs (x - a) <= 1 && abs (y - b) <= 1

step :: (Int, Int) -> Direction -> (Int, Int)
step (x, y) North = (x, y + 1)
step (x, y) South = (x, y - 1)
step (x, y) East = (x + 1, y)
step (x, y) West = (x - 1, y)

stepRope :: [(Int, Int)] -> Direction -> [(Int, Int)]
stepRope (h : t) dir = step h dir : follow (step h dir) t
  where
    follow prev (next : rest) = tug next prev : follow (tug next prev) rest
    follow _ [] = []
stepRope [] _ = []

part1 :: [Direction] -> Int
part1 = length . nub . fmap last . scanl stepRope [(0, 0), (0, 0)]

part2 :: [Direction] -> Int
part2 = length . nub . fmap last . scanl stepRope (replicate 10 (0, 0))

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 10: Cathode-Ray Tube Previous: Day 8: Treetop Tree House

First thought: Oy vey, another Array problem?

At Least the Parsing is Easy

Let's read in our grid as a list of numbers, and then drop them in an array. Our grid size is conveniently square, so we can get away with an easy length check.

input :: IO (Array (Int, Int) Int)
input = do
  s <- lines <$> readDay 2022 8
  return $ listArray ((1, 1), (length s, length s)) $ digitToInt <$> concat s

Part 1: Visibility from the Edge

For Part 1, we want to know how many trees are visible from the outside. To do this, we'll iterate over each tree, and check if it's visible. This will do some extra work, but it's very simple.

There are two main ways to reduce the work here. One is to check each of the rows and columns directly from the outside. Imagine shooting a ray into the grid and seeing how many trees are passed before it hits something. However, we'd have to store the exact trees in a Set, to avoid double-counting trees that are visible from other directions.

The second way to reduce the double work is to calculate each tree's visiblity based on the trees next to it. A tree is visible from the west only if it's western neighbor is visible and smaller.

How do we iterate over each tree? Well, a tree is really just an index in the array! Let's make some helper functions that can start with a tree, and return all of the other trees in a particular direction, ending at the edge of the grid:

type Tree = (Int, Int)

-- From a given index, step in a cardinal direction until we hit a boundary
northFrom, southFrom, eastFrom, westFrom :: Tree -> (Tree, Tree) -> [Tree]
northFrom (x, y) b = takeWhile (inRange b) [(x, y - d) | d <- [1 ..]]
southFrom (x, y) b = takeWhile (inRange b) [(x, y + d) | d <- [1 ..]]
eastFrom (x, y) b = takeWhile (inRange b) [(x + d, y) | d <- [1 ..]]
westFrom (x, y) b = takeWhile (inRange b) [(x - d, y) | d <- [1 ..]]

A tree is visible if it's visible from any of these four directions. Let's use the List monad to represent this choice. We'll create a list of our 4 directions, and then define a computation that can run on any of them.

treeIsVisible :: Array Tree Int -> Tree -> Bool
treeIsVisible a t = or $ do
  stepFrom <- [northFrom, southFrom, eastFrom, westFrom]
  let trees = stepFrom t $ bounds a
  return $ all (< (a ! t)) $ fmap (a !) trees

part1 :: Array Tree Int -> Int
part1 a = length . filter (treeIsVisible a) $ indices a

Part 2 - Maximal visibility

Part 2 ends up being very similar:

1. We will still iterate over each tree with indices a
2. We will still use the List monad to choose one of our four directions
3. This will result in a list of values. Instead of a boolean whether or not the given tree is visible from that direction, it will be the number of trees visible in that direction.
4. We will combine the values together. Instead of or, we will use product
5. Instead of filtering our trees and counting the length, we'll find the maximum resulting value.

takeUntil :: (a -> Bool) -> [a] -> [a]
takeUntil p = foldr (\x ys -> x : if p x then [] else ys) []

scenicScore :: Array Tree Int -> Tree -> Int
scenicScore a t = product $ do
  stepFrom <- [northFrom, southFrom, eastFrom, westFrom]
  return $ length $ takeUntil (\x -> a ! x >= a ! t) $ stepFrom t $ bounds a

part2 :: Array Tree Int -> Int
part2 a = maximum . fmap (scenicScore a) $ indices a

Full Code

module AOC2022.Day08 (spec) where

import Data.Array
import Data.Char (digitToInt)
import Input
import Test.Hspec

input :: IO (Array (Int, Int) Int)
input = do
  s <- lines <$> readDay 2022 8
  return $ listArray ((1, 1), (length s, length s)) $ digitToInt <$> concat s

spec :: IO ()
spec = hspec $ do
  describe "Day 8" $ do
    describe "Part 1" $ do
      it "runs on custom input" $ do
        myInput <- input
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 2" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` 0 -- redacted

type Tree = (Int, Int)

-- From a given index, step in a cardinal direction until we hit a boundary
northFrom, southFrom, eastFrom, westFrom :: Tree -> (Tree, Tree) -> [Tree]
northFrom (x, y) b = takeWhile (inRange b) [(x, y - d) | d <- [1 ..]]
southFrom (x, y) b = takeWhile (inRange b) [(x, y + d) | d <- [1 ..]]
eastFrom (x, y) b = takeWhile (inRange b) [(x + d, y) | d <- [1 ..]]
westFrom (x, y) b = takeWhile (inRange b) [(x - d, y) | d <- [1 ..]]

treeIsVisible :: Array Tree Int -> Tree -> Bool
treeIsVisible a t = or $ do
  stepFrom <- [northFrom, southFrom, eastFrom, westFrom]
  let trees = stepFrom t $ bounds a
  return $ all (< (a ! t)) $ fmap (a !) trees

part1 :: Array Tree Int -> Int
part1 a = length . filter (treeIsVisible a) $ indices a

takeUntil :: (a -> Bool) -> [a] -> [a]
takeUntil p = foldr (\x ys -> x : if p x then [] else ys) []

scenicScore :: Array Tree Int -> Tree -> Int
scenicScore a t = product $ do
  stepFrom <- [northFrom, southFrom, eastFrom, westFrom]
  return $ length $ takeUntil (\x -> a ! x >= a ! t) $ stepFrom t $ bounds a

part2 :: Array Tree Int -> Int
part2 a = maximum . fmap (scenicScore a) $ indices a

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 9: Rope Bridge Previous: Day 7: No Space Left On Device

1. Parse the raw lines into structured TerminalOutput commands.
2. Parse the list of TerminalOutput commands into a FileSystem tree.

First Parse - String to Terminal Output

First things first, we needed to convert the strings into something more useful:

data TerminalOutput
  = LS
  | Cd String
  | CdUp
  | LSDir String
  | LSFile Int String
  deriving (Eq, Show)

parseLine :: ParsecT [Char] u Identity TerminalOutput
parseLine = parseCdUp <|> parseCd <|> parseDir <|> parseFile <|> parseLS
  where
    parseCdUp = try $ string "$ cd .." $> CdUp
    parseCd = try $ fmap Cd (string "$ cd " >> many1 (noneOf "\n"))
    parseDir = try $ fmap LSDir (string "dir " >> many1 (noneOf "\n"))
    parseFile = try $ liftA2 LSFile (parseInt <* string " ") (many1 (noneOf "\n"))
    parseLS = try $ string "$ ls" $> LS

The mishmash of punctuation and parentheses isn't the easiest to read, but it generally parses the line left-to-right, discarding any cruft.

Parsing the Terminal Output Again?

With a list of TerminalOutput commands, I now wanted to parse a FileSystem tree. Sure, I could have just used recursion, but I didn't want to pass around the state of what directory I was in. Plus, the point of this is to learn, right?

To write a custom Parsec parser, I looked to the Text.Parsec.Prim module, specifically tokenPrim. We can define a combinator for each of our tokens like so:

ls :: ParsecT [TerminalOutput] u Identity ()
ls = tokenPrim show nextPos test
  where
    test LS = Just ()
    test _ = Nothing

cdup :: ParsecT [TerminalOutput] u Identity ()
cdup = tokenPrim show nextPos test
  where
    test CdUp = Just ()
    test _ = Nothing

cd :: ParsecT [TerminalOutput] u Identity TerminalOutput
cd = tokenPrim show nextPos test
  where
    test (Cd s) = Just (Cd s)
    test _ = Nothing

lsdir :: ParsecT [TerminalOutput] u Identity TerminalOutput
lsdir = tokenPrim show nextPos test
  where
    test (LSDir s) = Just (LSDir s)
    test _ = Nothing

lsfile :: ParsecT [TerminalOutput] u Identity TerminalOutput
lsfile = tokenPrim show nextPos test
  where
    test (LSFile i s) = Just (LSFile i s)
    test _ = Nothing

Note that ls, cdup parse a unit () type. They could return the TerminalOutput, but we want to ignore them in our final FileSystem anyways.

nextPos is a function that updates our "source position", stepping through our list of TerminalOutput commands as we parse. Since all of our tokens are a single command, they can share the same implementation:

nextPos :: SourcePos -> b1 -> b2 -> SourcePos
nextPos p = const $ const $ newPos (sourceName p) (sourceLine p) (sourceColumn p + 1)

Using Our Parsers to Make a FileSystem

Now that we have our primitives, we can define a parser for a FileSystem. A FileSystem is either a single File (with a name and size) or a Directory (with a name and a list of files or sub-directories).

data FileSystem = Directory String [FileSystem] | File String Int deriving (Eq, Show)

We can parse it like so:

parseFiles :: ParsecT [TerminalOutput] u Identity [FileSystem]
parseFiles = mapMaybe parseListing <$> many (try lsdir <|> try lsfile)
  where
    parseListing (LSFile i s) = Just $ File s i
    parseListing _ = Nothing

parseFileSystem :: ParsecT [TerminalOutput] u Identity FileSystem
parseFileSystem = do
  Cd name <- cd
  ls
  files <- parseFiles
  subdirs <- many parseFileSystem
  cdup <|> eof
  return $ Directory name (files ++ subdirs)

Note that we terminate our parse with an option of cdup <|> eof. This sidesteps the issue where you may not return to the root directory at the end of the input.

Wait, What Was The Question?

After this really-way-too-involved setup, we can now go about solving Part 1 and Part 2. These are both pretty simple functions now that we have our FileSystem object.

size :: FileSystem -> Int
size (File _ i) = i
size (Directory _ fs) = sum $ map size fs

listAll :: FileSystem -> [FileSystem]
listAll f@(File _ _) = [f]
listAll d@(Directory _ fs) = d : concatMap listAll fs

isDir :: FileSystem -> Bool
isDir (Directory _ _) = True
isDir _ = False

part1 :: FileSystem -> Int
part1 = sum . filter (<= 100000) . fmap size . filter isDir . listAll

diskSize, spaceNeeded :: Int
diskSize = 70000000
spaceNeeded = 30000000

part2 :: FileSystem -> Int
part2 root = minimum $ filter (>= spaceToFree) $ fmap size $ filter isDir $ listAll root
  where
    spaceToFree = spaceNeeded + size root - diskSize

This is doing a lot of extra work in calculating the size for each of the directories and sub-directories. A more efficient approach would precalculate the size of each directory when parsing it, so that it can be retrieved in constant time and avoid recomputing the size of subtrees.

Full Code

Here's the full code! The imports are more verbose than usual, to disambiguate which module the Parsec and Applicative functions came from.

module AOC2022.Day07 (spec) where

import Control.Applicative (liftA2)
import Data.Functor (($>))
import Data.Functor.Identity (Identity)
import Data.Maybe (mapMaybe)
import Input (parseInt, readDay)
import Test.Hspec (describe, hspec, it, shouldBe)
import Text.Parsec.Pos
  ( SourcePos,
    newPos,
    sourceColumn,
    sourceLine,
    sourceName,
  )
import Text.Parsec.Prim
  ( ParsecT,
    many,
    parse,
    tokenPrim,
    try,
    (<|>),
  )
import Text.ParserCombinators.Parsec
  ( ParseError,
    eof,
    many1,
    noneOf,
    string,
  )

input :: IO (Either ParseError FileSystem)
input = do
  raw <- lines <$> readDay 2022 7
  return $ do
    output <- traverse (parse parseLine "") raw
    parse parseFileSystem [] output

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "runs a test" $ do
      myInput <- input
      fmap part1 myInput `shouldBe` Right 0 -- redacted
  describe "Part 2" $ do
    it "runs a test" $ do
      myInput <- input
      fmap part2 myInput `shouldBe` Right 0 -- redacted

data TerminalOutput
  = LS
  | Cd String
  | CdUp
  | LSDir String
  | LSFile Int String
  deriving (Eq, Show)

parseLine :: ParsecT [Char] u Identity TerminalOutput
parseLine = parseCdUp <|> parseCd <|> parseDir <|> parseFile <|> parseLS
  where
    parseCdUp = try $ string "$ cd .." $> CdUp
    parseCd = try $ fmap Cd (string "$ cd " >> many1 (noneOf "\n"))
    parseDir = try $ fmap LSDir (string "dir " >> many1 (noneOf "\n"))
    parseFile = try $ liftA2 LSFile (parseInt <* string " ") (many1 (noneOf "\n"))
    parseLS = try $ string "$ ls" $> LS

data FileSystem = Directory String [FileSystem] | File String Int deriving (Eq, Show)

nextPos :: SourcePos -> b1 -> b2 -> SourcePos
nextPos p = const $ const $ newPos (sourceName p) (sourceLine p) (sourceColumn p + 1)

ls :: ParsecT [TerminalOutput] u Identity ()
ls = tokenPrim show nextPos test
  where
    test LS = Just ()
    test _ = Nothing

cdup :: ParsecT [TerminalOutput] u Identity ()
cdup = tokenPrim show nextPos test
  where
    test CdUp = Just ()
    test _ = Nothing

cd :: ParsecT [TerminalOutput] u Identity TerminalOutput
cd = tokenPrim show nextPos test
  where
    test (Cd s) = Just (Cd s)
    test _ = Nothing

lsdir :: ParsecT [TerminalOutput] u Identity TerminalOutput
lsdir = tokenPrim show nextPos test
  where
    test (LSDir s) = Just (LSDir s)
    test _ = Nothing

lsfile :: ParsecT [TerminalOutput] u Identity TerminalOutput
lsfile = tokenPrim show nextPos test
  where
    test (LSFile i s) = Just (LSFile i s)
    test _ = Nothing

parseFiles :: ParsecT [TerminalOutput] u Identity [FileSystem]
parseFiles = mapMaybe parseListing <$> many (try lsdir <|> try lsfile)
  where
    parseListing (LSFile i s) = Just $ File s i
    parseListing _ = Nothing

parseFileSystem :: ParsecT [TerminalOutput] u Identity FileSystem
parseFileSystem = do
  Cd name <- cd
  ls
  files <- parseFiles
  subdirs <- many parseFileSystem
  cdup <|> eof
  return $ Directory name (files ++ subdirs)

size :: FileSystem -> Int
size (File _ i) = i
size (Directory _ fs) = sum $ map size fs

listAll :: FileSystem -> [FileSystem]
listAll f@(File _ _) = [f]
listAll d@(Directory _ fs) = d : concatMap listAll fs

isDir :: FileSystem -> Bool
isDir (Directory _ _) = True
isDir _ = False

part1 :: FileSystem -> Int
part1 = sum . filter (<= 100000) . fmap size . filter isDir . listAll

diskSize, spaceNeeded :: Int
diskSize = 70000000
spaceNeeded = 30000000

part2 :: FileSystem -> Int
part2 root = minimum $ filter (>= spaceToFree) $ fmap size $ filter isDir $ listAll root
  where
    spaceToFree = spaceNeeded + size root - diskSize

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 8: Treetop Tree House Previous: Day 6: Tuning Trouble

This problem seems like a natural fit for recursion. Our core functionality will be a function that peeks the first few characters of the string. If they are unique, it returns the count. Otherwise, we discard a letter and try again with the rest of the string. Here's my first iteration at this, for Part 1:

charsUntilPacket :: String -> Int
charsUntilPacket (a : b : c : d : rest)
  | Set.size (Set.fromList [a, b, c, d]) == 4 = 4
  | otherwise = 1 + charsUntilPacket (b : c : d : rest)

Part 2 - Windows of size 14

Looking at 14 characters in a row is much the same. Pattern matching on 14 characters seemed a little excessive, though. I restructured charsUntilPacket to take a window size parameter, and renamed it charsUntilNUnique.

Lastly, I changed how we are checking for uniqueness. The Set approach works fine, but it forces the entire Set to be constructed to check its size. The alternative approach of nub s == s is, perhaps surprisingly, more efficient: it compares the elements one by one and can skip the remaining computation of nub s as soon as it discovers a mismatch. Laziness for the win!

Hoogle does find a function isNub that is equivalent. However, it's not in a package I'm familiar with.

Full Code

module AOC2022.Day06 (spec) where

import Data.List (nub)
import Input (readDay)
import Test.Hspec (describe, hspec, it, shouldBe)

input :: IO String
input = readDay 2022 6

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "runs on custom input" $ do
      myInput <- input
      part1 myInput `shouldBe` 0 -- redacted
  describe "Part 2" $ do
    it "runs on custom input" $ do
      myInput <- input
      part2 myInput `shouldBe` 0 -- redacted

charsUntilNUnique :: Int -> String -> Int
charsUntilNUnique i s =
  if nub (take i s) == take i s
    then i
    else 1 + charsUntilNUnique i (tail s)

part1 :: String -> Int
part1 = charsUntilNUnique 4

part2 :: String -> Int
part2 = charsUntilNUnique 14

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 7: No Space Left On Device Previous: Day 5: Supply Stacks

    [D]
[N] [C]
[Z] [M] [P]
 1   2   3

move 1 from 2 to 1
move 3 from 1 to 3
move 2 from 2 to 1
move 1 from 1 to 2

Initial thought: There's no way I'm parsing that stack diagram!

Parsing Moves

Based on parsing tricks I've learned recently, parsing the move instructions is straightforward:

data Move = Move Int Int Int

parseMove :: GenParser Char u Move
parseMove =
  liftA3
    Move
    (string "move " >> parseInt)
    (string " from " >> parseInt)
    (string " to " >> parseInt)

-- parseInt now lives in my reusable Input module:
parseInt :: GenParser Char u Int
parseInt = read <$> many1 digit

Modeling the Stacks

Lists are a great way to represent stacks in just about any functional language like Haskell, since you can push and pop the top of the list while the tail remains unmodified. But how will we represent our set of 9 stacks? For that, I opted for an array. Compared to Lists, Arrays in Haskell are fixed size and provide faster access and updates to indexed elements. We will be looking up individual stacks and modifying them for each move instruction, so this is perfect for our needs.

Like I said, I wasn't going to parse that initial structure. Here is my input, hardcoded as an array. The start of each string is the top of each stack.

stacks :: Array Int String
stacks =
  listArray
    (1, 9)
    [ "BVWTQNHD",
      "BWD",
      "CJWQST",
      "PTZNRJF",
      "TSMJVPG",
      "NTFWB",
      "NVHFQDLB",
      "RFPH",
      "HPNLBMSZ"
    ]

Haskell sidesteps the debate about 0-based and 1-based indexing, as you need to specify the index range explicitly! Here, our stacks start at 1, so we use 1-9 instead of 0-8.

Applying Moves to Our Stack

Now all we have to do is fold our list of Moves onto our Array. Part 1 is actually a little trickier than Part 2 here, as we can only move one item at a time. If we're moving more than one item, let's just move one and then recurse.

move :: Array Int String -> Move -> Array Int String
move a (Move 0 _ _) = a
move a (Move n x y) =
  let (h, rest) = splitAt 1 (a ! x)
   in move (a // [(x, rest), (y, h ++ (a ! y))]) (Move (n - 1) x y)

(a ! x) accesses the array element at index x. This code splits that element into the top item and the rest. It uses (a // assocs) to update the elements at the old and new index. Then it continues on, moving the next crate until the move is complete.

Part 2 is simpler, as we can move them all in one go:

moveAll :: Array Int String -> Move -> Array Int String
moveAll a (Move n x y) =
  let (pickedUp, rest) = splitAt n (a ! x)
   in a // [(x, rest), (y, pickedUp ++ (a ! y))]

Finally, we need to take the top item from each stack and concatenate them into a string:

peekStacks :: Array Int String -> String
peekStacks = fmap head . elems

part1 :: [Move] -> String
part1 = peekStacks . foldl move stacks

part2 :: [Move] -> String
part2 = peekStacks . foldl moveAll stacks

Is Parsing Really So Bad?

I solved this last night. When I woke up, I was refreshed and really didn't want to let this input get the best of me. How might we parse these stacks? Here's the plan:

• Parse each row one by one.
• Rows are either "[A]" or "\s\s\s", separated by spaces. In either case, grab the middle character.
• After we parse all rows, transpose them to get our stacks, filtering out any blank spaces.

Here is how that ended up looking:

parseStacks :: GenParser Char u [String]
parseStacks = fmap catMaybes . transpose <$> parseLines
  where
    parseCrate = find isLetter . Just <$> (oneOf "[ " *> anyChar <* oneOf " ]")
    parseLine = parseCrate `sepBy1` char ' '
    parseLines = parseLine `endBy1` newline

I stopped here. It should be trivial to parse this from the input file, and then parse the rest of the moves afterwards. We'll also need to convert our list of Strings into an Array by examining the length.

Full Code

module AOC2022.Day05 (spec) where

import Control.Applicative
import Data.Array
import Data.Char
import Data.List
import Data.Maybe
import Input
import Test.Hspec
import Text.ParserCombinators.Parsec

stacks :: Array Int String
stacks =
  listArray
    (1, 9)
    [ "BVWTQNHD",
      "BWD",
      "CJWQST",
      "PTZNRJF",
      "TSMJVPG",
      "NTFWB",
      "NVHFQDLB",
      "RFPH",
      "HPNLBMSZ"
    ]

data Move = Move Int Int Int

parseMove :: GenParser Char u Move
parseMove =
  liftA3
    Move
    (string "move " >> parseInt)
    (string " from " >> parseInt)
    (string " to " >> parseInt)

input :: IO (Either ParseError [Move])
input = traverse (parse parseMove "") . lines <$> readDay 2022 5

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "parses the stacks" $ do
      part1 [] `shouldBe` "BBCPTNNRH"
    it "runs on custom input" $ do
      myInput <- input
      part1 <$> myInput `shouldBe` Right "_________" -- redacted

  describe "Part 2" $ do
    it "runs on custom input" $ do
      myInput <- input
      part2 <$> myInput `shouldBe` Right "_________" -- redacted
  describe "Parsing" $ do
    it "parses the raw stack string" $ do
      parse parseStacks "" rawStacks
        `shouldBe` Right
          [ "BVWTQNHD",
            "BWD",
            "CJWQST",
            "PTZNRJF",
            "TSMJVPG",
            "NTFWB",
            "NVHFQDLB",
            "RFPH",
            "HPNLBMSZ"
          ]

move :: Array Int String -> Move -> Array Int String
move a (Move 0 _ _) = a
move a (Move n x y) =
  let (h, rest) = splitAt 1 (a ! x)
   in move (a // [(x, rest), (y, h ++ (a ! y))]) (Move (n - 1) x y)

peekStacks :: Array Int String -> String
peekStacks = fmap head . elems

part1 :: [Move] -> String
part1 = peekStacks . foldl move stacks

moveAll :: Array Int String -> Move -> Array Int String
moveAll a (Move n x y) =
  let (pickedUp, rest) = splitAt n (a ! x)
   in a // [(x, rest), (y, pickedUp ++ (a ! y))]

part2 :: [Move] -> String
part2 = peekStacks . foldl moveAll stacks

-- Parsing
rawStacks :: String
rawStacks =
  unlines
    [ "[B]                     [N]     [H]",
      "[V]         [P] [T]     [V]     [P]",
      "[W]     [C] [T] [S]     [H]     [N]",
      "[T]     [J] [Z] [M] [N] [F]     [L]",
      "[Q]     [W] [N] [J] [T] [Q] [R] [B]",
      "[N] [B] [Q] [R] [V] [F] [D] [F] [M]",
      "[H] [W] [S] [J] [P] [W] [L] [P] [S]",
      "[D] [D] [T] [F] [G] [B] [B] [H] [Z]",
      " 1   2   3   4   5   6   7   8   9 "
    ]

parseStacks :: GenParser Char u [String]
parseStacks = fmap catMaybes . transpose <$> parseLines
  where
    parseCrate = find isLetter . Just <$> (oneOf "[ " *> anyChar <* oneOf " ]")
    parseLine = parseCrate `sepBy1` char ' '
    parseLines = parseLine `endBy1` newline

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 6: Tuning Trouble Previous: Day 4: Camp Cleanup

The numbers in our input are all relatively small, to the point where we could brute-force check the elements of each range. But, let's try to avoid that by only examing the endpoints of the range.

This type of representation is bound to be more efficient. It also lends itself well to sweep line algorithms, which I bet we will see later this season.

The Range type

Our Range type is a data type that stores only its endpoints:

data Range = Range Int Int

In solving this challenge, I wanted to make the interface for this Range as reusable as possible. Most of the helper functions are analogs to similar functions on Data.Set or Data.List. For Part 1, we need to detect if one Range is a subset of another.

-- So reusable!
elem :: Int -> Range -> Bool
i `elem` Range a b = a <= i && i <= b

-- Much consistency!
isSubsetOf :: Range -> Range -> Bool
Range a b `isSubsetOf` target = a `elem` target && b `elem` target

-- Specific to Part 1:
isOverlap :: Range -> Range -> Bool
isOverlap a b = a `isSubsetOf` b || b `isSubsetOf` a

part1 :: [(Range, Range)] -> Int
part1 = length . filter (uncurry isOverlap)

For Part 2, we are looking for any overlap. We can also define some more commonly found functions:

-- Just like Sets!
intersection :: Range -> Range -> Range
intersection (Range a b) (Range x y) = Range (max a x) (min b y)

-- Just like Foldables, and Sets, and Maps...
null :: Range -> Bool
null (Range a b) = b < a

part2 :: [(Range, Range)] -> Int
part2 = length . filter (not . null . uncurry intersection)

Parsing

The final piece is to parse the input into a list of (Range, Range) pairs. To do this, I used Parsec.

parseRangePair :: GenParser Char u (Range, Range)
parseRangePair = do
  r1 <- parseRange
  _ <- char ','
  r2 <- parseRange
  return (r1, r2)
  where
    parseRange = do
      a <- read <$> many1 digit
      _ <- char '-'
      b <- read <$> many1 digit
      return $ Range a b

input :: IO (Either ParseError [(Range, Range)])
input = traverse (parse parseRangePair "") . lines <$> readDay 2022 4

This is pretty verbose, and I'm sure it can be optimized.

Full Code

Here it is all together:

module AOC2022.Day04 (spec) where

import Input
import Test.Hspec
import Text.ParserCombinators.Parsec
import Prelude hiding (elem, null)

input :: IO (Either ParseError [(Range, Range)])
input = traverse (parse parseRangePair "") . lines <$> readDay 2022 4

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "runs on custom input" $ do
      myInput <- input
      part1 <$> myInput `shouldBe` Right 0 -- redacted

  describe "Part 2" $ do
    it "runs on custom input" $ do
      myInput <- input
      part2 <$> myInput `shouldBe` Right 0 -- redacted

data Range = Range Int Int

parseRangePair :: GenParser Char u (Range, Range)
parseRangePair = do
  r1 <- parseRange
  _ <- char ','
  r2 <- parseRange
  return (r1, r2)
  where
    parseRange = do
      a <- read <$> many1 digit
      _ <- char '-'
      b <- read <$> many1 digit
      return $ Range a b

elem :: Int -> Range -> Bool
i `elem` Range a b = a <= i && i <= b

isSubsetOf :: Range -> Range -> Bool
Range a b `isSubsetOf` target = a `elem` target && b `elem` target

isOverlap :: Range -> Range -> Bool
isOverlap a b = a `isSubsetOf` b || b `isSubsetOf` a

part1 :: [(Range, Range)] -> Int
part1 = length . filter (uncurry isOverlap)

intersection :: Range -> Range -> Range
intersection (Range a b) (Range x y) = Range (max a x) (min b y)

null :: Range -> Bool
null (Range a b) = b < a

part2 :: [(Range, Range)] -> Int
part2 = length . filter (not . null . uncurry intersection)

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

See Also: Day 4 Bonus: Parsing

Next: Day 5: Supply Stacks Previous: Day 3: Rucksack Reorganization

Here's the original:

parseRangePair :: GenParser Char u (Range, Range)
parseRangePair = do
  r1 <- parseRange
  _ <- char ','
  r2 <- parseRange
  return (r1, r2)
  where
    parseRange = do
      a <- read <$> many1 digit
      _ <- char '-'
      b <- read <$> many1 digit
      return $ Range a b

Parsec defines parser combinators that can be used to compose powerful grammars. My original code does not use much composition, so maybe I'm doing something wrong!

Use Your Words, Human

One trick that helps in these situations is to try describing what we want in plain language. (This apparently works with computers, too.)

We want:

• Two Ranges, separated by a comma
• Each Range is two Ints, separated by a hyphen

Following this, we actually come across the sepBy and sepBy1 combinators:

parseRanges :: GenParser Char u [Range]
parseRanges = parseRange `sepBy1` (char ',')
  where parseRange = ...

While this looks promising, it doesn't compile. sepBy1 parses a list. Our Range constructor expects exactly 2 Ints, and our part1, part2 functions expect exactly 2 ranges. Let's go a different way, but I'll remember sepBy in later challenges.

Do or Do Not

Using do notation is resulting in verbose code. We have to bind the separator characters just to discard them, and we need a separate line just to return the final result.

Monads, Applicatives, and Functors are often described as being values wrapped in some abstract 'box'. In our last Day 3 bonus post, our box was functions; we wanted to compose values that still needed a String passed to them. Now we want to compose values that haven't yet been parsed. They are still in the Parser box, if you will.

We can "lift" our combining functions to work on boxed values. To discard the separator in between, we can use the operator (>>). This operator is like bind (>>=) except that it discards the first first result value.

Putting it all together, we have:

parseRangePair :: GenParser Char u (Range, Range)
parseRangePair =
  let parseInt = read <$> many1 digit
      parseRange = liftA2 Range parseInt (char '-' >> parseInt)
   in liftA2 (,) parseRange (char ',' >> parseRange)

Further refactoring?

Not right now, thank you. parseInt definitely belongs in my Input module, and the internal structure of parseRange and parseRangePair could also be useful to reuse. But that's a problem for a future day. Maybe even tomorrow!

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Main Post: Day 4: Camp Cleanup

Alas, nothing so complicated. (Phew!) Instead, our goal in both parts is to find common elements shared by various strings (or parts of strings).

Part 1

In Part 1, we need to find the only character that appears in both the first and second halves of each input string. Then we need to run that through a priority function to transform it into an integer.

Splitting the list is straightforward. Let's take the length of the list and use that to determine how many characters belong in each piece:

let size = length s `div` 2
in (take size s, drop size s)

-- Update:  I just learned about `splitAt` in Prelude:
-- splitAt :: Int -> [a] -> ([a], [a])
(s1, s2) = splitAt (length s `div` 2) s

I didn't care to get fancy with my priority function today:

charPriority :: Char -> Int
charPriority c
  | 'a' <= c && c <= 'z' = fromEnum c - fromEnum 'a' + 1
  | 'A' <= c && c <= 'Z' = fromEnum c - fromEnum 'A' + 27
  | otherwise = 0

Using Sets

Now, how should we compare the items in the first string with the items in the second? One option is to manually iterate over the characters in the first, checking if they are in the second. In the worst case, the common character will be at the end of each string, requiring O(n^2) comparisons. Instead, I chose to first transform the strings into a more efficient data structure, then compare those instead.

1. Construct a Set from each String. O(log n)
2. Combine the Sets by intersection. ~O(n) assuming similarly sized sets.
3. The only item in the remaining Set is our answer. O(1)
4. Total Runtime: O(n)

In practice, using asymptotic analysis here is questionable. Our input is very limited in size. This approach seems comparable to sorting the strings and then comparing them element-by-element, which is O(n log n) total. It doesn't seem possible to break the O(n) barrier, since you will always have the possibility of needing to look at every item in the list.

Here's the full code:

module AOC2022.Day03 (spec) where

import qualified Data.Set as Set
import Input
import Test.Hspec

input :: IO String
input = readDay 2022 3

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "vJrwpWtwJgWrhcsFMMfFFhFp" $ do
      part1 "vJrwpWtwJgWrhcsFMMfFFhFp" `shouldBe` 16
    it "runs on custom input" $ do
      myInput <- input
      sum (fmap part1 (lines myInput)) `shouldBe` 0 -- redacted

standout :: [Char] -> Char
standout s =
  let size = length s `div` 2
      (c1, c2) = (Set.fromList $ take size s, Set.fromList $ drop size s)
   in Set.findMin $ c1 `Set.intersection` c2

charPriority :: Char -> Int
charPriority c
  | 'a' <= c && c <= 'z' = fromEnum c - fromEnum 'a' + 1
  | 'A' <= c && c <= 'Z' = fromEnum c - fromEnum 'A' + 27
  | otherwise = 0

part1 :: String -> Int
part1 = charPriority . standout

Part 2 - Where Sets Pay Off

In Part 2, we no longer need to split the individual lines. Instead, we're looking for the common character in each group of 3 input lines. This is... basically the same thing! Let's factor out our commonItem logic, and generalize it to work on any number of Strings:

commonItem :: [String] -> Char
commonItem = Set.findMin . foldr1 Set.intersection . fmap Set.fromList

With this factored out, the only difference between Part 1 and Part 2 is how we generate our groups of strings. While Part 1 splits each line into two strings, Part 2 process the input in chunks of 3. Full code:

module AOC2022.Day03 (spec) where

import Data.List.Split
import qualified Data.Set as Set
import Input
import Test.Hspec

input :: IO String
input = readDay 2022 3

spec :: IO ()
spec = hspec $ do
  describe "Part 1" $ do
    it "vJrwpWtwJgWrhcsFMMfFFhFp" $ do
      part1 ["vJrwpWtwJgWrhcsFMMfFFhFp"] `shouldBe` 16
    it "runs on custom input" $ do
      myInput <- input
      part1 (lines myInput) `shouldBe` 0 -- redacted
  describe "Part 2" $ do
    it "runs on custom input" $ do
      myInput <- input
      part2 (lines myInput) `shouldBe` 0 -- redacted

commonItem :: [String] -> Char
commonItem = Set.findMin . foldr1 Set.intersection . fmap Set.fromList

splitInHalf :: String -> [String]
splitInHalf s = [take size s, drop size s]
  where
    size = length s `div` 2

charPriority :: Char -> Int
charPriority c
  | 'a' <= c && c <= 'z' = fromEnum c - fromEnum 'a' + 1
  | 'A' <= c && c <= 'Z' = fromEnum c - fromEnum 'A' + 27
  | otherwise = 0

part1 :: [String] -> Int
part1 = sum . fmap (charPriority . commonItem . splitInHalf)

part2 :: [String] -> Int
part2 = sum . fmap (charPriority . commonItem) . chunksOf 3

Runtime analysis

The runtime of Set.intersection is O(m log((n+1)/(m+1))). For similarly sized Sets, the log factor approaches a constant, which is why the runtime for Part 1 is O(n). In Part 2, our best case is that the first intersection results in a single item, after which the remaining intersections run with m=1, or O(log n). In the worse case, however, all but the final intersection share every character, taking the same O(n) time.

The Set from Data.Set is built with balanced binary trees. Another option is Data.HashSet, which would have closer to O(n) runtime for all operations. However, Data.HashSet is missing the findMin function that is so convenient here. While we know our result will contain a single item, HashSets in general are unordered containers with fewer options for lookups.

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

See Also: Day 3 Bonus: Split in Half

Next: Day 4: Camp Cleanup Previous: Day 2: Rock Paper Scissors

splitInHalf :: String -> [String]
splitInHalf s = [take size s, drop size s]
  where
    size = length s `div` 2

Prelude (essentially Haskell's standard library) has a function splitAt, which we can use:

splitInHalf :: String -> [String]
splitInHalf s = [s1, s2]
  where
    (s1, s2) = splitAt (length s `div` 2)

Converting from the tuple to the list should be unnecessary. Let's try chunksOf?

splitInHalf :: String -> [String]
splitInHalf s = chunksOf (length s `div` 2) s

Point Free?

We can convert the above function into a point-free style. Look at the form of our functions:

splitInHalf :: String -> [String]
halfLength :: String -> Int -- (`div` 2) . length
chunksOf :: Int -> String -> [String]

(r ->) is an instance of a monad, so let's factor (String ->) out from our types and see what's left. We replace each function (String -> a) with m a:

splitInHalf :: m [String]
halfLength :: m Int
chunksOf :: Int -> m [String]

So is there a function that can take our halfLength and chunksOf and returns our function splitInHalf? It would have the type of m a -> (a -> m b) -> m b. It does exist, it's called "bind" (>>=), and it's kinda the core functionaly of monads!

splitInHalf :: String -> [String]
splitInHalf = (`div` 2) . length >>= chunksOf

Using the flipped version of bind brings another new perspective:

splitInHalf :: String -> [String]
splitInHalf = chunksOf =<< (`div` 2) . length

This looks similar to our original, but composed of functions instead of values.

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Main Post: Day 3: Rucksack Reorganization

OpenAI recently released ChatGPT, an interactive language model for dialogues. It is built with some functionality to refuse inappropriate requests. Trending on HackerNews today is a post describing all of the way people have found to circumvent that filter. One of the most popular is to phrase the prompt as make believe. So that's what we're doing today. We're not cheating at Rock Paper Scissors; we're simply playing a character that would cheat at Rock Paper Scissors.

A Naive, But Solid Approach

The scoring for a single round of Rock Paper Scissors is based on two simple rules. One of them is dependent on the shape you throw (3 options), and the other is dependent on the outcome of the game (shapes you and your opponent throw, 3 * 3 == 9 options). That's not that many cases! Let's just hardcode them.

module AOC2022.Day02 (spec) where

import Control.Applicative
import Input
import Test.Hspec

input :: IO String
input = readDay 2022 2

spec :: IO ()
spec = hspec $ do
  describe "Day 2" $ do
    it "solves part 1" $ do
      myInput <- input
      part1 myInput `shouldBe` 0 -- redacted
    it "solves part 2" $ do
      myInput <- input
      part2 myInput `shouldBe` 0 -- redacted

part1 :: String -> Int
part1 = sum . fmap score . lines

score :: String -> Int
score = liftA2 (+) scoreShape scoreOutcome

scoreShape :: String -> Int
scoreShape [_, _, 'X'] = 1
scoreShape [_, _, 'Y'] = 2
scoreShape [_, _, 'Z'] = 3
scoreShape _ = 0

scoreOutcome :: String -> Int
scoreOutcome "A X" = 3
scoreOutcome "A Y" = 6
scoreOutcome "A Z" = 0
scoreOutcome "B X" = 0
scoreOutcome "B Y" = 3
scoreOutcome "B Z" = 6
scoreOutcome "C X" = 6
scoreOutcome "C Y" = 0
scoreOutcome "C Z" = 3
scoreOutcome _ = 0

part2 :: String -> Int
part2 = sum . fmap score2 . lines

score2 :: String -> Int
score2 = liftA2 (+) scoreShape2 scoreOutcome2

scoreShape2 :: String -> Int
scoreShape2 "A X" = 3
scoreShape2 "A Y" = 1
scoreShape2 "A Z" = 2
scoreShape2 "B X" = 1
scoreShape2 "B Y" = 2
scoreShape2 "B Z" = 3
scoreShape2 "C X" = 2
scoreShape2 "C Y" = 3
scoreShape2 "C Z" = 1
scoreShape2 _ = 0

scoreOutcome2 :: String -> Int
scoreOutcome2 [_, _, 'X'] = 0
scoreOutcome2 [_, _, 'Y'] = 3
scoreOutcome2 [_, _, 'Z'] = 6
scoreOutcome2 _ = 0

OK, so it's a little long, but I doubt there is a simpler, more understandable approach. The only real trick is the use of liftA2 to convert + from an operator on numbers to an operator on functions. For further reading, check out Learn You A Haskell's chapter on Applicative Functors, especially regarding instance Functor ((->) r).

Who Needs Simple?

While the code is working just fine, there is something deeply unsatisfying about such repetitive statements. My goal isn't to strictly minimize the amount of code, though, so to justify further exploration let's introduce a self-imposed "Part 3": make it work with Rock Paper Scissors Lizard Spock, an extension of Rock Paper Scissors with 5 options.

The key insight is that all games like Rock Paper Scissors Lizard Spock can be represented as a cyclic order. For any game with 2k+1 shapes, each shape has k other shapes that beat it and k other shapes that lose to it. For code golfers, this opens up a plethora of modular arithmetic tricks to aid in solving. We'll focus more on the algebraic side of things.

So let's start with a data type that implements Ord:

data Shape = Rock | Paper | Scissors deriving (Eq, Show)
instance Ord Shape where
  compare x y =
    let minmax = [Rock, Scissors]
     in if x `elem` minmax && y `elem` minmax then compare y x else compare x y```

This compare function is no good! While it may work for our needs, it is not a valid instance of the Ord typeclass, since it is not transitive. (Rock is less than Paper, and Paper is less than Scissors, but Rock is not less than Scissors.)

So we throw that away and create our own typeclass CyclicEnum, using the same code to implement a cycle compare, or ccompare. Given a Shape, we also want to be able to find the Shape that is some number of steps down the cycle, so we introduce another function toCyclicEnumFrom.

class (Bounded a, Ord a, Enum a) => CyclicEnum a where
  ccompare :: a -> a -> Ordering
  toCyclicEnumFrom :: a -> Int -> a
  ccompare x y =
    let minmax = [minBound, maxBound]
     in if x `elem` minmax && y `elem` minmax then compare y x else compare x y
  toCyclicEnumFrom a i = toEnum $ (i + fromEnum a + sizeof a) `mod` sizeof a


sizeof :: CyclicEnum a => a -> Int
sizeof a = 1 + val maxBound - val minBound
  where
    val = fromEnum . (`asTypeOf` a)

With this new algebraic representation, we unfortunately have to parse the strings. Let's assume that in our Rock Paper Scissors Lizard Spock, example, we would use A, B, C, D, and E as well as V, W, X, Y, and Z. We can do some modular arithmetic on the character codes to generalize this:

parseCode :: CyclicEnum a => Char -> a
parseCode = toCyclicEnumFrom minBound . clampAlphabet . fromEnum
  where
    -- A, B, C -> 0, 1, 2 and X, Y, Z -> -3, -2, -1
    clampAlphabet = (`subtract` 13) . (`mod` 26) . (+ 13) . (`subtract` fromEnum 'A')

With our new representation, we can rephrase our scoring function in terms of the underlying enum values. We can also implement the requested behavior from Part 2, to decode the outcome of the game into its actual shapes, using our handy toCyclicEnumFrom function:

decodeGame :: CyclicEnum a => (a, a) -> (a, a)
decodeGame (a, o) = (a, toCyclicEnumFrom a (fromEnum o - sizeof a `div` 2))

Putting It All Together

Here's the full code. Implementing Rock Paper Scissors Lizard Spock is now as simple as adding two new items to the Shape enum!

The proper order of the cycle according to the usual rules would be Rock-Spock-Paper-Lizard-Scissors. Each shape defeats the two preceding items and loses to the two following shapes.

class (Bounded a, Ord a, Enum a) => CyclicEnum a where
  ccompare :: a -> a -> Ordering
  toCyclicEnumFrom :: a -> Int -> a
  ccompare x y =
    let minmax = [minBound, maxBound]
     in if x `elem` minmax && y `elem` minmax then compare y x else compare x y
  toCyclicEnumFrom a i = toEnum $ (i + fromEnum a + sizeof a) `mod` sizeof a

sizeof :: CyclicEnum a => a -> Int
sizeof a = 1 + val maxBound - val minBound
  where
    val = fromEnum . (`asTypeOf` a)

data Shape = Rock | Paper | Scissors deriving (Eq, Show, Ord, Bounded, Enum)

instance CyclicEnum Shape

parseCode :: CyclicEnum a => Char -> a
parseCode = toCyclicEnumFrom minBound . clampAlphabet . fromEnum
  where
    -- A, B, C -> 0, 1, 2 and X, Y, Z -> -3, -2, -1
    clampAlphabet = (`subtract` 13) . (`mod` 26) . (+ 13) . (`subtract` fromEnum 'A')

parseGame :: String -> (Shape, Shape)
parseGame [a, ' ', x] = (parseCode a, parseCode x)

scoreShape :: CyclicEnum a => a -> a -> Int
scoreShape = const $ (1 +) . fromEnum

scoreOutcome :: CyclicEnum a => a -> a -> Int
scoreOutcome they you = (3 *) $ fromEnum $ ccompare you they

score :: CyclicEnum a => (a, a) -> Int
score = liftA2 (+) (uncurry scoreShape) (uncurry scoreOutcome)

decodeGame :: CyclicEnum a => (a, a) -> (a, a)
decodeGame (a, o) = (a, toCyclicEnumFrom a (fromEnum o - sizeof a `div` 2))

part1 :: String -> Int
part1 = sum . fmap (score . parseGame) . lines

part2 :: String -> Int
part2 = sum . fmap (score . decodeGame . parseGame) . lines

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 3: Rock Paper Scissors Previous: Day 1: Calorie Counting

Day 1: Calorie Counting is a bit of a warm-up, as usual for the first day's challenge. This year, we have input like this:

1000
2000
3000

4000

5000
6000

7000
8000
9000

10000

Each grouping represents the snacks carried by a single elf, and each line is the calorie count for an individual snack. In Part 1, we need to sum up each group and find the greatest. In Part 2, we need to find the three (3) greatest.

First Solution

Here's my first attempt at solving the problem.

import Data.List
import Data.List.Split
import Input
import Test.Hspec

input :: IO String
input = readDay 2022 1

spec :: IO ()
spec = hspec $ do
  describe "Day 01" $ do
    describe "Part 01" $ do
      it "runs on custom input" $ do
        myInput <- input
        part1 myInput `shouldBe` 0 -- redacted
    describe "Part 02" $ do
      it "runs on custom input" $ do
        myInput <- input
        part2 myInput `shouldBe` 0 -- redacted

part1 :: String -> Int
part1 = maximum . calorieCounter

part2 :: String -> Int
part2 = sum . take 3 . reverse . sort . calorieCounter

calorieCounter :: String -> [Int]
calorieCounter = fmap (sum . fmap read . lines) . splitOn "\n\n"

I use Hspec to run my code as a test suite. Once I find the correct answer, I add it as an expectation. This allows me to refactor my code more easily, either in solving Part 2 or in cleanup afterwards. Input.readDay is a simple helper method that reads my input file from a local directory.

Polishing

There were a few things I wanted to improve with this solution:

1. Part 1 and Part 2 can both be viewed as "Take the N greatest elves and sum them". But the code for Part 1 and Part 2 were pretty different. I wanted to move the sorting into the calorieCounter, so that it could be used in both parts.
2. reverse forces the full list to be evaluated, so reverse . sort sorts the whole list even when we only need a few top items. The Data.Ord module provides a Down type which can sort in descending order. Combined with sortOn, this allows us to lazily sort only as much of the list as we need to take.
3. Is there any way to simplify the fmap? splitOn can operate on any list, not just Strings (aka, [Char]). We should be able to use lines first, and then split the result into groups, rather than split into groups first, and then fmap lines.

Instead of splitOn "\n\n", we would use splitOn [""]. Since each item in the list is a line, our delimiter is now one item long. We can replace splitOn [""] with splitWhen null.

The final code looks like this:

import Data.List
import Data.List.Split

part1 :: String -> Int
part1 = head . calorieCounter

part2 :: String -> Int
part2 = sum . take 3 . calorieCounter

calorieCounter :: String -> [Int]
calorieCounter = sortOn Down . fmap (sum . fmap read) . splitWhen null . lines

Polish I didn't do:

I'm still using head in part1 instead of sum . take 1. It's not quite equivalent! While head is more concise, it could bottom on an empty input.

sum . take 1 will always return an Int, defaulting to 0 for an empty list. With this option, we could add the number of items to take as an argument to calorieCounter: part1 = calorieCounter 1 and part2 = calorieCounter 3

A third option is listToMaybe, which would return Just 69836 for my input and None for an empty input.

Advent of Code 2022 Series

This post is part of a series describing my Haskell solutions to Advent of Code 2022.

Next: Day 2: Rock Paper Scissors

Today, however, I underwent a larger maintenance task, and moved this site from Heroku (with a custom Node.js server with Express) to Vercel (with a Next.js backend). Here's looking forward to many more years of zero maintenance.

Why The Move?

My primariy motivation for moving now is that Heroku suffered a security breach, and I am worried that Salesforce isn't going to maintain Heroku very well going forward.

While I was migrating providers, there were several other pain points I wanted to address:

• Support Typescript and React to build more quickly.
• Reduce the overhead of adding a new blog post. (Less markup?)
• Refresh HTTPS certificates automatically via LetsEncrypt
• Deploy quickly and easily

Next.js covers the former two points, and deploying with Vercel covers the latter two. Were there other options? Definitely. I could have used any static site generator and a number of deployment hosts (even including Heroku). This isn't an ad. Next and Vercel seem like they will work with minimal effort and comfortable technologies, though, so I'm going for it.

Most of that seems inevitable, but that last piece, the markup, feels like wasted effort. More effort makes writing less enjoyable and widens the gaps between posts, simply because I don't want to be bothered with that hassle again. In an ideal world, I would like to just write the words and post them. Everything else (the paragraph tags, links to external sites, emphasis markers, etc) would be automatically added or inferred based on context. So, what is stopping me from living in that utopia?

A Trend Towards Simplicity

There are a lot of different ways out there to edit content. I will admit that I do bring a lot of the pain of markup onto myself. I use Emacs to author my posts in vanilla HTML. Emacs is not the prettiest editor, and HTML is quite verbose. When I add structure to an HTML document, I am wrapping parts of a content tree in tags. Even the smallest tags, like <p>Paragraph</p> take seven characters to represent. Emphasizing a phrase takes <em>nine whole characters!</em>

There are lighter weight ways to mark up the same structure. In contrast to HTML, Markdown only requires *two characters* to emphasize text. To make a new paragraph, you simply hit enter just like you would in Google Docs or Word. This ease of basic use has made Markdown the defacto standard for marking up rich text across the web. It seems every site has its own flavor.

Does Markdown represent the end up markup in web content? The name itself is a pretty big hint that the answer is no. Markdown is markup. And while it may be easier to write, in fact it still maps 1:1 to HTML. So while Markdown might make my authoring life easier, it is a far cry from a world with no markup.

Markup In Everyday English

What would happen if I dropped markup entirely? This post would just be a stream of sentences with no paragraph tags, emphasis, hyperlinks, or any other information about how different text is supposed to be presented. Even with all of the “excess” stripped away, there is still a structure behind the words: grammar.

I could strip away the grammar, too. For a lot of people, grammar is looked at with the same hatred towards wasted effort that I have toward HTML tags.

lol u da best mate i luv u

The more I strip out, the simpler the result, until what I am left with is so minimal that it seems more of a puzzle than an English sentence. Spaces between words, commas separating clauses, and punctuation marking questions or exclamations — these all add structure and meaning. At some point, if I cut too much out then I lose the meaning entirely. Without markup, there is no meaning.

That, I think, is the key insight. I can strip away all of the markup, grammar, and other structure until all meaning is lost, and then consider the minimal markup to be what needs to be added back in order to reliably convey the message. And what that minimal need will depend on what idea is being conveyed and to whom.

Take Only What You Need

Markup is tedious, but without structure in language, there is no meaning. The trick then, is to use only the markup is needed to convey the message in the way you want. Grammar, sentences, and paragraph structures can help people understand the whole of what I am presenting. Likewise, even things like attractive and accurately styled links can help your message be consumed.

And you may not care only about humans. Search engine indexers and web crawlers may need markup to help parse your post. If it is important to you that they understand your idea as well as human readers do, then it makes sense to spend as much time crafting your message for those consumers as well.

In the end, if you only add markup you need to convey your message, it is inherently semantic. With that perspective, it is not hard to reach that ideal world of going straight from writing your idea down to posting it. In fact, we may already be there.

A lot of people would have a lot of different reactions to that, but I was pleasantly surprised. The question posed was this: If you keep doubling the resolution of a computor monitor, how many pixels will the infinitely divided screen have?

Butterick comes to the conclusion that it is uncountably infinite. In an update, readers had written to him that it is actually countably infinite. He admits that this is so, and explains the error of his ways. There's just one problem...

Butterick was right all along!

The Flaw, or Lack Thereof

In his original argument, Butterick attempts to draw a bijection between the pixels on an infinite resolution screen and the set of infinite binary strings. In the correction, he says that this bijection failed to actually map any pixels. I think the bijection is sound, though. Let me see if I can get the actual mapping down.

Mapping Pixels to Binary Strings

Each pixel is somewhere on the screen. Let's assume it's a square screen, and assign coordinates to the corners. Top left is (0,0) and bottom right is (1,1). Anywhere in between can clearly be addressed by a coordinate pair.

Note that we only care that each pixel can be a coordinate pair, not that all coordinate pairs will necessarily be used. That's the next section.

Given a pixel, we map it to a binary string by dividing the space like Butterick did. For each digit, we divide the space in half, alternating horizontal and vertical. If the digit is on the left or top, we set the digit to 0. Bottom or right gets a 1. If it is precisely on the line, we'll give it a 0 and keep going. We continue this process indefinitely, thus constructing the string that perfectly matches the pixel.

Every pixel is somewhere in the space, and so every pixel will map to a binary string. Further, the pixels are infinitely small, and so the binary string will be of infinite length.

Mapping Binary Strings to Pixels

Can each infinite binary string map to a pixel? I believe so. When we split the resolution of the monitor, we cut each pixel into four parts. When taken in pairs, we can use binary strings to map which of the resulting pixels we are talking about. 00 means top-left, 01 means top-right, 10 means bottom-left, and 11 means bottom-right.

Because of the manner of splitting, after an infinite process of these pairs, we will have followed the splits to the exact pixel. Further, each binary string represents a unique sequence, and so each string will map to a unique pixel.

So, not only does every pixel map to an infinite binary string, but every infinite binary string maps to one of our infinitely-small pixels. Bijection accomplished; there are uncountably many pixels.

More Intuition

There's another way of thinking about this which might help you believe that the mapping works. Suppose that we had split the screen in ten pieces in each dimension instead of two. We'd be left with 100 times the pixel each time. From there, consider the coordinate location of each pixel.

After one split, you'd have pixels at locations like (0.1,0.3) or (0.7,0.8). You'd never have anything smaller than the tenths digit showing up in your pairs.

After another split, you'd have pairs like (0.17,0.34) or (0.79,0.81). Again, nothing smaller than the hundredths digit. But do you see the pattern?

After N splits, you can represent any pair with up to N decimal digits. After an infinite series of splits, you'd have infinite digits to work with. And with infinite digits, you can represent any real number between 0 and 1.

There are uncountably infinite real numbers between 0 and 1, and so there must be an uncountably infinite number of pixels.

The Not-So-Flawed Correction

I'm not entirely sure the reasoning of the people who wrote in to correct Butterick, but I can at least comment on the logic of the correction he posted. It wasn't so much flawed as just counting something different.

In the correction, he counts pixels by assigning them to positive integers. By doing so, he claims that since you can map all of the pixels to integers, there must be countably many of them. That's true, and this is all well and good, but it doesn't say anything about the ininite resolution screen.

You see, the set of all of the pixels of all finitely-sized screens in all the world, no matter what their resolution, is countably infinite. But these are finite resolutions, not our “infinity screen.” It's a subtle disctinction, but an important distinction.

That's All I've Got...For Now

I hope this does something to clear up the issue (and I hope Internet Folks will tweet me if I'm wrong). Problems like this are really fun to think about. I'm done for now, but I think there is another followup post coming soon. Infinity is a weird thing. Be wary of it.

In summary, the post showed the interesting way that method works using the revealing module pattern. Since you are defining function statements and exposing them through an object literal, this may not always refer to what you'd expect. Specifically, this will refer to the returned object literal, allowing you to chain methods within that publically exposed API.

I've written a decent amount of JavaScript using the revealing module pattern, so this wasn't exactly news to me. I wasn't shocked that you can write methods that chain using that pattern. Instead, the most thought provoking aspect of the article was the almost-footnote at the end: this doesn't work for private methods. Because this refers to the object literal, you cannot use it to chain any private or protected methods that you may have defined within the same constructor closure.

Can we fix that? Maybe.

A New SimpleCache Module

To do this, we first need a new SimpleCache module with a private method. I added one public method, init, which can be called to insert dummy values. For the sake of this example, init in turn calls two private methods using chaining: initSome and initMore. Here's the code:

// Create an instance of our cache and set some keys. Notice that the [new] operator
// is optional since the SimpleCache (and revealing module pattern) doesn't use
// prototypical inheritance. And, we can use method-chaining to set the cache keys.
var cache = SimpleCache().init();

output = document.getElementById('output')
output.innerHTML = cache.get('a') || false;


// ---------------------------------------------------------- //
// ---------------------------------------------------------- //


// I provide a super simple cache container.
function SimpleCache() {

    // Create an object without a prototype so that we don't run into any cache-key
    // conflicts with native Object.prototype properties.
    var cache = Object.create( null );

    var priv = {
        get: get,
        has: has,
        remove: remove,
        set: set,
        init: init,
        initSome: initSome,
        initMore: initMore
    };

    var publ = {
        get: get.bind(priv),
        has: has.bind(priv),
        remove: remove.bind(priv),
        set: set.bind(priv),
        init: init.bind(priv)
    };

    // Reveal the public API.
    return(publ);


    // ---
    // PUBLIC METHODS.
    // ---


    // I get the value cached at the given key; or, undefined.
    function get( key ) {
        return( cache[ key ] );
    }


    // I check to see if the given key has a cached value.
    function has( key ) {
        return( key in cache );
    }


    // I remove the given key (and associated value) from the cache.
    // --
    // NOTE: Returns [this] for method chaining.
    function remove( key ) {
        delete( cache[ key ] );
        return( publ );

    }


    // I cache the given value at the given key.
    // --
    // NOTE: Returns [this] for method chaining.
    function set( key, value ) {
        cache[ key ] = value;
        return( publ );

    }

    // I initialize the cache with some dummy values
    // --
    // NOTE: Returns [this] for method chaining.
    function init() {
        this
          .initSome()
          .initMore();
        return ( publ );
    }

    // ---
    // PRIVATE METHODS
    // ---

    // I initialize the cache with some dummy values
    // --
    // NOTE: Returns [this] for method chaining.
    // NOTE: Private
    function initSome() {
        this
          .set('a', 'Alice')
          .set('b', 'Bob')
          .set('c', 'Carol');
        return ( this );
    }

    // I initialize the cache with some more dummy values
    // --
    // NOTE: Returns [this] for method chaining.
    // NOTE: Private
    function initMore() {
        return this
          .set('x', 'foo')
          .set('y', 'bar')
          .set('z', 'baz');
        return ( this );
    }

}

A Separate Object, with Bound Public Methods

Notice that all of our methods, both public and private, are defined in the same way as before. Additionally, we create explicit publ and priv objects. When we expose our methods on the public object, we bind them to the priv object. This ensures that internal functions can call each other with chaining, as they will all be bound to the same object.

Lastly, in our public chained methods, we return publ instead of this. That way, public users of our SimpleCache are never given a reference to the private object, and instead are always passed the publicly exposed API. Note that public methods can still chain to other public methods.

Is This Actually Useful?

In his original post, Ben questioned the usefulness of chaining private methods. The example above is admittedly contrived just for this purpose. I don't know that I've seen any real case for this in the wild, and the dual-object approach is awfully complex for what it accomplishes. Not to mention the issues this could cause with prototypal inheritance and method lifting. When you bind the public methods, the consumer of the module loses the ability to redirect this to something else. Is throwing a wrench at your module's users worth it for slightly easier to use private methods?

Defining extra objects and binding functions also increases the memory footprint of your module. Each time you create one of these new SimpleCaches, you are eating up just a little more of your user's browser resources.

So, in the end, while this was an interesting thought experiment, I really cannot see anybody doing this in an actual project. What do you think? Agree or disagree? Have a better way of doing it? Let me know on Twitter.

What I used:

Update: OnSIP has since removed their developer offering.

• SIP.js and an OnSIP Developer account - This would work using the vanilla WebRTC API as well. I used OnSIP since it's what I'm familiar with (I'm not trying to do a sales pitch here).
• Flac.js and Aurora.js - Put out by Audiocogs, these libraries let you load and play FLAC files in your browser using the Web Audio API. They have several other codecs available as well.
• A FLAC file to play. I used Coldplay's Sky Full of Stars. The actual song chosen probably doesn't matter.
• Chrome, for the browser transmitting the FLAC file. Firefox gets finicky about sending certain MediaStreams over WebRTC.

Putting it together

Wiring these pieces up really could not have been much easier. Flac.js and Aurora.js together provide a simple way to preload and decode the FLAC file, and they also spit out events implementing the same interface as SIP.js! Since Aurora.js plays the file using a source context, all we have to do is grab that and connect it to a new MediaStream destination. From there, SIP.js can take the stream and offer it in place of your regularly captured microphone audio.

In the end, the explanation is probably longer than the code itself.

<script src="aurora.js"></script>
<script src="flac.js"></script>
<script src="sip-0.6.3.js"></script>

// Load the FLAC file
window.player = AV.Player.fromURL('http://localhost/path/to/file.flac')
player.preload()

player.on('ready', function () {
  console.log('ready')

  // Aurora doesn't create the audio context until you start playing it.
  player.play()
  player.pause()

  // Wire the WebAudio source and destination together.
  var dest = player.device.device.context.createMediaStreamDestination()
  player.device.device.node.connect(dest)

  // Send the stream to a destination using SIP and WebRTC.
  new SIP.UA()
    .invite('listener@example.onsip.com', { media: { stream: dest.stream } })
    .on('accepted', function () {
      player.play()
    })
})

When you load the page, it will fetch the specified FLAC file and start preloading it, before calling the specified SIP address. I pointed it to my OnSIP address and was able to receive the call in InstaPhone. The call showed up like any normal call, and when I answered it, the music began playing!

What's next?

Playing a FLAC file over WebRTC using under 20 lines of JavaScript! I know I have plans of building some cool things with this. Streaming music from my Pi to my phone? Sure! Preloading my playlist so it can stream even while I am on the subway? You bet! What about you? If you have some crazy ideas, head over to Twitter and share them!

Just remember, if you are playing music over WebRTC, mind the licenses. I plan on sending music only to myself, and only music that I have purchased. I would advise a similar level of copyright caution to any other experimenters.

It has been over a year since curiosity got the best of me and I purchased a Raspberry Pi. And how could I not? At less than $50, you get a little computer, complete with an ethernet jack, HDMI out, and a couple of USB ports to boot, all running off of a 5V 1A micro USB charger. I had about a dozen of those chargers lying around unused, since day-to-day charging of my phone, Kindle, etc really only required one or two in circulation.

So, I ordered a Raspberry Pi. And boy was I excited! I dreamed of connecting the ethernet ports already wired through my apartment's walls and turning them into my own version of Stark's JARVIS. When the Pi arrived, though, there were difficulties. It turned out the SD card was DOA, and so my Pi was shelved, one operating system short.

I've since moved out of that wired up apartment (and in with my SO, which I would consider a very worthwhile trade), but I still get that tingly sensation when I think of smartening my living quarters with some custom tech. The new apartment tends to hold pockets of uncomfortable heat as well, so the low power usage of the Pi is incredibly appealing.

And so, the Pi came off the shelf and back into the workshop (read: corner of my desk). I'm still not sure entirely what I am going to build with the Pi (perhaps something music related), but I am happy to say that I managed to get it primed and ready for development. Here's the rundown of the setup process.

The SD Card and Operating System

As I dove back into this, I was optimistic that I could get things working, but I really didn't know exactly what had gone wrong the first time around. Possible scapegoats were the SD card, fluctuating power from a weak charger, or maybe even a hardware issue on the Pi itself. The first step was to debug the SD card.

I don't use SD cards for anything, really, so I wasn't sure how to debug it. Neither my work laptop or home PC could read them, and I didn't have any customized reader on hand. But, on a stroke of luck, my SO's laptop (an older Macbook) actually had a slot to read it! Strange that the ports change so much between generations on those. Anyways, the laptop didn't recognize the card, but it was reading others fine. I guess the original SD card was dead all along.

This is where I opened up my Amazon cart and starting dropping things in. I decided not to bother getting a blank card and writing the OS image manually, so the first item in my card was the NOOBS SD card. I also added a four port powered USB hub and a case for the Pi.

The NOOBS card was really great. Disk images and bootable media have always been a real source of pain for me. This card removes all of the worry by packing several Linux distros right there for you to pick from. No messing around with disk partitions or boot flags. Just plug in a keyboard, scroll down to your choice OS, and go. I went with Arch Linux, to match my PC.

Lesson: Don't give yourself unnecessary hardship before you even start.

With Little Power Comes Great Responsibility

At this point, I could boot up the Pi and log in as root. Awesome! Next stop, Wifi. I wasn't planning on keeping this within close proximity to the router, so getting a USB Wifi dongle configured was my top priority. I started reading up on netctl and interfaces and...

Keyboard is dead.

Unplug it, plug it back in. Nothing. Reboot the Pi. Nothing. sigh Nothing. (Okay, I didn't really expect that to work.) Switching USB ports worked, for a while. Then the second would go down and the first would work again. Something weird was going on.

It turns out that both USB and the Pi itself have mechanisms in place to limit the current flowing through them. This can make things like USB keyboards and Wifi dongles stop working, but on the bright side, the device doesn't catch fire and burn down the surrounding domecile. It's a trade-off. The trick is, these mechanisms (called polyfuses) don't clear right away. You have to set them down, walk away, and come back hours or days later.

It took me a lot of trial and error to get a reliable power situation running, where devices had enough consistent electricity without driving the current up to the point of killing the Pi. It looks something like this:

The power cable coming into the Pi is slightly better than your average phone charger, supplying 1.2 Amps at 5V. This gives a little flexibility for powering the Pi itself and any device connected directly to it. In this case, that's the keyboard (the HDMI monitor has its own power, and the other USB goes to the powered hub).

The USB hub from Amazon manages the power for the USB dongle, as well as other USB devices I plan to connect (like an external hard drive). It supplies 2.5 Amps, which is more than enough for the Wifi dongle. I haven't tried the external drive yet, so this may take more tweaking.

As an aside, don't try to power the Pi from the hub. I did this, thinking it could draw from the hub's excess power while still looking at the other devices on the hub. Instead, it dropped into a hard reboot cycle that I'm surprised didn't cause significant corruption to the SD card.

Lesson: Power is finicky when there isn't much of it.

To the Internet!

Okay, Wifi for real this time. Once I had the power set up properly, Wifi was a lot easier to get going. It turns out that most of my problems were caused by the dongle not having power and becoming unreachable. Those went away, and the packets flowed.

Along the way, though, I had a fair share of netctl errors. Tracking them down was tricky, as the system time would reset to 1969 each time the Pi booted. Logs were buried and debug information was hard to come by. I found myself manually setting the time to January 2014, and stepping forward a day each time the system booted.

Once the time was temporarily fixed, I managed to get to the Internet. That let me use NTP to get the real time. The last step was setting them both to happen on startup with systemctl. Everything went pretty smoothly from there.

One system update and a few pacman installs later, I have a working system. It even runs Node:

Next Stop, Adventure!

Now that the basic system is set up, I'm stoked to get something real up and running. The sky is the limit, and there's not a butt in sight.

Browsers nowadays provide lots of ways to personalize your experience. Firefox has its Add Ons and Chrome has Extensions. These can be great for enhancing your browser, from increasing productivity, personalizing themes, or even adding just a little humor to your day to day surfing.

Extensions can be dangerous, though. From extensions with poor security to AdWare vendors taking advantage of auto-updates to install malware in previously trusted extensions, you have to keep as watchful eye on extensions as any software you would install and run on your computer. But there's one danger that I doubt any security or news outlet will warn you about:

Butts.

That's right. Last week, I tried out a very popular (and I admit, hilarious) Chrome extension Cloud to Butt Plus. Install this little extension and it will do one thing: replace every instance it finds of the 'cloud' (or 'the cloud') online with 'butt' (or 'my butt'). I guarantee if you install this extension, you will forget about it until it strikes hours or days later. Hilarity ensues. But it's not all fun and games...

Cloud to Butt replaces every cloud it finds, regardless of where in the page it is. This includes unexpected places, such as input fields. Just last week, while working on the website at work (by the way, have you seen the new section for developers?), I signed into Drupal to edit a couple pages. As the page content loaded to be edited, Cloud to Butt happily traversed the text areas, explaining everything you would want to know about butt-based architectures and undersubscribed butt networks.

So beware, anybody who works with butt storage or who would like to harness the power of my butt. You never know when a humorous extension may really surprise you.

It's Cooler in my Mind

When I first set out, I had this grand vision of sailing a pirate ship through unknown waters, shooting cannonball at firebreathing dragons. I knew it would be a challenge to fit all of the features I wanted into 1K, but I opted for overshooting rather than trying to come up with an idea that sounded suitably bite-sized. Maybe I would surprise myself, or 1024 bytes would turn out to be more than it sounds.

It didn't. 1K is tiny. I wasn't familiar with the Canvas API, so I decided to go the DOM route. First of all, that was a huge mistake. DOM is not only harder to draw things with than a canvas, but also incredibly expensive to style. Who has room to type out 'background-color' or '-webkit-transition' when those precious bytes could be going to add clouds or random spawn points? But at this point, I was committed to making it work as best I could. There's always next time to try something new.

Let's Break It Down

Before I go further, you may want to check out the demo on JS1K to see what I'm talking about. It's not pretty. You should really look at some of the awesome things other people made as well. But anyways, if you've decided to stick around, below I'll walk through the entire source code. Don't worry, it's not too long.

The first part just removes the canvas using the provided function. I also included a block comment at the top of the file, to help myself keep track of different variables. The final portion of this chunk defines a few of those variables.

/* a b - body c - ship d - dragon e f g h i - mouse X j - mouse Y k l m M - Math n - setTimeout o - setInterval p - 'px' q r s - 'style' t - 1000 u - 400 v - 50 w x y z */

n = setTimeout; o = setInterval; t = 1000; u = 400; v = 50; M = Math; p = 'px'; s = 'style';

<p>As it turns out, CSS was a huge cost.  I factored out all of the styling for the dragon, the pirate ship, and even the background into this one function <code>setStyles</code>.  It uses a <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with"><code>with</code></a> statement to save precious bytes on property access.  I was running the code through the <a href="https://developers.google.com/closure/compiler/">Google Closure Compiler</a>, so I wasn't worried about the long function name; it would get changed to a single character later.</p>

```javascript
function setStyles(q, l_background, l_height, l_width, l_top, l_left, l_transition, l_visibility) {
  with(q[s]) {
    position = 'absolute';
    background = l_background;
    height = l_height + p;
    width = l_width + p;
    top = (q.T = l_top) + p;
    left = (q.L = l_left) + p;
    transition = l_transition;
    visibility = l_visibility;
  }
}

Next, I create the pirate and the dragon. They live as DIV elements, styled appropriately. Note the expensive (read: long) names of the DOM methods. createElement, appendChild, and innerHTML are almost as painful as the CSS properties above. The colors are wasting bytes as well, but that was just laziness.

// Create pirate and dragon
function createBlock(isDragon) {
  var q = document.createElement('div');
  isDragon ?
    setStyles(q,'green',v,v,v,v) :
    setStyles(q,'brown',20,v,u,u);
  isDragon ? (d=q) : (c=q);
  b.appendChild(q);
  q.h = q.innerHTML = 5;
}
setStyles(b,'skyblue',t,t);
createBlock(0);
createBlock(1);
d.U = d.L;
c.U = c.L;

The bullet code was interesting. I had originally planned to fire the bullet to the mouse, or perhaps at a set distance from the boat. After I saw how little room I had to work, collision detection and aiming went out the window. Instead, the bullets animate from the ship to the dragon, or vise versa, using a CSS transition. When they are done, they are hidden. This code also includes the health tracking. Starting healths are cached on the objects, and if the target drops to 0, it is reset to its original health, as well as its position.

// Create or update a bullet (cannonball or fireball)
function bulletStyle(fromShip, start, u) {
  u || (u = document.createElement('div'));
  var t = (fromShip ^ start) ? d : c;

  setStyles(u,fromShip?'#000':'orange',5,5,t.T+25,t.L+25,
           'top 1s,left 1s,visibility 1s',start || 'hidden');
  return u;
}

// Fire a bullet
function bullet(fromShip,target) {
  var u = bulletStyle(fromShip,1);
  b.appendChild(u);
  n(bulletStyle.bind(0,fromShip,0,u),0);

  n(function () {
    if (!--target.h) {
      target.h = 5;
      target.T = target.U;
      target.L = target.U;
    }
    target.innerHTML = target.h;
  }, t);
}

// Fire cannon on click
this.onclick = bullet.bind(0,1,d);

This code rotates the ship with the mouse, moving the dragon in the opposite direction. I hoped this would give the impression of sailing across the open seas, although some imagination is definitely required. Updating the DOM on every mouse move proved too expensive, so I simply update the mouse position and update the DOM on an interval about 40 times per second. (Remember that o is setInterval.)

// Pirate follows mouse
b.parentNode.onmousemove = function (e) {
  i = e.x;
  j = e.y;
}
l=i=j=1;

o(function () {
  var dstyle = d[s];
  var cstyle = c[s];
  var a = M.PI/2-M.atan2(i-u,j-u);

  if (!--l) {
    l = 5;
    cstyle.webkitTransform = cstyle.transform = 'rotate(' + a + 'rad)';
  }
  dstyle.top = (d.T = (d.T - M.sin(a)+t) % t) + p;
  dstyle.left = (d.L = (d.L - M.cos(a)+t) % t) + p;
}, 24);

o(bullet.bind(0,0,c),3*t);

Room For Improvement

Just about every aspect of this could benefit from some love. From using requestAnimationFrame for better performance or avoiding strings for colors, all the way to massive overhauls such as, you know, not destroying the canvas and using the DOM instead, I could have done a lot better. There are still a couple weeks before the contest ends, so I may revisit it, though I don't expect I have a chance of winning.

I did, however, learn an immense amount from this challenge. Working under the 1K restriction forced me to think about cost differently. Day to day, I develop WebRTC applications designed for modern browsers on good networks. The size of the JavaScript file is almost never a factor in our technical decisions. Finding myself suddenly worrying about the length of CSS properties was an interesting twist. I would highly recommend giving it a try. Even if your final product isn't a masterpiece, you'll learn to think about your code in a completely different way. And hey, you'll probably still do better than I did.

One-Pass DOM Query

In the original article, the JavaScript used document.querySelectorAll to find the accordions, and then another accordion.querySelectorAll to find the click targets within each accordion. This forces the browser to traverse the DOM of the accordions at least twice (more for nested accordions). We can avoid this by querying for only the click targets, and then implicitly finding the accordions from there. Here's the CodePen:

(function () {
  var accordions, targets, ancestor, i;
  
  if(!document.querySelectorAll || !document.body.classList || !Array.prototype.indexOf) return;
  
  targets = document.querySelectorAll('.accordion > section > h1');
  

  for (i = 0; i < targets.length; i++) {
    ancestor = targets[i].parentNode.parentNode;
    if (!ancestor.classList.contains('js')) {
      ancestor.accordionTargetBehavior = (function () {
        var currentTarget;
        
        return function () {
          if (currentTarget)
            currentTarget.classList.remove('expanded');
          currentTarget = this.parentNode;
          currentTarget.classList.add('expanded');
        };
      })();
    }
    
    targets[i].addEventListener('click', ancestor.accordionTargetBehavior, false);
    ancestor.classList.add('js');
  }
})();

Instead of querying for the accordions, we go straight for the heading elements with document.querySelectorAll('.accordion > section > h1'); and use parentNode to find the accordion from there. We also take advantage of the .js class, previously just used to mark accordions as active, to avoid initializing an accordion twice.

Finally, we cache the click handler function on the accordion element itself, where it can contain a reference to the currently expanded element in a closure. Each heading in the accordion uses that same function, and therefore has the ability to update the current target.

I ran this variation through jsPerf to see if the changes actually made a difference, and by golly they did! In both Chrome and Firefox, speeds increased by factors of 2 to 4. You can see the full results and run the tests yourself on the Accordion Selection jsPerf page.

DL-DD-DT - Using Definition Lists for Accordions

When looking for examples of accordions in the wild, I came across this one on Mozilla's Mobile Firefox FAQ page. The list itself uses an unordered list, but each section contains question and answer pairs represented as a definition list. Wouldn't it be cool if the questions themselves expanded out to show the answers?

Unfortunately, as shown by the examples on MDN, definition lists have a man-to-many relationship between terms and definitions. This, along with their flat structure, makes selecting sections of definition lists challenging. With a little help from CSS3 general sibling selectors, we can get past these hurdles.

See the Pen Accordion Variation - dd by Will Mitchell (@wakamoleguy) on CodePen.

The HTML is a simple definition list. Note that Firefox and Chrome both have multiple definitions. The JavaScript is tweaked to select on definition elements rather than sections, but is otherwise the same as the original.

The CSS is where the magic happens. There are three main selectors at work here. .accordion.js > dt.expanded ~ dd selects all of the definitions following an expanded term. For example, if Chrome is expanded, it will find the Chrome definitions and the Internet Explorer definition. We need to make sure that the IE defintion has CSS of a higher priority applied to it. For that, .accordion.js > dt.expanded ~ dt:not(.expanded) ~ dd does the trick. After an expanded term, it finds the next unexpanded term, and then selects all of the definitions from then on. Finally, we need a way to select the definitions before the expanded term. .accordion.js > dt:not(.expanded) ~ dd gets the job done. Note that this is lower priority than the expanded selector, and won't interfere with those styles.

This still doesn't deal with multiple terms that share one definition, although I don't think that would be very difficult. Using JavaScript to mark all those terms as expanded or cleverly applying the adjacent sibling selector (+) would probably work.

Keyboard Navigation

Our original accordion was not very friendly to keyboard users. It would be nice if we could Tab between accordion headings and expand them by pressing Return. Well, we can with just a little extra markup. By adding 'permalinks' to each heading, we automatically get keyboard access. Pressing enter will invoke the 'click' handler, as well. We just need to be sure to prevent the default behavior of the event to avoid page jumping. Go ahead and click inside the CodePen and use Tab, Shift+Tab, and Return to test it out.

See the Pen Accordion Variation - Keyboard by Will Mitchell (@wakamoleguy) on CodePen.

Multiple Selection

Sometimes it's important to be able to expand multiple sections of the accordion at once. This is an incredibly easy modification...just get rid of tracking the currentTarget:

See the Pen Accordion Variation - Multiple by Will Mitchell (@wakamoleguy) on CodePen.

Accordion? Nah, let's do tabs.

You've spent all this time on an accordion list, and now the designer comes to you saying that accordions are out and tabs are all the rage. Hours of work starting from scratch? Nah! Just a few CSS changes. That's right. All of this uses the same JavaScript and HTML as our original accordion.

See the Pen Accordion Variation - Tabs by Will Mitchell (@wakamoleguy) on CodePen.

Conclusion

As you can see, it's easy to quickly expand the realm of possibilities, even from a base as simple as the vanilla accordion widget. What is important to your website or application? Performance on slower devices? Keyboard controls for accessibility? Most, if not all, of these variations can be mixed and matched, too. And hey, if you are inspired to create your own variations or you found this article helpful or even if you hated it, tweet me about it.

Rather than give up, I decided to break it up into two posts. In this one, I'll show off a very basic, almost primitive accordion list. In a future post, I will go over many different behavioral, semantic, and stylistic directions to take to customize an accordion list to fit your exact needs.

In the end, the goal is not to create a one-size-fits-all widget that is perfect for everybody. That is the kind of goal best suited for frameworks. The goal is to show what is possible with vanilla JavaScript, because sometimes you don't need to download an extra 80K just to make a section of your site collapsible.

Anyways, enough of that. Here we go.

The HTML

A lot of different structures could be turned into an accordion list. From jQuery UI's unsemantic <div>s and <span>s to ordered or unordered lists to even <dl> definition lists, just about anything can play the role of a collapsible set of content blocks. For this basic accordion, I chose to use HTML5 <section> elements, as I felt it made the example the cleanest.

<section class="accordion">
  <section>
    <h1>Yesterday</h1>
    <p>I was sick yesterday, so not much happened.</p>
  </section>
  <section>
    <h1>Today</h1>
    <p>I have a bunch of things to do today:</p>
    <ul>
      <li>Grocery shopping</li>
      <li>Stop at the bank</li>
      <li>Dinner and a movie</li>
    </ul>
  </section>
  <section>
    <h1>Road Blocks</h1>
    <p>I'm sick!<p>
  </section>
</section>

There's not much to see: a section to become an accordion and three sub-sections to hide and show. I've included a nested list just to prove that the accordion is fairly robust in what content it can show. The outer <section> gets the class accordion, but otherwise there is no extra markup. Remember that if JavaScript is disabled or fails to load, the user will still see the HTML. Keep it clean.

The JavaScript

The most basic accordion has very simple behavior. In the beginning, all list items are collapsed; only the heading content is visible. On interacting with the heading (click or touch, for example), the other content in the list item expands out and becomes visible, at the same time collapsing any other items. Here is the code, followed by an in-depth explanation.

(function () {
  var accordions, i;

  // Make sure the browser supports what we are about to do.
  if (!document.querySelectorAll || !document.body.classList) return;

  // Using a function helps isolate each accordion from the others
  function makeAccordion(accordion) {
    var targets, currentTarget, i;

    targets = accordion.querySelectorAll('.accordion > * > h1');
    for(i = 0; i < targets.length; i++) {
      targets[i].addEventListener('click', function () {
        if (currentTarget)
          currentTarget.classList.remove('expanded');

        currentTarget = this.parentNode;
        currentTarget.classList.add('expanded');
      }, false);
    }

    accordion.classList.add('js');
  }

  // Find all the accordions to enable
  accordions = document.querySelectorAll('.accordion');

  // Array functions don't apply well to NodeLists
  for(i = 0; i < accordions.length; i++) {
    makeAccordion(accordions[i]);
  }

})();

Okay, so there's a lot going on in just a few lines of code. Let's break it down.

Short Circuit When Unsupported

We depend on the browser having implemented element.classList (Can I use...) and Document.querySelectorAll (Can I use...). If they don't have those, the accordion won't work. Rather than crash, we detect this and exit cleanly.

Find Things Once

DOM access is slow. We deal with this by fetching everything we need up front and caching it for later. This especially shines when clicking to expand a new section. We could search the sections siblings for any expanded sections, but that is slow and tedious. Instead, we hold on to the currently expanded section so we have it ready to go. And when we do click a new section, all we have to do is swap a couple classes and update the variable. Easy-peasy!

Some of you may be saying "But hey! Aren't you doing a whole bunch of querySelectorAll calls? Doesn't that traverse the DOM way more than it needs to?" Umm...yeah. A clever person could find a way to traverse the DOM once, looking only for accordion sections' heading elements an inferring the outer accordion from there. Perhaps that will make a return visit in another post. For now, I'm satisfied not having to go back to the DOM after initialization.

Mark Working Accordions

accordion.classList.add('js');

This may seem unnecessary, but it's imperative to keeping the accordion accessible. Remember that for modern browsers which can support the accordion, we would like to start with the headers collapsed. And yet older browsers should see expanded content. We accomplish this by adding the .js class to the accordion. This marks it as enabled and provides a CSS hook to style on.

The CSS

This is where our hard work in JavaScript land will pay off. By adding relevant classes to a semantic HTML structure, the CSS involved becomes fairly simple. I left off vendor prefixes. Browsers that don't support the full transition effect will gracefully degrade to switching instantly between visible and invisible.

.accordion.js > * {
   overflow: hidden;
}

.accordion.js > *:not(.expanded) > *:not(h1) {
    max-height: 0;
    margin-top: 0;
    margin-bottom: 0;
    opacity: 0;
    visibility: hidden;
}

.accordion.js > .expanded > *:not(h1) {
    max-height: 10em;
    opacity: 1;
    visibility: visible;
}

.accordion.js > * > h1 {
    cursor: pointer;
    visibility: visible;
}

.accordion.js > * > *:not(h1) {
    transition:
        max-height 1s,
        visibility 1s,
        margin 1s,
        opacity 1s;
}

Most of the magic here is hidden in transition the max-height of non-heading children of collapsible content. Ideally, we would like the content to transition from height: 0 to height: auto, but animating to the automatic height of an element isn't possible. Instead, we overshoot with max-height: 10em. The 10em will vary depending on the content; you must pick a value bigger than the content will every display (so as to avoid trimming), but overshooting by too much will cause odd animation timing.

We also strip the vertical margins of collapsed content while they are collapsed, which prevents weird spacing issues. I also like to add an opacity shift, too, to get a fade effect.

Finally, not that each style is protected by the .accordion.js selector, so they will only apply to enabled accordions. Users in older browsers will be shown a block of content with only default styling.

Conclusion

It certainly isn't a silver bullet, but in just 33 lines of (commented, spaced) JavaScript and even less CSS, you can get a nice accordion effect on your page. Here's the final result:

See the Pen Vanilla Accordion by Will Mitchell (@wakamoleguy) on CodePen.

So next time you are creating a web site or web app, don't just run to a bloated UI library. Instead, take a few minutes to assess the situation and decide what you really need. Bytes do affect performance, and sometimes less really is more. You, too, can help get the web back on its vanilla diet.

Tune in next time for some more options on customizing accordions, including different HTML structures, keyboard access, and more!

What is wakamoleguy.com? It's my website. For the time being, that means it's my personal blog. I'll keep the subject matter pretty technical, although I won't commit to talking about any one topic. I'll write what I know. Since I'm currently doing a lot of web development, that probably means mostly JavaScript and HTML5 posts at first.

As I write and accumulate examples, I hope to host those on wakamoleguy.com as well. Experiments and proofs of concept may show up here, too. In the end, I hope it will become my home on the web.

If you experience a delay when visiting this site, please excuse me. I am using free Heroku hosting which takes five or ten seconds to wake up after inactivity. Anyways, thank you for putting up with it, welcome, and enjoy your stay!