# Re: Paul Graham's PyCon Keynote

```> Date: Thu, 10 Apr 2003 10:43:29 -0500
> From: Matt Hellige <matt@immute.net>
>
> 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).
>
>    So:
>      - strings are just lists of characters, and all lists of characters are
>        printed as strings by default. It's literally just a type alias.
>      - lists are just:
>          data List x = [] | Cons x (List x)
>        which defines cons cells and the list terminator in the obvious way
>        (a list of x's is either nil or a pair of an x and a list of x's).
>        The parser also provides syntactic sugar for this data-type in
>        that [1, 2, 3] == Cons 1 (Cons 2 (Cons 3 [])). Of course, one
>        could (and probably should) argue that a more general solution
>        would be to define [...] as a macro, so you could redefine it or add
>        similar constructs.
>      - integers are, _in_principle_, just constructors for another algebraic
>        data type. Of course, it's one that we could never write,
>        because it has infinitely many constructors (or, in a practical
>        computer, a finite but enormously large number of constructors),
>        but conceptually, we can say:
>          data Integer = 0 | 1 | -1 | 2 | -2 | 3 | -3 | ...
>

Or:

data Integer = Zero | Successor Integer | Predecessor Integer

Not the most efficient way to do things, but it's simple and has a finite
number of constructors.

Mike

```