A few interesting points in “the quest for Meta”:

Type-Passing Style

The intermediate code Lunar generates is in type-passing style; new parameters are introduced to functions to carry types. Assertions are performed on types in non-template code, and other type computations are emitted for template code. The partial evaluator “evaluates away” the type parameters, then should be able to remove them from the final code since they are no longer used.

It’s interesting that the term “type-passing style” has already been coined. One aspect of the unification of generic programming (which takes types as parameters and returns a function or type) and functional programming (which takes values as parameters and returns a value) which I’ve been thinking about is unifying the calling syntax. This would mean that some function could take both value and type arguments, as well as the function could be specialized on the type of value parameters.

It seems, though, that the authors haven’t hit the “grand unified theory” that I’m trying for, as evidenced by the fact they have chosen to omit the features which are hard. Take parameter overloading as an example: if types are passed as parameters, then two functions statically dispatched on type have the same ’signature’. In C++, you could implement these in different compilation modules, but you can’t do this in an intermediate language because the compiler would need to implement a centralized dispatch on type with knowledge of all the different implementations – even if this is later resolved at compile time.

I’m also thinking about saying, “Screw it, let’s throw out the ’sacred cow’ of being able to compile separate ‘compilation units’ individually. Computers have gotten fast, memory is cheap, we can make a compiler which reads all the source, thinks for a while, then spits out the answer.”

Quadruple Form

I’m always curious about new forms for intermediate languages. This is an area that I haven’t decided on for Meta just yet, since I need to get a better idea of how the type system will work. In any case, the intermediate language has a general form called “quadruple form”, which is a form where, as the article states:

In quadruple form, most instructions are of the form: r <- x1 * x2, where r is a name for the result, x1 and x2 are names or literals, and * is an operator.

Interesting, but it doesn’t appear as powerful as lambda calculus and seems geared for imperative languages.

square(x) = x*x;

If the compiler sees the expression “square(4)” in the code, it can replace it with “16″ at compile time, correct? Well what about this equivalent function?:

square(x) = system(sprintf("echo %d*%d |bc", x, x));

Aha! Side effects are a problem! This now gets a lot messier, since the compiler needs to know which functions it can run at compile time and for which functions it must generate run-time instructions. Language compilers are typically very conservative at estimating this, but this will not do for Meta!

We can say the first function is “pure”. In other words, given the function and the same input parameters, it will produce the same result. It keeps no internal state and uses no operating system objects such as files or sockets. In other words, it is not only a computer programming function, it is also a mathematical function.

Enter the world of the Scheme language for a moment. By unenforced convention, Scheme functions which mutate objects have names which end with an exclamation point. They jump out at the programmer, saying “I’m actually modifying an object.” This isn’t exactly consistent with the purity concept, but we are going to steal the idiom. In Meta, all non-pure functions must end with ‘!’. This not only solves our problem about running user code at compile time, but it allows programmers to reason much better about the code at a glance and helps us with concurrent programming.

The rules are:

• All impure library functions will be labeled with ‘!’.
• Functions labeled with ‘!’ aren’t required to have side effects:

  g!() = 0; // g!() actually has no side effects.  Perhaps it will later.

• Functions which directly call functions labeled with ‘!’ must also be labeled with ‘!’.

  g() = f!();  // error, g() cannot call f!()
  g!() = f!(); // OK, g!() can call f!()

• Impure functions may not be passed to functions which don’t expect them.

  // OK, h is pure
  let f(g) = g() in
  let h() = 0 in
  f(h); 
   
  // Compile error
  let f(g) = g() in
  let h!() = 0 in
  f(h!);
   
  // OK, f(g!) indicates that g! can be impure.  Note that we
  // haven't labeled f because it doesn't actually invoke g!.
  let f(g!) = g! in
  let h!() = 0 in
  f(h!);
   
  // OK, now we must label f
  let f!(g!) = g!() in
  let h!() = 0 in
  f!(h!);
   
  // We can always pass a pure function where an impure one is acceptable.
  let f!(g!) = g!() in
  let h() = 0 in
  f!(h);

• Functions whose purity depends on the parameters passed may annotate parameters with ‘!?’. In these cases, the function itself need not be annotated with ‘!’, but whether a particular invocation will require the enclosing function to be labeled will be determined from the parameters passed.

  // This expression does not require the function containing it
  // to be labeled with '!'.
  let h() = 0 in
  let f(g!?) = g!?() in
  f(h);
   
  // This expression does.
  let h!() = 0 in
  let f(g!?) = g!?() in
  f(h!);

And so, I have decided that I must write a language. I expect this to be a many-year personal endeavor, but a lot of these language complaints I have on a recurring basis, and I suspect starting a language should have a lot more influence than simply complaining.

The language is tenatively named “Meta”. C++ provides rich meta-programming support in a statically typed environment; however, it falls down in many different ways and this rich support has never been successfully exported to another language. Meta intends to export this rich meta-programming support to a functional language (which is a different beast, so we aren’t just trying to “fix C++”).

Meta will be compiled, statically-typed, and functional. It will not be lazy. Objects will be immutable. It should be able to write safely concurrent programs, and should be usable in large projects by multiple developers, meaning that it should be pragmatic.

I will make a series of posts on design decisions for Meta, and I ask for feedback and input.