Posted on Nov 12, 2017
I recently gave an IBM Tech Talk (replay available here) on Rosie v1.0. And there’s a subreddit available for discussion and questions.
The talk covers:
- How regex fails to scale “in the large”, i.e. to complex patterns, large collections of patterns, teams of developers, and big data.
- RPL extends the core concepts of regex, resulting in a pattern language that is familiar to developers yet strictly more powerful than regular expressions.
- RPL is designed like a programming language, with attention to readability, maintainability, modularity (packages), and to (devops) tools.
The last part of the last point is important. Inspired in some ways by how the designers of Google’s Go paid attention to software engineering practice, Rosie was designed to work well with software tools like Git, Travis, Jenkins, and others.
Plays well with git and friends
RPL was designed with the kind of syntax found in programming languages. In particular, you can have whitespace and comments scattered around your (pattern) code. This makes RPL much easier to read and maintain than regex, but it also makes diff-based tools like Git more useful. Git, and tools like it, are based on diff, which is line-oriented. Most regex are embedded in programs as literal strings dense with magic characters and escape sequences. That makes it difficult to see the changes when reading diff output:
Also, RPL patterns can be combined into packages. A package can import other packages, so that a group of interdependent files of RPL patterns can be stored in an online repository (e.g. on Gitlab). That makes it easy to use such a package:
- Do a
git clone
of the repo with the RPL package into a local directory - Add the local directory to Rosie’s
libpath
Plays well with Travis, Jenkins and friends
Rosie also plays well with build and test automation. RPL files can contain
unit tests which are executed with the rosie test
command. The tests can be
run during development, to ensure (1) that changes to the pattern definitions
did not cause regression errors, and (2) to capture new requirements (where a
pattern must newly accept or reject certain input).
Finally, the compilation and unit test actions invoked by rosie test
also
ensure that all pattern dependencies (packages) are available.
Today, Rosie does not support separate compilation and execution steps. So it
is possible to pass unit tests but fail in deployment if the deployment
environment is missing a needed dependency. (The same is true of Javascript,
Python, and other languages.) However, the rosie test
command can be used to
“smoke test” a deployment, to ensure that all RPL dependencies are installed,
that the RPL compiles without errors, and that the patterns pass all of their
unit tests.
Discussion on reddit
A Rosie subreddit has been created for discussion of these posts and for questions about Rosie and RPL. See you there!
Follow us on Twitter for announcements about the RPL approach to #modernpatternmatching.