farblog, by Malcolm Rowe

On Scala

Shortly after I posted my previous entry about providing a language feature to declare deferred evaluation semantics for function arguments (which I termed, loosely, ‘auto-lambda-isation’), Blair Zajac wrote to let me know that Scala (about which I knew almost nothing) supports exactly this feature:

… you can do that in Scala with by-name parameters. This code here uses implicits to add a ?? operator to any type in a specific namespace and uses by-name parameters to not eval any arguments it doesn’t need. A parameter of type => A means by name.

class OrTest[A](o : => A) {
 def ??(other : => A) = {
   if (null != o) {
     o
   }
   else {
     other
   }
 }
}

object Test extends Application {
 implicit def anyToOrTest[A](o : A) : OrTest[A] = { new OrTest(o) }

 val s1 = "string1"
 val s2 : String = null
 val s3 = "string3"

 println(s1)
 println(s1 ?? s2)
 println(s2 ?? s3)
}

(The example above is evaluating simple strings, but Blair’s original example included methods as well, but since they look exactly the same as the usages above, I’ve skipped them here.)

Incidentally, Scala looks really quite interesting: skimming through the Scala tutorial, I see some notable things:

Scala’s certainly something I’m adding to my (ever-growing) list of ‘must look into this sometime’!

Posted at 22:30:19 BST on 27th June 2008.

auto λ

Here’s a random thought: would it be useful for programming languages to provide a way to mark a function’s arguments such that expressions would be automatically converted (‘boxed’, if that’s not an overloaded term) to lambda expressions (anonymous inline functions) at the point of call?

Some background first: earlier today, Jon Skeet introduced me to the C# null-coalescing operator. For the uninitiated, this allows you to write something like:

string shipToAddress =
    order.shipToAddress ?? order.billingAddress ?? order.customer.address;

where shipToAddress will get set to the first non-null value of the three expressions listed. The ?? operator is therefore very much like the SQL COALESCE function, except that a C# or Java version of COALESCE — implemented as a regular function — would by necessity evaluate all the arguments before calling the function, and wouldn’t provide the short-circuit evaluation that makes the ?? (and &&, ||, etc) operators so useful.

Which led me to wonder: would it make sense for a C#/Java-like language to allow functions to declare that their arguments should be subject to deferred evaluation? This would not only allow me to write my own short-circuiting implementation of COALESCE (obviating the need to create yet-another-language-token), but also to write other variations as needed: return the first non-null-non-empty string, for example.

Jon pointed out that my concept of ‘deferred execution’ is exactly equivalent to converting the expression into a lambda expression at the point of call, which is probably an easier way to think about it. So I guess I’m imagining something like the following syntax (which also uses varargs, though the two concepts are orthogonal):

T coalesce(lambda<T> exprs...) {
  for (lambda<T> expr : exprs) {
    T result = expr.call();
    if (result != null) {
      return result;
    }
  }
  return null;
}

void foo() {
  string shipToAddress = coalesce(order.shipToAddress,
      order.billingAddress, order.customer.address);
}

Here lambda<T> is a type that is functionally (heh) similar to JavaScript’s Function type, providing a call() method that evaluates the expression and returns the result. The clever part (such that it is) would need to happen at the callsite — automatically wrapping each expression in an anonymous function.

One notable disadvantage with this syntax is that it is no longer possible to determine whether an expression is evaluated merely by looking at the callsite — obviously significant for expressions with side-effects.

In this respect, this is similar to the fact that you cannot tell whether the C++ statements X x; f(x); will result in the call f(x) mutating x — f() will receive a copy of x or a reference to x, depending on whether the function is declared as void f(X x) or void f(X& x) (and typically C++ style guides will require that the latter is used only with a const modifier, precisely to avoid this kind of confusion).

C# avoids C++’s reference-or-value ambiguity by requiring the caller to use the ref keyword for pass-by-reference; Java by enforcing pass-by-value for all primitive types (and by not supporting value types); perhaps a similar approach for auto-lambda-boxing would sense, though it would be slightly awkward to have to write the Haskell-style:

string shipToAddress = coalesce(\order.shipToAddress,
    \order.billingAddress, \order.customer.address);

… which I suppose brings us full-circle as an argument for expressing behaviour like this via core language operators!

Posted at 13:38:08 BST on 17th June 2008.

Stupid UNIX (shell) tricks

I was looking at the (now ancient, by internet standards) history meme a while ago. Here’s my results, at work:

100 (build)
87 p4
47 grep
41 cd
33 vim
20 ls
18 kill
16 (starting up a webserver)
15 rm
14 less

and at home:

88 ls
61 cd
35 less
31 curl
18 rm
17 svn
16 ./configure
12 su
12 make
12 cat

One thing I noticed when browsing through my shell history (yeah, yeah, I’m that sad) is that I make use of a load of little tricks that I didn’t know about only a year ago (when I wasn’t using the shell on such a regular basis). Here’s a couple:

Globs are great. In particular, brace expansion rocks:

diff -u some/long/tab/completed/path/file.{old,new}
cp another/long/path/to/file{,.bak}
ls src/java{,tests}/com/example/something

Piping is fun too. I run foo | less all the time, but I also do foo | cat occasionally. This is useful because it prevents foo from seeing stdout as a terminal, which makes some programs behave differently; for example, ps -f will trim command lines to the terminal width, while ps -f | cat will show the whole command.

The shell is a great calculator. Well, within limits: it’s great as long as everything you want to do will fit into a 64-bit signed int (so no floating point, and I can’t try out my favourite equation either). But it’s easy to use:

echo $((1 + 1))
echo $((0x41))
echo $((1 << 48))

Finally, here’s one I only started using recently: you probably know that you can use cd - to return from the directory you came from, but did you know that ~- expands to that old directory? I’ve using it when flicking between directories to do things like less ~-/somefile.

Posted at 22:35:18 BST on 29th May 2008.

Top (App Engine) Tip

If you’ve added developers to your App Engine project and can’t work out why they don’t seem to be recognised as administrators — login:admin paths return a 403, users.is_current_user_admin() returns false, etc — you need to check two things:

  1. (the easy bit) The developers need to accept your invitation to join the project. The Developers page on the administration console should show a status of “Active”, not “Pending”.
  2. (the just-plain-weird bit) Someone — you, or one of the new developers — needs to redeploy your application.

If you skip step 2, you’ll find that the new developers can access the administration console fine, but aren’t considered to be administrators by your application. This is totally weird, and totally undocumented. Hopefully it’ll be fixed soon, but until then, maybe this note will save someone else some confusion.

Posted at 08:48:22 BST on 21st May 2008.