Lambda the Ultimate

Functional Object Oriented Programming?

Or maybe it's just that in Ruby arrays take the place lists have in functional programming as the universal glue datatype (cf. Why FP Matters)?

Here's one of quite a few places where I find I prefer Ruby to Python. Python's array.reverse() reverses the array in place and returns null (IIRC). You can't string array operations together - array.reverse().reverse() gives you an error, not the original value of array. I've obviously become contaminated by FP thinking, because this now seems entirely wrong to me...

Side-effects must be sequenced properly. However, in most languages the order in which sub-expressions are evaluated is not completely defined (in particular, the order in which parameters are evaluated is often undefined). In such a language, the sequence in which the side-effecting procedure applications of an expression are evaluated is generally undefined. This can lead to many kinds of surprising problems. Therefore, side-effecting procedures should generally not return a useful value.

For example, consider the following snippet using a side-effecting reverse() that returns the modified array.

  a = [5, 10]
  a.reverse()[0] - a.reverse()[0]

What is the value of the second expression?

For example, consider the following snippet using a side-effecting reverse() that returns the modified array.

a = [5, 10] a.reverse()[0] - a.reverse()[0]

What is the value of the second expression?

Right. However, this isn't the case in all (most?) imperative languages (e.g. Scheme, C, Ocaml,...). Even in Java and Python, where the order of expression evaluation is defined to be from left to right (modulo precedence and associativity), I would probably avoid relying on expression evaluation order too much.

Consider constructing a function that transforms a program using iterator operations to a program that uses operations on lazy lists and another function that transforms a program using operations on lazy lists to a program using iterator operations.

I think this is a good point and can be generalized to say that objects are a means to delay evaluation (among other things). The syntax may not be as desirable as implicit laziness, but the results are similar.

abstract class Iterator(a) {
    abstract isDone(): Boolean;
    abstract current(): a;
    abstract rest(): Iterator(a);
}


infixr :: (head: a, tail: Iterator(a)): Iterator(a) {
    return {isDone  := false;
            current := head;
            rest    := tail};
}


empty := {isDone := true; current := error; rest := error};
break := empty;


values := 1 :: 2 :: 3 :: empty;
loop {
    print(values!)
}


twice(value: a): Iterator(a) {
    return value :: value :: empty;
}


loop {
    print(twice(42)!)
}


find(it: Iterator(a), pred: Predicate(a)):Maybe(a) {
    result := nothing;
    loop {
        each := it!;
        if pred(each) {
            result = each;
            break;
        }
    }
    return result;
}

The way I characterized it's popularity at OSCON was Perl is to Python as Python is to Ruby. Perl is about an order of magnitude more popular than Python, and two orders more than Ruby.

I discussed exactly this sort of thing in a little story I posted to LtU a while back.

And so are functins (at least if they are first class).

But perhaps we are on the verge of a discussion about procedural abstraction vs. data abstraction? Imagine the fun.

I can see why it's better for side-effecting operations not to return useful values; I think that what's got into me is a preference for referential transparency where possible, such that I would simply prefer it if [1, 2, 3].reverse() were non-side-effecting. Ruby appeals to me (over Python) insofar as it tends to swing that way as well. But this is rather trivially personal.

Perl is to Python as Python is to Ruby

Patrick was talking about orders of magnitude of popularity, but it struck me that there might be some other senses in which this could be argued as well. Python can be characterised as "Perl cleaned up": it tries to simplify, to lay out orthogonally (whether it really does this is perhaps debateable, but my point is just that it was one of GvR's stated intentions), to find one ("Pythonic") way to do it, and so on.

Now Ruby does not really continue in that exact direction - in fact it's seen by some detractors as lapsing back in the direction of Perl, largely I think on the superficial basis that it happens to use a couple of "line noise" operators. But Ruby no less than Python has a notion of "the Ruby way" behind it, and part of "the Ruby way" is to use concise little block functions (which incidentally are also closures) and combine them with iterators.

Ruby had yield before Python did, and Ruby's block syntax is not a wart the designer would like to do away with (which is the case with Python's lambda). In spite of Ruby's fairly thorough-going object orientation, a core Ruby idiom is the application of functions to lazily evaluated lists (well, OK, iterators). Its libraries use that idiom extensively; you need to be comfortable with it to get on with the language. So Ruby is - at times - not so much a "message passing" language as a "block passing" language. It's a kind of strong misreading, if you'll pardon the expression, of Smalltalk.

Another more subtle difference is the distinction Ruby makes between methods and blocks. Both are like functions but are defined differently, have different calling conventions etc.

In JavaScript both are functions, or more precisely methods (functions are methods of a global singleton object). Also, in JavaScript functions are passed like any other type, there is no "last implicit arg", and you call them via the reference, not using a special yield instruction. I prefer the JavaScript way here.

We did encountered some warts mixing functional style with OO – we had to introduce a Function.from() operator to convert methods on objects into functions. So I do agree there are advantages to the Ruby way.

I consider Ruby's use of arrays as a "universal glue datatype" a bit dangerous. JavaScript uses arrays the same way, which is why BeyondJS introduces lazy lists. The reason I see arrays as dangerous is that using them is a lot easier than constructing containers that support iterators, thus many programmers may simply use arrays disregarding potential problems. Consider the readlines function (block? method?). It would be tempting to write code that scans a file for values as:

readlines.grep(/hello/).each {|line| puts line}

But what if the file is 10GB? In BeyondJS I would write:

File.StdIn.filter(/hello/).foreach(alert);

which does the same thing. But because File.StdIn returns a lazy list, its content is never stored in memory all at the same time.

SRFI-44 discussion archive http://srfi.schemers.org/srfi-44/mail-archive/maillist.html covers this topic in detail. See also http://pobox.com/~oleg/ftp/Scheme/enumerators-callcc.html

Anyway, if this is what you mean, then clearly it is a viable option only in high-order languages (with anonynous functions, first-class functions etc.)

The iterator is a solution to a programming language problem. Most patterns are.

By enumerators you mean for-each like procedures, right?

That is right. Alas, the terminology in this area is very confusing: it's quite unfortunate that C++ STL chose the term "iterator" for a passive entity that should be better called an "accessor" or a "cursor". That's why the articles mentioned earlier use the terms "enumerator" and "iteratee", or a "cursor".

The iterator is a solution to a programming language problem. Most patterns are.

Well said!