Haxe and Short Lambdas

People have been often asking me why there is no short lambdas syntax in Haxe. While I have been explaining it several times to different people directly, I thought it was a good idea to write it down there so people can know about the reasons behind this choice.

But first let’s explain a bit what short lambdas are, for developers that might not know about them.

If you have been doing some JavaScript, you have often used functions as values, such as:

button.onClick = function(e:Event) {
 …
};

Here we assign the value of the onClick method to function value.

Another common usage is the Array.map function that duplicates an Array content by applying a function to each of the elements and creating the array of the returned values:

var a = [1,2,3,4];
var aSquare = a.map(function(x) { return x * x; });
trace(aSquare); // [1,4,9,16]

Compared to JavaScript or other similar languages, curly braces are optional in function bodies in Haxe, so you can actually write the following which is already more readable:

var aSquare = a.map(function(x) return x * x)

Using functions as values is a favored way of writing code in functional programming, which instead of modifying some mutable state (variables or objects) works by applying map and filters in order to produce a new state.

First let me state that I’m a huge fan of functional programming. The Haxe compiler itself is entirely written in OCaml, which is a powerful functional language, and I could not have written such a complex piece of software without using functional style programming.

Also, Haxe have been designed from the start to enable and fully support both object oriented and functional programming styles.

Several important Haxe features comes directly from functional languages, such as the fact that there is no statements, only expressions, the function type notation Int -> Int -> Bool and the .bind notation to allow partial application of parameters, the per-function type parameters, etc.

Not to mention the ability to use all local variables and even the current object this context into the local functions, which makes Haxe much more usable than JavaScript (for instance) for which this represents the current runtime object, such as the following example shows:

class Foo {
  function new() {
      …
      button.onClick = function(e:Event) {
         trace(this); 
         // this = the current Foo instance in Haxe
        // but most likely the ‘button’ value in JS
      }
   }
}

So yes, Haxe is perfectly ready for functional programming.

Now, what are short lambdas ?

Short Lambda is an alternate syntax to write local functions such as “function(x) return x*x” in a shorter way. By using specific syntax we can remove the “function” keyword and by assuming that we will always return the expression value, we can ignore the “return” as well.

The problem here is that each language has come up with its own syntax for writing short lambdas. Here’s a quick overview of the differences :

In C# : x => x * x and (x,y) => x * y
In OCaml (fun(x) x * x) and (fun(x,y) x * y)
In Scala : (x:Int) => x * x and (x:Int,y:Int) => x * x
In Python : lambda x : x * x and lambda x,y : x * y
In Java 8+ : (int x) -> x * x and (int x, int y) -> x * y

This is the main reasons there is not short lambdas in Haxe.

While functional languages are actually older than object oriented languages (LISP was created before ALGOL), they have not made it into the C family (and its descendants) until quite recently.

As a consequence, I consider that adopting any of these syntaxes in Haxe (or any new alternative that you might imagine) will make the language less readable.

Let’s question this statement for a minute.

Who is writing the program ? YOU are writing it, and most likely if you feel the need to use short lambdas, if you know about them, then there should be no problem, right ?

But who is actually reading your code ? Maybe most of the time it’s only you. Maybe. But as soon as you are part of a team, or if you distribute your code as open source, or if someone want to reuse/modify/debug/etc. your code, then you no longer are the only one that reads it.

My goal when designing Haxe syntax was not to invent a new form of syntax that will save developers a few keystrokes and makes them feel like they are coding directly into The Matrix. That’s actually quite the opposite. The whole design of Haxe — and particularly its syntax — has always been driven by the need to maximize the readability of the code.

Of course not every piece of Haxe code is readable by anybody. There can be bad code, their can be complex code, their can be macros code. And their can even be complex bad macros code.

But in general case I am quite satisfied with the Haxe code readability.

Haxe can be learnt in matter of hours if you have already a background in either JavaScript, Java, C#, ActionScript, PHP, or similar languages. More importantly, you don’t need to KNOW Haxe to be able to actually read Haxe code (providing you have already learn a similar language).

Of course there’s differences in terms of syntax, such as the fact that we are using “function new() {}” as a class constructor while other OO languages are using the class name. But even in that case it’s pretty straightforward for somebody that does not know about Haxe to *guess* that’s the constructor.

Now try to guess [x,y] => x * y if you’re not familiar with functional programming and short lambdas…

On the contrary the current Haxe equivalent “function(x,y) return x * y”, while being a bit longer to type, might trigger a different reaction from the user : “Owww ? You can pass functions as parameters ? Ah I see that’s how it works ! Kewwwl”.

This might not be 100% accurate but there’s still very higher percentage of people that will understand the Haxe syntax than the short lambdas syntax.

Here’s my advice to Haxe developers : think about people reading your code. Some things might save YOU some time, but will make others spend theirs.

Let’s look at SMS for an example. Young people in France (and other countries I guess) use very abbreviated syntax when sending SMS to each others. It saves time for the writer, the reader might spend a bit more time reading it, but he’s mostly likely used to it (he knows how to read “short lambdas”).

But what if you write a book that will be read by thousands of people ? Using SMS writing might be an interesting essai de style, but that’s maybe not the best idea…

All of this to explain you the reason why the are no short lambdas in Haxe a the moment.

I am saying at the moment because things might evolve in the future. If functional programming takes off and suddenly all the mainstream languages have short lambdas which are actually USED by most of the developers and if there is more or less a common syntax for it, there I will have no longer any objection to add short lambdas to Haxe. That might takes around 10 minutes to patch the compiler, a lot less than it took me to write this post ☺

And finally if you really *WANT* short lambdas in Haxe, if you feel your life is miserable without them, then don’t forget that there’s always a macro for it !

Best Regards

Nicolas