Milne, R., Strachey, C.: A Theory of Programming Language Semantics. Halsted Press, New York, NY, USA (1977)  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of various programming languages. The seminal paper on denotational semantics is [Scot71] Other introductory papers including useful bibliography are [Tenn76] and [Moss90] Introductory books presenting in more depth the underlying theory and the techniques that have been developed include [Miln76], Stoy77] Gord79] Alli86] and [Schm86] An graduate level book with more mathematical depth is [Gunt92] This thesis was strongly influenced by [Tenn91] an excellent book revealing the connections between syntax and the various flavours of semantics. The same is accomplished by [Mitc96] ....

R. E. Milne and C. Stachey, A Theory of Programming Language Semantics, Chapman and Hall, London, UK, 1976.

....free P. No = else Representation Independence bool true;P ( x, x) int 1;P( x 0,x x) Game Semantics of Imperative Languages using Regular Expressions . Milne Strachey marked store models. These can fail to validate garbage collection [2]. Functor category models handle locality well. representation independence. Snapback remains problematic [6, 5] object spaces handle snapback too. Full abstraction up to order 2 via the Yoneda embedding [8, 4] reasoning [7] semantics: full Semantics of ....

....handle snapback too. Full abstraction up to order 2 via the Yoneda embedding [8, 4] reasoning [7] semantics: full Semantics of Imperative Languages using Regular Expressions . Milne Strachey marked store models. These can fail to validate garbage collection [2]. models handle locality well. Parametricity constraints can be added to handle representation independence. Snapback remains problematic [6, 5] object spaces handle snapback too. Full abstraction up to order 2 via the Yoneda embedding [8, 4] reasoning ....

[Article contains additional citation context not shown here]

R.E. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, 1976.

....Records are also useful for more specific discussions of inheritance in object oriented languages, because they are a good representation for objects. A record is a finite mapping from labels to values [6] The record concept as used here is essentially equivalent to modules [2] environments [18], labeled products, etc. However, a record may simply be viewed as a collection of named attributes. A field name that lacks a value is assumed to be mapped to the undefined value #. The association of a label to a value is called a component of the record. A record with labels x 1 , x n ....

R. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....veri cation (step 1) and compiler implementation veri cation (steps 2 and 3) Compiling veri cation is part of theoretical informatics and program semantics and work on it has been started by J. McCarthy and J.A. Painter in 1967 [29] Proof styles are operational [29, 4] or denotational [30] depending on how source language semantics is de ned. If a source language has loops or (function) procedures, then term rewriting or copy rule semantics is employed throughout [28] Other operational styles split in natural [34] or structural [37] operational or state machine like [20] ....

....then term rewriting or copy rule semantics is employed throughout [28] Other operational styles split in natural [34] or structural [37] operational or state machine like [20] Denotational semantics has started with D. Scott s work [41] and typical compiling correctness proofs can be found in [30]. The authors in [22, 32, 33] use an algebraic denotational style for clearer modular proofs, based on state transformations resp. predicate transformers. Mechanical proofs are often based on interpreter semantics, a further variant of the operational style, and sometimes include high level ....

