This section is very tentative.

There seem to be basic situations where you must know what you have by the logic of where you got it.

The most familiar form of this is the 32 bit floating point number. There is no test that you can apply to 32 bits of data to determine whether they form a floating point number. The same bits may, elsewhere, form an integer.

Algol 68 can pass a REAL or INT to a subroutine that takes a parameter of mode UNION(REAL, INT). The routine can ascertain which case holds with a conformity clause. This is implemented not by associating a type field with every value, but only in those values where there is a declared "flexibility".

I think that we should have a mode "OS-FILE" which can be passed to the OS simulator. Such a value would be composed of a type indicator along with the basic value. For example <"co-gate-producer",resume key> might be an OS file.

The first component tells the simulator the kind of animal it has and the second component is the animal.

A commonplace analogy is the instructions for something that you purchase. The thing and the instructions for it are separate.

We have the concept of a directory. We also have the concept of a record collection. But a directory is {composed of ?} a record collection. The instructions can say that the object is a directory if you want the simulator to treat it so.

I am uneasy with these arguments. Usually I think that a routine parameter should be at a constant level of abstraction. I think that "record collection" and "directory" are at different levels but I am not sure.

Perhaps a structure does not an abstraction make!