[Python-Dev] Py2.6 ideas

[Andrew Koenig]

> Maybe Raymond's proposed record type should have two versions: one
> that's also a tuple, for compatibility, and one that's just a record.

FWIW, ML unifies tuples and records by defining a tuple to be a record whose
component names are all consecutive integers starting with 1.

For example, in ML, the literal { name = "ark", state = "NJ" } represents a
record with type { name: string, state: string }.  The identifiers "name"
and "state" are bound during compilation, ML being a statically typed
language.

In ML, one extracts a component named foo by applying a function named #foo.
So, for example, the value of

	#state { name = "ark", state = "NJ" }

is "NJ", and trying to evaluate

	#foo { name = "ark", state = "NJ" }

results in a compilation error because of type-checking failure.

Component names can be either identifiers or integers.  So, for example,

	{ name = "spells", 1 = "xyzzy", 2 = "plugh" }

is a record of type {1: string, 2: string, name: string }.

So here is the point.  If the component names of a record are all positive
integers with no gaps, the record is *also* a tuple.  So, for example

	{ 2 = "plugh", 1 = "xyzzy" }

has exactly the same meaning--including the same type--as

	{ "xyzzy", "plugh" }

In both cases, the compiler normalizes the display, both of the value (i.e.
it prints {"xyzzy", "plugh"} instead of { 2 = "plugh", 1 = "xyzzy" }, and it
prints the type as

	string * string

instead of (the equivalent)

	{ 1: string, 2: string }

So in ML, tuple types aren't really anything special -- they're just
abbreviations for elements of a particular subset of record types.