Whenever source and target boxes are not type-compatible (see figure 2), copy and share cannot proceed on their own. However, should an adequate type converter exist for the application involved, the operation can proceed.
Automatic type conversion in copy operations is useful not just to handle typical data translations, as it was seen before, but also to automate copying on heterogeneous systems (e.g.: application X could use Xintel and Xsparc boxes; employing Xintel2sparc and Xsparc2intel translators). Whenever source and target locations are homogeneous, translating application data to a network format (and vice-versa) can then be avoided in a natural way. Simply, the conversion would not be triggered by the system. In certain cases, homogeneous environments with different processing power or hardware capabilities (e.g an Intel-based PDA vs. an Intel-based desktop environment) could be considered to employ different box types (e.g. a low-quality image format vs. a high-quality image format). In that way, data would be converted automatically to a cheaper format, which could be handled with less resources, on those environments where resources are scarce.
Using converters for share has more subtleties than using them for copy. Being a converter a one-way operation, in most of the cases, there will not be a reverse-converter to obtain the source from the target. When the reverse-converter exists, the pair of forward and reverse converters may be used to establish a type compatibility declaration which does transform the box back and forth--unlike typical compatibility declarations, which behave as type casts. Even when the reverse-converter exists, it is not clear that applying the reverse-converter will regenerate the original source box--e.g. using a2ps (which translates an ASCII text to PostScript) and then ps2ascii (which does the opposite) will hardly yield the original text. We had to choose between two simple alternatives:
By following the second approach, non-type-compatible sharing can effectively express dependencies between boxes. That is hardly expressed using files. We use the concept of non type-compatible sharing to effectively maintain different formats or views for the same information (e.g. the LATEX and the, generated, PostScript for a given document).
Converters can be plugged together to build new converters (e.g. in the example used above, the Xintel2sparc converter can be ensembled by plugging together Xintel2network and Xnetwork2sparc converters). On automatic type conversions, the OS can combine converters automatically when a single converter is not enough (when more than one combination is feasible, the OS can simply select the first combination found).
In general, a converter can accept n different input boxes, and generate m different output boxes (where n and m could be zero, and each box can be of a different type).
In a box-based environment, users execute programs by using a copy operation from a program input box to the program output box. An imaginary graphical user interface for a box-based environment would let the user copy the program input to the program output; asking for additional input boxes when the converter needs so. All that is to say that programs manipulate boxes.
Finally, it should be said that converters are the answer to the question: will typed boxes end up causing the same inconveniences typed files cause? Unlike traditional typed files, boxes allow type conversion by installation of adequate converters (an extreme case would be the installation of an universal type converter, which simply bypasses the entire type system).