[1] Katz Got Your Tongue

  • [3]Home
  • [4]About
  • [5]Projects
  • [6]Talks
  • [7]Podcasts
  • [8]Schedule

Login Subscribe
Jan 9, 2012 6 min read

JavaScript Needs Blocks

While reading Hacker News posts about JavaScript, I often come across the
misconception that Ruby's blocks are essentially equivalent to JavaScript's
"first class functions". Because the ability to pass functions around,
especially when you can create them anonymously, is extremely powerful, the
fact that both JavaScript and Ruby have a mechanism to do so makes it natural
to assume equivalence.

In fact, when people talk about why Ruby's blocks are different from Python's
functions, they usually talk about anonymity, something that Ruby and
JavaScript share, but Python does not have. At first glance, a Ruby block is an
"anonymous function" (or colloquially, a "closure") just as a JavaScript
function is one.

This impression, which I admittedly shared in my early days as a Ruby/
JavaScript developer, misses an important subtlety that turns out to have large
implications. This subtlety is often referred to as "Tennent's Correspondence
Principle". In short, Tennent's Correspondence Principle says:

    "For a given expression expr, lambda expr should be equivalent."

This is also known as the principle of abstraction, because it means that it is
easy to refactor common code into methods that take a block. For instance,
consider the common case of file resource management. Imagine that the block
form of File.open didn't exist in Ruby, and you saw a lot of the following in
your code:

begin
  f = File.open(filename, "r")
  # do something with f
ensure
  f.close
end

In general, when you see some code that has the same beginning and end, but a
different middle, it is natural to refactor it into a method that takes a
block. You would write a method like this:

def read_file(filename)
  f = File.open(filename, "r")
  yield f
ensure
  f.close
end

And you'd refactor instances of the pattern in your code with:

read_file(filename) do |f|
  # do something with f
end

In order for this strategy to work, it's important that the code inside the
block look the same after refactoring as before. We can restate the
correspondence principle in this case as:

    ```ruby # do something with f ```

    should be equivalent to:

    do
      # do something with
    end

At first glance, it looks like this is true in Ruby and JavaScript. For
instance, let's say that what you're doing with the file is printing its mtime.
You can easily refactor the equivalent in JavaScript:

try {
  // imaginary JS file API
  var f = File.open(filename, "r");
  sys.print(f.mtime);
} finally {
  f.close();
}

Into this:

read_file(function(f) {
  sys.print(f.mtime);
});

In fact, cases like this, which are in fact quite elegant, give people the
mistaken impression that Ruby and JavaScript have a roughly equivalent ability
to refactor common functionality into anonymous functions.

However, consider a slightly more complicated example, first in Ruby. We'll
write a simple class that calculates a File's mtime and retrieves its body:

class FileInfo
  def initialize(filename)
    @name = filename
  end

  # calculate the File's +mtime+
  def mtime
    f = File.open(@name, "r")
    mtime = mtime_for(f)
    return "too old" if mtime < (Time.now - 1000)
    puts "recent!"
    mtime
  ensure
    f.close
  end

  # retrieve that file's +body+
  def body
    f = File.open(@name, "r")
    f.read
  ensure
    f.close
  end

  # a helper method to retrieve the mtime of a file
  def mtime_for(f)
    File.mtime(f)
  end
end

We can easily refactor this code using blocks:

class FileInfo
  def initialize(filename)
    @name = filename
  end

  # refactor the common file management code into a method
  # that takes a block
  def mtime
    with_file do |f|
      mtime = mtime_for(f)
      return "too old" if mtime < (Time.now - 1000)
      puts "recent!"
      mtime
    end
  end

  def body
    with_file { |f| f.read }
  end

  def mtime_for(f)
    File.mtime(f)
  end

private
  # this method opens a file, calls a block with it, and
  # ensures that the file is closed once the block has
  # finished executing.
  def with_file
    f = File.open(@name, "r")
    yield f
  ensure
    f.close
  end
end

Again, the important thing to note here is that we could move the code into a
block without changing it. Unfortunately, this same case does not work in
JavaScript. Let's first write the equivalent FileInfo class in JavaScript.

// constructor for the FileInfo class
FileInfo = function(filename) {
  this.name = filename;
};

FileInfo.prototype = {
  // retrieve the file's mtime
  mtime: function() {
    try {
      var f = File.open(this.name, "r");
      var mtime = this.mtimeFor(f);
      if (mtime < new Date() - 1000) {
        return "too old";
      }
      sys.print(mtime);
    } finally {
      f.close();
    }
  },

  // retrieve the file's body
  body: function() {
    try {
      var f = File.open(this.name, "r");
      return f.read();
    } finally {
      f.close();
    }
  },

  // a helper method to retrieve the mtime of a file
  mtimeFor: function(f) {
    return File.mtime(f);
  }
};

If we try to convert the repeated code into a method that takes a function, the
mtime method will look something like:

function() {
  // refactor the common file management code into a method
  // that takes a block
  this.withFile(function(f) {
    var mtime = this.mtimeFor(f);
    if (mtime < new Date() - 1000) {
      return "too old";
    }
    sys.print(mtime);
  });
}

