[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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