Hundred Year Language

I wrote a message to the LL1 mailing list in response to Paul Graham's Hundred-Year Language essay. Here it is.

On Thu, 10 Apr 2003, Matt Hellige wrote:

> "How far will this flattening of data structures go? I can think of
> possibilities that shock even me, with my conscientiously broadened
> mind. Will we get rid of arrays, for example? After all, they're just
> a subset of hash tables where the keys are vectors of integers. Will
> we replace hash tables themselves with lists?"

A lot of this is actually the approach taken by Haskell (and, I imagine, other related languages), in which the only real data construct is the algrabraic (tagged) data type. Everything else is basically syntactic sugar (or "semantic sugar", which I'll explain in a bit).

I've been playing with the idea of a language where even the difference between data structures and functions is erased.

You can think of an n-ary function as a simple n-ary array of values. If you allow assigning to the result of a function (meaning that the function should return the assigned value the next time it's called), then functions can take the place of data structures, and vice versa.

Since you used the example of Haskell lists, here's my own list example, using a C++ syntax:

class List {
    List() {
        size() = 0;
    }

    int size();

    T get(int i);

    int append(T val) {
        get(size()) = val
        size()++;
        return size() - 1;
    }
}

Here, get(int) and size() are basically N-array arrays -- they have no side-effects, and their value is simply determined by whatever value was assigned to them last. I usually assume a semantics where functions are initially undefined everywhere, and attempting to read an undefined value results in an error (so get(0) would assert if you hadn't called append yet).

This general idea is pretty close to what Paul Graham wrote in his essay:

How far will this flattening of data structures go? I can think of possibilities that shock even me, with my conscientiously broadened mind. Will we get rid of arrays, for example? After all, they're just a subset of hash tables where the keys are vectors of integers. Will we replace hash tables themselves with lists?

I've basically done exactly what he described, but then lumped in functions too.

I'm not sure whether this is a good idea -- I generally prefer statelessness, and I'm not sure it's a good idea to introduce state into previously-stateless features like functions. I started following this idea because I was trying to define a specification language for data structures, and since the data structures I was interested in involved state, this was the natural way of doing it.

On the other hand, at least the state is constrained to a class. It's really no worse than having member variables supporting the public methods of a class. And for the data structures I'm interested in (e.g. in-memory caches of on-disk indices), state of some sort is a necessity.

Posted on April 10, 2003 01:50 PM
More languages articles