> 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