R. Milne and Ch. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....veri cation (step 1) and compiler implementation veri cation (steps 2 and 3) 17 Compiling veri cation is part of theoretical informatics and program semantics and work on it has been started by J. McCarthy and J.A. Painter in 1967 [46] Proof styles are operational [46, 5, 6] or denotational [47] depending on how source language semantics is de ned. If a source language has loops or (function) procedures, then term rewriting or copy rule semantics is employed throughout [42, 45] Other operational styles split in natural [55] or structural [58] operational or state machinelike [32, ....

....or copy rule semantics is employed throughout [42, 45] Other operational styles split in natural [55] or structural [58] operational or state machinelike [32, 33] Denotational semantics has started with D. Scott s work [65, 64] and typical compiling correctness proofs can be found in [47]. The authors in [37, 63, 50, 51] use an algebraic denotational style for clearer modular proofs, based on state transformations resp. predicate transformers. Mechanical proofs are often based on interpreter semantics, a further variant of the operational style [67] and sometimes include high ....

R. Milne and Ch. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....(step 1) and compiler implementation veri cation (steps 2 and 3) Compiling veri cation is part of theoretical informatics and program semantics and work on it has been started by J. McCarthy and J.A. Painter in 1967 [MP67] Proof styles are operational [MP67, BR92, BS98] or denotational [MS76] depending on how source language semantics is de ned. If a source language has loops or (function) procedures, then term rewriting or copy rule semantics is employed throughout [Lan73, LS87] Other operational styles split in natural [NN92] or structural [Plo81] operational or ....

....semantics is employed throughout [Lan73, LS87] Other operational styles split in natural [NN92] or structural [Plo81] operational or state machine like [Gur91, Gur95] Denotational semantics has started with D. Scott s work [Sco70, SS71] and typical compiling correctness proofs can be found in [MS76] The authors in [HJS93, Sam93, MO97, MOW00] use an algebraic denotational style for clearer modular proofs, based on state transformations resp. predicate transformers. Mechanical proofs are often based on interpreter semantics, a further variant of the operational style [Sto77] and sometimes ....

R. Milne and Ch. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....possibly of higher order type, can appear within the bodies of such declaration blocks, there are serious difficulties. The aim of this expository paper is to survey recent progress on this problem, especially work using categorical methods. The traditional denotational semantic approach [9, 19, 18] is to assume a denumerable set L of locations (abstract storage addresses) and construct a set of states (also known as stores ) along the following lines: S = L (V funusedg) where V is the set of storable values. For simplicity, we will assume there is a single type of storable ....

....of Canada. effect of a variable declaration is to bind the declared variable identifier to any currently unused location for the execution of the block body. This kind of interpretation of local variables is adequate to show the correctness of the usual style of implementation of block structure [9]; however, many authors [3, 16, 13, 5, 14, 2, 8] have criticized it as being insufficiently abstract. For example, consider the simple equivalence new . 0; C j C ; when identifier is not free in command C. The equivalence is a consequence of the inaccessibility of the new location to ....

[Article contains additional citation context not shown here]

R. E. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, and Wiley, New York, 1976.

....Later on an obvious semantics will be given to it. The graph representation of P : 1; 2; 3; I 1 [1; 2; 3; I 2 S add r X cons O 2.2. Denotational Semantics We assume that the reader is acquainted with the basic theory of Complete Partial Order Sets (see [LoS84, MiS76, ScB69, Sco70, Sto77]) In order to give denotational semantics for ST languages, we first need some definitions: Let D be a flat domain. i.e. D is a set which is equipped with a partial order , so that it contains a least element , and all its other elements are incomparable) Denote by Omega D the set of all ....

Milne R. and Strachey C.: A Theory of Programming Language Semantics. Chaprmand and Hall, 1976.

....generally simple programs (probably making use of a library of algorithms verified by other methods. Semantics also concerns itself with other questions, which are harder to formulate in the other methods. Denotational semantics was originally intended as a way of formally specifying languages [MS76], in terms of more or less familiar and useful mathematics. Denotational semantics can also guide language design in certain directions, exposing constructs as questionable or incompatible, and occasionally suggesting new constructs. For example, it is impossible to write a procedure taking two ....

Milne and Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....that would yield the above diagram with A Theta B instead of C and with D instead of C. In this section we compare this categorical generalization with three forms of logical relations that have already appeared in the literature, Kripke logical relations [Plo80, MM91] cpo logical relations [MS76, Rey74, CP92], and the relational setting over PER models discussed in Section 4 of [BFS90] Kripke logical relations over ordinary Henkin models were first used in [Plo80] in a characterization of lambda definability. Kripke logical relations were then adapted to Kripke lambda models in [MM91] Inductive ....

R.E. Milne and C. Strachey. A theory of programming language semantics. Chapman and Hall, London, and Wiley, New York, 1976. 24

....Science, Centre of the Danish National Research Foundation. ## Ny Munkegade, Building 540, DK 8000 Aarhus C, Denmark. E mail: danvy, jrvest brics.dk 1 Introduction 1. 1 Denotational semantics and semantics implementation systems Twenty years ago, when denotational semantics was developed [23, 37], there were high hopes for it to be used to specify most, if not all programming languages. When Mosses developed his Semantics Implementation System [25] it was with the explicit goal of generating compilers from denotational specifications. Time passed, and these hopes did not materialize as ....

....reflecting the traditional call return strategy of Algol 60 [30] but is otherwise completely straightforward. 3 3 Being stack based is of course not a requirement. An unstructured store would also need to be threaded throughout, but its implementation would require a garbage collector [23]. We specialize it and obtain three address code that is comparable to what can be expected from a compiler implemented e.g. according to the Dragon Book [1] This experiment is significant for the following reasons: Semantics implementation systems: Our source language is realistic. Our ....

Robert E. Milne and Christopher Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, and John Wiley, New York, 1976.

....gives rise to an occurrence property over let parameters that can be exploited to specify a stack based abstract machine for A normal forms. Doubtlessly it would be interesting to recast this work in a categorical setting, but that is not our point here. 8 Related work Since Milne and Strachey [19], virtually everybody uses a control stack for continuation parameters. Exceptions include Appel, who uses the heap as his unique memory resource [2] CPS compiler writers have not been without noticing that the free variables of the continuation could naturally be implemented with the ....

Robert E. Milne and Christopher Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, and John Wiley, New York, 1976.

....are equal if their meanings are equal. Then we can perform mechanical simplification and abstraction or at least prove the validity of our manual simplifications and abstractions. This parallels the use of formal semantics in conventional programming languages, as discussed in say 116 [7]. We also want our language to be high level. We could certainly consider Generalised Semi Markov Processes (GSMPs) as a semantics for simulation. But a GSMP description is very far from any current notion of system specification. Given a system of any complexity it is very hard to see that a GSMP ....

R.E. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

....parts of Verdi would be implemented. The present work complements the model theory by presenting an alternative definition of the semantics of the executable portion of Verdi, with a proof of correspondence between the new semantics and the old. The new semantic definition is denotational in style [4, 13, 14]. I tried as much as possible, within the other constraints of the project, to adopt the so called standard style of definition. However, I avoided many of the usual typographical and notational conventions, as these were inconsistent with the existing model theory. Since the bulk of this report ....

....to a true operational definition appears to be too great to bridge in one step. Instead, this new denotational definition can be considered as the first of possibly several steps required to relate the very abstract model theory with a very concrete operational semantics. Milne and Strachey, in [4], use six steps to run from a standard semantics to an operational semantics of an ALGOL 68 like language. The distinction between an operational and a denotational definition is not as great as it may seem. In general, operational definitions define some kind of an interpreter that executes a ....

R. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

No context found.

Milne, R., Strachey, C.: A Theory of Programming Language Semantics. Halsted Press, New York, NY, USA (1977)

No context found.

Milne, R., Strachey, C.: A Theory of Programming Language Semantics. Halsted Press, New York, NY, USA (1977)

No context found.

Robert E. Milne and Christopher Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, and John Wiley, New York, 1976.

No context found.

Robert Milne and Christopher Strachey, A Theory of Programming Language Semantics, London: Chapman & Hall, 1976.

No context found.

R. Milne and C. Strachey. A theory of programming language semantics. Chapman and Hall, 1976.

No context found.

R. E. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, 1976.

No context found.

R. Milne and Christopher Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, 1976. Also Wiley, New York.

No context found.

R. E. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman and Hall, London, 1976.

No context found.

Milne, R. and Strachey, Christopher. A Theory of Programming Language Semantics. Chapman and Hall, London (1976). Also Wiley, New York.

No context found.

Milne, R., Strachey, C.: A Theory of Programming Language Semantics. Chapman Hall, two volumes (1976)

No context found.

R. Milne and C. Strachey. A Theory of Programming Language Semantics. Chapman & Hall Ltd., 1976.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC