Monday 29 May 2017 Extending Rillet

Since first releasing Rillet.js, my Javascript streams library, back at the start of May, I've carried on working on it and some how managed to produce, at time of writing, a further 10 releases of one sort or another. While some of those are trivial documentation fixes, I have added quite a number of additional terminal methods and a stream modifier too.

The motivation for part of this work has been to provide parity with JavaScript's Array class. If you can do it eagerly with an Array, you should be able to do it lazily with Rillet, hence the addition of every, some, none, and join. I've drawn inspiration (by which I mean copied) from other streams libraries, including .NET's Linq, Java 8 Streams, Python iterators, and my own previous work, which so far has resulted in the max, min, and sum terminators. Lastly, and perhaps most importantly coming as it does from work I've been doing, is the modifier method uniq, which strips duplicates from the stream.

Of course, all modifiers can be written in terms of filter or map, and all terminators can be written in terms of reduce, sometimes trivially so. Here's max

  seq.reduce((a,b) => (a > b) ? a : b, Nill);

and sum, which is even simpler

  seq.reduce((a,b) => Number(a)+Number(b), 0);

Why bother, then? The first reason, and it's a pretty important one, is that's it's simply more expressive. What a call to sum does is pretty obvious, while reduce((a,b) => Number(a)+Number(b), 0), although in no way obscure still requires you to think a bit. This is even more the case for something like

  seq.filter(function() {
    const seen = {};
    return i => {
      if(seen[i]) return false;
      seen[i] = true;
      return true;
    }
  }())....

which is a whole lot wordier, significantly less obvious than

  seq.uniq()....

and also contains a subtle bug. Correctness, then, is another reason. Each time you have to write an extra bit of code, you risk getting it wrong. The more the library can do for you, the fewer bugs you'll write. Finally, there are cases where a specialised implementation can be more efficient. Rillet's none, some, and every can all return early when appropriate, while the same tests expressed in terms of reduce would have to continue until the sequence was exhausted. For most cases I expect the execution time difference to be trivial, but when it does count, it could be significant.

When I first put Rillet together it wasn't really much more than a little demonstration to support my ACCU talk. Rather to my surprise, my recent work has all been in JavaScript, and so I've been using it anger. It's working out rather well so far.

---

Tagged javascript, fp, code, and rillet

---