There are two very common problems here. First, this has changed contexts. We
can fix this by allowing a binding as a second parameter, but it means that we
need to make sure that every time we refactor to a lambda we make sure to
accept a binding parameter and pass it in. The var self = this pattern emerged
in JavaScript primarily because of the lack of correspondence.

This is annoying, but not deadly. More problematic is the fact that return has
changed meaning. Instead of returning from the outer function, it returns from
the inner one.

This is the right time for JavaScript lovers (and I write this as a sometimes
JavaScript lover myself) to argue that return behaves exactly as intended, and
this behavior is simpler and more elegant than the Ruby behavior. That may be
true, but it doesn't alter the fact that this behavior breaks the
correspondence principle, with very real consequences.

Instead of effortlessly refactoring code with the same start and end into a
function taking a function, JavaScript library authors need to consider the
fact that consumers of their APIs will often need to perform some gymnastics
when dealing with nested functions. In my experience as an author and consumer
of JavaScript libraries, this leads to many cases where it's just too much
bother to provide a nice block-based API.

In order to have a language with return (and possibly super and other similar
keywords) that satisfies the correspondence principle, the language must, like
Ruby and Smalltalk before it, have a function lambda and a block lambda.
Keywords like return always return from the function lambda, even inside of
block lambdas nested inside. At first glance, this appears a bit inelegant, and
language partisans often accuse Ruby of unnecessarily having two types of
"callables", in my experience as an author of large libraries in both Ruby and
JavaScript, it results in more elegant abstractions in the end.

Iterators and Callbacks

It's worth noting that block lambdas only make sense for functions that take
functions and invoke them immediately. In this context, keywords like return,
super and Ruby's yield make sense. These cases include iterators, mutex
synchronization and resource management (like the block form of File.open).

In contrast, when functions are used as callbacks, those keywords no longer
make sense. What does it mean to return from a function that has already
returned? In these cases, typically involving callbacks, function lambdas make
a lot of sense. In my view, this explains why JavaScript feels so elegant for
evented code that involves a lot of callbacks, but somewhat clunky for the
iterator case, and Ruby feels so elegant for the iterator case and somewhat
more clunky for the evented case. In Ruby's case, (again in my opinion), this
clunkiness is more from the massively pervasive use of blocks for synchronous
code than a real deficiency in its structures.

Because of these concerns, the ECMA working group responsible for ECMAScript,
TC39, [12]is considering adding block lambdas to the language. This would mean
that the above example could be refactored to:

FileInfo = function(name) {
  this.name = name;
};

FileInfo.prototype = {
  mtime: function() {
    // use the proposed block syntax, `{ |args| }`.
    this.withFile { |f|
      // in block lambdas, +this+ is unchanged
      var mtime = this.mtimeFor(f);
      if (mtime < new Date() - 1000) {
        // block lambdas return from their nearest function
        return "too old";
      }
      sys.print(mtime);
    }
  },

  body: function() {
    this.withFile { |f| f.read(); }
  },

  mtimeFor: function(f) {
    return File.mtime(f);
  },

  withFile: function(block) {
    try {
      var f = File.open(this.name, "r");
      block(f);
    } finally {
      f.close();
    }
  }
};

Note that a parallel proposal, which replaces function-scoped var with
block-scoped let, will almost certainly be accepted by TC39, which would
slightly, but not substantively, change this example. Also note block lambdas
automatically return their last statement.

Our experience with Smalltalk and Ruby show that people do not need to
understand the SCARY correspondence principle for a language that satisfies it
to yield the desired results. I love the fact that the concept of "iterator" is
not built into the language, but is instead a consequence of natural block
semantics. This gives Ruby a rich, broadly useful set of built-in iterators,
and language users commonly build custom ones. As a JavaScript practitioner, I
often run into situations where using a for loop is significantly more
straight-forward than using forEach, always because of the lack of
correspondence between the code inside a built-in for loop and the code inside
the function passed to forEach.

For the reasons described above, I strongly approve of [13]the block lambda
proposal and hope it is adopted.

[14]

Published by:

[15] Yehuda Katz
[16]
Katz Got Your Tongue © 2024
[17]Powered by Ghost
[pixel]

References:

[1] https://yehudakatz.com/
[3] http://www.yehudakatz.com/
[4] https://yehudakatz.com/about/
[5] https://yehudakatz.com/projects/
[6] https://yehudakatz.com/talks/
[7] https://yehudakatz.com/podcasts/
[8] https://yehudakatz.com/schedule/
[12] http://wiki.ecmascript.org/doku.php?id=strawman%3Ablock_lambda_revival&ref=yehudakatz.com
[13] http://wiki.ecmascript.org/doku.php?id=strawman%3Ablock_lambda_revival&ref=yehudakatz.com
[14] https://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/
[15] https://yehudakatz.com/author/wycats/
[16] https://yehudakatz.com/2012/04/13/tokaido-my-hopes-and-dreams/
[17] https://ghost.org/