Articles from Brian Hicks
We’re in the middle of a series about implementing functional data structures in Elm.
In part one we implemented the skeleton of our sets using a binary search tree.
Last week, part two, we added membership tests and size to our set.
This week we’re going to make a quick pit stop to talk about how folds work, and next week we’ll implement them for our set.
Now that our trees balance themselves we can keep replicating the built-in set API.
This week, we’ll answer two questions:
- Is an item in the set?
- How many items are in the set?
And we’re going to do it recursively!
Today we’re starting a series on building functional data structures using Elm.
The goal: build a native set implementation from first principles.
We’re going to reimplement the standard library’s Set API.
This is going to be a toy implementation, so we won’t optimize as much as we could, but we’ll be able to learn some new things!
You’re hacking along on your JSON decoder. Life is rosy, the birds are singing,
the sun is shining, but then… you get an email: JSON Schema change.
(lightning cracks, a vampire cackles in the distance)
So how do you deal with that? You’re not just gonna give up, but your data model
is already pretty set. Are you going to have to change everything?
Last week Murphy Randle had me on Elm Town as a guest to talk about JSON.
We walked through the Elm
JSON.Decode documentation, and talked about hairy things we’d run into.
If you want a good overview of the landscape for the
JSON.Decode API, give it a listen.
First-time Elm users have a hard time learning how to compose decoders.
People tend to get stuck on what they all mean, but it’s not too hard: just think of them like LEGO.