[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: address@hidden*Subject*: Re: Paul Graham's PyCon Keynote*From*: Michael Vanier <address@hidden>*Date*: Thu, 10 Apr 2003 18:14:16 -0700*In-reply-to*: <20030410104329.B22375@metro.immute.net> (message from MattHellige on Thu, 10 Apr 2003 10:43:29 -0500)*References*: <20030409190051.20529.qmail@mail.archub.org> <20030410104329.B22375@metro.immute.net>*Sender*: address@hidden

> 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

**Follow-Ups**:**Re: Paul Graham's PyCon Keynote***From:*Jakub Travnik <J.Travnik@sh.cvut.cz>

**References**:**Re: Paul Graham's PyCon Keynote***From:*Paul Graham <pg@archub.org>

**Re: Paul Graham's PyCon Keynote***From:*Matt Hellige <matt@immute.net>

- Prev by Date:
**Re: Paul Graham's PyCon Keynote** - Next by Date:
**Re: Paul Graham's PyCon Keynote** - Previous by thread:
**Re: Paul Graham's PyCon Keynote** - Next by thread:
**Re: Paul Graham's PyCon Keynote** - Index(es):