Lambda the Ultimate

Hi all,

I'm new to this forum, but it seemed like there are a lotta smart people here, so I wanted to throw an idea out there and see what the 1337 hax0rz think about it. (btw, I'm also not a programming languages guy, so please correct me if I'm wrong)

The Problem:
So there are a lot of programming languages out there, but pretty much all of them are about programming a process, rather than programming an algorithm. Consider the following program:


#include "myCards.h"

int main(void)
{
myCards cards;
cards.shuffle();
cards.deal();
return 0;
}


This is usually a clear way of writing a program, any programmer that looks at the code can deduce the algorithm, namely, create the cards, shuffle them, then deal them. However, this C++ code is actually programming a very specific process and not necessarily the algorithm that it seems to imply. In actuality, you know very little about this code. All we can deduce from this code is that an object was created, and two of its member functions were called in succession. It could be the code that sets up and detonates a bomb, or the code to break eggs and fry them sunny-side up. It depends completely on how myCards.h is defined, and the algorithmic information is buried within the complex relationships.

It is no wonder that understanding someone else's code can be as time-consuming as rewriting the code from scratch. Code without comments is tantamount to writing unusable code.

The Idea
When you are playing cards, you will use this algorithm. Get the cards, shuffle them, then deal the cards. The algorithm is very consistent and reusable - you do the same thing whether you're getting ready to play blackjack, poker, or even go-fish even though those games are very different. So the idea is to create a programming language where you can program the algorithm, and capture everything that is important to the algorithm, separating it from what is process specific.

So looking back on the algorithm -- 1.Get the cards, 2. Shuffle them, 3. Deal the cards. What is different between this and the C++ code before is that here, we don't care how to do it, just get it done. It doesn't matter if I riffled the cards, or pulled some out the middle and put them on top, just as long as they get randomized -- which is what I meant by shuffling them.

The algorithmic way of writing this code would be -- 1.get to the state where i have the cards 2. get to the state where the cards are shuffled 3. get to the state where the cards are dealt. The difference is that this is goal-based -- get there, I don't care how you do it, rather than process-based -- do these specific things.

The Language
The language will be a goal-based language, where each function contains the goal of the function -- which state it will be in after it finishes, and will guarantee that it will get there if the initial conditions are met. Each function will contain a sequence of subgoals to get it from the initial state to the goal state. During compilation/run-time, a STRIPS-like calculation will be done to plan which specific functions to call to create an AST corresponding to the tree of goals and subgoals where each function is a node.

Correctness can be proven since each function is supposed to go from its initial state to goal state, if it doesn't, the the function is incorrect and the run-time can isolate more bugs.

Conclusion
The difficulty in reusing old code is the lack of pre/post information about functions. So a language that requires that information in the form of initial conditions / goal state will allow for greatly reusable code, that will be able to self modify for various purposes at run-time.

K, so there's more to it if people are interested... but right now, it's still in the planning stages, and could use some help from some experts. A simple proof-of-concept version was written in python. I'm trying to work out a version 2 that will compile to parrrot vm. Any ideas/comments/people that are interested?

I wrote up a small blurb about C# attributes used prominently for reflection, and how I think they can be replaced with interfaces without losing any of the declarative benefits, or requiring special compiler handling for metadata. I argue that parameterizing objects with interfaces is ultimately safer than using attributes, given the static typing benefits.

We suggest to use the locality concept as a general form of component, that can be used, at the same time, as a unit of modularity, of isolation, and of mobility. Specifically, we introduce in this paper Oz/K, a kernel programming language, that adds to the Oz computation model a notion of locality borrowed from the Kell calculus. We present an operational semantics for the language, and several examples to illustrate how Oz/K supports open distributed programming.

Oz/K: A kernel language for component-based open programming