I’m prepared to own up to my biases. I like delimited continuations. I like zippers. I like getting halfway through my work, shelving my work for a time, and coming back to it later.
We’ve seen the relationship between resumable exceptions and delimited dynamic variables before, but what about languages where you don’t have direct access to the call stack? Let’s implement delimited dynamic variables by implementing resumable exceptions with call/cc (obligatory mention of why call/cc’s a bad idea). So what’s that look like in Ruby, then?
At LShift, we tend to be big fans of functional programming, and in particular I’ve found ideas from languages like Clojure and Haskell do influence how I use more mainstream languages such as Ruby.
One technology that’s been useful to us on a current project is QuickCheck-alike for Ruby, Rantly. Briefly, rather than testing a module in your code by taking a set of (hopefully representative) examples of use and demonstrating that they produce the correct (usually pre-calculated) output, you can have the library generate input data and compare the results to a model.
Nat Pryce wrote a fun little library the other day called code-words. It rips your source into words, and turns the words into a wordcloud. In short, a visual representation of the most common words in your source, and using font size to indicate the more common terms. The aim is to give an introduction into the concepts the code speaks about. And in playing around with it I noticed something interesting.
Ruby excels at “embedded” DSLs – domain specific languages that are simultaneously plain Ruby and yet distinctly their own. RSpec springs to mind as an excellent example. At any rate, I have a DSL that recently underwent a fairly invasive change, and I wanted to automate moving model descriptions from the old format to the new.
Zippers continue to fascinate me. Let’s recap a bit: a zipper is a data structure representing the navigation and mutation of an otherwise immutable structure. We’ve looked at several different implementations here on the LShift blog, in several different languages.
Today, we’re going to see what else we can do with zippers.
I recently ran into the need for testing the behaviour of a parser of a modelling language. The parser processes a number of model descriptions in gem files, as well as local definitions. Until recently, the parser would process the gems in an arbitrary order. However the language while ostensibly declarative, isn’t, because of a huge restructuring of the parser. As a result, some bugs lurk in the changed code. These bugs, because of the arbitrary processing order of the model gems, manifest on some machines and not others. Forcing an ordering on the gem processing masks the underlying issues, even while letting the users of the parser to get on with their lives.
What to do? Random testing to the rescue! I cast around for Ruby ports of QuickCheck, and found two: rushcheck and rantly. Rushcheck hasn’t been wrapped up in a gem, so I decided to take rantly for a spin.
You are currently browsing the archives for the Ruby category.