Resp ectful Type Converters
Jeannette M Wing John Ockerbloom
May
CMU CS
School of Computer Science
Carnegie Mellon University
Pittsburgh PA
Submitted to IEEE Transactions on Software Engineering
Abstract
In converting an ob ject of one type to another we exp ect some of the original ob ject s b ehavior to remain
the same and some to change How can we state the relationship b etween the original ob ject and converted
ob ject to characterize what information is preserved and what is lost after the conversion takes place
We answer this question by introducing the new relation respects and say that a type converter function
C A B respects a type T We formally de ne respects in terms of the Liskov and Wing b ehavioral notion
of subtyping types A and B are subtypes of T
We explain in detail the applicability of resp ectful type converters in the context of the Typed Ob ject Mo del
TOM Conversion Service built at Carnegie Mellon and used on a daily basis throughout the world We also
brie y discuss how our respects relation addresses a similar question in two other contexts type evolution
and interoperability
This research is sp onsored in part by the Defense Advanced Research Pro jects Agency and the Wright Lab oratory
Aeronautical Systems Center Air Force Materiel Command USAF F and Rome Lab oratory Air
Force Materiel Command USAF under agreement number F and in part by the National Science
Foundation under Grant No CCR The U S Government is authorized to repro duce and distribute reprints
for Governmental purp oses notwithstanding any copyright annotation thereon The views and conclusions contained
herein are those of the authors and should not b e interpreted as necessarily representing the o cial p olicies or
endorsements either expressed or implied of the Defense Advanced Research Pro jects Agency Rome Lab oratory or the U S Government
Keywords type converters ob ject rep ository distributed ob jects subtype ob ject oriented design abstraction function sp eci cations semantics Larch type evolution interoperability
Motivation
The tremendous growth of the Internet and the World Wide Web gives millions of p eople access to vast
quantities of data While users may b e able to retrieve data easily they may not b e able to interpret or
display retrieved data intelligibly For example when retrieving a Microsoft Word do cument without a
Microsoft Word program the user will b e unable to read edit display or print it In general the type of
the retrieved data may b e unknown to the retrieving site
Users and programs cop e with this problem by converting data from one type to another e g from the
unknown type to one known by the lo cal user or program Thus to view the Word do cument we could
convert it to ASCI I text or HTML and then view it through our favorite text editor or browser A picture
in an unfamiliar Windows bitmap type could b e converted into a more familiar GIF image type A mail
message with incomprehensible MIME attachments could b e converted from an unreadable MIME enco ded
type to a text image or audio type that the recipient could examine directly In general we apply type
converters on data ob jects transforming an ob ject of one type to an ob ject of a di erent type
What Information Do Type Converters Preserve
In converting ob jects of one type to another we exp ect there to b e some relationship b etween the original
ob ject and the converted one In what way are they similar The reason to apply a converter in the rst
place is that we exp ect some things ab out the original ob ject to change in a way that we are willing to forgo
a
but we also exp ect some things to stay the same For example supp ose we convert a L T X le to an HTML
E
a
le We may care to ensure that the raw textual contents of the original L T X do cument are preserved but
E
not the formatting commands since they do not contribute to the meaning of the do cument itself here the
preserved information is the underlying semantics of the text contained in the do cument Alternatively if
a
we convert a L T X le to a table of contents do cument we may care to ensure that the number order and
E
titles of chapters and sections in the original do cument are preserved but not the bulk of the text here the
preserved information is primarily the do cument s structure
The question we address in this pap er is How can we characterize what information is preserved by a
type converter Our answer is given in terms of the b ehavior of some type T Informally we say a converter
C A B respects type T if the original ob ject of type A and the converted ob ject of type B have the
same b ehavior when b oth ob jects are viewed as a type T ob ject That is from T s viewp oint the A and B
ob jects lo ok the same If the converter resp ects a type then it preserves that type s observable b ehavior
This pap er formalizes this novel notion of respectful type converters
Our particular formalization of respects exploits the subtype relationship that holds among types of ob
jects The Liskov and Wing notion of b ehavioral subtyping conveniently characterizes semantic di erences
b etween types If S is a subtype of T users of T ob jects cannot p erceive when ob jects of type S are substi
tuted for T ob jects Intuitively if C resp ects type T an ancestor of b oth A and B in the subtype hierarchy
then T captures the b ehavioral information preserved by C
This pap er sp ells out how to determine whether a given ancestor T in a type hierarchy is resp ected by
a converter C A B Figure In general A and B need not b e subtypes of each other in practice
they are often siblings or cousins in a given type hierarchy Also in general T is not necessarily the least
common ancestor of A and B
Here is an example of why T is not just any ancestor of A and B Supp ose that the PNG image and
map type Figure that sp eci es the colors of the pixels in GIF image types are b oth subtypes of a pixel
a rectangular region GIF images are limited to distinct colors PNG images are not Assuming the
pixel map type also do es not have a color limit then a general converter from PNG images to GIF images
would not resp ect the pixel map type it is p ossible to use pixel map s interface to distinguish a PNG image
with thousands of colors from its conversion to a GIF image with at most colors On the other hand
map is in turn a subtype of a more generic bitmap type that simply records whether a graphical supp ose pixel
map are considered set if element is set or clear see Figure Supp ose further that elements in a pixel
they are not black and clear if they are black As long as the PNG to GIF converter do es not change any
non black color to black or black to non black and otherwise preserves the pixel layout there is no way
for the bitmap interface to distinguish the PNG image from the GIF image that results from the conversion
Here then the PNG to GIF converter resp ects the bitmap type T
......
AB
C: A B
Figure Do es Converter C Resp ect Type T
bitmap (set or clear)
pixel_map (1000's of colors)
PNG GIF (1000's of colors) (256 colors)
C: PNG GIF
Figure The PNG to GIF converter resp ects bitmap but not pixel map
Although we explore the idea of resp ectful type converters primarily in the context of le and do cument
converters type converters show up in other contexts Most programming languages have built in type
converters de ned on primitive types for example ascii integer char string and string array char The
real world is continually faced with painful costly yet seemingly simple conversions the U S Postal System
converted ve digit zip co des to ve four digit zip co des Bell Atlantic recently added a new area co de
necessitating the conversion of a large p ortion of phone numbers in Western Pennsylvania from the area
co de to and payroll pro cessing centers routinely need to convert large databases of employee records
whenever extra elds are added to the relevant database schema
Roadmap to Rest of Paper
In this pap er we formally characterize the notion of when a converter respects a type We rst review in
Section how we sp ecify types and determine when one type is a subtype of another b orrowing directly
from Liskov and Wing s b ehavioral notion of subtyping In Section we exploit this notion of subtyping
to de ne the respects relation b etween a converter and a type
Armed with these formal de nitions in Section we show how they are used in practice in the application
of the Typed Ob ject Mo del TOM Conversion Service which we built at Carnegie Mellon and use on a daily
basis In Section we discuss a further extension of respects that enables us to relate the implementation
of types to their sp eci cations sp eci cally the abstraction function used to show the correctness of the
implementation of abstract types ts neatly into the way we de ne respects In Section we brie y discuss two
other applications of our respects relation type evolution and reusability in the context of interoperability
Section gives a status rep ort of the TOM Conversion Service and puts it in a broader setting given TOM s
environment We close with a discussion of future work
Behavioral Subtyping
The programming language community has come up with many de nitions of the subtype relation The goal
is to determine when this assignment
x T E
is legal in the presence of subtyping Once the assignment has o ccurred x will b e used according to its
apparent type T with the exp ectation that if the program p erforms correctly when the actual type of x s
ob ject is T it will also work correctly if the actual type of the ob ject denoted by x is a subtype of T
What we need is a subtype requirement that constrains the b ehavior of subtypes so that users will not
encounter any surprises
No Surprises Requirement Prop erties that users rely on to hold of an ob ject of a type T should
hold even if the ob ject is actually a member of a subtype S of T
which guarantees Liskov s substitutability principle of subtypes
In their TOPLAS pap er A Behavioral Notion of Subtyping Liskov and Wing formalized this
requirement in their de nition of subtyping The novel asp ect of their subtype de nition is the ability to
handle mutable types In this pap er we present a simpli ed version of their de nition since for all our
applications we can ignore mutable ob jects We discuss the extension of our work to mutability as future
work in Section
Under this simpli cation rst we describ e our mo del of ob jects and types and then how we sp ecify types
Finally we de ne the subtype relation
Mo del of Ob jects Types and Computation
We assume a set of all p otentially existing ob jects Obj partitioned into disjoint typed sets Each ob ject
has a unique identity A type de nes a set of values for an ob ject and a set of methods that provide the only
means to manipulate or observe that ob ject
Ob jects can b e created and manipulated in the course of program execution A state de nes a value for
each existing ob ject It is a pair of mappings an environment and a store An environment maps program
variables to ob jects a store maps ob jects to values
State Env Store
Env Var Obj
Store Obj Val
Given a variable x and a state with an environment e and store s we use the notation x to denote
the value of x in state i e x s e x When we refer to the domain of a state dom we mean
more precisely the domain of the store in that state
We mo del a type as a triple hO V M i where O Obj is a set of ob jects V Val is a set of values and
M is a set of metho ds Each metho d for an ob ject is a constructor or an observer Constructors of an ob ject
of type return new ob jects of type observers return results of other types Ob jects are immutable their
values cannot change All our types are immutable We also allow metho ds to signal exceptions we assume
termination exceptions i e each metho d call either terminates normally or in one of a number of named
exception conditions To b e consistent with ob ject oriented language notation we write x m a to denote
the call of metho d m on ob ject x with the sequence of arguments a
Ob jects come into existence and get their initial values through creators Unlike other kinds of metho ds
creators do not b elong to particular ob jects but rather are indep endent op erations They are the class
methods the other metho ds are the instance methods
A computation i e program execution is a sequence of alternating states and transitions starting in
some initial state
0
T r T r
0 1 1 n 1 n n
Each transition T r of a computation sequence is a partial function on states
i
Ob jects are never destroyed i n dom dom
i 1 i
Type Sp eci cations
A type sp eci cation contains the following information
The type s name
A description of the set of values over which ob jects of the type ranges
For each of the type s metho ds
Its name
Its signature i e the types of its arguments in order result and signaled exceptions
Its b ehavior in terms of pre conditions and p ost conditions
Figure gives an example of a type sp eci cation for GIF images We give formal sp eci cations written
in the style of Larch but we could just as easily have written informal sp eci cations Since these
sp eci cations are formal we can do formal pro ofs p ossibly with machine assistance like with the Larch
Prover to show that a subtype relation holds
The GIFImage Larch Shared Language trait and the invariant clause in the Larch interface type sp ec
i cation for GIF images together describ e the set of values over which GIF image ob jects can range GIF
images are sequences of frames where each frame is a b ounded two dimensional array of colors App endix
A contains the GIFImage trait as well as those for frame sequences frames colors etc
A type invariant constrains the value space for a type s ob jects In the GIF example the type invariant
says that a GIF image can have at most di erent colors The colorrange function de ned in GIFImage
returns the range of colors mapp ed onto by the array The predicate x app earing in an invariant clause
for type stands for the predicate For all computations c and all states in c
x x dom x
GIF type
uses GIFImage gif for G
for all g GIF
invariant j col or r ang e g j
color get color i j int
ensures r esul t ov er l ay g i j
frame get frame i int
requires i l en g
ensures r esul t g i
b o ol is set i j int
ensures r esul t ov er l ay g i j BLACK
b o ol equal a GIF
ensures r esul t a g
end GIF
Figure A Larch Type Sp eci cation for GIF Images
The requires and ensures clauses in the Larch interface sp eci cation state the metho ds pre and
p ost conditions resp ectively To b e consistent with the Liskov and Wing pap er and the Larch approach
1
pre conditions are single state predicates and p ost conditions are two state predicates In Larch interface
sp eci cations as shown in Figure the absence of a requires clause stands for the pre condition true
The get color metho d returns the color of the i j th array element of g The overlay function de ned in
GIFImage returns the color value of the i j th array element of the last frame in the sequence that gives
a value for i j otherwise it returns BLACK a distinguished color value introduced in the LSL trait for
colors For example if there are three frames in the frame sequence and for a given i j the rst frame
maps the array element to BLACK the second to RED and the third do es not map i j to any color
b ecause it is not within its b ounds then RED is returned
To ensure that the sp eci cation is consistent the sp eci er must show that each creator for the type
establishes s invariant and each of s metho ds preserves the invariant These are standard conditions and
their pro ofs are typically straightforward
The inclusion of pre and p ost conditions in the sp eci cation of a type s metho ds allows us to relate
the b ehaviors of two di erent types this is the main di erence b etween the Liskov and Wing de nition of
subtyping and those that rely on just signature information e g Cardelli For example two metho ds
with the same signature e g addition and exp onentiation for integers may have dramatically di erent
b ehavior Relying on just signature information identi es these metho ds that b ehave di erently thus ner
subtyping distinctions can b e made when b ehavioral information is used in addition to signature information
The Subtype Relation
The subtype relation is de ned in terms of a checklist of prop erties that must hold b etween the sp eci cations
of the two types and Since in general the value space for ob jects of type will b e di erent from the
value space for those of type we need to relate the di erent value spaces we use an abstraction function
to de ne this relationship Also since in general the names of the metho ds of type can b e di erent from
1
However since we write formal sp eci cations for only immutable types in this pap er to increase their readability we take
the lib erty of not qualifying variables denoting ob jects with pre or post subscripts since x x for all ob jects x
pr e post
those of type we need to relate which metho d of corresp onds to which metho d of we use a renaming
map to de ne this corresp ondence In a programming language like Java this is just the identity map
as realized though metho d overloading
is a subtype of if the following two conditions hold informally stated
The abstraction function resp ects the invariants If the subtype invariant holds for any subtype value
s then the sup ertype invariant must hold for the abstracted sup ertype value s
Subtype metho ds preserve the sup ertype metho ds b ehavior If m is a subtype metho d then let n b e
the corresp onding m metho d of the sup ertype
Signature rules
Arguments to m are contravariant to the corresp onding arguments to n m s result is covariant
to the result of n
Any exception signaled by m is contained in the set of exceptions signaled by n
Metho ds rules
n s pre condition implies m s under the abstraction function
m s p ost condition implies n s under the abstraction function
The metho ds rules are completely analogous to the contra covariant signature rules
2
The formal de nition of the subtype relation is given in Figure It relates two types and
each of whose sp eci cations we assume resp ectively preserves its invariant I and I In the metho ds rules
since x is an ob ject of type its value x or x is a member of S and therefore cannot b e used directly
pr e post
in the predicates ab out ob jects which are in terms of values in T The abstraction function is used to
translate these values so that the predicates ab out ob jects make sense
Why do es this subtype relation guarantee that the No Surprises Requirement holds Recall that the
Requirement refers vaguely to prop erties This de nition of subtype guarantees that certain prop erties of
the sup ertype those stated explicitly or provable from a type s sp eci cation are preserved by the subtype
The rst condition directly relates the invariant prop erties the second condition relates the b ehaviors of
the individual metho ds and thus preserves any observable b ehavioral prop erty of any program that invokes
those metho ds
This de nition of subtyping supp orts multiple sup ertypes If S is a subtype of b oth T and U then
the designer is obligated to show the ab ove checklist of conditions holds b etween S and T and b etween S
and U Implementation problems that arise b ecause of multiple inheritance are irrelevant subtyping is a
relationship b etween sp eci cations not implementations
map To show that GIF is a subtype of pixel map Figure Figure gives a type sp eci cation for pixel
we de ne the following abstraction function
PM
G PM
G
PM
i j Integer g i j ov er l ay g i j
G
Using this abstraction function the pro ofs that the invariant signature and metho ds rules hold are
straightforward
Resp ects
De nition of Resp ectful Type Converter
Supp ose we have two types A hO V M i and B hO V M i A converter C is a partial function
A A A B B B
from V to V Thus when we say that a converter maps from type A to type B we mean more precisely
A B
that it maps the value space of type A to the value space of type B for notational convenience we continue
to write the signature of C as A B
2
It is a simpli cation of Liskov and Wing s constraint rule de nition Fig of by omission of the constraint rule
condition
Definition of the subtype relation hO S M i is a subtype of hO T N i if
there exists an abstraction function S T and a renaming map M N such that
The abstraction function resp ects invariants
Invariant Rule s S I s I s
may b e partial need not b e onto but can b e many to one
Subtype metho ds preserve the sup ertype metho ds b ehavior If m of is the corresp onding
renamed metho d m of the following rules must hold
Signature rule
Contravariance of arguments m and m have the same number of arguments If
the list of argument types of m is a and that of m is b then i a b
i i i i
Covariance of result Either b oth m and m have a result or neither has If there
is a result let m s result type b e a and m s b e b Then b a
Exception rule The exceptions signaled by m are contained in the set of exceptions
signaled by m
Methods rule For all x
Pre condition rule m pr e x x m pr e
pr e pr e
Post condition rule m post m post x x x x
pr e pr e post post
Figure De nition of the Subtype Relation
Let T b e a type that is a common ancestor of A and B in a given type hierarchy T is a sup ertype of b oth
A and B Then there exist ancestor types A A b etween A and T such that there exist the following
1 n
abstraction functions
A A
0 1
A A
i i i+1
A T
n n
Assuming for all i n dom ran let b e the functional comp osition of
i i 1 i
n 0
For B we similarly de ne B and for i m Figure illustrates these constructs
i i
Figure gives the de nition of the respects relation for a converter C A B and type T The rst
condition requires that m s pre condition holds for a s abstracted value under i it holds for the converted
value of a abstracted under Thus from T s viewp oint if m is de ned for A s values it should b e de ned
for B s values and vice versa The second condition requires that m s p ost condition holds for a s abstracted
value under i it holds for the converted value of a abstracted under Thus given that m is de ned
then its b ehavior must b e the same for A s values and B s values from T s viewp oint
Both conditions together guarantee that T s b ehavior is preserved by the conversion of ob jects of type
A to those of type B Informally T cannot p erceive a di erence b etween the original A ob ject and the
converted B ob ject thus C respects T
Finally if a and C a abstractly map to the same value in T that is a C a for all a in the
domain of C then the respects relation trivially follows This sp ecial case is often useful in pro ofs that a
converter resp ects a type as we will see in the next section
pixel map type
uses PixelMap pixel map for PM
map for all p pixel
invariant tr ue
color get color i j int
ensures r esul t p i j
set i j int b o ol is
ensures r esul t p i j BLACK
b o ol equal a pixel map
ensures r esul t a p
map end pixel
Figure A Larch Type Sp eci cation for Pixel Maps
PNG and GIF Example Revisited
Let us lo ok at the PNG to GIF example more carefully First we give the type sp eci cation for PNG images
and abstraction functions that enable us to argue the remaining subtype relationships of Figure Then
map but that we consider converters b etween PNG and GIF to argue that no total converter resp ects pixel
some resp ect bitmap
map ob jects The type sp eci cation for PNG images is given in Figure PNG images di er from pixel
in two ways they are framed and asso ciated with each PNG ob ject p is a gamma value denoted
gamma p used in a gamma correction function g c The gamma correction function corrects for di erences
among monitors some are dimmer than others and thus have di erent color balances We abstract from the
intricacies of gamma correction functions for our purp oses here they take as arguments a color an input
gamma factor an output gamma factor and return a color The constant STDG is the standard gamma
value for normal monitors The Gammas and PNGImage traits are in App endix A
Note to show that PNG is a subtype of pixel map we have a nontrivial application of the renaming map
where get corrected color get color Only the last three metho ds for PNG have corresp onding
sup ertype metho ds the rest are left unmapp ed by
map We de ne b elow two abstraction functions one to show that PNG is a subtype of pixel
PM
P BM
P
8
g c p i j g amma p S T D G if xmin p i xmax p
<
PM
i j Integer p i j y min p j y max p
P
:
BLACK otherwise
map is a subtype of bitmap and one to show that pixel
BM
PM BM
PM
set if pm i j BLACK
BM
i j Integer pm i j
PM
clear if pm i j BLACK
Consider a converter C P G that maps values of PNG images to GIF values
Claim There is no such converter that respects pixel map if the converter is de ned for PNG images of
more than colors
Proof A simple counting argument su ces to prove this Let p be the value of a PNG image where
PM
map value P also has at least j col or r ang e p j n and n Then the corresponding pixel
P
PM
colors This holds because the color value of p g c p i j g amma p S T D G So every array
P
PM
element of p maps to some array element of p Furthermore if two array elements in p have di erent
P T α : A T β : B T n n m m
A n B m α : A A β i i i+1 i: B i Bi+1 ......
A B 1 1 α : A A β : B B 0 1 0 1
AB
α= α... α ... α n i 0 β= β... β ... β
m i 0
Figure Two Comp ositions of Abstraction Functions
Definition of respects relation Let C A B b e a converter function a partial function
mapping values of type A to values of type B Let T b e an ancestor of b oth A and B in a given
type hierarchy Then converter C respects T if for each metho d m of T a dom C
m pr e a x m pr e C a x and
T pr e T pr e
m post a x a x m post C a x C a x
T pr e post T pr e post
where and are de ned in text and depicted in Figure
Figure De nition of the Resp ects Relation
PM
colors so do the corresponding cells in p To prove this we show that if two gamma corrected colors
P
are the same then the original colors c and c also had to be the same i e
Suppose
g c c g amma p S T D G g c c g amma p S T D G
By the transitivity and re exivity properties of gamma correction functions see Appendix A
we know that
g c g c c g amma p S T D G S T D G g amma p c
By substitution in line we get
g c g c c g amma p S T D G S T D G g amma p c
Yielding
c c
PM
So if there are n colors in p then there are also at least n in p
P
The conversion of p to a GIF image C p can have a maximum of colors by the invariant of GIF
PM
map value C p can image Furthermore there is no way the abstraction mapping of C p to a pixel
G
add any further colors except for BLACK since we see from the GIF to pixel map abstraction function
PM PM
that every element in the color set of C p is either BLACK or one of the colors used in one
G G
PM PM
of the frames of C p Therefore some of the colors available in p are not available in C p
P G
color i j for some i and j wil l be di erent Therefore the converter cannot respect So the value of get
pixel map 2
PNG type
uses PNGImage PNG for P
for all p PNG
invariant tr ue
color get uncorrected color i j int
requires xmin p i xmax p y min p j y max p
ensures r esul t p i j
gamma gamma get
ensures r esul t g amma p
int get xmin
ensures r esul t xmin p
and similarly for get xmax get ymin and get ymax
color get corrected color i j int
ensures xmin p i xmax p y min p j y max p
r esul t g c p i j g amma p STDG
xmin p i i xmax p y min p j j y max p
r esul t BLACK
set i j int b o ol is
ensures r esul t g c p i j g amma p STDG BLACK
b o ol equal a GIF
ensures r esul t a p
end PNG
Figure A Larch Type Sp eci cation for PNG Images
It is p ossible however to have a converter from PNG images to GIF images that resp ects the bitmap type
Claim There exist such converters that respect bitmap
3
Proof By existence Here is a simple minded converter
C P G
C p g where
xmin g xmin p xmax g xmax p
y min g y min p y max g y max p
BLACK if g c p i j g amma p S T D G BLACK
i j Integer g i j
WHITE otherwise
BM PM
Composing the abstractions functions we get a bitmap b for a given PNG image p
PM P
8
set if xmin p i xmax p y min p j y max p
<
i j Integer b i j g c p i j g amma p S T D G BLACK
:
clear otherwise
PM BM
we get a bitmap b for a given GIF image C p Composing the abstractions functions
G PM
set ov er l ay C p i j BLACK
i j Integer b i j
clear otherwise
By substituting the de nition of overlay given the de nition of C above we get that Since the
two bitmaps are the same the converter C respects bitmap 2
An Application The TOM Conversion Service
Overview of TOM
As part of his Ph D thesis Ockerbloom the second author invented a Typed Ob ject Mo del a data
mo del involving ob jects types and their asso ciated metadata The thesis includes de nitions and explana
tions of intersubstitutability which is like our respects relation though formulated di erently The thesis also
includes full information ab out the design of TOM and describ es exp erience building and using TOM based
applications
Ockerbloom implemented an instance of the TOM mo del a type broker that allows users in a distributed
environment to store types and type conversion functions to register new ones and to nd existing ones
a
The kinds of types TOM supp orts to day are di erent kinds of do cument types e g Word L T X Power
E
Point binhex HTML and packages of such do cument types e g a mail message that has an embedded
p ostscript le a tar le or a zip le The kinds of conversions TOM supp orts are o the shelf converters
TM
like postscript pdf i e Adob eDistiller o the Web ones like latex html and some home grown ones like
powerpoint html
Users can comp ose available converters to pro duce an ob ject of a desired target type For example
to make a fourteen year old Scrib e do cument available on the Web the rst author used a scribe latex
a
converter to pro duce a L T X le and then an enhanced latex html converter to pro duce the Web version
E
This scenario is similar to that describ ed in the introduction Section here the comp osition of the two
a
converters preserves the semantics of the original Scrib e do cument Ironically the L T X program failed to
E
a
run successfully on the intermediate L T X le but for this application it did not matter it was the end
E
result the HTML le that mattered
Some of TOM s converters esp ecially the home grown ones are de ned in terms of others For example
the conversion of a PowerPoint do cument to an HTML le is actually done through the application of
nine di erent intermediate steps going through di erent intermediate types like rtf p ostscript and ppm
3
A more realistic converter would not map all non BLACK colors to WHITE but to something closer to the original color
however the ab ove simpli es the pro of communication package
zephyrgram mail_message delimited_package
parsed_mail_message zipfile tarfile MIMEmultipart uuencoding
same mixed alternatives
Figure Part of TOM s Type Hierarchy
These intermediate steps include converting p ostscript les to ppm les resizing and rotating ppm les and
converting ppm les to GIF les TOM users of the powerpoint html converter see none of these intermediate
steps
We discuss TOM s usage and status in more detail in Section
Snipp ets from the TOM Type Hierarchy
When Ockerbloom designed TOM he made the following critical design decision All ob jects are immutable
The rationale b ehind the decision is that he wanted to treat arbitrary information in a distributed environ
ment like the Web as ob jects If ob jects can change in value then issues of storage up date and concurrency
control must b e resolved p erhaps using standard distributed le system or distributed database techniques
If ob jects cannot change in value then TOM do es not have to worry ab out how they are stored where they
are stored how they are up dated if and how they are copied or replicated and how to co ordinate concurrent
access to them Rather ob jects can live anywhere b e created by anyone and b e shipp ed around freely
Despite this design simpli cation of disallowing mutable types TOM do es supp ort an interesting sub
type hierarchy Figure gives a subgraph of the TOM type hierarchy For example TOM makes a
package and one which is just a distinction b etween a package type that has clear delimiters delimited
mail message containing a mail header and some uninterpreted contents A parsed mail message is distinct
from a mail message b ecause the type of the message s contents has b een determined e g a p ostscript le
Also TOM supp orts packages of packages and so for example a mail message can contain a forwarded mail
message which itself contains a MIMEmultipart le TOM is smart enough to unwrap these packages and
present their contents so that users can meaningfully interact with the individual pieces
Notice two examples of multiple sup ertypes in this subgraph The parsed mail message type is a subtype
of b oth mail message and delimited package and a mail message itself is a subtype of b oth package and
communication
We carefully designed the TOM type hierarchy so that each subtype either only adds new metho ds or
changes by overriding old metho ds in a constrained way Thus proving that the Liskov and Wing subtype
conditions hold b etween types in the TOM hierarchy is relatively easy There are two main cases
Case If no changes to old metho ds are made then the pro of is trivial Since no old metho d is document
hierarchical hyperlinked paginated document document document
troff Scribe LaTeX HTMLPDF Word PowerPoint postscript ASCII
LaTeX_with_URLs
Figure Another Part of TOM s Type Hierarchy
overridden invariants are preserved and the b ehavior of old metho ds is preserved In the typical case
the subtype ob ject simply has more extra state information e g more elds in a record more instance
variables of an ob ject or extra attributes The abstraction function is the obvious many to one function
that throws away the extra state information The b ehavior of the subtype metho ds is identical to that of
the corresp onding sup ertype metho ds and new metho ds de ned on the extra state have no corresp onding
sup ertype metho d
For example b ordered windows colored windows and scrollable windows are all extended subtypes of
a more generic window type In their pap er Liskov and Wing call these extension subtypes since the
subtype extends the sup ertype by providing additional state and corresp ondingly additional metho ds
Case If changes to old metho ds are made then Part of the subtype de nition applies the con
tra covariant rules the exception rule and most imp ortantly the pre p ost condition rules must b e shown
If subtypes always only further constrain the b ehavior of the corresp onding sup ertype metho ds then it is
easy to show that invariants are preserved given that Part holds and that the sp eci cations are consistent
The abstraction function is usually into rather than onto
For example in Figure GIF image is a subtype of pixel map by constraining the colors over which a
GIF image element can range In their pap er Liskov and Wing call these constrained subtypes b ecause the
degree of variability is reduced in the subtype
In general a subtype might b oth extend and constrain its sup ertype For example in Figure uuenco ding
constrains delimited package by constraining the number of items in the package to b e exactly one it extends
delimited package by including UNIX le protection bits as additional state
Consider another snipp et of the TOM type hierarchy that deals with do cument types shown in Figure
a
Supp ose that L T X and HTML do cuments b oth abstractly map to a hierarchical do cument type that
E
sp eci es a hierarchy of sections and the text included in each section The converter function latex html
resp ects the hierarchical do cument type if it preserves the b o dy text and the section hierarchy implied by
a
L T X sectioning commands and HTML header levels A lo oser conversion b etween the same two types
E
might preserve the b o dy text but not the section hierarchy and thus resp ects the generic do cument type
but not the hierarchical do cument type Note that type conversions may involve not only siblings but
cousins or ancestors as well Hence an html ascii converter might simply resp ect the generic do cument
a a
with URLs to basic L T X de ned so that it follows the abstraction function type A converter from L T X
E E
a
b etween the same types resp ects the basic L T Xtype i e the parent type
E
Incorp orating Concrete Types
So far we have discussed the respects relation in terms of abstract types since the subtype relation is de ned
in terms of a relation on abstract types It makes sense however to consider the respects relation in terms of
concrete types to o For example when we implement an abstract type in a programming language we choose
a representation type for the abstract type and de ne the abstract type s metho ds in terms of metho ds on
the representation type
The TOM context introduces another kind of concrete type When a user retrieves an ob ject from a
remote site in reality that ob ject is enco ded in terms of some transmissible type a concrete representation
of the abstract ob ject These transmissible types are in turn represented in terms of primitive types that the
underlying communication substrate understands for TOM and for the purp oses of this pap er it su ces
that every transmissible ob ject b e representable in terms of sequences of bytes part of the byte sequence
might represent metadata e g the name of the abstract type and the rest represents the data ob ject itself
Both of these kinds of concrete types may give rise to a new kind of converter that from a concrete
type to another concrete type For example in programming languages if we have an abstract p oint type
with two di erent representations one using Cartesian co ordinates and one using p olar we may want to
implement a converter that takes any Cartesian p oint and pro duces the corresp onding p olar co ordinates
Similarly for an abstract matrix type we may want to represent matrices in terms of b oth row order and
column order and de ne converters b etween the two
In the TOM context integers may b e represented in terms of a bit sign extension byte sequence or
a twos complement little endian byte sequence or even ASCI I strings These are all plausible concrete
representations of integers and conversions b etween them should resp ect the abstract integer type
Extending the De nition of Resp ects
To extend our de nition of respects to accommo date converters from concrete type to concrete type we
b orrow from the programming language community we use the very same abstraction function used to
prove the correctness of data representations rst introduced by Hoare in
Let converter C A B b e de ned on two concrete types A and B Then if A
conc conc conc conc conc
and B are correct implementations of abstract types A and B resp ectively there exist abstraction
conc
functions
A A A
conc
B B B
conc
We mo dify the de nition of respects by mo difying the de nitions of and of Section accordingly
Assuming that dom ran A and dom ran B we de ne
0 0
A
n 0
B
m 0
That is we rst apply the abstraction function A on the concrete value of type A to form an abstract
conc
value of type A we do the same to the concrete value of type B using B C resp ects T if the same
conc
condition holds as b efore but using the revised and abstraction functions de ned ab ove In the case
that the converter C maps an abstract type to a concrete one or vice versa then we can omit the application
of A or B as appropriate
Examples
A degenerate example of this extension to the resp ects relation is the abstract p oint example If we write a
conversion function from Cartesian co ordinates to p olar co ordinates abstractly they are the same p oint and
should exhibit the same b ehavior as de ned by the sp eci cation of the abstract p oint type
A less degenerate example from the TOM application is in representing directories A directory type
might b e represented as a list of strings type The list of strings type might in turn b e represented by the
the sequence of bytes type i e a transmissible type A client who wishes to view the contents of a remote
directory can do so even though the client s le system e g Window NT may di er from the server s e g
afs
A common situation in using TOM involves a client retrieving an ob ject from a remote server The client
would like to view the ob ject originally in type A as an ob ject of type B so far as it resp ects some type T
In the client s mind some abstract conversion from A to B is b eing p erformed The problem is that the A
ob ject has to b e represented in terms of something transmissible across the wire so rst it is enco ded into
some transmissible type and then the client deco des the transmitted ob ject into a B ob ject Here A and
conc
B may very well b e the same transmissible type e g sequence of bytes but at b oth the client and
conc
server sides abstract interpretations are de ned on A and B to yield resp ectively ob jects of A and B
conc conc
For example supp ose a client fetches a compressed Word le from a Web server and wants to view it as an
HTML le in a Web browser Both the Word le and the HTML le are ultimately represented as sequences
of bytes The conversions required to uncompress and convert the Word do cument to HTML resp ect the
generic do cument type via abstraction that captures b oth their relations to the generic do cument types
and the relation of their byte sequence representations to the abstract types Word and HTML
Finally consider the problem of parsing integers retrieved from a text do cument and storing them in
a packed byte array We can mo del this problem as a conversion from a string based representation of
integers to a byte based representation We have an abstract type int a concrete type ibytes and another
concrete type istr The abstraction function istr int is atoi i e the standard C library function The
abstraction function ibytes int is de ned as follows for a given ibytes value b
n 1
b b b n
1
where n is the number of bytes in b Then is a conversion from istr to ibytes that resp ects int This
example illustrates a common way to nd a conversion function In general if types A and B are b elow
type T by a comp osition of subtype and representation relations and is the abstraction function from A
1
to T and is the abstraction function from B to T and is invertible then is a conversion from A
to B that resp ects T
Two Other Applications of the Resp ects Relation
The notion of a converter resp ecting a type shows up in other contexts b esides explicit type conversion
provided by the TOM Conversion Server We cast one critical asp ect of type evolution in terms of our resp ects
relationship and we show how resp ectful type converters enable reuse in the context of interoperability
Type Evolution
In Clamen s survey on type evolution he states that ob ject oriented databases tend to rely on two adaptation
strategies for handling the evolution of database schemas which can b e mo deled as types The rst
strategy converts instances from old types to new ones The second strategy uses emulation to allow instances
of old types to b e used through interfaces of b oth the new types and the old type Resp ectful type converters
play a role in b oth strategies For conversions they ensure that appropriate information is preserved They
aid in emulation by converting b etween types when an ob ject of an old type is used through a new type s
interface in a way that ensures that the new type s metho ds when called on the converted ob ject are
consistent with the old type s metho ds called on the original ob ject We will see an example of this strategy
in the next section with our zip le tar le converter
The type evolution problem arises most commonly in the context of databases A change to a database
schema e g the addition of a new eld in a record necessitates changing all records consistent with the old
schema to b e consistent with the new one For example supp ose we maintain an address b o ok of colleagues
each entry type has a name address o ce phone number home phone number fax number and e mail
address We wish to up date our address b o ok so that each entry can contain a url also This is a simple
but common example of type evolution
As we have seen a simple change like adding new state information to a type is just a simple application
of subtyping Here the new address b o ok entry type is a subtype of the old one As b efore the abstraction
function loses the extra information de ned by the subtype
Where do converters play a role It answers in part the question of what the relationship b etween the
orginal and evolved type is In our example the converter C entry entry and url respects the entry
type Here A and T of our general de nition are the same type entry Intuitively we want this converter
to resp ect the original type b ecause we want old co de that used to work with old address b o ok entries to
continue to work with the new ones even though new ones contain more state information
Consider this less trivial example of type evolution where a type converter may or may not resp ect a
given type dep ending on the type converter s de nition Supp ose we have a type HMS that keeps track
of time in terms of hours minutes and seconds HMS has a subtype HMSZ that also includes the time
zone The abstraction function is again the obvious one that loses the time zone information Consider two
di erent type converters The rst C HMS HMSZ adds Eastern Standard Time to all HMS values
This converter resp ects HMS The second C HMS HMSZ converts all HMS values to times according
to Greenwich Mean Time and then adds Greenwich Mean Time to pro duce an HMSZ value C do es not
resp ect HMS since for any non GMT time value the hours of the HMS and HMSZ values would b e di erent
Thus the resp ects relation helps characterize what information should b e preserved when types evolve
We should not b e able to evolve types without any thought as to what the relationship b etween the original
and evolved type should b e In other words we have an instance of the same question as for type converters
and our answer is similar type evolution should preserve some information b etween the old and new types
Our respects relation gives type evolution a correctness condition to satisfy b ecause it is de ned in terms of
a type not just the evolution conversion function
Reuse for Interoperability
At the heart of the interoperability problem is resolving mismatches among heterogeneous comp onents
2
For n comp onents e g n di erent types at worst we need n converters to do pair wise communication
b etween the comp onents to achieve p oint to point connectivity We can reduce the number by requiring
the use of a common language or standard thereby requiring only n translation functions n enco de and n
deco de functions for full connectivity Regardless interoperability requires some number of type converters
If we know that the types are structured in way that preserves some information then we can reduce the
number of converters we need to implement by exploiting common ancestors for a group of types
Supp ose type T a virtual type de nes ve metho ds and has two subtypes A and B Supp ose also
there is a converter from A to B that resp ects T Then instead of implementing those ve metho ds twice
we need only implement each once and rely on the single converter to e ect their b ehavior on A ob jects
Thus we implement six functions ve metho ds plus one converter rather than ten We not only save some
implementation e ort but we reuse the e ort exp ended already for one type
In general for n heterogeneous comp onents each of which is to have the same m metho ds de ned if all
n comp onents are subtypes of some type T then we need only implement m n functions rather than
m n functions The more subtypes of T and the more metho ds shared by those subtypes the greater the
p otential reuse
In practice there may exist o the shelf converters e g commercial pro ducts b etween heterogeneous
comp onents moreover these comp onents are unlikely to b e arranged in a type hierarchy To apply our ideas
in practice we typically identify some common sup ertype even if it means de ning a virtual sup ertype
T such that the use of these existing converters guarantee that T s b ehavior is preserved Thus we can
provide stronger formalizable guarantees to users of these o the shelf converters
Our TOM type hierarchy illustrates a real case of this scenario There already exist zip le tar le and
tar le zip le type converters The package sup ertype of zip le and tar le and the three others shown in
Figure is actually a virtual type that exp orts over one half dozen metho ds all common to its subtypes
These metho ds include getting the ith item from the package returning the count of items in the package
unwrapping the ith item getting the name of the ith item in the package and returning a list of names
of items in the order they app ear in the package Rather than implement all the metho ds for b oth zip le
and tar le we implemented them for only tar le Note that we rely on the respects relation for it to b e
meaningful to do the conversion on zip les treating them as tar les
TOM Status
TOM Use
The Web site for the TOM Conversion Service at Carnegie Mellon is http tom cs cmu edu It supp orts
roughly abstract data types a few hundred concrete data types and over type converters including
over meaningful comp ositions of ab out primitive converters By July the number of accesses to
the TOM conversion service stabilized to b etween and p er month which is an average of b etween
and p er day Accesses came from over sites in over countries in six continents from all types of
organizations including educational government and commercial institutions One class of the most p opular
converters are those to unwrap mail messages with embedded les Another class consists of those which
take a do cument of one type and pro duce a le of a di erent type typically for viewing or printing The most
a
common source types for converting are mail messages Microsoft Word PowerPoint p ostscript L T X and
E
p df les the most common target types are Web sections HTML text p ostscript and GIF images
The TOM Conversion Service includes a Web based user interface that hides much of the complexity of
type conversion from the user in three imp ortant ways
TOM is a connected network of type brokers If a user makes a request to one instance of a TOM
broker S and S do es not know ab out the data type or converter in question but do es know of another
instance T that do es then completely transparently to the user S will contact T to pro cess the
request Thus there can b e multiple instances of a TOM server where each knows ab out a few types
and converters collectively all the TOM servers comprise a distributed ob ject server
TOM can comp ose converters to do conversions If the user gives TOM a source type and a target
type TOM can gure a plan of conversion steps to apply It can make such plans on the y such as
when it comp oses an rtf html converter with an html text converter TOM can formulate conversion
plans that resp ect types since if conversion C resp ects type T and conversion C resp ects type T
1 1 2 2
then C C resp ects any common sup ertype of b oth T and T
1 2 1 2
Given an ob ject e g a Word do cument to convert TOM uses heuristics to guess what the type of
the source ob ject is It can also tell a user when a requested conversion is unsupp orted or meaningless
Revisiting TOM State
Recall the mo del of state introduced in Section A state consists of an environment which maps variables
to ob jects and a store which maps ob jects to values
State Env Store
Env Var Obj
Store Obj Val
TOM supp orts hand les to ob jects le names and URLs are two subtypes of the handle type Handles
are also TOM immutable ob jects and provide a dereference metho d For example the content of a le is a
TOM ob ject not the le itself a le name is a TOM ob ject which when dereferenced refers to the content
of a le These handles make up exactly the set Var the domain of the environment
By de nition values of immutable ob jects cannot change and since TOM s ob jects are all immutable the
store of any TOM state never changes except by the addition of new ob jects What ab out the environment
which keeps track of how to access ob jects It turns out that the environment may change In particular
for a given state he si while its store comp onent s cannot change its environment comp onent e
may change
More precisely the binding b etween handles to TOM ob jects may change and these changes are e ected
by users of TOM More imp ortantly TOM has no control over these changes In the context of programming
languages when a program is run the program s environment is the machine it runs on the implementation
of the programming language s runtime system has complete control over the program s state including
its environment Thus a new variable declared can b e given an initial binding to an ob ject this binding
can b e added to the program s environment When the program terminates all these bindings presumably
disapp ear The program and its environment are self contained
TOM op erates in an op en distributed environment where users can change the bindings b etween handles
and ob jects TOM has no control over this mapping The consequence is that from the user s viewp oint
it lo oks as if these ob jects are mutable In other words the dereference metho d on a handle might yield
di erent results at di erent times such as when someone has edited the le b eing referenced Futhermore
two di erent handles e g two di erent URLs may dereference to the same le contents TOM cannot
control or might not even know ab out this binding For example it is common for many di erent URLs to
refer to the same le on a given Web site and it is common for system administrators to exp ort a URL for
remote access but use an internal le name for lo cal access Thus from a more global p ersp ective TOM
ob jects app ear to users as shared mutable ob jects
Unfortunately as users of lo cal and distributed le systems the Web or publicly accessible p ersistent
ob ject rep ositories we have no control over the semantic guarantees that these di erent contexts provide
UNIX like le systems for example provide no consistency guarantees a change by one user to a le may
not b e seen by another who has a replica or cached copy of that le These weak consistency guarantees
mean that while the subtyping relation may hold from TOM s internal viewp oint it can b e intentionally or
inadvertently violated by someone who accesses a TOM ob ject from outside of TOM by implicitly changing
the binding b etween some handle and TOM ob ject
This situation is neither new nor surprising For any p ersistent ob ject rep ository that do es not sit in
isolation i e makes its ob jects available through means other than that rep ository s interface the same
situation will arise Thus this situation simply serves as a warning to the user of that p ersistent ob ject
rep ository and as a reminder to its designer the p otential mutability of a system s environment must b e
taken into consideration when accessing the rep ository s ob jects What may b e immutable in one context
may appear to b e mutable from a broader p ersp ective
Summary and Future Work
In this pap er we de ned a novel notion of respectful type converters to capture what information a conversion
function preserves when transforming ob jects of one type to another We greatly leverage o the Liskov and
Wing notion of b ehavioral subtyping to characterize this information succinctly Their framework gives
us the key technical to ol we need in particular the abstraction functions to de ne formally how two
i
di erent ob jects can b e viewed as the same We also extended our de nition to incorp orate concrete types
by leveraging o Hoare s abstraction functions for proving the correctness of the implementations of abstract
types
An alternative more general approach to de ning respects would neither require that types A B and
T b e related in a type hierarchy at all nor require that types A and B b e related to A and B in
conc conc
any implementation hierarchy We however would still need to assume the existence of some functions that
map values of one type to another these functions would serve the purp ose of our abstraction functions but
p erhaps b e otherwise unconstrained
We also describ ed the utility of resp ectful type converters in the context of working system the Carnegie
Mellon TOM Conversion Service We brie y suggested the relevance of the resp ects relation for type evolution
and interoperability From our application examples we can characterize the three most common kinds of
converters as
Those mapping from one abstract type to another abstract type Here the converter resp ects a third
abstract type usually a virtual type introduced in the type hierarchy Examples include conversions
b etween di erent do cument types of Section
Those mapping from a sup ertype to a subtype or vice versa the converter resp ects the sup ertype e g
the time zone example of Section
Those mapping from a concrete type to a concrete type the converter resp ects the abstract type that
b oth concrete types implement e g the p oint matrix and integer examples of Section
By sticking to the design decision that no TOM ob ject can b e mutable we avoid the problem of shared
access to mutable ob jects Thus TOM do es not have to worry ab out what subtyping means in the presence
of mutability As a corollary showing the subtype relation holds of TOM s type hierarchy is simple and
usually straightforward
The real p ower of the Liskov and Wing de nition of subtype however is in handling mutable types
Though we do not exploit this p ower in this pap er for simplicity and b ecause our application did not
demand it our de nition of respects can b e extended to accommo date mutable types Type sp eci cations
would include a predicate called type constraints by Liskov and Wing which captures what b ehavior may
not change from state to state hence it captures additional invariant prop erties of mutable ob jects The
de nition of respects would additionally need to consider the preservation of type constraints and the b ehavior
of mutator metho ds
References
Frank Bamberger Peter Ford and Jeannette M Wing Interoperability chapter C pages
Interuniversity Communications Council Inc EDUCOM
Luca Cardelli A semantics of multiple inheritance Information and Computation
Stewart Clamen Type evolution and instance adaptation Technical Rep ort CMU CS R Carnegie
Mellon Computer Science Department Pittsburgh PA June
S J Garland and J V Guttag An overview of LP the Larch Prover In Proceedings of the Third
International Conference on Rewriting Techniques and Applications pages Chap el Hill NC
April Lecture Notes in Computer Science
Daniel C Halb ert and Patrick D O Brien Using types and inheritance in ob ject oriented programming
IEEE Software September
C A R Hoare Pro of of correctness of data representations Acta Informatica
J J Horning J V with S J Garland Guttag K D Jones A Mo det and J M Wing Larch Languages
and Tools for Formal Speci cation Springer Verlag New York
Barbara Liskov Data abstraction and hierarchy In OOPSLA Addendum to the Proceedings
Barbara Liskov and Jeannette M Wing A b ehavioral notion of subtyping ACM TOPLAS
November
John Ockerbloom Mediating among diverse data formats Technical Rep ort CMU CS Carnegie
Mellon Computer Science Department Pittsburgh PA January
Amy M Zaremski Signature and sp eci cation matching Technical Rep ort CS CMU CMU
Computer Science Department January Ph D thesis
App endix A Larch Traits and Type Sp eci cations
This app endix contains the following Larch sp eci cations bitmap interface type sp eci cation BitMap trait
Color trait for color literals ColorSet trait for sets of colors Frame trait FrameSeq trait GIFImage trait
Gammas trait PNGImage trait and PixelMap trait App endix A of the Larch Bo ok contains traits for
Bo olean Integer FloatingPoing Set Deque and Array all of which we use b elow
bitmap type
uses BitMap bitmap for BM
for all b bitmap
invariant true
b o ol is set i j int
ensures result b i j set
b o ol equal a bitmap
ensures result a b
end bitmap
BitMap trait
includes Array Bit Integer Integer BM Bits
end BitMap
Bits trait
includes Bo olean Bit for Bo ol set for true clear for false
end Bits
ColorLiterals trait
A trait for N colors where BLACK and WHITE and N
Color enumeration of BLACK WHITE N
end ColorLiterals
ColorSet Color CS trait
includes ColorLiterals Set Color CS
end ColorSet
Frame F trait
includes Array Color Integer Integer F ColorSet Color CS
introduces
xmin xmax y min y max F Integer
col or r ang e F CS
asserts for all i j Integer f F
xmin f xmax f
y min f y max f
xmin f i xmax f y min f j y max f f i j col or r ang e f
end Frame
FrameSeq F FS trait
includes Deque Frame FS
introduces
overlay FS Integer Integer Color
colorrange FS CS
FS Integer F
asserts for all i j Integer f F fs FS
overlay fs i j if len fs then BLACK else
if xmin l ast fs i xmax l ast fs y min l ast fs j y max l ast fs
then l ast fs i j
else ov er l ay init fs i j
col or r ang e empty fg
col or r ang e fs f col or r ang e col or ang e f
fs i if i len fs then last fs else fs i
exempting
i I nteg er empty i
i fs i
i l en fs fs i
end FrameSeq
GIFImage trait
includes FrameSeq G for FS ColorSet Color CS
asserts for all g G
BLACK col or r ang e g
end GIFImage
Gammas trait
includes FloatingPoint Gamma for F
introduces
STDG Gamma
g c Color Gamma Gamma Color
asserts for all c Color g h i Gamma
g c c g g c re exivity
g c g c c g h h i g c c g i transitivity
end Gammas
PNGImage trait
includes Frame P for F Gammas
introduces
gamma P Gamma
end PNGImage
PixelMap trait
includes Array Color Integer Integer PM ColorSet Color CS
introduces
colorrange PM CS
asserts for all i j Integer pm PM
BLACK col or r ang e pm
pm i j col or r ang e pm
end PixelMap