Accepted for CHI '86: Conference on Human
`Factors in Computing Systems (April 1986)
`
`An Input-Output Model for Interactive Systems
`
`Mary Shaw
`
`Computer Science Department
`and
`Software Engineering Institute
`Carnegie-Mellon University
`Pittsburgh, Pa 15213 USA
`
`Abstract: Interactive user interfaces depend critically
`on underlying computing system facilities for input and
`output. However, most computing systems still have
`input-output facilities designed for batch processing.
`These facilities are not adequate for interfaces that rely
`on graphical output, interactive input, or software con-
`structed with modem methodologies. This paper details
`the deficiencies of batch-style input-output for modem in-
`teractive systems, presents a new model for input-output
`that overcomes
`these deficiencies, and suggests
`software organizations to take advantage of the new
`model.
`
`1. Introduction
`Input and output are perhaps the most systematically
`neglected features of programming languages. They are
`usually ad hoc, and they are usually poorly integrated
`with the other facilities of their hosts -- the languages in
`which they are embedded.
`Input and output are
`generally supported only for the primitive scalar types of
`the host languages, although they are occasionally sup-
`ported (though usually in an inflexible way) for nonscalars
`such as records and arrays.
`The situation was bad enough before the introduction
`of abstract data types and interactive graphic displays,
`but these additional complications have overburdened
`the classical ad hoc input and output mechanisms
`beyond their design limitations. It Is now time to develop
`a sound model for input and output that will address the
`problems introduced by modem programming technol-
`ogy. Such a model will help to put classical input and
`output on a solid footing; It will also provide a basis for
`abstract data types and interactive systems.
`Interactive input and output are fundamentally dif-
`ferent from conventional implementations of input and
`output in two ways:
`
`• The output device serves as a continuous sensor
`or observer of the application software and
`provides current information about the state of the
`computation, whereas conventional input and out-
`put provides information to the human user only
`when the application software chooses to report.
`• Input is an interactive process requiring feedback
`(sometimes from the application software that will
`receive the input), whereas input is conventionally
`treated as a simple parsing task. Moreover, inter-
`active Input is often under control of the human
`user rather than the program, yielding an event-
`driven system rather than a program-driven one.
`The model developed here explains both conventional
`input-output and the newer, event-driven view of inter-
`action.
`This paper begins by suggesting an informal model of
`input and output that explains classical -- that is, batch-
`It then describes the
`input and output.
`oriented —
`problems introduced by modern programming technology
`and extends the model to deal with them. The paper
`closes with some remarks on experience with software
`organizations to support the model.
`
`2. Classical Input and Output
`Input and output facilities in programming languages
`are responsible for receiving input data from the external
`In
`world and for returning output to the external world.
`order to do this, these mechanisms must be able to con-
`vert input data to the internal representations used by the
`program and then convert the internal representations
`back to output form. Thus, the crucial issue for input and
`output is change of representation for given data values.
`We are concerned here with input and output between
`programs and humans rather than with communication
`among programs or between programs and mass
`storage. We are interested primarily in imperative
`(Pascal-like) languages, but most of what we say applies
`to other classes of languages as well. The► model relies
`heavily on the use of abstract data types — either with or
`It has also been in-
`without direct language support.
`fluenced by the object-oriented style of program or-
`ganization.
`
`The programming languages of the 1960's and 1970's
`provided specialized
`facilities
`for
`input and output
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`..... ..
`
`....... ..
`..... •-•
`
`Input-output
`conversions
`
`Ou
`
`-v
`
`,sequence
`/ /
`of
`\."--.. i character
`Input
`..f"
`
`\integer\
`
`float
`vector[...]
`\record[...]
`\enum E
`,\MyTypel
`\MyType2
`
`The
`Program
`
`..Z
`External
`World
`Figure 1: Simple input-output requires conversion between data types of the
`program and specialized types suitable for direct transmission to physical
`input and output devices.
`do not provide formal pre- and post-conditions. Figure 1
`processing individual lines of text or streams of charac-
`depicts the problem of simple input-output.
`ters.
`The roots of these mechanisms lie in batch
`processing, and interactive computing using conventional
`In addition to the direct conversion operation, input
`video terminals (CRTs) still largely continues this tradi-
`and output operations usually have side effects on the in-
`tion.
`put or output stream, such as extending an output file or
`truncating an input file. With allowances for the variability
`This section develops a model that treats input and
`of these side effects, the model presented here applies
`output as a problem of converting between the data types
`both to stream and to line-by-line input and output.
`of the program and some specialized types suitable for
`direct transmission to the available input and output
`Default use of the input-output facilities of many lan-
`devices. This suffices to explain classical character-and
`guages provides roughly this simple level of functionality.
`line-oriented input and output. Section 3 extends the
`In Basic, for example, the commands
`model to abstract data types and interactive systems.
`INPUT x
`2.1. Minimal Input and Output
`PRINT x
`At the very least, input requires conversion of data be-
`encode the operations
`tween some specialized string type particularly well-
`x = In(InputStreamp
`suited for the input-output device (a device-relative type)
`Append(OutputStream, Out(x))
`and the built-in types of the program such as integers,
`If the input stream contains "12.35", the effect of these
`floating point numbers, booleans, strings, etc. Likewise,
`commands is to set the value of variable x to 12.35 and
`the
`requires conversion between between
`output
`produce the output "12.35".
`program's built-in types and a device-relative string type
`well-suited to the output device (often the same as the
`2.2. Formatted Input and Output
`string type used for input). We will let Pi denote any of
`The simple input-output scheme of section 2.1 is too
`the primitive data types of the programming language for
`restrictive for practical use, and virtually all languages
`Which input and output are supported.
`support some means of influencing the details of format-
`The simplest possible view of input and output is thus
`ting. The formatting information is encoded in a special
`that some simple string type, say seq-of-char, is built into
`format notation. We will let F,,, and Fout denote input and
`the input-output system. This special type is not in
`output formats, respectively. The encoded formats are
`general available for direct use by programmers. For
`passed to the conversion routines along with the vari-
`most primitive types P1 the minimal input-output system
`ables. Thus the system provides operatiops with the
`provides built-in operations with signatures
`functionality
`—> seq-of-char
`Out. P1
`—>
`In: seq-of-char
`The functional specifications of these operations simply
`require correct conversion between the two represen-
`tations. This specification is essentially syntactic, so we
`
`Out P1 x Fout
`—> seq-of-char
`In: seq-of-charx F17
`--> pJ
`Figure 2 depicts the problem of simple formatted input-
`output.
`
`2
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`\integer
`
`\si
`\float
`
`...
`
`''''''''''
`
`vector[...] \!
`
`................
`
`Input-output
`conversions
`with format
`support
`
`\record[...]
`
`\ enum E
`
`\MyTypel
`
`\MyType2 \
`
`The
`Program
`Figure 2:
`
`Ou • ut
`
`F.
`
`Input
`
`sequence
`of
`j
`character j
`
`External
`World
`Simple formatted Input-output consults format information
`for each value as it is converted.
`The specifications of the In and Out operations must
`be refined to account for the format parameters, but the
`operations are still fundamentally syntactic: they require
`the conversion between the two representations to ad-
`here to the format restrictions and to be correct within the
`Thus detailed
`accuracy specified by the
`format.
`specifications of the operations In and Out depend on the
`semantics of the particular format language being used.
`For purposes of this paper, the choice of format language
`is not significant, provided it can express at least the
`usual range of variability.
`The operations presented here provide a model that
`explains the most significant characteristics of formatted
`input-output systems. Since the syntactic idiosyncrasies
`tend to obscure the essential character of input-output as
`a process of changing representations, they are ignored
`here.
`2.3. Realistic input and Output
`Even with the addition of formatting, this formulation of
`input-output is still too restrictive, especially for output.
`The actual output of a system is often influenced by infor-
`mation about the state or history of the input and output
`transactions. For example, if a table of numbers is being
`printed, the position of individual numbers on a line and
`the number of spaces produced between individual
`numeric values must be adjusted for column alignment.
`For a second example, the system may provide page
`numbers and column headers whenever a page fills up or
`may align columns on a page. Thus input and output for
`many systems require state information that persists
`beyond individual invocations of the conversion functions.
`is persistent, operation& must be
`Since
`this state
`provided to initialize and manipulate it. These operations
`are commonly implicit in the format language.
`In order to explain actual input and output systems,
`we introduce an explicit state, 10State, to capture the
`state of the input-output facility that persists beyond in-
`
`A variety of formalisms for formatting have been used.
`The details are not important here, but the essential re-
`quirement for a format notation is that it provide enough
`information to select from among the conversion alter-
`natives provided by the system. These examples from
`Fortran, C, and Pascal suggest the possibilities:
`Fortran
`Pascal
`scanf("%f",x);
`99 FORMAT(F5.2)
`read(x);
`READ (5,99) X
`print(x:5:2); printf("%5.2f",x);
`WRITE (6,99) X
`If the input stream contains "12.35", all these programs
`read that input and yield the output "12.35". However,
`these commands have different effects when the input
`contains either more or fewer than five characters.
`The format languages for input and output, though
`deceptively similar, are actually not identical. For simple
`cases like field width or desired precision, the same ex-
`pression often has reasonable interpretations for both in-
`put and output. However, the output processor can make
`strong assumptions about the internal representation and
`the possible output forms, whereas the input processor
`must be prepared to handle any of a number of input
`strings, including erroneous formations. As a result, the
`rules for allowable input strings in any particular system
`may be rigid or fairly flexible.
`Format notations span a wide range of expressive-
`In addition to specifying the rules for
`ness and power.
`converting individual scalars, they may specify the way
`individual scalar values are arranged in the input or laid
`out on the output medium. Special syntax is often used
`to combine several individual input or output operations
`into a single invocation. As a result, most input-output
`the operations
`systems do not provide precisely
`described here. These operations do, however, explain
`the underlying functionality after the syntactic sugar is
`converted to calls on the basic operations. With the ex-
`tensions of section 2.3, they explain most existing for-
`matted input-output systems.
`
`3
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`\\\\\\
`\integer
`
`
`
` t1 t\Loat \
`
`
`. .....
`....
`.. .•
`
`- .
`•
` .....
`......
`...
`
`)41
`
`\vector[...]
`
`\record[...]
`
`\enum E
`
`\MyTypel
`
`\MyType2
`
`Input-output
`conversions
`with format
`support
`
`Out•ut
`
`/sequence
`/
`of
`/
`•
`line
`
`i
`/
`
`Input
`
`/ sequence
`of
`character
`
`The
`Program
`Figure 3:
`
`External
`World
`Realistic formatted input-output requires history or state
`information in addition to formats for individual values.
`of input and output, these Fortran statements form a
`dividual primitive operations. This state influences the in-
`composite operation that could be decomposed into Out
`terpretation of both input and output operations, it can be
`format operations for the individual vector elements and
`manipulated either explicitly (by SetUp operations) or im-
`blank spaces together with SetUp operations to handle
`plicitly (as a side effect of In and Out operations. We
`the overall layout.
`also select a richer type than seq-of-char for the device-
`relative object type of the Out operation in order to sup-
`port full-page
`layouts.
`For the case of classical
`character-oriented output the output can be segmented
`into lines (with vertical alignment controlled by lOState),
`so we will use seq-of-line to represent the richer device-
`relative output type. Real systems therefore provide in-
`put and output mechanisms to support operations with
`signatures more like
`Out Pi x Fout x 10State
`—> seq-of-line x lOState
`In: seq-of-char x Fin x lOState
`—> P, x lOState
`SetUp:
`—> lOState
`lOState x
`The SetUp operation is only partially specified here; this
`definition is suggestive of a class of operations that take
`parameters appropriate to the state change being per-
`formed. The scope controlled by the input-output state
`need not be restricted to single phrases or lines. In RPG,
`for example, a page restore and new column headings
`can be generated automatically each time an output page
`is filled. Figure 3 depicts the problem of realistic for-
`matted input-output.
`The role of the state is demonstrated by the Fortran
`format and statement
`100 FORMAT ('1 New page header,(/10(F10.2, 2X)))
`200 WRITE (6,100) V
`These statements print all the elements of vector V,
`beginning on a new page with page heading, printing ten
`elements per line, until the vector is exhausted. The
`bookkeeping required to keep track of information such
`as the current position in the vector, the current column,
`and the current line depends on maintaining a correct
`representation of the current state of the output trans-
`action while it is in progress. With respect to our model
`
`3. Abstract Data Types and Interactive
`Interfaces
`The interface between people and computers is a criti-
`cal factor in effective computer use. This interface has
`become increasingly important with the advent of inter-
`active systems with high-performance graphic displays. I
`will now turn to the problems of input and output for such
`systems.
`As noted above, early interactive systems used input
`and output mechanisms designed for batch processing,
`simply treating the teletype as both an input and an out-
`put device. When video terminals replaced teletypes, we
`retained the same strategy (but we lost the ability to look
`back on the paper listing for results that had been
`produed a few dozen lines previously). The record of an
`interactive session that takes place in this mode, with
`line-by-line input and output scrolled on a display, is
`called a typescript. Typescripts are often discarded as
`they are displayed, but some systems provide a
`mechanism for logging them in a file.
`In a typescript-oriented system, the output is a
`program history — a stream of snapshots of subsets of
`the program state. The subsets of the program state and
`the timing of the snapshots are controlled by the program
`that is executing. A system that provides only this form
`of output neglects the needs of the human user, who is
`often better served by a single, continuously updated,
`view of the program state. It ignores the advantages of
`providing the human user with control over the pbrticular
`In addition, it fails to exploit the
`view to be displayed.
`human's ability to use (and the terminars ability to
`provide) cues based on keeping current values of par-
`ticular information in fixed positions.
`
`4
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`In contrast, a two-dimensional interface presents a
`variety of information simultaneously and updates it
`dynamically; a given piece of information can be kept up-
`to-date in a fixed position. Work on text editors [Card
`82, Meyrowitz 82] and interaction 'techniques [Embley
`81, Hirsch 81] support the intution that two-dimensional
`displays are better than one-dimensional typescripts.
`Thus, the availability of inexpensive high-performance
`displays provides an opportunity for qualitiative improve-
`ments to interactive interfaces. Sophisticated display in-
`terfaces are currently difficult and expensive to develop,
`and a number of research projects are addressing
`various aspects of the problem [Baecker 79, de Jong
`80, Green
`81, Guttag
`80, Hayes
`82, Kernighan
`81, Mallgren
`82, Myers
`80, Reisner
`81, Rowe
`83, Teitelman 84, VanWyk 82, Wallis 80]. The present
`work contributes a model for input and output that is com-
`plementary to those methodological explorations.
`Because the role of the human user is much more sig-
`nificant in interactive systems than in batch systems, the
`significance of the timing of input and output events is
`more critical in interactive systems. Sensitivity to event
`timing occurs in several ways.
`• The feedback provided by the system must be
`properly synchronized with input from the user.
`For example, if a system prompt is provided, it
`must actually be sent to the output device before
`user input is supplied. Further, feedback is usually
`provided to the user as each input phrase is
`developed.
`• Any system that allows the user to provide input
`values by pointing to values currently displayed on
`the screen must be extremely careful to update the
`display whenever the stored values change.
`Otherwise the user may provide incorrect Input by
`pointing to a displayed image that does not match
`the stored value that will be inserted in the input
`stream.
`• Interactive systems must cope with input provided
`asynchronously by the user: processing of the
`command that means "terminate this process
`immediately" should not wait until the current
`process terminates on its own.
`These timing issues force the implementor of the input-
`output system to rethink such issues as the use of buf-
`fers, the significance of system delays, and the use of in-
`terrupts.
`In addition, advances in software and hardware tech-
`nology have introduced new problems. These include
`system provisions for
`• Abstract data types (user-defined types): Ap-
`propriate input and output conversions for user-
`defined types should be selected as part of the
`design of the abstract type. This requires type-
`specific knowledge, but conventional input-output
`systems (and the model presented in Section 2) do
`not provide a way to supply that information to the
`input-output system. Similar considerations often
`apply to primitive nonscalar types such as arrays
`and records.
`• Two-dimensional output. High-performance dis-
`plays provide a graphic capability that can enhance
`
`the quality of interfaces. This requires the ability to
`construct two-dimensional images that represent
`data values, but conventional input-output systems
`do not support graphics.
`• Interactive input Interactive sytems must provide
`feedback to the user while he or she supplies input
`actions. In addition, input operations may refer to
`information that is currently displayed on the ter-
`minal. This requires active involvement of the
`input-output system in feedback and the interpreta-
`tion of pointing actions, but this notion is entirely
`foreign to conventional input-output systems.
`We will consider each of these problems in turn, then ex-
`tend the informal model of section 2 to show how to deal
`with them. The purpose of this section is to present the
`problems introduced by modern programming systems.
`The next section proposes a model for input and output
`in such systems.
`3.1. User-Defined and Nonscalar Types
`During the 1970's, work on abstract data types
`showed how to extend the set of primitive types provided
`by a language to include types defined by the user
`[Liskov 77, Shaw 81]. One of the objectives of this work
`was for the programming language and support system
`to provide the same system support for types defined by
`the user as it provided for primitive types. Although the
`work was generally successful, it did not succeed in
`providing genuine type extensibility for input and output.
`Full support for input-output in the presence of type
`extensibility (or even system-supported nonscalar types
`such as records) requires solutions to two problems
`• Providing the type-definer with control over conver-
`sion between internal representations and the
`device-relative types used for input and output.
`• Providing the type-definer with access to system
`input and output facilities, including the lOState,
`the facilities for constructing output renderings by
`composing renderings of components, and the
`facilities for parsing input streams.
`Thus, in order to make the input-output facilities ex-
`tensible to new types, it is necessary to provide a way for
`user-defined conversions to be added to the set of con-
`versions known to the input-output system. Some sys-
`tems provide default conversions from internal represen-
`tations to strings, but since these have no knowledge of
`the type abstractions involved, they can do no better than
`dumping the internal structure of the type. However, this
`is not sufficient.
`for example, a set
`Consider,
`represented as a vector (used for the set elements) and
`an integer (used for the current number of set elements).
`A common representation stores current set elements in
`the lowest-indexed array elements. A default output con-
`version could do no better than converting the integer
`and all the array elements to strings and inserting a few
`type-specific conversion,
`standard delimiters.
`A
`however, would convert only
`the active elements,
`separate them with commas, and add set braces at the
`front and back. The integer would not be converted for
`output; it would be used only to determine how many ar-
`ray elements to convert.
`
`5
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`integer
`
`float
`
`vector[...]
`
`C-
`• 'cz•
`"1
`
`record[...],
`
`• <...4
`
`Ou
`
`Input
`
`External
`The
`World
`Program
`Figure 4:
`Input-output for user-defined and nonscalar types requires the
`formatting capabilities to be provided for all types, not just for primitive
`scalar types.
`sideration is changed. Therefore, in addition to allowing
`the programmer to define the operations themselves, the
`system must provide a mechanism for registering these
`definitions with the input-output control mechanism so
`that they can be invoked as necessary. Figure 4 depicts
`the facilities required for input and output of user-defined
`and nonscalar types.
`
`enum E
`
`MyTypel-•
`
`MyType2.•
`
`<A • •
`(.1
`Input-output
`conversions with
`format support
`
`Since user-defined types are often composite struc-
`tures whose elements are of other types, reasonable im-
`plementations of input and output must also be able to
`call on the input and output conversions of the other
`types as subroutines.
`In order for this to work, the
`device-relative types used for input and output conver-
`sion must be available to programmers as actual data
`types. (For this reason, type-specific routines that do in-
`dividualized conversion but interact directly with the input
`or output devices also fail to solve the whole problem.)
`This facility is not typically provided by conventional pro-
`gramming languages. There are some exceptions: the
`functions sscanf and sprintf in C and so-called "core-to-
`core" input-output in certain other systems allow the
`programmer to obtain the results of built-in input-output
`operations. However, even these systems do not allow
`user-defined types to be added to the built-in input-output
`conversion tools.
`For user-defined types, we will let Ti denote any user-
`defined type. Only the designer of the user-defined type
`Ti has enough information to know how to convert be-
`tween Ti and the standard special type used for input or
`In addition, proper formatting for nonscalars
`output.
`varies a lot from application to application. Therefore we
`need a richer input-output facility, one that supports user-
`defined types Ti wherever it supports primitive types Pt
`The required functionality is achieved by adding Ti to the
`set of types required by the signatures of the In and Out
`operations:
`Out: (Pt Ti} x F out x lOState
`--> seq-of-line x lOState
`In: seq-of-char x F1 x lOState
`--> {Pp Ti x lOState
`--> lOState
`lOState x
`Setup:
`Although it is straightforward to extend the signatures of
`the specification, it is harder to implement the change.
`The type-specific conversion routines will be provided by
`the user program, and it is not practical to recompile the
`runtime system each time the set of types under con-
`
`3.2. Two-Dimensional Output
`The introduction of high-resolution, high-bandwidth
`displays has made a qualitative difference in the kinds of
`user interfaces that can be defined. The use of graphics
`literally adds a new dimension to the class of images that
`can depict data values, and the ability to maintain par-
`ticular data values at fixed locations on the display allows
`the user to take advantage of physical layout to avoid
`searching a typescript for information. Three new
`problems arise as a result of the new technology:
`• Conversion of internal representation to output
`form that includes graphics as well as text
`• Continuous maintenance of the image
`• Allocation of space on the display
`The power of two-dimensional interfaces is best il-
`lustrated with examples. Figure 5 shows the display
`during an interactive session using the Xerox Cedar pro-
`gramming environment [Teitelman 84].
`In this display,
`the bottom row of small images denote processes that
`are alive but not of current interest. Three processes are
`active, each within one window. The three windows are
`arranged so as to use all the display without allowing any
`window to obscure any of the others. At the top of each
`window and at the top of the screen, menus provide
`quick access to common commands.
`
`Figure 6 shows the Microsoft Chart application running
`on an Apple Macintosh. The program constructs plots
`from given data. One window is used for the data for
`each plot, and several plots can be combined in a single
`
`6
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`Coder IA Doeuwaystalion atOMIllf
`&BP 01•1611,- Milt WWII.* Ns !LAIC CAM .on 1•111•411. bkr
`
`110,1
`
`MI& OW ecorlar
`
`ION OM. 4.11
`• •••••••••
`• ,••••••• •••
`tr.. pm ••
`Spoon
`
`n...
`amp.*
`Cab“...4.
`tow worm C
`*Ow %CM nhon. N. mil ...I 0 IN Men lb am •04. mil dim mom Me Ow
`ea yr ima. we Ims a. =maw ••••••••• wow., *fa. Alm Md.
`••••
`1•••••• v... Om 10.0..110•1010mund. taw P.
`160
`'Lll•
`
`N.. •
`
`
`
`•••••••• mamma.
`
`••••/*. HAI
`-
`in• ant MIK smil C.. owe tr.
`•••••••I OW WIN. MN. My =Memo
`WM.. ay Or, im pm= imp
`•Ivar.infr
`FM IMMO •
`P..,
`
`••• woman • •• 000.1. •
`•
`
`Cs 11•••••• ••••••
`...mu
`tow.. pow
`, •
`trt=mi"Tra Ume D
`a
`
`INC/0.54. MTHAT.Ilir
`elm maroon ••••••••••••••1
`ge.
`011...1117,•=.
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`••••
`
`Oa, w.
`Simeon
`th.1001.11.
`4.111
`pp g.
`
`•
`
`••••141
`1.001.11ar MM.
`11•••••. WY/.
`1110.011W •••••••
`111••••••• b••
`▪
`
`Figure 5: Display layout in Cedar Documentation Browser
`of choices are possible, depending on characteristics of
`graph. This example differs from the previous one in
`the graphics device, but they must support images that
`several ways. First, the windows are allowed to overlap;
`include at least character strings, lines, and colored
`simple user actions select the window that is active, or in-
`(pattern-filled) areas. For the sake of discussion, we'll
`tuitively "on top," at any time. Second, all the windows
`call the type Image; it might be represented as a display
`In particular,
`shown here belong to the same process.
`list of strings, lines, and shapes.
`changes to either of the data windows are reflected in the
`window that contains the graph.
`User-defined types require the ability to create partial
`images and compose them to form the complete image
`Decisions such as the number of windows to as-
`to be displayed, just as they did for character-sequence
`sociate with a process and the policy for sharing display
`output. Less obviously, this facility can be used to good
`space among several windows are included in the design
`advantage by primitive types of the programming lan-
`decisions make when interfaces are created.
`guage. Since two-dimensional images are richer than
`Clearly, the sequence of characters is not an ade-
`character sequences, the internal state required to com-
`quate internal representation for images directed to a
`pose them will also be richer.
`graphics output device. Therefore, a new internal type
`for constructing the output image is required. A number
`
`r * File Edit Data Gallery Chart
`NASA Demand
`
`Format
`
`100.011B1ts
`
`I 0.011Bits
`
`New Ser
`
`Order:
`Proa Prod
`Order: JJ
`
`I
`1:81 Plot Series
`x
`
`1983
`1984
`
`0.5118879060
`0.5349228624
`
`IC :1111.11 Manned MM.
`
`Cod* Size
`
`
`
`0.1MBits
`1960
`
`1965
`
`1970
`
`1975
`Year
`Onboard Code Size for Mann
`and Annual Programmer P
`
`Order:
`Eg Plot Se
`
`1965
`1966
`1968
`1970.5
`1973
`1981
`
`IS
`1S
`1S
`197
`50 fillit
`t
`r' ti•
`1911X I 10 411A4,9K7/11
`
`l'••
`
`0.159744
`0.39
`0.622592
`1245184
`0262144
`16
`
`Figure 6: Display layout in Macintosh Chart application.
`
`7
`
`Ingenico v. IOENGINE
`IPR2019-00416 (US 8,539,047)
`Exhibit 2100
`
`

`

`\integer
`
`\float
`
`\\\
`vector[...]
`
`\record[...],
`
`\\enum E
`
`\\ MyTypel •
`
`MyType2
`
`Ar..,••
`•
`
`•
`• • •
`•
`
`•
`
`Output
`
`/image =
`{ string,
`line,
`shape }
`
`-------
`
`•••••
`Input
`
`sequence
`;
`of
`;
`token ;
`//4
`/token =
`{ char, pt}
`
`Input-output
`conversions with
`format support
`
`The
`Program
`
`External
`World
`Figure 7: Two-dimensional output requires a significantly larger
`intermediate state and a richer target type.
`Graphics displays provide the ability to improve on the
`cal locus of information about overall layout, which
`typescript mode of output as well as on the image
`may be encoded as format information Fcomp.
`generated for individual values. It is useful to regard the
`• Actual display of a complete Image is thes respon-
`entire display as a single image that is built up from
`sibility of the implementation of type Image.
`images of individual values. This decision allows the
`In object-oriented terms, each of these steps would be
`same mechanisms to be used for constructing images of
`a method of the appropriate type.
`individual values and for composing the entire display.
`The lOState contains the information to control for-
`When the problem is viewed this way, the generation
`matting and layout. A set of functions which we call
`of a partial image is similar to the generation of a single
`generically QueryStyle must be provided to extract per-
`scalar value to print in a typescript. The partial image
`tinent format information (e.g., Fin from the lOState).
`can be produced without binding all display decisions,
`We now need functionality like
`such as color and position on the display. Decisions
`Out {Pfr TI x Fout —> Protolmage
`about the proper location of each image can then be
`Compose: Protolmage x Fcomp x lOState
`represented in the internal state of the input-output sys-
`—> Image x lOState
`tem and used to bind any remaining decisions about the
`In: seq-of-charx Fin x lOState
`display when the partial images are composed into the
`—>
`x lOState
`c