15.17. Defining values with tables

| Chapter 15: Tables |

| 15.17. Defining values with tables

Just as we can define many similar things (or kinds) using a table, we can also define a whole run of new values. Again, this avoids unnatural prose like

> The chemical elements are Hydrogen, Helium, Lithium, ..., and Ununquadium.

But a further advantage is that by using a table we are able to give properties to values for the first time. For example:

> Solar distance is a kind of value. 1000 AU specifies a solar distance. Planet is a kind of value. The planets are defined by the Table of Outer Planets.

> Table of Outer Planets

> planet | semimajor axis
> Jupiter | 5 AU
> Saturn | 10 AU
> Uranus | 19 AU
> Neptune | 30 AU
> Pluto | 40 AU

creates five values of the kind "planet", but it also makes a property called "semimajor axis" which belongs only to these five values. Thus:

> say "Pluto orbits at [semimajor axis of Pluto]."

produces "Pluto orbits at 40 AU." We can both use and change this value:

> Praying is an action applying to nothing. Understand "pray" as praying.
> Instead of praying:
> now the semimajor axis of Pluto is 1 AU;
> say "Your prayers are answered, and the Almighty moves Pluto in closer to the fire."

Similar properties would be made for each column of the table after the first (there can be any number of properties, including none). Because the values are created first, before the rest of the table is gone through, we can even use "planet" as one of the values of properties:

> Table of Outer Planets

> planet | semimajor axis | centre of government
> Jupiter | 5 AU | Jupiter
> Saturn | 10 AU | Saturn
> Uranus | 19 AU | Saturn
> Neptune | 30 AU | Pluto
> Pluto | 40 AU | Pluto

All of this is intended to be closely parallel to defining a whole run of things, such as the coloured jerseys, using a table, but there are two important restrictions: firstly, when a kind of value is defined by table, the table must contain all of its possible values; and secondly, the column names (after the first) cannot coincide with names of any properties held by any other value (or thing, for that matter). So it is a good idea to give the columns very specific names ("centre of government") rather than vague names which might cause clashes elsewhere ("owner").

Two technical footnotes. In a table used to define a kind of value, blank entries are not left blank: they are filled in with suitable default values. For instance, if the semimajor axis column had been all "--"s except for listing Neptune at "30 AU", say, Inform would deduce that the column was meant to hold a value of kind "solar distance", and would set the solar distances for all of the other planets to be "0 AU". It does this to ensure that "solar distance of P" exists for any planet P.

The second technical note is that we must not sort such a table, because it is used during play to store the properties, and if it were to get rearranged then so would the properties be - with probably disastrous results.

Previous | Contents | Next