the abstract state machine ( asm ) thesis , first proposed in @xcite and elaborated in @xcite , asserts that every algorithm is equivalent , on its natural level of abstraction , to an abstract state machine .
beginning in @xcite and continuing in @xcite , @xcite , @xcite , and @xcite , the thesis has been proved for various classes of algorithms . in each case , the class of algorithms under consideration was defined by postulates describing , in very general terms , the nature of the algorithms . in each case
the main theorem was that all algorithms of this class are equivalent , in a strong sense , to appropriate asms .
the work in @xcite directly leading to the present paper is briefly overviewed in the following section .    the present paper continues this tradition , but with an important difference .
previously , the standard syntax of asms , as presented in @xcite , was adequate , with only very minor modifications .
our present work , however , requires a significant extension of that syntax .
the extension allows an asm program to refer to the order in which the values of external functions are received from the environment , and it allows the program to declare a step complete even if not all external function values have been determined .
the main purpose of this paper is to extend the analysis of interactive , small - step algorithms , begun in @xcite , by removing the restriction to `` ordinary '' algorithms . here
we provide postulates and definitions describing a general notion of interactive , small - step algorithm . in a companion paper
@xcite we also extend the syntax and semantics of abstract state machines ( asms ) so that non - ordinary algorithms become expressible .
there we provide    syntax and semantics for asms incorporating interaction that need not be ordinary ,    verification that asms satisfy the postulates , and    proof that every algorithm satisfying the postulates is equivalent , in a strong sense , to an asm .
the algorithms considered in this paper proceed in discrete steps and do only a bounded amount of work in each step ( `` small - step '' ) but can interact with their environments during a step , by issuing queries and receiving replies .
such algorithms were analyzed in @xcite , subject to two additional restrictions , which we expressed by the word `` ordinary . '' first , they never complete a step until they have received replies to all the queries issued during that step .
second , the action of the algorithm  the queries issued and the next state produced  at any step
is completely determined by the algorithm , the current state , and the function that maps the current step s queries to the environment s answers . in other words , this answer function is the only information from the environment that the algorithm uses . in particular , the order in which the environment s answers are received has no bearing on the computation .    in the present paper ,
we lift these restrictions .
we allow an algorithm to complete a step even while some of its queries remain unanswered .
we also allow the algorithm s actions to depend on the order in which answers were received from the environment .
see the discussion in section  [ post ] and particularly remark  [ time - stamp ] for a discussion of why the order of arrival of answers is of special importance and why it can not be subsumed in answer functions .
it was shown in @xcite that ordinary algorithms are equivalent to asms of the traditional sort , essentially as described in @xcite . in order to similarly characterize the more general algorithms of the present paper
, we shall , in @xcite , extend the syntax and semantics of asms .
in particular , we provide a way to refer to the timing of the evaluations of external functions and a way to terminate a step while some queries remain unanswered .
see subsection  [ hist ] for a discussion of the intuitive picture of interactive algorithms that leads to these particular extensions and indicates why they suffice .    at the referees request , we comment briefly on the impact to be expected from this work .
numerous issues are involved here , which would be better addressed in a broad discussion of the asm thesis rather than in this introduction , but it seems appropriate to say a few words about future prospects .
probably the most immediate impact that we expect from the asm approach is on the foundations of software engineering .
clarification of commonly used notions  like state , level of abstraction , interaction  is long overdue .
closer to theoretical computer science , the asm computation model is the most general computation model that we know .
it supports for example computing with structures rather than strings ; see @xcite for particular examples leading to interesting theoretical results and questions .
finally it may be disappointing that , unlike the church - turing thesis , the asm thesis has not been used for negative results ; will it be ?
the attention of theorists is moving gradually toward the analysis of the overall behavior of algorithms and not only their input - output behavior .
the previous work most closely related to the present paper is the series of papers @xcite , in which the asm thesis is proved for other classes of algorithms  small - step algorithms in @xcite , parallel algorithms in @xcite ( both without external intra - step interaction , but with communication between subprocesses in the parallel case ) , and ordinary interactive small - step algorithms in @xcite .
also , andreas glausch and wolfgang reisig @xcite adapted the postulates of @xcite to describe a restricted but important class of `` small - step '' distributed algorithms . in this section ,
we briefly overview the work in @xcite directly leading to the present paper , and we also briefly discuss other work that is related to our goals and analysis , though it applies rather different methods .
many algorithms are naturally understood on a high level of abstraction ; for example states could be relational structures ( databases ) .
the step to a simulation operating over string representations of the abstract entities may lower the abstraction level of the algorithm ; see section [ sec : other ] for discussion .
such a step may be less trivial than meets the eye : for instance it is not known whether there is a polynomial - time algorithm that , given two adjacency matrices , determines whether they represent the same graph .
the abstract state machine ( asm ) model of @xcite intended to capture arbitrary algorithms at their natural levels of abstraction .
the asm thesis of @xcite asserts that every algorithm is equivalent , on its natural level of abstraction , to an abstract state machine .
subsequent experimentation provided confirmation of the thesis @xcite .
paper @xcite was the first of a series of papers offering _ speculative justification _ for the thesis , for particular classes of algorithms .
they all follow the same general pattern ;    1 .
describe axiomatically a class @xmath0 of algorithms .
2 .   define behavioral equivalence of @xmath0 algorithms .
3 .   define a class @xmath1 of abstract state machines .
prove the following characterization theorem for @xmath0 : @xmath2 , and every @xmath3 is behaviorally equivalent to some @xmath4 .
the characterization provides a theoretical programming language for @xmath0 and opens the way for more practical languages for @xmath0 .
the justification of the asm thesis thus obtained is speculative in two ways :    * the claim that @xmath0 captures the intuitive class of intended algorithms is open to criticism . *
definition of behavioral equivalence is open to criticism .
but the characterization of @xmath0 by @xmath1 is precise , and in this sense the procedure _ proves _ the asm thesis for the class of algorithms @xmath0 modulo the chosen behavioral equivalence .    so @xmath0 should be as broad as possible within the intended class of algorithms , and behavioral equivalence should be as fine as possible , even if coarser notions of equivalence might suffice for many purposes .
the finer the behavioral equivalence , the stronger the characterization theorem .
in this subsection we briefly overview the realization of this program for isolated small - step algorithms in @xcite and ordinary interactive small - step algorithms in @xcite .
the algorithms of @xcite are executed by a single sequential agent and are isolated in the following sense : there is no interaction with the environment during the execution of a step
. the environment can intervene in between algorithm s steps .
but we concentrate on step - for - step simulation , and so inter - step interaction with the environment can be ignored .
this class of algorithms is axiomatized by three simple postulates .
the * sequential time postulate * says that an algorithm defines a deterministic transition system , a ( not necessarily finite - state ) automaton .
more explicitly , the algorithm determines    * a nonempty collection of states , * a nonempty subcollection of initial states , and * a state - transition function .
the algorithm is presumed to be deterministic .
nondeterministic choices involve interaction with the environment ; see @xcite for discussion .
the term state is used in a comprehensive way .
for example , in case of a turing machine , a state would include not only the control state but also the head position and the tape contents .    the postulate does not mention a notion of final state , see @xcite for discussion .
sequential time already suffices to define _ behavioral equivalence _ of algorithms : two algorithms are behaviorally equivalent if they have the same    * states , * initial states , and * state - transition functions .
this is as fine as possible , though it may be too fine for many purposes .
but , as already noted above , the finer the equivalence , the stronger the characterization theorem .
the * abstract state postulate * says that    * all states are first - order structures of a fixed vocabulary , * the transition function does not change the base set of a state , and * isomorphism of structures preserves everything , which here means states , initial states and the transition function .
it reflects the vast experience of mathematics and mathematical logic according to which every static mathematical situation can be adequately represented as a first - order structure .
the idea behind the second requirement is that , even when the base set seems to increase with the creation of new objects , those objects can be regarded as having been already present in a `` reserve '' part of the state .
what looks like creation is then regarded as taking an element from out of the reserve and into the active part of the state .
( the nondeterministic choice of the element is made by the environment . )
see @xcite and the next section for discussion .
the idea behind the third requirement is that all relevant state information is reflected in the vocabulary : if your algorithm can distinguish red integers from green integers , then it is not just about integers .    the * bounded exploration postulate * expresses the idea that a sequential algorithm ( in the traditional meaning of the term ) `` computes in steps of bounded complexity '' @xcite .
more explicitly , it asserts that the values of a finite set @xmath5 of terms ( also called expressions ) , that depends only on the algorithm and not on the input or state , determine the state change ( more exactly the set of location updates ) for every step ; see @xcite or the next section for precise definitions of locations and updates .
thus , there is a uniform upper bound on the total size of locations that an algorithm needs to explore at any state .
bounded exploration is the reason why all algorithms considered , here and in the rest of this paper , are called ` small - step ' .
the characterization theorem of @xcite establishes the asm thesis for the class @xmath0 of algorithms defined by sequential time , abstract state , and bounded exploration and the class @xmath1 of machines defined by the basic asm language of update rules , parallel rules and conditional rules @xcite .    while the intent in @xcite is to capture algorithms executing steps in isolation from the environment , a degree of _ intra - step interaction _
is accommodated in the asm literature since @xcite : ( i )  using the import command to create new elements , and ( ii )  marking certain functions as _ external _ and allowing the environment to provide the values of external functions .
one pretends that the interaction is inter - step .
this requires the environment to anticipate some actions of the algorithm .
also , in @xcite , nesting of external functions was prohibited ; the first study of asms with nested external functions was @xcite .
the notion of _ run _ determines whether _ inter - step _ interaction is allowed , see @xcite for precise definitions and discussion .      in @xcite
it is argued at length why the inter - step form of interaction can not suffice for all modeling needs . as a small example take the computation of @xmath6 where @xmath7 is an external call ( a query ) with argument 7 , whose result @xmath8 is used as the argument for a new query @xmath9 .
an attempt to model this as inter - step interaction would force splitting the computation into substeps .
but at some level of abstraction we may want to evaluate @xmath6 within a single step .
limiting interaction to the inter - step mode would necessarily lower the abstraction level .
thus @xcite sets modeling _ intra - step _ interaction as its goal .
different forms of interaction , such as message - passing , database queries , remote procedure calls , inputs , outputs , signals ,   all reduce to a single universal form : a single - reply zero - or - more - arguments not - necessarily - blocking _
query_. all arguments and the reply ( if any ) should be elements of the state if they are to make sense to the algorithm . for a formal definition of queries
see @xcite ; a reminder is given in the next section .
for a detailed discussion and arguments for the universality of the query - reply approach see @xcite .
articles @xcite limit themselves to interactive algorithms which are _ ordinary _ in the sense that they obey the following two restrictions :    1 .
the actions of the algorithm depend only on the state and the replies to queries , and not on other aspects , such as relative timing of replies , and 2 .
the algorithm can not complete its step unless it has received replies to all queries issued .
the first restriction means that an algorithm can be seen as operating on pairs of form @xmath10 where @xmath11 is a state and @xmath12 an _ answer function _ over @xmath11 : a partial function mapping queries over @xmath11 to their replies .
the second restriction means that all queries issued are _ blocking _ ; the algorithm can not complete its step without a reply .
( some uses of non - blocking , asynchronous queries can still be modeled , by assuming that some forms of queries always obtain a default answer .
but this is an assumption on environment behavior . )
the present paper lifts both restrictions , and thus extends the theory to _ general _ interactive algorithms .
several of the postulates of @xcite cover the same ground as the postulates of @xcite , but of course taking answer functions into account .
the most important new postulate is the * interaction postulate * , saying that the algorithm , for each state @xmath11 , determines a _ causality relation _ @xmath13 between finite answer functions and queries .
the intuition behind @xmath14 is this : if , over state @xmath11 , the environment behaves according to answer function @xmath12 then the algorithm issues @xmath15 . the causality relation is an abstract representation of potential interaction of the algorithm with the environment .
but not all answer functions can actually arise in such interaction .
context _ for @xmath16 is a minimal ( with respect to graph inclusion ) answer function @xmath12 with the following closure property : if @xmath17 for some subfunction @xmath18 , then @xmath19 .
intuitively , this means that @xmath12 gives answers for exactly those queries that the algorithm would ask , given @xmath12 .
this incorporates both the idea of blocking  all queries that are issued must be answered  and the more basic idea that an algorithm can not see replies to queries that it did nt issue .
the * updates postulate * asserts that , for every context @xmath12 for @xmath16 , the algorithm either _ fails _ or produces the next state .
this refines the transition relation of sequential time of @xcite .
the possibility of explicit failure is new here ; the algorithm may obtain replies that are absurd or inconsistent from its point of view , and it can fail in such a case .
the next state , if there is one , is defined by an update set , which can also contain trivial updates : `` updating '' a location to the old value .
trivial updates do not contribute to the next state , but in composition with other algorithms can contribute to a clash , see @xcite and also the next section for discussion .
the inductive character of the context definition is unwound and analyzed in detail in @xcite .
the answer functions which can occur as stages in the inductive construction of contexts are called _ well - founded_. this captures the intuition of answer functions which can actually arise as records of interaction of an algorithm and its environment .
two causality relations ( over the same state ) are _ equivalent _ if they make the same answer functions well - founded .
equivalent causality relations have the same contexts but the converse is not in general true : intermediate intra - step behavior matters .
two ordinary interactive algorithms are _ behaviorally equivalent _ if    * they have the same states and initial states , * at all states they have equivalent causality relations , and * at all state - context pairs , either they both fail or they produce the same update sets as required by updates .    the * bounded work postulate * of @xcite extends bounded exploration of @xcite to queries .
as a consequence every well - founded answer function is finite . furthermore , there is a uniform bound on the size of well - founded answer functions .
queries can be expressed by external functions @xcite , but there is a complication . in some cases
different textual occurrences of the same external function symbol applied to the same arguments can be reasonably assumed to define the same query , and thus to represent the same reply . in some cases , for instance with object - creation operators of oop languages , different occurrences of the same external function symbol with the same arguments
are always assumed to represent different queries which always obtain different fresh replies .
there are also many intermediate possibilities .
most of @xcite is devoted to a discussion of and a general solution to this problem using the device of _ query - templates _
, which we reuse here . in @xcite the syntax and semantics of ordinary interactive asms is defined .
the syntax is essentially the same as the asm language of @xcite with the addition of external function symbols , a subset of the asm language of @xcite .
what is new is that the restriction of @xcite , forbidding nesting of external function symbols , can now be safely lifted : the query semantics and the analysis of causality provided by @xcite did not exist at the time @xcite was written .
thus the semantics of @xcite was constrained to inter - step interaction only .
the characterization theorem for the class @xmath0 of algorithms defined in @xcite and the class @xmath1 of machines defined in @xcite is proved in @xcite .
efforts to characterize algorithms mathematically began with the work of alonzo church @xcite and alan turing @xcite in the 1930 s .
turing gave a careful analysis and a gradual simplification of what can happen during an algorithmic computation performed by a person .
the result was the turing machine model of computation and a mathematical characterization , now universally accepted , of the functions ( from finite strings to finite strings ) that are computable in principle , disregarding limitations of time and memory .
the simplifications , however , typically lower the level of abstraction in a drastic way ; just compare any algorithm in @xcite or @xcite with a turing machine implementation of that algorithm .
the latter involves details  the data representation on the tape , indications how the read / write head should find the right place for the next `` real '' work , etc .
 that are not essential to the algorithm ( but essential for the turing machine ) .
thus , although turing s work successfully characterized the ( in principle ) computable functions , it characterized the algorithms that compute them only to the extent that one ignores levels of abstraction .
( `` in principle '' means that there are no bounds on resources , so `` computable '' does not mean that we are able carry out the computation in the real world . )
the asm thesis , in contrast , asserts that algorithms can be described at their natural levels of abstraction by asms .
the textbook algorithms can be written as asms without introducing irrelevant details of implementation .
a detailed implementation , such as a turing machine or an assembly language program , can also be written as an asm .
there are some other differences between the turing machine model and the asm model related to lowering of the abstraction level in the turing machine model . in the turing model , inputs and outputs
are strings .
asms deal naturally with computations involving abstract entities .
examples include the gauss elimination algorithm over arbitrary fields and the ruler - and - compass constructions of geometry .
particularly important examples include computations with finite structures , e.g.  relational databases .
databases can be implemented as strings . to do that
, arbitrary choices may be necessary ( to order the underlying sets ) .
thus string encoding exposes the implementation while database queries are supposed to be implementation independent .
furthermore , even when an algorithm works with strings , its parallel or interactive character can be lost in a turing machine simulation .
slightly before turing s paper @xcite , church @xcite proposed another mathematical characterization of computability , in terms of definability in lambda - calculus .
church s proposal turned out to be equivalent to turing s ; that is , the lambda - definable functions are just those that are computable by turing machines . unlike turing s proposal , however ,
church s was not accompanied by an attempt to analyze the general notion of algorithm ; it therefore lies considerably farther from our work .
andrei n. kolmogorov @xcite has given another mathematical description of computation , presumably motivated by the physics of computation rather than by an analysis of the actions of a human computer .
for a detailed presentation of kolmogorov s approach , see @xcite . also see @xcite and the references there for information about research on pointer machines .
like turing s model , these computation models also lower the abstraction level of algorithms .
yiannis moschovakis @xcite proposed that the informal notion of algorithm be identified with the formal notion of _ recursor_. a recursor is a monotone operator over partial functions whose least fixed point includes ( as one component ) the function that the algorithm computes .
the approach does not seem to scale to algorithms interacting with an unknown environment .
see ( * ? ? ?
* section  4.3 ) for a critique of moschovakis s computation model .
an approach to interactive computing was pioneered by peter wegner and developed in particular in @xcite .
the approach is based on special interactive variants of turing machines called _ persistent turing machines _ , in short ptms .
interactive asms can step - for - step simulate ptms . goldin and wegner
assert that `` any sequential interactive computation can be performed by a persistent turing machine '' @xcite .
but this is not so if one intends to preserve the abstraction level of the given interactive algorithm . in particular , ptms can not step - for step simulate interactive asms @xcite .
the topic of the present paper is intra - step interaction between a single sequential - time algorithm and its environment ( that is , the rest of the world ) .
we are not aware of any previous literature on intra - step interaction . on the other hand , the communication mechanism that emerges from our study
is not limited to intra - step interaction .
our investigation did not happen in a vacuum .
it is hard for us to indicate particular sources that influenced our thinking , but surely  consciously or unconsciously  our thinking was influenced by the theory of distributed algorithms , by programming languages attempting to provide means for communication between computing agents , and by computing technology .
a few references that seem relevant to us are @xcite .
this section is devoted to the description of interactive , small - step algorithms by means of suitable definitions and postulates .
some parts of this material are essentially the same as in @xcite , which dealt with small - step algorithms that interact with the environment only between steps ; some other parts are as in @xcite , which dealt with small - step algorithms that interact with the environment within steps but only in the `` ordinary '' manner described in the introduction .
we shall present these parts again here , without repeating the explanations and motivations from @xcite and @xcite , but see section [ sec : overview ] .
for the genuinely new material , dealing with the non - ordinary aspects of our algorithms interaction with the environment , we shall present not only the definitions and postulates but also the reasons and intuitions that lie behind them .    in the following presentation of the postulates and their intuitive motivation , we use the word `` algorithm '' ( or `` interactive , small - step algorithm '' ) in an informal sense .
our discussion amounts to an analysis of this intuitive notion , and our postulates are a distillation of the results of the analysis .
afterward , in definition  [ alg - def ] , we give the phrase `` interactive small - step algorithm '' a formal meaning , based on the postulates .
thus , definition  [ alg - def ] implicitly asserts a thesis , namely that the postulates and the formal notion defined from them adequately capture the intuitive notion that we analyzed . in @xcite
, we shall show that algorithms in our formal sense are behaviorally equivalent to asms . in the light of this result ,
the thesis implicit in definition  [ alg - def ] is really the asm thesis for interactive small - step algorithms .    throughout the definitions and postulates that follow , we consider a fixed algorithm @xmath20
. we may occasionally refer to it explicitly , for example to say that something depends only on @xmath20 , but usually we leave it implicit .
our first postulate is a cosmetic improvement of the state postulate of @xcite , and most of it is assembled from parts of postulates in @xcite .
we refer the reader to @xcite for a careful discussion of the first three parts of the postulate and to @xcite for the last part .
states postulate : the algorithm determines    a finite vocabulary @xmath21 ,    a nonempty set s of _ states _ which are all @xmath21-structures ,    a nonempty subset @xmath22 of _ initial states _ ,    a finite set @xmath23 of _ labels _ ( to be used in forming queries ) .
as in the cited earlier papers , we use the following conventions concerning vocabularies and structures .    [ vocab ]    a vocabulary @xmath21 consists of function symbols with specified arities
.    some of the symbols in @xmath21 may be marked as _
static _ , and some may be marked as _
relational_. symbols not marked as static are called _
dynamic_.    among the symbols in @xmath21 are the logic names : nullary symbols @xmath24 , @xmath25 , and @xmath26 ; unary @xmath27 ; binary equality ; and the usual propositional connectives .
all of these are static and all but @xmath26 are relational .
an @xmath21-structure consists of a nonempty base set and interpretations of all the function symbols as functions on that base set .    in any @xmath21-structure
, the interpretations of @xmath24 , @xmath25 , and @xmath26 are distinct .    in any @xmath21-structure , the interpretations of relational symbols are functions whose values lie in @xmath28 .    in any @xmath21-structure @xmath11 , the interpretation of @xmath27 maps @xmath29 and @xmath30 to @xmath29 and everything else to @xmath30 .    in any @xmath21-structure @xmath11 ,
the interpretation of equality maps pairs of equal elements to @xmath29 and all other pairs to @xmath30 .    in any @xmath21-structure @xmath11
, the propositional connectives are interpreted in the usual way when their arguments are in @xmath28 , and they take the value @xmath30 whenever any argument is not in @xmath28 .
we may use the same notation @xmath11 for a structure and its base set .
we may omit subscripts @xmath11 , for example from @xmath24 and @xmath25 when there is no danger of confusion .
a _ potential query _ in state @xmath11 is a finite tuple of elements of @xmath31 .
a _ potential reply _ in @xmath11 is an element of @xmath11 .
here @xmath31 means the disjoint union of @xmath11 and @xmath23 .
so if they are not disjoint , then they are to be replaced by disjoint isomorphic copies .
we shall usually not mention these isomorphisms ; that is , we write as though @xmath11 and @xmath23 were disjoint .
interaction of an algorithm with its environment has been analyzed at length in @xcite .
the analysis established that all forms of interaction reduce to queries and replies .
the algorithms of @xcite are insensitive to the relative timing of replies within a step , and the environment interaction during a step could be expressed there as an answer function mapping queries to their replies .
the following simple example shows that the expressive power of answer functions is not sufficient in general .
[ ex : broker ] for a simple example , consider a broker who has a block of shares to sell .
he asks two clients whether they want to buy the shares .
both of them reply that they want to buy the whole block .
the broker will sell the shares to the client whose message reaches him first .
[ ans - fn ] an _ answer function _ for a state @xmath11 is a partial map from potential queries to potential replies .
a _ history _ for @xmath11 is a pair @xmath32 consisting of an answer function @xmath33 together with a linear pre - order @xmath34 of its domain . by the _ domain _ of a history @xmath35 , we mean the domain @xmath36 of its answer function component , which is also the field of its pre - order component .
recall that a _ pre - order _ of a set @xmath37 is a reflexive , transitive , binary relation on @xmath37 , and that it is said to be _ linear _ if , for all @xmath38 , @xmath39 or @xmath40 .
the equivalence relation defined by a pre - order is given by @xmath41 the equivalence classes are partially ordered by @xmath42\leq[y]\iff x\leq y,\ ] ] and this partial order is linear if and only if the pre - order was .
the _ length _ of a linear pre - order is defined to be the order type of the induced linear ordering of equivalence classes .
( we shall use this notion of length only in the case where the number of equivalence classes is finite , in which case this number serves as the length . )
we also write @xmath43 to mean @xmath39 and @xmath44 .
( because a pre - order need not be antisymmetric , @xmath43 is in general a stronger statement than the conjunction of @xmath39 and @xmath45 . )
when , as in the definition above , a pre - order is written as @xmath34 , we write the corresponding equivalence relation and strict order as @xmath46 and @xmath47 .
the same applies to other subscripts and superscripts .
we use histories to express the information received by the algorithm from its environment during a step .
the notion of answer function comes from @xcite , where these functions , telling which queries have received which replies , represented the whole influence of the environment on the algorithm s work .
when algorithms are not required to be ordinary , then additional information from the environment , namely the relative order in which replies were received , becomes relevant to the computation .
this information is represented by the pre - order part of a history .
if @xmath48 and @xmath49 , this means that the answer @xmath50 to @xmath51 was received strictly before the answer @xmath52 to @xmath15 . if @xmath53 , this means that the two answers were received simultaneously
the rest of this subsection is devoted to explaining in more detail the intuition behind this formalization of the intuitive notion of the history of an algorithm s interaction with its environment during a step .
we do not , however , repeat here sections  2 and 4 of @xcite .
the first of these two sections explains in detail our reasons for using queries and replies as our model of the interaction between an algorithm and its environment .
the second explains the reasons for our specific definitions of ( potential ) queries and replies .
here , we presuppose these explanations and adopt the query - reply paradigm of @xcite ; see also section [ sec : overview ] .
our task now is to explain what is added to the picture from @xcite when we remove the restriction to ordinary algorithms .
much of the information provided by an environment can and should be viewed as being part of its replies to queries .
this includes not only the information explicitly requested by the query but also such varied information as `` how hard did the user ( who is part of the environment ) bang on the keyboard when typing this input '' or `` at what time was this input provided '' if such information is relevant to the algorithm s execution .
thus , we can view such information as being included in the answer function @xmath54 , without referring to the second component of a history , the pre - order .
the purpose of the pre - order , on the other hand , is to represent the order in which the algorithm becomes aware of the environment s answers .
even if the environment provides a time - stamp as part of each reply , this order can not be read off from the replies .
the algorithm may become aware of the replies in an order different from that indicated by the time stamps . in the broker example [ ex : broker ]
, the broker will sell the shares to the client whose message reaches him first , even if the message from the other client is sent earlier .
[ time - stamp ] could the environment provide , as part of its replies , time stamps that tell when the algorithm becomes aware of the replies ?
if so , could we then proceed as in @xcite , where algorithms get information from the environment only via the answer function ?
in other words , could we dispense with the pre - order component in histories ?
the idea of a time stamp telling not when the reply was sent but when it is received is not as absurd as it might appear .
the factors affecting the time of receipt , such as the speed of connections over which the reply travels and the speed at which the algorithm is executed , are not specified by the algorithm and the state , so they are part of the environment , albeit a different part from that ordinarily involved in answering queries .
so the complete environment could conceivably assemble replies that include the time that the algorithm sees them .
such an environment would be quite unusual , and of course it would have to be subject to the constraint that the time stamps accurately reflect at least the order in which replies are received .
but , if such an environment can be imagined , could we use it , at least for theoretical purposes , to avoid the need for the pre - order compnent in histories ?
if so , then the present paper could stay closer to the work previously done in @xcite , and we would have been quite happy to avoid the extra work .
the pre - orders are , however , needed , even for theoretical purposes .
consider the broker example above .
part of the broker s algorithm tells him what to do if both clients reply . to model that in the style of @xcite , assuming that replies include accurate information about their arrival times , the algorithm would have to wait for both replies ,
read both time stamps , and act accordingly .
but in fact , the algorithm does not wait for both replies .
if it receives one reply , it acts on the basis of that reply without waiting for the other .    in effect
, this algorithm and others like it decide the relative order of receipt of two replies as soon as one of the replies is received . if one is received and the other is nt , then the received one is earlier .
this common sense approach is unavailable if the timing comparisons have to be based on reading time stamps embedded in the replies .
thus , even if we constrained our environments to always provide time stamps that accurately indicate the time a reply is seen by the algorithm , we would still need machinery like that in the present paper to decide the relative order of two replies even if only one has been seen .    even though the pre - order @xmath34 is about the replies , the formal definition says that it pre - orders the domain of the answer function @xmath54 , i.e. , the set of queries .
the reason is a technical one : different queries may receive the same reply , and in that case the single reply could occur at several positions in the ordering .
each query , on the other hand , is issued just once because , in accordance with the conventions of @xcite , if what appears to be the same query is issued repeatedly , then we regard the repetitions as distinct queries ( since they can receive different replies ) . thus
, the order in which replies are received can be conveniently represented by pre - ordering the associated queries .
it may be more intuitive to think of pre - ordering the set of pairs ( query , reply ) , i.e. , the graph of the answer function .
this view of the situation would make no essential difference , since these pairs are in canonical bijection with the queries .
we emphasize that the timing we are concerned with here is logical time , not physical time .
that is , it is measured by the progress of the computation , not by an external clock .
if external , physical , clock time is relevant , as in real - time algorithms , it would have to be provided separately by the environment , for it is not part of the program or of the state .
the relevant values of the physical time could be regarded as the replies to repeated queries asking `` what time is it ? ''    in particular , we regard a query as being issued by the algorithm as soon as the information causing that query ( in the sense of the interaction postulate below ) is available . this viewpoint would be incorrect in terms of physical time , for the algorithm may be slow to issue a query even after it has the prerequisite information .
but we can regard a query as being logically available as soon as information causing it is present .
this is why we include , in histories , only the relative ordering of replies .
the ordering of queries relative to replies or relative to each other is then determined .
the logical time of a query is the same as the logical time of the last of the replies causing that query .
our use of pre - orders rather than partial orders , i.e. , our allowing two distinct replies to be received simultaneously , also reflects our concern with logical rather than physical time .
one can argue that no two events are exactly simultaneous in the physical sense ( though they could be so nearly simultaneous that one should treat them as simultaneous ) , but logical simultaneity is certainly possible .
it means merely that whenever the computation had access to one of the replies it also had access to the other .
the linearity of the pre - ordering , i.e. , the requirement that every two replies be received either in one order or in the other or simultaneously , formalizes the following important part of our view of sequential - time ( as opposed to distributed ) algorithms .
( it is not a postulate of our formal development but an informal principle that underlies some of our definitions and postulates .
)    one executor principle a small - step algorithm is executed by a single , sequential entity .
even if there are ( boundedly many ) subprocesses running in parallel , they all operate under the control of a single , master executor .
the aspect of this principle that is relevant to the linearity of histories can be summarized in the following informal principle , in which the first part emphasizes the role of the master executor in the interaction with the environment , while the second part is a consequence of the sequentiality of the executor .
holistic principle the environment can send replies only to ( the executor of ) the algorithm , not directly to parts of it ; similarly it receives queries only from the algorithm , not from parts of it .
any two replies are received by the algorithm either simultaneously or one after the other .
the pre - orders in our histories are intended to represent the order in which replies are received by the master executor .
if there are subprocesses , then the master may pass the replies ( or information derived from them ) to these subprocesses at different times , but that timing is part of the algorithm s internal operation ( possibly also influenced by the replies to other queries like `` what time is it ? '' ) , not part of the environment interaction that histories are intended to model .
the linearity of our pre - orders reflects the fact that they represent the ordering as seen by a single , sequential entity ; this entity sees things in a sequence .    in more detail
, we picture the execution of one step of an algorithm as follows .
first , the algorithm ( or , strictly speaking , its executor ) computes as much as it can with only the information provided by the current state .
this part of the computation , the first phase , will in general include issuing some queries
. then the algorithm pauses until it is `` awakened '' by the environment , which has replied to some ( not necessarily all ) of the queries from phase  1 .
the algorithm proceeds , in phase  2 , to compute as much as it can using the state , the new information from the environment , and the information recorded during phase  1 .
then it again pauses until the environment has provided some more replies ( possibly to queries from phase  2 and possibly to previously unanswered queries from phase  1 ) and awakens the algorithm
. then phase  3 begins , and this pattern continues until the algorithm determines , in some phase , that it is ready to complete the current step , either by executing certain updates ( computed during the various phases ) of its state or by failing ( in which case the whole computation fails and there is no next state ) .
the logical ordering of replies refers to the phases at which replies were received .
that is , if @xmath55 , this means that the reply @xmath56 to @xmath57 was received at an earlier phase than the reply @xmath58 to @xmath59 .
similarly , @xmath60 means that these two replies were received at the same phase .
we have assumed , in the preceding description of phases , that the algorithm is awakened to begin a new phase only when some new reply has been provided .
one may worry that this is not general enough , that the environment can awaken the algorithm even when no new replies are available .
the rest of this remark is devoted to discussing this issue and justifying our assumption ; it can safely be skipped by readers not worried about such subtleties .
in such a case , it is natural to assume that the algorithm , having determined that it has no new information with which to advance the computation , simply resumes its pause until awakened again . in order for the algorithm to be a small - step algorithm
, such fruitless awakenings must happen only a bounded number of times per step , with the bound depending only on the algorithm .
the reason is that , even if all the algorithm does when awakened is to observe that no new replies have arrived , this observing is work , and a small - step algorithm can do only a bounded amount of it per step .
it seems possible , however , for an algorithm to admit a few fruitless awakenings per step , and the results of the computation could even depend on these awakenings .
consider , for example , an algorithm that works as follows .
it begins by issuing a query @xmath15 and pausing .
when awakened , it outputs 1 and halts if there is a reply to @xmath15 ; otherwise , it pauses again .
when awakened a second time , it outputs 2 if there is now a reply to @xmath15 , and , whether or not there is a reply , it halts .
notice that , if @xmath15 receives the reply @xmath61 , then whether this is seen at the first or the second awakening does nt affect the history , which consists of the function @xmath62 and the unique pre - order on its domain @xmath63 .
so the history fails to capture all the information from the environment that is relevant to the computation .
there are two ways to correct this discrepancy .
one , which we shall adopt , is to regard the fruitless awakening as amounting to a reply to an implicit query , of the form `` i m willing to respond to awakening . ''
( for several fruitless awakenings , there would have to be several such queries , distinguished perhaps by numerical labels . )
now the two scenarios considered above , where @xmath15 has received a reply at the first awakening or only at the second , are distinguished in the histories , because the reply to the new , implicit query will be simultaneous with the reply to @xmath15 in the one scenario and will strictly precede the reply to @xmath15 in the other scenario .
an alternative approach would be to avoid introducing such implicit queries but instead to replace the pre - order constituents of histories by slightly more complicated objects , `` pre - orders with holes . ''
the idea is that the scenario where an answer to @xmath15 is available only at the second awakening would be represented by the answer function @xmath62 as above , but the pre - order would be replaced with something that says `` first there s a hole and then @xmath15 . ''
formalizing this is actually quite easy , as long as the pre - order is linear and the set @xmath37
to be pre - ordered is finite ( as it will be in the situations of interest to us ) .
a linear pre - order of @xmath37 with holes is just a function @xmath51 from @xmath37 into the natural numbers . for any @xmath64 ,
the elements of @xmath65 constitute the @xmath66 equivalence class , which may be empty in case of a hole .
ordinary pre - orders correspond to the special case where the image @xmath67 is an initial segment of n.    although the approach using pre - orders with holes corresponds more directly to intuition , we prefer the first approach , with implicit queries , for two reasons . first , it allows us to use the standard terminology of pre - orders rather than introducing something new .
second , its chief disadvantage , the need for implicit queries , is mitigated by the fact that we need other sorts of implicit queries for other purposes .
for example , in ( * ? ? ?
* section  2 ) , implicit queries modeled the algorithm s receptiveness to incoming ( unsolicited ) messages and to multiple answers to the same query .
notice that , in all cases , our implicit queries represent the algorithm s willingness to pay attention to something provided by the environment .
we next define initial segments of histories , which will serve to model the interaction with the environment part way through a step .
let @xmath68 be a pre - order of a set @xmath37 .
an _ initial segment _ of @xmath37 with respect to @xmath68 is a subset @xmath69 of @xmath37 such that whenever @xmath39 and @xmath70 then @xmath71 .
an _ initial segment _ of @xmath68 is the restriction of @xmath68 to an initial segment of @xmath37 with respect to @xmath68 .
an _ initial segment _ of a history @xmath72 is a history @xmath73 , where @xmath69 is an initial segment of @xmath36  with respect to @xmath34 .
( we use the standard notation @xmath74 for the restriction of a function or a relation to a set . )
we write @xmath75 to mean that the history @xmath76 is an initial segment of the history @xmath35 .
notice that any initial segment with respect to a pre - order @xmath68 is closed under the associated equivalence @xmath77 .
notice also that if @xmath78 then @xmath79 is an initial segment of @xmath34 .
we also point out for future reference that , if two histories @xmath80 and @xmath81 are initial segments of the same @xmath35 , then one of @xmath80 and @xmath81 is an initial segment of the other .
intuitively , if @xmath72 is the history of an algorithm s interaction with the environment up to a certain phase , then a proper initial segment of this history describes the interaction up to some earlier phase .
if @xmath68 pre - orders the set @xmath37 and if @xmath82 , then we define two associated initial segments as follows .
@xmath83    the following postulate is almost the same as the postulate of the same name in @xcite .
the only difference is that we use histories instead of answer functions .
this reflects the fact that the decision to issue a query can be influenced by the timing of the replies to previous queries .
interaction postulate for each state @xmath11 , the algorithm determines a binary relation @xmath13 , called the _ causality relation _ , between finite histories and potential queries .
the intended meaning of @xmath84 is that , if the algorithm s current state is @xmath11 and the history of its interaction so far ( as seen by the algorithm during the current step ) is @xmath35 , then it will issue the query @xmath15 unless it has already done so .
when we say that the history so far is @xmath35 , we mean not only that the environment has given the replies indicated in @xmath33 in the order given by @xmath34 , but also that no other queries have been answered . thus , although @xmath35 explicitly contains only positive information about the replies received so far , it also implicitly contains the negative information that there have been no other replies . of course
, if additional replies are received later , so that the new history has @xmath35 as a proper initial segment , then @xmath15 is still among the issued queries , because it was issued at the earlier time when the history was only @xmath35 .
this observation is formalized as follows .    for any state @xmath11 and history @xmath35
, we define sets of queries @xmath85    thus , @xmath86 is the set of queries that have been issued by the algorithm , in state @xmath11 , by the time the history is @xmath35 , and @xmath87 is the subset of those that have , as yet , no replies .
[ descr - causes ] we have described the causality relation in terms of detailed causes , histories @xmath35 that contain the algorithm s whole interaction with environment up to the time the caused query is issued . a text describing the algorithm , either informally or in some programming language , would be more likely to describe causes in terms of partial information about the history .
for example , it might say `` if the query @xmath51 has received the reply @xmath8 but @xmath88 has no reply yet , then issue @xmath15 . ''
this description would correspond to a large ( possibly infinite ) set of instances @xmath89 of the causality relation , namely one instance for every history @xmath35 that fits the description , i.e. , such that @xmath90 and @xmath91 . more generally , whenever we are given a description of the conditions under which various queries are to be issued
, we can similarly convert it into a causality relation ; each of the conditions would be replaced by the set of finite histories that satisfy the condition .
the reverse transformation , from detailed causes representing the whole history to finite descriptions , is not possible in general .
the difficulty is that the finite descriptions might have to specify all of the negative information implicit in a history , and this might be an infinite amount of information . in most situations , however , the set of queries that might be issued is finite and known .
then any finite history @xmath35 can be converted into a finite description , simply by adding , to the positive information explicit in @xmath35 , the negative information that there have been no replies to any other queries among the finitely many that could be issued .    for semantical purposes , as in the present section
, it seems natural to think of causes as being the detailed histories . from the behavior of an algorithm
, one can easily determine whether @xmath84 ( at least when @xmath35 is attainable as in definition  [ att - def ] below and we ignore causes of @xmath15 that have proper initial segments already causing @xmath15 ) ; just provide the algorithm with replies according to @xmath35 and see whether it produces @xmath15 at that moment ( and not earlier ) .
it is not easy to determine , on the basis of the behavior , whether @xmath15 is issued whenever a description , like `` @xmath51 has reply @xmath8 and @xmath88 has no reply '' is satisfied , as this involves the behavior in a large , possibly infinite number of situations .    for syntactic purposes , on the other hand ,
descriptions seem more natural than detailed histories . and indeed , the syntax of our asms ( in @xcite ) will not involve histories directly but will involve descriptions like `` @xmath51 has reply @xmath8 and @xmath88 has no reply '' in the guards of conditional rules .    notice that there is no guarantee that @xmath92 , although this will be the case for attainable histories ( defined below ) . in general , a history as defined above may contain answers for queries that it and its initial segments do nt cause
. it may also contain answers for queries that would be issued but only at a later phase than where the answers appear . in this sense , histories need not be possible records of actual interactions , between the algorithm and its environment , under the causality relation that is given by the algorithm .
the following definition describes the histories that are consistent with the given causality relation .
informally , these are the histories where every query in the domain has a legitimate reason , under the causality relation , for being there .
a history @xmath35 is _ coherent _ , with respect to a state @xmath11 or its associated causality relation @xmath13 , if    @xmath93 , and    the linear order of the @xmath46-equivalence classes induced by @xmath34 is a well - order .    the first requirement in this definition , which can be equivalently rewritten as @xmath94 says that , if a query @xmath15 receives an answer at some phase , then it must have been issued on the basis of what happened in strictly earlier phases . in particular , the queries answered in the first phase , i.e. , those in the first @xmath46-class , must be caused by the empty history .
the second requirement is needed only because we allow infinite histories ; finite linear orders are automatically well - orders .
the purpose of the second requirement is to support the usual understanding of `` cause '' by prohibiting an infinite regress of causes .
it will follow from the bounded work postulate below in conjunction with the interaction postulate above , that we can confine attention to histories whose domains are finite .
then clause 2 in the definition of coherence would be automatically satisfied .
nevertheless , we allow a coherent history @xmath35 to have infinite domain and even to have infinitely many equivalence classes , with respect to @xmath34 , provided their ordering induced by @xmath34 is a well - ordering .
there are two reasons for this generality .
first , it will allow us to state the bounded work postulate in a relatively weak form and then to deduce the stronger fact that the histories we really need to consider ( the attainable ones ) are finite .
second , it avoids formally combining issues that are conceptually separate .
finiteness is , of course , an essential aspect of computation , especially of small - step computation , and the bounded work postulate will formalize this aspect .
but the notions of coherent and attainable histories are conceptually independent of finiteness , and so we do not impose finiteness in their definitions .
[ cpt1 ] as mentioned above , the notion of coherence is intended to capture the idea of a history that makes sense , given the algorithm s causality relation . here
we implicitly use the fact that we are describing an entire algorithm , not a component that works with other components to constitute an algorithm .
if we were dealing with a component @xmath95 , working in the presence of other components , then it would be possible for queries to be answered without having been asked by @xmath95 , simply because another component could have asked the query .
see @xcite for a study of components .
it follows immediately from the definitions that any initial segment of a coherent history is coherent .
a history @xmath35 for a state @xmath11 is _ complete _ if @xmath96 .
thus , completeness means that all queries that have been issued have also been answered . it can be regarded as a sort of converse to coherence , since the latter means that all queries that have been answered have also been issued earlier .
if a complete history has arisen in the course of a computation , then there will be no further interaction with the environment during this step .
no further interaction can originate with the environment , because no queries remain to be answered .
no further interaction can originate with the algorithm , since @xmath35 and its initial segments do nt cause any further queries .
so the algorithm must either proceed to the next step ( by updating its state ) or fail .      at the end of a step
the algorithm will , unless it fails , perform some set of updates .
the next postulate will express this property of algorithms formally .
first , we adopt the formalization of the notion of update that was used in earlier work , starting with @xcite .
a _ location _ in a state @xmath11 is a pair @xmath97 where @xmath98 is a dynamic function symbol from @xmath21 and @xmath99 is a tuple of elements of @xmath11 , of the right length to serve as an argument for the function @xmath100 interpreting the symbol @xmath98 in the state @xmath11 .
the _ value _ of this location in @xmath11 is @xmath101 .
an _ update _ for @xmath11 is a pair @xmath102 consisting of a location @xmath103 and an element @xmath104 of @xmath11 .
an update @xmath102 is _ trivial _ ( in @xmath11 ) if @xmath104 is the value of @xmath103 in @xmath11 .
we often omit parentheses and brackets , writing locations as @xmath105 instead of @xmath106 and writing updates as @xmath107 or @xmath108 instead of @xmath109 or @xmath110 .
the intended meaning of an update @xmath107 is that the interpretation of @xmath98 is to be changed ( if necessary , i.e. , if the update is not trivial ) so that its value at @xmath99 is @xmath104 .
because our algorithms are not required to be ordinary , they may finish a step without reaching a complete history .
the following postulate says that they must finish the step when they reach a complete history , if they have not already done so earlier .
step postulate  part a the algorithm determines , for each state @xmath11 , a set @xmath111 of _ final histories_. every complete , coherent history has an initial segment ( possibly the whole history ) in @xmath111 .
intuitively , a history is final for @xmath11 if , whenever it arises in the course of a computation in @xmath11 , the algorithm completes its step , either by failing or by executing its updates and proceeding to the next step .
since incoherent histories can not arise under the algorithm s causality relation , it will not matter which such histories are final .
we could have postulated that only coherent histories can be final , but there is no need to do so .
it does no harm to allow incoherent final histories , though they are irrelevant to the algorithm s computation . by allowing them
, we may slightly simplify the description , as algorithms subject to our postulates , of programs written in some programming language ; if the language allows one to say `` finish the step '' then this can be directly translated into final histories , without having to check for coherence .
similar comments apply to the remaining parts of the step postulate below , where we require update sets or failure for coherent histories but allow them also for incoherent ones .
[ att - def ] a history for a state @xmath11 is _ attainable _ ( in @xmath11 ) if it is coherent and no proper initial segment of it is final .
since initial segments of coherent histories are coherent , it follows that initial segments of attainable histories are attainable .
the attainable histories are those that can occur under the given causality relation and the given choice of final histories .
that is , not only are the queries answered in an order consistent with @xmath13 ( coherence ) , but the history does not continue beyond where @xmath111 says it should stop .    our earlier statements to the effect that incoherent histories do nt matter can be strengthened to say that unattainable histories do nt matter .
thus , for example , although we allow one final history to be a proper initial segment of another ( even when both are coherent ) , the longer of the two will be unattainable , so its being final is irrelevant .
step postulate  part b for each state @xmath11 , the algorithm determines that certain histories _ succeed _ and others _
fail_. every final , attainable history either succeeds or fails but not both .
we write @xmath112 for the set of successful final histories and @xmath113 for the set of failing final histories .
non - final or unattainable histories may succeed or fail or both , but this will be irrelevant to the behavior of the algorithm . if we restrict attention to attainable histories , then @xmath112 and @xmath113 partition @xmath111 .
the intended meaning of `` succeed '' and `` fail '' is that a successful final history is one in which the algorithm finishes its step and performs a set of updates of its state , while a failing final history is one in which the algorithm can not continue  the step ends , but there is no next state , not even a repetition of the current state .
such a situation can arise if the algorithm computes inconsistent updates .
it can also arise if the environment gives inappropriate answers to some queries .    for more about failures ,
see the discussion following the update postulate in ( * ? ? ?
* section  5 ) .
there is , however , one difference between our present situation and that in @xcite .
there , the algorithm depended upon getting answers to all its queries , so it is reasonable to expect that an inappropriate answer always results in failure . in our present situation ,
however , the algorithm may be willing to finish its step without getting the answer to a certain query . in this case , an inappropriate answer to that query need not force failure .
when a history in @xmath114 arises during the computation , the algorithm should perform its updates and proceed to the next step .
we formalize this in the third and last part of the step postulate , keeping in mind that only attainable histories can arise .
the notation @xmath115 for the update set is taken from @xcite .
the superscript @xmath116 refers to the fact that trivial updates can be included in the update set .
although they do not affect the next state , they can affect whether clashes occur when our algorithm is run in parallel with another .
step postulate  part c for each attainable history @xmath117 for a state @xmath11 , the algorithm determines an _ update set _ @xmath118 , whose elements are updates for @xmath11 .
it also produces a _ next state _
@xmath119 , which    has the same base set as @xmath11 ,    has @xmath120 if @xmath121 , and    otherwise interprets function symbols as in @xmath11 .
the step postulate is the analog , for our present situation , of the update postulate of @xcite .
there are two differences between these postulates , reflecting the two requirements of ordinariness in @xcite that have been lifted in the present work .
first , since we now consider algorithms that can finish a step without waiting for all queries to be answered , we include in the notion of algorithm the information about when to finish a step .
this is the notion of final history introduced in part  a of the step postulate .
if an algorithm never finishes a step while queries are still pending , then its final histories could be defined as being the complete histories ( or the complete , coherent histories ) , and there would be no need to specify f separately in the algorithm .
the complete , coherent histories correspond to the contexts , as defined in @xcite .
second , because we allow an algorithm to take into account the order in which it receives replies to its queries , decisions about failures and updates depend not only on the answer function @xmath33 but on the whole history @xmath35 , including the ordering information contained in @xmath34 .
the intuition and motivation behind the other aspects of the step postulate are discussed in detail in @xcite and @xcite .    in notations like @xmath111 , @xmath114 , @xmath122 , @xmath118 , and @xmath119
, we may omit @xmath11 if only one @xmath11 is under discussion .
we may also add the algorithm @xmath20 as a superscript if several algorithms are under discussion .
notice that the step postulate requires @xmath118 and @xmath119 to be defined when @xmath35 is an attainable , final , successful history , but it allows them to be defined also for other histories .
any values they may have for other histories , however , will not affect the algorithm s computation .
notice also that the next state is completely determined by the current state and the update set .
so when describing an algorithm , we need not explicitly describe @xmath123 if we have described @xmath115 .
if @xmath118 clashes , i.e. , if it contains two distinct updates of the same location , then the description of @xmath119 is contradictory , so the next state can not exist . thus , if such a @xmath35 is attainable and final , it must be failing . that is , clashes imply failure .
[ ex;broker : re ] we revisit the broker example [ ex : broker ] in terms of our definitions .
part of the broker s algorithm is easy to describe : the empty history causes two queries , @xmath124 and @xmath125 .
query @xmath126 expresses the take - it - or - leave - it offer to client @xmath127 to buy a block of @xmath8 shares of stock @xmath128 at price @xmath51 .
a history that contains a positive reply from just one client is final and successful and produces updates recording a sale to that client .
note that , if both clients reply positively but at different times , then the history as an initial segment containing only the reply from the client who answered first , so the stock is sold to this client .
it is also easy to handle histories in which both clients answer negatively ; such a history is successful and final but results in no updates ( or perhaps in an update recording that these clients had the chance to buy the stock and turned it down ) .
note that , although this situation represents a failure of the broker to accomplish his aim , it should not be considered a failing history , as it does not mean that the broker goes out of business .    what if the broker receives positive replies from both clients at the same time ? it is tempting and perhaps realistic to assume that this situation can not occur , but that assumption amounts to a constraint on the environment , and we do not consider in this paper such a restriction of the theory to some `` admissible '' histories .
furthermore , when the broker really can not receive two replies simultaneously , this will be because of some aspect of his receiving mechanism , and it seems that such aspects can be modeled using one of the following ideas .
the broker could systematically prefer one of the clients .
then a history with simultaneous positive replies from both clients would be final and successful and would produce updates recording a sale to the preferred client .
alternatively , the broker could break ties non - deterministically .
that is , a history with simultaneous positive replies from both clients would cause a new query to the environment , asking for a non - deterministic choice of a client .
any reply naming a client would result in a successful final history with a sale to that client .
to finish the specification of the algorithm , we must say what is to be done if netiher client replies , or if one replies negatively and the other does nt reply .
one approach is to declare such histories not to be final .
the broker simply waits , perhaps forever .
a more realistic approach is that the broker s offers to the clients include a time limit .
an easy way to model this is to have the empty history cause , in addition to the offers to the clients , a third query @xmath129 , to be thought of as a time - out query , i.e. , a request to be informed by the environment , when the time limit has been reached .
then any history with a reply to this query but no positive reply from a client will be final and successful and result in no update ( or an update recording that there was no sale and why ) .
the algorithm can still hang , if the environment fails to respond to the time - out query , but that seems a reasonable result for a broker who imposes a time - limit but ca nt find out when it has been reached .
although the primary subject of this paper is intra - step interaction between an algorithm and its environment , it is not our intention to prohibit inter - step interaction of the sort described in @xcite and mentioned in [ sec : overview : seqth ] .
inter - step interaction is , however , quite easy to describe ; the environment is permitted to make arbitrary changes to the state s dynamic functions between the steps of the algorithm .
thus , a _ run _ of an algorithm is a ( finite or infinite ) sequence of states , starting with an initial state , in which each state but the first is obtained from its predecessor either by an intervention of the environment or by a step of the algorithm . in the intervention case ,
the successor state has the same base set and static functions as the predecessor , but the dynamic functions can be arbitrarily altered . in the case of an algorithm step
, there is a successful final history @xmath35 , describing the environment s replies to the algorithm s queries during the step , and if the state before the step was @xmath11 then the state after the step is @xmath119 . since what happens in the intervention steps is quite arbitrary , our concern in this paper is to analyze what happens in the algorithmic steps .
the notion of run , therefore , occurs only in peripheral remarks like this one , not in the main development .
a referee asked why both intra - step and inter - step interaction are needed .
in fact , one could eliminate inter - step interaction , but it would require considerable cooperation from the environment because of the following complications . note that there is no a priori bound on the number of locations that the environment could update in an inter - step action .
so that action can not be simulated by a small - step algorithm in one step .
this problem can be circumvented by having the algorithm ask about these environmental updates only when they are needed for the computation .
this means that the environment must `` remember '' these updates until they are needed ; furthermore , it must keep track of whether these updates are overwritten by the algorithm s own updates .      as in previous work , starting with @xcite , we require that the information relevant to the algorithm s computation that is given by the state must be explicitly given by the structure of the state , not implicitly given by the particular nature of its elements . formally , this means that the computation must be invariant under isomorphisms .
any isomorphism @xmath130 between states can be extended in an obvious , canonical way to act on queries , answer functions , histories , locations , updates , etc .
we use the same symbol @xmath127 for all these extensions .
isomorphism postulate suppose @xmath11 is a state and @xmath130 is an isomorphism of @xmath21-structures .
then :    @xmath131 is a state , initial if @xmath11 is .
@xmath127 preserves causality , that is , if @xmath84 then @xmath132 .
@xmath127 preserves finality , success , and failure , that is , @xmath133 and @xmath134 .
@xmath127 preserves updates , that is , @xmath135 for all histories @xmath35 for @xmath11 .    in the last part of this postulate , and throughout this paper , we adopt the convention that an equation between possibly undefined expressions is to be understood as implying that if either side is defined then so is the other .    we have required that isomorphisms preserve even the irrelevant parts of the algorithm , like update sets for unattainable or non - final histories .
this requirement could be dropped , thereby weakening our postulate , without any damage to our results .
nevertheless , it seems a natural requirement in a general description of algorithms .
the intuition behind it is that , even if an algorithm includes irrelevant information , the states should still be abstract ; not even the irrelevant information should be able to `` see '' the particular nature of the elements of the state .
for example , if @xmath136 is an isomorphism , and @xmath35 is an unattainable ( hence irrelevant ) history in @xmath111 , then our postulate requires @xmath137 ( which is equally unattainable and thus irrelevant in @xmath131 ) to be in @xmath138 . to allow the contrary would be to allow the algorithm to refer to the difference between @xmath11 and @xmath131 , a difference that , because of the isomorphism , involves only the particular elements constituting these states , not their abstract structure
the final postulate formalizes the requirement that a small - step algorithm can do only a bounded amount of work in any one step .
the bound depends only on the algorithm .
work includes assembling queries ( from elements of the state and labels ) and issuing them , computing what queries to issue , deciding whether the current history suffices to finish the step , deciding whether the computation has failed , and computing updates .
our formalization of this closely follows the corresponding postulate in ( * ? ? ?
* section  5 ) ; the use of a set of terms to represent the bounded part of the state that the algorithm looks at goes back to @xcite
.    bounded work postulate    there is a bound , depending only on the algorithm , for the lengths of the tuples in @xmath86 , for all states @xmath11 and final , attainable histories @xmath35 .
there is a bound , depending only on the algorithm , for the cardinality @xmath139 , for all states @xmath11 and final , attainable histories @xmath35 .
there is a finite set @xmath5 of @xmath21-terms ( possibly involving variables ) , depending only on the algorithm , with the following property .
suppose @xmath11 and @xmath140 are two states and @xmath35 is a history for both of them .
suppose further that each term in @xmath5 has the same value in @xmath11 as in @xmath140 when the variables are given the same values in @xmath141 .
then :    if @xmath84 then @xmath142 ( so in particular @xmath15 is a query for @xmath140 ) .    if @xmath35 is in @xmath112 or @xmath113 , then it is also in @xmath143 or @xmath144 , respectively .
@xmath145 .
this completes our list of postulates , so we are ready to define the class of algorithms to be treated in this paper and @xcite .
[ alg - def ] an _ interactive , small - step algorithm _ is any entity satisfying the states , interaction , step , isomorphism , and bounded work postulates .
since these are the only algorithms under consideration in most of this paper , we often omit `` interactive , small - step '' ; on the other hand , when we want to emphasize the difference between these algorithms and the `` ordinary algorithms '' treated in @xcite , we may refer to the present class of algorithms as `` general , interactive , small - step algorithms '' .    as we explained near the beginning of this section
, definition  [ alg - def ] provides a formal meaning for `` ( interactive , small - step ) algorithm '' , whereas the preceding discussion , leading up to the postulates , was based on an informal notion of ( interactive , small - step ) algorithm .
the definition expresses our belief that the formal notion accurately represents the informal one , i.e. , that our postulates adequately describe the intuitive notion .
the remainder of this section is devoted to some terminology and results connected with the bounded work postulate .    a set @xmath5 with the property required in the third part of the bounded work postulate
is called a _ bounded exploration witness _ for the algorithm .
two pairs @xmath146 and @xmath147 , consisting of states @xmath11 and @xmath140 and a single @xmath35 that is a history for both , are said to _ agree _ on @xmath5 if , as in the postulate , each term in @xmath5 has the same value in @xmath11 as in @xmath140 when the variables are given the same values in @xmath141 .
the first two parts of the bounded work postulate assert bounds for final , attainable histories .
they imply the corresponding bounds for all attainable histories , thanks to the following lemma .
let @xmath11 be a state .
any coherent history for @xmath11 is an initial segment of a complete , coherent history for @xmath11 .
any attainable history for @xmath11 is an initial segment of a final , attainable history for @xmath11 .    since @xmath11 is fixed throughout the proof , we omit it from the notation .    to prove the first assertion ,
let @xmath35 be a coherent history . according to the definition , its order - type ( meaning , strictly speaking
, the order - type of the ordering induced by @xmath34 on the equivalence classes under @xmath46 ) is some ordinal number @xmath12 .
we shall inductively define a sequence of coherent histories @xmath148 , starting with @xmath149 . here
@xmath64 will range over either the set n of all natural numbers or the set of natural numbers up to some finite @xmath150 to be determined during the construction .
after @xmath148 is defined , if it is complete , then stop the construction , i.e. , set @xmath151 .
if @xmath148 is incomplete , this means that the set @xmath152 is nonempty .
extend the answer function @xmath153 by adjoining @xmath154 to its domain and assigning it arbitrary values ( in @xmath11 ) there . call the resulting answer function @xmath155 , and make it into a history @xmath156 by pre - ordering its domain as follows . on @xmath157
, @xmath158 agrees with @xmath159 .
all elements of @xmath160 are @xmath158 all elements of @xmath154 .
elements of @xmath154 are @xmath158 only each other . in other words , we extend the ordering of @xmath157 by adding @xmath154 at the end , as a single equivalence class .
it is straightforward to check that each @xmath148 ( if defined , i.e. , if the sequence hasnt ended before @xmath64 ) is a coherent history ; the order - type of its equivalence classes is @xmath161 .
if @xmath148 is defined for only finitely many @xmath64 , then this is because the last @xmath148 was complete , and so we have the required result .
it remains to consider the case where @xmath148 is defined for all natural numbers @xmath64 . in this case , let @xmath162 be the union of all the @xmath148 s .
( more formally , if we regard functions and orderings as sets of ordered pairs , then @xmath163 is the union of the @xmath153 s , and the pre - order @xmath164 is the union of the @xmath159 s . )
then @xmath162 is also coherent . indeed , if @xmath165 then there is some @xmath64 such that @xmath166 . as @xmath148 is coherent , @xmath167 .
but , since each @xmath148 is an initial segment of the next , and therefore of @xmath162 , we have @xmath168 and so @xmath169 .
furthermore , the order - type of @xmath162 is @xmath170 ( where @xmath171 is the order - type of the natural numbers ) , so it is well - ordered .
to finish the proof of the first part of the lemma , we need only check that @xmath162 is complete .
suppose , toward a contradiction , that @xmath172 .
so there is an initial segment @xmath76 of @xmath162 such that @xmath173 . by the interaction postulate
, @xmath76 is finite , so it is an initial segment of @xmath148 for some @xmath64 .
then @xmath174 that contradicts the assumption that @xmath172 , so we have shown that @xmath162 is complete .
thus , @xmath175 is an initial segment of the complete , coherent history @xmath162 , and the first assertion of the lemma is proved .    to prove the second assertion ,
let @xmath35 be an attainable history .
in particular , it is coherent , so , by the first assertion , it is an initial segment of a complete , coherent history @xmath162 . by part
a of the step postulate , @xmath162 has an initial segment @xmath76 that is a final history .
if @xmath162 has several initial segments that are final histories , then let @xmath76 be the shortest of them ; thus no proper initial segment of @xmath76 is final .
since both @xmath35 and @xmath76 are initial segments of @xmath162 , one of them is an initial segment of the other .
since @xmath35 is attainable and @xmath76 is final , @xmath76 can not be a proper initial segment of @xmath35 .
therefore , @xmath35 is an initial segment of @xmath76 .
furthermore , @xmath76 is coherent , because it is an initial segment of the coherent history @xmath162 .
it follows , since no proper initial segment of @xmath76 is final , that @xmath76 is attainable , as desired .
the following corollary extends the first assertion in the bounded work postulate to histories that need not be final .
[ bd - query ] there is a bound , depending only on the algorithm , for the lengths of the tuples in @xmath86 for all states @xmath11 and all attainable histories @xmath35 .
the bound on lengths of queries issued by final , attainable histories , given by the bounded work postulate , applies to all attainable histories , because these are , by the lemma , initial segments of final ones .
the next corollary similarly extends the second assertion of the bounded work postulate , and adds some related information .    [ bd - dom ] there is a bound , depending only on the algorithm , for @xmath139 , for all states @xmath11 and attainable histories @xmath35 .
the same number also bounds @xmath176 for all attainable @xmath35 .    by the lemma ,
any attainable history @xmath35 is an initial segment of a final , attainable history @xmath162 . then @xmath177 .
the bound provided by the bounded work postulate for @xmath178 thus applies to @xmath35 as well .
this proves the first assertion of the corollary , and the second follows because @xmath35 , being attainable , is coherent , which implies @xmath92 .
one of our principal aims in this paper and its sequel @xcite is to show that every algorithm , in the sense defined above , is behaviorally equivalent , in a strong sense , to an asm .
of course , this goal presupposes a precise definition of the notion of behavioral equivalence , and we devote the present section to presenting and justifying that definition . as in earlier work on the asm thesis , beginning in @xcite and continuing in @xcite , the definition of equivalence is intended to express the idea that two algorithms behave the same way in all possible situations .
we must , of course , make precise what is meant by `` behave the same way '' and by `` possible situations . ''
much of what needs to be said here was already said in ( * ? ? ?
* section  6 ) in the more restricted context of ordinary interaction , and we shall refer to some of that discussion in motivating our definition of behavioral equivalence .
part of the definition of equivalence of algorithms is straightforward . as in previous work ,
we require equivalent algorithms to have the same states , the same initial states , the same vocabulary , and the same labels .
the requirement that they agree as to states and initial states is clearly necessary for any comparison at all between their behaviors , specifically the aspect of behavior given by the progression of states in a run .
the requirement that they agree as to vocabulary is actually a consequence of agreement as to states ( and the requirement , in the definition of algorithm , that there be at least one state ) , because any structure determines its vocabulary .
the requirement that they agree as to labels ensures that the algorithms have , in any state , the same potential queries ; this is needed for any comparison between their behaviors , since issuing queries is observable behavior .
the requirements just discussed say that equivalent algorithms agree as to all the items introduced in the states postulate .
it is tempting to go through the remaining postulates , look for statements of the form `` the algorithm determines '' such - and - such , and require equivalent algorithms to have the same such - and - such .
unfortunately , this approach , which in @xcite would produce the correct notion of equivalence , is too restrictive when applied to interactive algorithms in @xcite and the present paper .
the difficulties were already pointed out in ( * ? ? ?
* section  6 ) in connection with the causality relation .
the examples given there exhibit the following two sorts of problems .
first , a causality relation could have instances @xmath84 whose @xmath35 could never actually occur in the execution of the algorithm , for example because @xmath179 contains queries that the algorithm would never issue .
second , as in ( * ? ? ?
* example  6.4 ) , the @xmath35 in an instance @xmath84 of causality could contain redundant elements , such as a query - reply pair that would have to be present in order for another query in @xmath179 to be issued .
algorithms whose causality relations differ only in such irrelevant ways should count as equivalent .
that is , we should care only about what queries the algorithm issues in response to histories that can actually occur when this algorithm runs .
similar comments apply to the remaining ingredients of an algorithm , in which histories are used .
the notions of final , successful , and failing histories and the update sets should not be required to agree completely when two algorithms are equivalent ; it suffices that they agree on those histories that can actually occur .
[ cpt2 ] we emphasize again that we are dealing here with a situation where only the algorithm and its environment are involved .
when several algorithms interact ( and we do not choose to consider each as a part of the environment for the others ) , the situation would be more complex .
consider , for example , two algorithms that function as components in a larger computation .
the first of these components might issue a query whose reply is used by the second .
in that case , instances @xmath84 of the second component s causality relation can be relevant even if that component would never issue the queries in @xmath179 .
some aspects of this situation will arise in @xcite when we discuss the `` do in parallel '' construct of asms ; a thorough discussion will be provided in @xcite .    to formalize the preceding discussion
, we must still say something about the notion of a history that can actually appear .
we have already introduced a precise version of this notion , namely the notion of an attainable history .
this notion , however , depends on the causality relation and the notion of finality given with the algorithm .
when we define equivalence of two algorithms , which one s attainability should we use ?
there are two natural choices : require the algorithms to agree ( as to queries issued , finality , success , failure , and updates ) on those histories that are attainable for both algorithms , or require agreement on all histories that are attainable under at least one of the algorithms .
( there are also some less natural choices , for example to require agreement on the histories attainable under the first of the two algorithms ; this threatens to make equivalence unsymmetric . ) fortunately , these options lead , as we shall prove below , to the same notion of equivalence of algorithms .
having advertised our notion of equivalence as a strong one , we take the apparently stronger of the natural definitions as the official one and then prove its equivalence with the apparently weaker one .    [ equiv - def ] two algorithms are _ behaviorally equivalent _ if    they have the same states ( therefore the same vocabulary ) , the same initial states , and the same labels ,    in each state , they have the same attainable histories ,    for each state @xmath11 and each attainable history @xmath35 , they have the same set @xmath86 ,    for each state , the two algorithms have the same attainable histories in @xmath112 and @xmath113 ( and therefore also in @xmath111 ) .    for each state and each attainable , final , successful history
, they have the same update sets .
the following lemma shows that the notion of equivalence is unchanged if we delete the second item in the definition and weaken the subsequent ones to apply only to histories that are attainable for both algorithms .
[ equiv - la ] suppose two algorithms have the following properties .
they have the same states ( therefore the same vocabulary ) , the same initial states , and the same labels ,    for each state @xmath11 and each history @xmath35 that is attainable for both algorithms , they have the same set @xmath86 ,    for each state , any history that is attainable in both algorithms and is in @xmath112 or @xmath113 for one of the algorithms is also in @xmath112 or @xmath113 , respectively , for the other .    for each state and each history that is attainable for both and final and successful ( for one and therefore both )
, they have the same update sets
.    then these two algorithms are equivalent .    comparing the hypotheses of the lemma with the definition of equivalence
, we see that it suffices to prove that , under the hypotheses of the lemma , any history that is attainable in a state @xmath11 for either algorithm must also be attainable in @xmath11 for the other . indeed , this would directly establish the second clause of the definition , and it would make the subsequent clauses in the definition equivalent to the corresponding hypotheses in the lemma .
let @xmath180 and @xmath181 be two algorithms satisfying the hypotheses of the lemma .
fix a state @xmath11 for the rest of the proof ; we shall suppress explicit mention of @xmath11 in our notations . to prove that @xmath180 and @xmath181 have the same attainable histories , we first recall that any attainable history ( for either algorithm ) has finite domain by corollary  [ bd - dom ] and therefore has finite length
. we can therefore proceed by induction on the length of histories . since the empty history vacuously satisfies the definitions of `` coherent '' and `` attainable '' , we need only verify the induction step .
consider , therefore , a nonempty history @xmath35 that is attainable for @xmath180 .
let the last equivalence class in @xmath179 be @xmath182 and let @xmath76 be the initial segment of @xmath35 obtained by deleting @xmath182 from the domain .
then @xmath76 is attainable for @xmath180 ( because @xmath35 is ) and therefore also for @xmath181 ( by induction hypothesis ) .
furthermore , the linear order of the equivalence classes of @xmath35 , being finite , is certainly a well - ordering .
so to complete the proof that @xmath35 is attainable for @xmath181 , it suffices to verify that it satisfies , with respect to @xmath181 , the first clause in the definition of coherence ( that every @xmath183 is caused by an initial segment that ends before @xmath15 ) and that no proper initial segment of it is final .
for the first of these goals , observe that the induction hypothesis gives what we need if @xmath184 , so we need only deal with the case that @xmath185 . in this case , we know that @xmath186 because @xmath35 is coherent for @xmath180 .
but since @xmath76 is attainable for both algorithms , the second hypothesis of the lemma applies , and we infer that @xmath187 , as required .    for the second goal
, we already know that @xmath76 is attainable for @xmath181 and so none of its proper initial segments can be final .
the only proper initial segment of @xmath35 not covered by this observation is @xmath76 , so it remains only to show that @xmath76 is not final for @xmath181 . since @xmath76 is not final for @xmath180 ( because @xmath35 is attainable for @xmath180 ) and since @xmath76 is attainable for both algorithms , the third hypothesis of the lemma immediately gives the required conclusion .
a referee asked why equivalence of algorithms is not defined in a more usual way , by defining a notion of _ run _ and then defining two algorithms being equivalent if they have the same runs .
the alternative definition of equivalence is possible but it is not simpler
. a run would not be merely a sequence of states as in @xcite ; it would have to include the queries and replies as well .
note also that our definition of equivalence requires that the two algorithms have the same behavior at every state @xmath11 whether @xmath11 is reachable or not .
it is thus independent of the set of initial states . to match this
, the run - based definition of equivalence should allow runs to start at arbitrary states .
we have formally defined the class of interactive small - step algorithms ( definition  [ alg - def ] ) by means of postulates that generalize the postulates of @xcite and @xcite , and we have explained why we believe that this definition matches the intuitive notion of interactive small - step algorithm .
we have also defined a strong notion of behavioral equivalence for such algorithms .
this work provides the essential prerequisites for an analysis of these algorithms in terms of abstract state machines and for the proof of thhe asm thesis in thee small - step interactive case . that analysis and proof will be carried out in @xcite , beginning with the definition of the appropriate class of asms .
nick benton , luca cardelli and cdric fournet , `` modern concurrency abstractions for c # , '' in _ proceedings of the 16th european conference on object - oriented programming ( ecoop 2002 ) .
june 10 - 14 , 2002 university of mlaga , spain _ , b. magnusson , ed .
, springer - verlag , lecture notes in computer science 2374 .
andreas blass , yuri gurevich , dean rosenzweig , and benjamin rossman , `` interactive small - step algorithms ii : abstract state machines and the characterization theorem '' ( tentative title ) , in preparation .
yuri gurevich , `` evolving algebras : an introductory tutorial '' , bull .
eatcs 43 ( feb .
1991 ) , 264284 .
reprinted with slight revisions in _ current trends in theoretical computer science : essays and tutorials _ , eds .
g. rozenberg and a. salomaa world scientific , 1993 , 223394 .
alan m. turing , `` on computable numbers , with an application to the entscheidungsproblem '' , _ proceedings of the london mathematical society _ , series 2 , vol .
42 ( 19361937 ) , 230265 ; correction , _ ibidem _ , vol .
43 , 544546 . reprinted in @xcite and available online at @xmath188