Lambda the Ultimate

I was looking at Scala, and this is where I got the idea from. The difference in Scala is that each function is treated as an instance of one of the nine function classes (function0, ..., function9) but is itself not a type. What this means is that you can't parameterize with a function.

In Scala you can write:

{
  var x : List[int];
  ...
  x.foreach(Console.println); 
}

which requires the object to be instantiated first and then passed. I want to pass the type instead so that the compiler expand the code in place:

{
  var x : List[int];
  ...
  x.foreach[Console.println](); 
}

This is more efficient in Heron because it uses
C++ semantics for parameterized types.

That's interesting to know. The other day I was working on fuzzy membership functions. That could be one approach to the problem.

I always thought the most interesting aspect of Python not the language itself, but the fact that the designers put in so many flexible hooks to twist the runtime behaviour of objects.

I like that Python can be highly customizeable by simply toying around with these methods:
__setattr__
__getattr__
__delattr__
__cmp__
__gt__
__lt__
__call__
__iter__

You can proxy attribute access to child attributes, for instance. so many sweet ways to do creative stuff...

Python is a lovely customizeable, programmable runtime...

Have you heard of common lisp?

heard it's the ugly duckingly of the Lisp family... ;)

Scheme has my vote for best overall designed Lisp.

And, yes, i'm aware of Paul Graham's "programmable programming language" quote from his friend.

still, Python has several nice things going for it, which _are_ easier in the eyes than either Scheme or CL...

"Functions are isomorphic to instances of classes with a single method, not field."

I am perhaps not being clear. What I am proposing is that the actions which take place in a function would occur instead in the class constructor (which I am unsure if it is technically a method, because it can't be invoked in Heron in any context outside of construction of the object), and instead of having a return value as functions usually do, the class would return the value in a result field.

To illustrate using C++, any function would be rewritten from this:

int square(int x) { return x * x; } 

int n = square(42)

to this:

struct square 
{ 
  typedef int result_type;
  result_type result;    
  // constructor
  square(int x) {
    result = x * x;
  }
}

int n = square(42).result;

What is different about this approach is that by treating the function as a class (as opposed to function pointer or object) you can pass any function as a template parameter (instead of as an argument).

A delegate in C# is an object that encapsulates a target object and method name - basically a method pointer. Delegates are called by calling Invoke on them. They can also be called asynchronously by calling BeginInvoke, which queues the delegate for execution by a thread in the thread-pool and returns an IAsyncResult object that can be used to check whether the delegate has finished executing. You pass the IAsyncResult object to the EndInvoke method of the delegate to wait for it to finish and pick up a return value, or catch an exception.

Borrowing from this pattern, you could extend the "square" example as follows:

(C# code)
public class Square
{
   private ManualResetEvent waitHandle = new ManualResetEvent(false);
   private int x;
   private int result;
   private Exception exception;

   public Square(int x)
   {
      this.x = x;
      Thread t = new Thread(new ThreadStart(ComputeResult));
      t.Start();
   }

   private void ComputeResult()
   {
      try
      {
         result = x * x;
      }
      catch (Exception exception)
      {
         this.exception = exception;
      }
      waitHandle.Set();
   }

   public int Result
   {
      get
      {
         waitHandle.waitOne();
         if (exception==null)
            return result;
         else throw exception;
      }
   }
}

This will start the computation off on another thread, which will collect any result or error in a private field and set a synchronization event when it's finished. Calling Result waits for the synchronization event and either returns the result or throws the exception.

Alternative execution schemes are possible - you could wait until Result is called before actually performing the computation, for instance, so that the constructor simply captures the arguments for later. One could perhaps have an optional mode parameter to the constructor that specified whether lazy or asynchronous execution was desired.

In C# though the function itself can not be treated as a type.

Unless you also have classes as first-class citizens (which no typed language supports, AFAIK) this would prevent functions from being first-class, wouldn't it? That makes them almost useless.

I don't see any advantage in exchange either. What does it buy you?

I believe Dylan supports first-class classes. It's a functional language, though, so it would be easy enough to just pass functions directly.

OOHaskell represents classes as functions, so they're first-class as well. Of course, representing a function with a class implemented as a function seems a bit redundant.

I don't see any disadvantage to passing functions as template parameters. The advantage is that the compiler can generate mor efficient code by inlining the function.

Didn't I just point out the (huge) disadvantage? Functions would no longer be first-class, i.e. you could not return them from other functions, compose them, store them in a list, or whatever. But being able to do this is the whole point of having a functional language.

You probably couldn't even have closures, because they would correspond to runtime definition of classes.

For the few cases that would still be possible under your proposal the inlining optimisation you mention is possible already. Some compilers even do it where worthwhile according to certain heuristics, but not everywhere, to avoid code bloat (in languages with first-class functions, function calls should be comparably cheap anyway).

You would be able to compose functions. The following creates a new function by repeatedly applying f to an argument.

def repeat[f : F[T], n : 'int](x : T)
{
  f(x);
  if (n > 1) {
   repeat[f, n-1](x);
  }
}

A list of functions could be created at compile-time using meta-programming techniques.

def f(int x) : int {
  result = x + 1;
}

def g(int x) : int {
  result = x * 2
}

def fxn_list[H : F[int][int], T : fxn_list] {
  def head : H;
  def tail : T;
}

def apply_fxn_list[XS : fxn_list](int n) : int {
  result = XS.head(apply_fxn_list[XS.tail](n))
}

def apply_fxn_list[XS : void](int n) : int {
  result = n;
}

def test(int n) : int {
  def fxns = fxn_list[F, fxn_list[G, void]];
  result = apply_fxn_list[fxns](n);
}

I concede that this is not as expressive nor elegant as if functions were treated as objects.

You can however implement closures in my proposed approach.

First, a minor change: instead of putting code in a constructor, better put it in a static method. Or if you don’t have anything like static methods, in a plain method invoked on a dummy object with no fields. This way the result will be returned in a natural way, without an auxiliary field.

But this is cosmetics. Unless your classes differ significantly from what I’ve seen in statically typed languages, this restricts to have a finite set of global functions—you can’t define a function locally with access to local variables of the containing code.

This is more restrictive than the C++ approach of objects with operator(). C++ function objects can access local environment—you must pack the relevant bits of environments manually, but it’s possible at all.

This is also more restrictive from C function pointers, because in your system the type depends on the implementation, not only on the interface (function signature).

So there are two properties participating in expressiveness: the ability to access local environment, and having a type dependent only on the interface. True closures have both, C++ objects with operator() have the first, C function pointers have the second, and your system has neither.

The local variables for functions would be fields in my proposed system. The access to these fields could be shared by passing a context variable to the constructors. This would enable closures.

I like the static method idea.

I have this feeling that Monsieur Diggins is one of the people pushing the Boost.Interfaces library for inclusion. ;)

For those of us who don't have ACM subscription, a short substitute: Knowledge Representation in
Domain Specific Languages.