Let's Talk About Lambda Functions!

[James J. Besemer]

Ian Bicking wrote:

> Well, it looks a lot like lambda calculus, because True and False are
> two different classes, with definitions like:

> This should remind one of true/false in lambda calculus (though
> obviously with a very different notation).

Narrowly interpreted, there is a similarity, in that both systems
build up their "control flow" abstractions from True and False,
as opposed to, say, COND.  Further, they both define True
and False in terms of each language's fundamental abstraction
mechanism, class definitions in Smalltalk's case and and Lambda
expressions for Lambda Calculus.

However, the notations and the underlying abstractions are so
vastly different I find it hard to view them as anything but largely
unrelated.  But maybe I'll feel differently tomorrow.

> The compiler specifically looks for those
> methods, and turns them into traditional if statements in the bytecode.

This is simply an optimization for speed.  Most compilers also
handle special cases for small integer arithmetic.  Even newer
ones compile direct to machine code instead of byte codes.

These compiler optimizations are completely optional.  They
have nothing to do with the language design and certainly have
absolutely nothing to do with any purported difficulties implementing
Lambda or Smalltalk control structures.

If there's a weakness in the Language, it's that the fully general
hash table lookup for each and every operation (including small
integer arithmetic and trivial control structures) is extremely
expensive and an obvious hot spot to try to optimize.

> That is, you can't (usefully) implement ifTrue: in your own custom
> class.

Absolutely not true.

You can implement like methods in your own classes and it
will work just fine.  Key is that Smalltalk's block construct
allows passing in as an argument unevaluated chunks of code,
which the method itself controls if/when to execute.  The compiler
will recognize that the destination+method is not one of the
patterns it knows how to optimize so it will generate a fully
general message send.  Ultimately your object will get the
ifTrue: message with it's block argument and you can evaluate
the block or not, depending on the instance's local state or whatever.

E.g., you define a method for your class by a method that does
a three-way branch:

    ifZero: z ifGreater: g ifLesser: s
        ( state > 0 ) ifTrue: [ ^g value ]
        ( state < 0 ) ifFalse: [ ^s value ]
        ^z value

To call it:

    myStateObj  ifZero: [ zero block ]
                ifGreater: [ greater block ]
                ifLesser: [lesser block ]

You could even extend Numbers themselves to have this new
control flow construct.

Smalltalk's blocks ARE the language's Lambda equivalent, they
work quite well, and they're implemented fully generally at the
user level.  They're one source of the language's incredible
flexibility and power.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com