[chuck-users] wishlist for the new year

[Hans Aberg]

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