Re: Paul Graham's PyCon Keynote

[Kimberley Burchett <address@hidden>]

On Thu, 10 Apr 2003, Matt Hellige wrote:

> 2) "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<T> {
    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.

--
Kimberley Burchett
http://www.kimbly.com/