Blue pane. Not the full monty. (Was units)

Brian Shearing 100270.1071 at compuserve.com
Sat Apr 11 20:59:43 UTC 1998


Alan Kay writes "As a tiny example, it would help in many
ways if Smalltalk had "units" (meters, ergs, liters, etc.)."

In the sixties when Alan was working on these ideas on one
side of the Atlantic, I and a small group of programmers were
building the General Engineering System, GENESYS, for the
UK government on the other side. The idea was that software
in engineering disciplines such as structural engineering,
highways design, surveying, and water engineering could share
common styles of input and output, and could be developed
and used identically across a range of computers and operating
systems. Some of you may remember project ICES from MIT
which shared some of the aims of GENESYS.

One of the matters we had to tackle was that of units of measure
and, by implication, dimensionality. During the seventies
GENESYS came to be used widely in the UK and other countries
in northern Europe. The UK was still imperial in its weights and
measures, although SI units were emerging. Other countries in
Europe were metric by tradition. We simply had to find a way
of allowing mixtures of unit.

The solution that we adopted was to give choice of units to the
user, not the programmer. For every item of input and output,
the programmer declared a dimensionality such as LENGTH/TIME.
The user could choose a set of units. Programs were written in
base SI units such as metre and gram. Input routines converted
from user's units to base SI units. Output routines did the reverse.

We had a double-comma operator enabling an item of input to be
written with explicit units. For example, to overide the declared
units the user could enter an item as 25.6,,KM/HR.

For little more effort by us than including a simple expression
parser in the numeric input routines, the user could work in any
units, and the programmer could forget the whole issue.

We had to be careful to distinguish mass from weight, and we
had to make the formatting of output dependent on the choice
of unit. But except for one or two complications such as these,
the ratio of utility to effort was gratifyingly high.

This tale from the sixties suggests a low cost adaptation of a
programming language in which the syntax of a literal numeric
value, both within program text and as accepted by input routines,
is extended to include dimensionality. Thus 25.6 means 25.6
but 25.6km/hr means whatever 25.6 kilometres per hour is in
base SI units. Output routines could take an extra parameter as
in nextput: speed units: 'km/hr'. 

Thinking of units and dimensionality only as a concern of input
and output, or more precisely of encoding and decoding, does not
of course address the programming issue of extending the meaning
of 'type' to include dimensionality, thereby achieving an extra level
of strong typing. But it does seem to meet many requirements.
It could even be considered a step towards what Alan describes as
"humanizing" Smalltalk to deal with world concepts. It isn't the
full monty, but maybe it's one of those 80-20 ideas.

Brian Shearing

The Software Factory
28 Padbrook
Limpsfield
Surrey RH8 0DW
England





More information about the Squeak-dev mailing list