On 3 Jan 2010, at 23:39, mike clemow wrote:
There's no reason that functions shouldn't be objects by default. There ought to be a function type. Then we wouldn't need functors to do functional programming. Perhaps even a lambda keyword. "fun int" could define a type...
lambda(int y) { return y + 1; } @=> fun int x;
<<< x(4) >>>; // prints 5
// obviously, that's fraught with issues... function pointers could work like this:
fun int f(int g) { return g+1; }
f @=> function x;
<<< x(4) >>>; // prints 5 <<< x(4.4) >>>; // error
ChucK, with its "fun" has in fact a syntax similar to SML (and OCaml is a derivation). In SML, one writes fun twice x = x*2 val twice = fn : int -> int The typing is a bit cumbersome - more like the old style in C, which has fallen largely out of use. In Haskell, the definition is twice :: Int -> Int twice x = x*x This is better, but one ends up with repeating the name of the function. Here, it repeated once, but one can have cases: f :: Int -> Int f 1 = ... f 2 = ... where the 1 and 2 can be various complicated patterns. The type must also start with uppercase names. In Haskell, the lambda is written as \x -> x*x if I would want to define the function on the fly without giving it a name. This is better, closer to that math x |-> x*x, on which Church's original lambda-calculus was based on. So an alternative way to define function is twice :: Int -> Int twice = \x -> x*x In fact, one can omit the type declaration, because Haskell uses a Hindley-Milner like type system which mostly can infer the type from an expression. This is convenient, but imposes limitations on function name overloading.
This is going to be a huge thing to implement.
Functional lambda calculus takes a bit to implement. But doing C++ style templates is not a very happy solution, that either. :-)
First, we should be able to continue to better do these things using the built-in object system using functors. Okay, but we need to be able to determine the class of an object at runtime (I've experimented with this already--so has Graham Coleman, who had a patch for an instanceOf method). This requires introspection. We should have that.
Constructors -- we've been flirting with that idea for a long time. We need those. Interfaces... yes.
These are much more modest additions, and it would be nice to see them. Hans