Noether: Symmetry in Programming Language Design

Total Page:16

File Type:pdf, Size:1020Kb

Noether: Symmetry in Programming Language Design Noether: Symmetry in Programming Language Design What problems am I trying to solve with this language? Symmetry Expressiveness Coherence he sublanguages, in order of decreasing symmetry $long the way we%ll tal& brie#ly about how to implement transactions efficiently' (onus slides: )e*ected features How to program gigantic computers? +''' as the power o# available machines grew by a #actor of more than a thousand! society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found [their- job in this exploded #ield of tension between ends and means. he increased power of the har"ware! together with the perhaps even more dramatic increase in its reliability! made solutions #easible that the programmer had not dared to dream about a few years be#ore. And now, a few years later! ,they] had to "ream about them and! even worse! ,they] had to transform such dreams into reality. Is it a wonder that we found ourselves in a software crisis?/ 0 Edsger W. Di*&stra, The Humble Programmer (EWD2345! $C6 uring Lecture 789: How to program gigantic computers? Source: Wi&ime"ia Commons user Wgsimon! license CC (<=S$ 2'4' Data #rom English Wi&ipe"ia: ransistor count' How to program gigantic computers? Historical Cost of Computer Memory and Storage (not inflation-adjusted) Extrapolated US$ for M! Date Source: *cmit'com! © :447! :472 ?ohn C' 6cCallum 1+<ou can use the material here' Please ac&nowle"ge the source'/5 he problem Languages an" tools have improved greatly over that time! but have they improve" enough? The +So#tware Crisis/ is still here: Programs are too large! complex! and "i##icult to maintain' @o=one &nows how to write correct! secure! or reliable programs' @o=one &nows how to review a given program #or correctness, security, an" reliability! with economical e##ort' Correctness! security! an" reliability are three sides o# the same coin' Some techniAues! e'g' pure #unctional programming or (in di##erent ways) ob*ect programming, seem to help' ;ow "o they help? Symmetry Thesis: many programming language techniAues/disciplines help by imposing symmetries, which aid reasoning about programs' $ symmetry gives a set of possible transformations that do not change a given property' In Geometry: translation (e'g' of an in#inite lattice5D rotationD reflection' In Physics: time- and location=invariance in (e.g'5 general relativityD CP symmetry' In Programming (all of these are language=dependent): Confluence: in a pure language! evaluating in "if#erent or"ers pro"uces the same result' 6oving a call o# a pure #unction to a "if#erent time, or tas&! "oes not change its result' )eflexive/symmetric/associative operators and #unctions' $lpha renaming' $""ing an" removing parallelism annotationsD maybe other annotations' Expansion and abstraction o# E#unctions! macros! mo"ules! type synonyms! '''F' Common subexpression elimination. $""ing an" removing staging' rait #lattening' )epresentation changes' $""ing an" removing "ead co"e. Comments and #ormatting' Inter#ering features Many programming language featuresBproperties interfere with symmetries we'd li&e to have' Some are essential features: Side effectsD localBtas& state Hailure handling Concurrency Some are not: Dynamic scoping Iverloading Implicit coercion Introspection (stac&! local variables! function code, objects! .''5 +Jnhygienic/ or textual macros $nything that violates memory safety $nything that violates Actor locality Colliding namespaces Clobal stateD modes (e'g' floating point modeBstate) $ design wart in a feature (e'g' module or macro system5 can stop it having desired symmetries' With care, similar or better expressiveness can be achieved without problematic features! or with restricted variations on them''' but what do we do about the essential ones? Symmetry “breaking/ We want the strongest symmetries possible #or any given expressiveness' Solution: strati#ied languages' @ot a new idea (e'g' Erlang! Oz! Haskell5! but Noether ta&es it #urther' $t each level, we a"" one or more #eatures an" brea& a symmetry. Some symmetries are so use#ul that they should be preserved globally 1#or example: memory sa#ety and Actor locality laws5' ThereGs a tra"e=o## between optimizing the symmetry=expressiveness pro#ile! and &eeping the number o# levels small to reduce complexity. If we start by "esigning with one level per bro&en symmetry, we can always collapse levels together later. The sublanguages don't have to be neste"! but we ma&e them nested: #or simplicity o# understan"ing an" teaching the #ull languageD #or simplicity o# in#erring which sublanguage weGre in and conveying that to the programmerD to ma&e the design problem of which #eatures depend on others tractable' We coul" relax this constraint i# it was important, but havenGt nee"e" to #or Noether' Coherence Getting strong symmetries when a whole program is in a small sublanguage isnGt enough' @ontrivial programs are inten"e" to be a mixture o# subprograms at "i##erent levels' We need to &now whether symmetry properties are maintained when mixing levels' $nother physical analogy: Sublanguage with strong symmetries ⬄ highly ordered phase of matter! e.g' a solid' Sublanguage with weaker symmetries ⬄ less ordered phase of matter! e.g' a fluid. $ material is coherent if it maintains its phase when moved within a less ordered phase' Example: most solids maintain their phase and shape when moved in a fluid''' L unless! say, the fluid corrodes the solid. $ sublanguage is coherent if code in that sublanguage maintains its symmetry properties when used anywhere within a larger language' Example: a pure function can be executed anywhere in an impure program without losing symmetry (confluence within the function! determinism! etc'5''' L unless! say, the impure language has reflective features that break opaqueness of pure functions' Noether programming language Ibject=capability, type", parallel and concurrent! potentially highly optimizable' Strati#ied sublanguages of increasing expressiveness and "ecreasing symmetry. This tal& consi"ers mainly semantics rather than syntax' Why a new language? #ewer constraints on optimizing symmetryMexpressiveness profile' existing languages have features (e'g' exception handling! concurrency5 that we want to specify an" combine in different ways' address previously unsolved or solved-only-as=research problems: precise resource control! partial failure, flow control in asynchronous message passing! etc' security + expressiveness + speed is already very har"D adding a requirement for compatibility with some existing language would make it impossible. ( he problem is running existing programs with expected performance'5 compatibility is overrated; familiarity is more important. +a language really defines its own universe, and that a language designer has the power to control what can or cannot happen within that universe./ M Tom Van Cutsem Programming language design is fun! Emmy Noether 6athematician an" theoretical physicist! ?ewish, expelle" #rom @azi Germany in 7822' Einstein in 782P: +In the *u"gement of the most competent living mathematicians, HrQulein @oether was the most signi#icant creative mathematical genius thus #ar produce" since the higher e"ucation o# women began' In the realm of algebra! in which the most gi#te" mathematicians have been busy #or centuries, she "iscovere" metho"s which have prove" of importance in the "evelopment o# the present="ay younger generations of mathematicians. Pure mathematics is, in its way! the poetry of logical i"eas' Ine seeks the most general ideas o# operation which will bring together in simple, logical and uni#ied #orm the largest possible circle o# #ormal relations' In this e##ort toward logical beauty spiritual #ormulas are "iscovere" necessary #or the "eeper presentation into the laws of nature'/ $ppropriate #or Noether-0 because it can be viewe" as a @oetherian 1terminating) rewriting system. Some o# Emmy @oether%s other work on abstract algebra is in"irectly relevant! an" we can use analogies with physical symmetry properties to explain the language' ;ard to believe this name hasn%t already been snapped up #or a programming language. (Google says not5 Symmetry properties (ecause Noether is in general nondeterministic ! we nee" to be particularly careful in how we "efine properties such as referential transparency! confluence, etc' We mo"el evaluation as a rewriting system 1�! ⊳5! where � is a set o# terms an" ⊳ is an irreflexive binary relation on �' Hor Noether! let � R � ∪ � ∪ � ∪ E ⊥ F! where � is the set o# reducible terms 1i.e. that can be rewritten by ⊳5! � is the set o# #ailure terms! � the set o# success terms! and ⊥ a special term "enoting nontermination. Each #ailure term is associated with a reason which is always a success term' $ Noether term other than ⊥ can be represented as a program #ragment and a +store/! which maps locations to other program #ragments' @otation: T is terminating under ⊳! written T stops! iff there are no infinite ⊳-chains starting from T' When this is true for all T in �! (�, ⊳5 is noetherian' → ≝ ⊵S ↔ ≝ 1⊴ ∪ ⊵5S T ⇥ U ≝ T → U ∧ U ∉ � [U is a normal form o# T- T⤓ ≝ { U : T ⇥ U }! i# T stops ≝ { U : T ⇥ U } ∪ { ⊥ F! otherwise T fails ≝ T⤓ ⊆ � S ≋ T ≝ S⤓ = T⤓ T ⤞ U ≝ T⤓ \ � = { U } Symmetry properties hese symmetries always hold: $dding unused bin"ings to a store $lpha-renaming of locations $lpha-renaming of bound variables Other definitions relating to pure functional languages: hurch-!osser: S ↔ T ⇒ ∃ U 1 S → U ∧ T → U ) Fail-stop deterministic: U T⤓ \ � | ≤ 1 Fail-stop definite: T stops ∧ | T⤓ \ � | ≤ 1 StracheyGs definition of referential transparency: “if we wish to find the value of an expression which contains a sub-expression! the only thing we need to know about the sub-expression is its value./ his is a bit unsatisfactoryD see ,SVndergaar" and Sestoft 1984- for details' !eferential transparency: S ≋ T ⊢ # ,S- ≋ # ,T- 1if two expressions are equivalent, substituting them at the same point in a containing expression preserves eAuivalence)' Unfoldability: de# f 1 x 5 = # ,x- ⊢ S ≋ T ⇒ # ( S ) ≋ # ,T- Noether-0 is Church=)osser! fail=stop definite! referentially transparent, and unfoldable.
Recommended publications
  • A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)
    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop­ ment of the algorithmic language ALGOL. Nevertheless, it seems perti­ nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text.
    [Show full text]
  • Individual Mechanical Stimulation
    Durham E-Theses Investigations into the structure and function of nerve and skeletal muscle of anisoptebous odonata, with special reference to aeschnid nymphs Malpus, C. M. How to cite: Malpus, C. M. (1968) Investigations into the structure and function of nerve and skeletal muscle of anisoptebous odonata, with special reference to aeschnid nymphs, Durham theses, Durham University. Available at Durham E-Theses Online: http://etheses.dur.ac.uk/8803/ Use policy The full-text may be used and/or reproduced, and given to third parties in any format or medium, without prior permission or charge, for personal research or study, educational, or not-for-prot purposes provided that: • a full bibliographic reference is made to the original source • a link is made to the metadata record in Durham E-Theses • the full-text is not changed in any way The full-text must not be sold in any format or medium without the formal permission of the copyright holders. Please consult the full Durham E-Theses policy for further details. Academic Support Oce, Durham University, University Oce, Old Elvet, Durham DH1 3HP e-mail: [email protected] Tel: +44 0191 334 6107 http://etheses.dur.ac.uk 2 INVESTIGATIONS. INTO THE STRUCTURE AND FUNCTION OF NERVE. AND SKELETAL. MUSCLE OF ANISOPTEHOUS ODONATA, WITH SPECIAL REFERENCE TO AESCHNID NYMPHS by C. MV MALPUS, B.SC.. (Dunelm) GREY: COLLEGE:. Being a thesis presented in candidature for the degree of Doctor of Philosophy of the University of Durham. January 1968 PUBLICATION A preliminary report of some of this work, comprising the subject matter of Chapter k and part of Chapter 7, has been published under the title of "Electrical and Mechanical Responses of the skeletal muscle of a primitive insect"' in Nature 215, 991 - 992.
    [Show full text]
  • The Structure and Stability of Simple Tri-Iodides
    THE STRUCTURE AND STABILITY OF SIMPLE TRI -IODIDES by ANTHONY JOHN THOMPSON FINNEY B.Sc.(Hons.) submitted in fulfilment of the requirements for the Degree of Doctor of Philosophy UNIVERSITY OF TASMANIA HOBART OCTOBER, 1973 . r " • f (i) Frontispiece (reproduced as Plate 6 - 1, Chapter 1) - two views of a large single crystal of KI 3 .H20. The dimensions of this specimen were approximately 3.0 cm x 1.5 cm x 0.5 cm. • - - . ;or • - This thesis contains no material which has been accepted for the award of any other degree or diploma in any University, and to the best of my knowledge and belief, this thesis contains no copy or paraphrase of material previously published or written by another person, except where reference is made in the text of this thesis. Anthony John Finney Contents page Abstract (iv) Acknowledgements (vii) Chapter 1 - The Structure and Stability of Simple 1 Tri-iodides Chapter 2 - The Theoretical Basis of X-Ray Structural 32 Analysis Chapter 3 - The Crystallographic Program Suite 50 Chapter 4 - The Refinement of the Structure of NH I 94 4 3 Chapter 5 - The Solution of the Structure of RbI 115 3 Chapter 6 - The Solution of the Structure of KI 3 .1120 135 Chapter 7 Discussion of the Inter-relation of 201 Structure and Stability Bibliography 255 Appendix A - Programming Details 267 Appendix B - Density Determinations 286 Appendix C - Derivation of the Unit Cell Constants of 292 KI .H 0 3 2 Appendix D - I -3 force constant Calculation 299 Appendix E - Publications 311 ( iv) THE STRUCTURE AND STABILITY OF SIMPLE TRI-IODIDES Abstract In this work the simple tri-iodides are regarded as being those in which the crystal lattice contains only cations, tri-iodide anions and possibly solvate molecules.
    [Show full text]
  • 6Th Jan. 2016. Catalogue F, for Box-Files F1
    Version 1: 6 th Jan. 2016. Catalogue F, for box-files F1 – F9. Scope: all the technical reports, scientific journal papers and equipment/software manuals that exist in paper form (originals or photocopies of originals) for the following Elliott analogue and digital computers: Nicholas, 401, 402, 403 (WREDAC), (404), 405, 802, 803, 503. Also, documents relevant to Automation, Industrial Process Control, ARCH & analogue computers. (For much more on these automation topics, and for extra data on Nicholas, 401 and ARCH, see CatV1). Box- Date Description Comment file ID F1 March Elliott Journal, vol. 1, no. Quarto, buff, 36 pages including a foreword by Sir Ben 1951 1, March 1951. Lockspeiser and two pages of Elliott adverts. Only five issues of this House Journal (as listed here) were produced. Two have buff covers, three have light grey covers. This first issue has a short typed note, sent by John Bunt in about 2001 to SHL, explaining that ‘George Olah was Dr Ross’s brother-in-law’. This first issue contains the following research papers: (a) 150 years of instrument making, (Anon); (b) Magnetic amplifiers and their application to industrial purposes,(H M Gale). (c) Pulsed circuits for resistance strain gauges, (J G Yates). (d) Application of the force-balance principle to pneumatic instruments for process control, (D T Broadbent). (e) A photo-electric curve follower, (K L Selig). (f) Precision alternating current measurement with a DC/AC comparator, (G F Shotter & H D Hawkes). (g) A phase front plotte for testing microwave aerials, (C A Cochrane) (h) A precision sine-cosine potentiometer, (W H Pearse).
    [Show full text]
  • Professor Sir Tony Hoare Interviewed by Dr
    IN PARTNERSHIP WITH NATIONAL LIFE STORIES AN ORAL HISTORY OF BRITISH SCIENCE Professor Sir Tony Hoare Interviewed by Dr Thomas Lean C1379/52 © The British Library Board http://sounds.bl.uk This interview and transcript is accessible via http://sounds.bl.uk . © The British Library Board. Please refer to the Oral History curators at the British Library prior to any publication or broadcast from this document. Oral History The British Library 96 Euston Road London NW1 2DB United Kingdom +44 (0)20 7412 7404 [email protected] Every effort is made to ensure the accuracy of this transcript, however no transcript is an exact translation of the spoken word, and this document is intended to be a guide to the original recording, not replace it. Should you find any errors please inform the Oral History curators. © The British Library Board http://sounds.bl.uk The British Library National Life Stories Interview Summary Sheet Title Page Ref no: C1379/52 Collection title: An Oral History of British Science Interviewee’s Hoare Title: Professor Sir surname: Interviewee’s Tony Sex: Male forename: (Charles Anthony Richard) Occupation: Computer scientist Date and place of birth: Mother’s Father’s occupation: Colonial civil servant occupation: Dates of recording, Compact flash cards used, tracks (from – to): 17/05/2011 (1-3), 08/09/2011 (4-6), 12/10/2011 (7-8), 12/12/2011 (9-10), 09/01/2012 (11- 13),27/02/2012 (14-15) Location of Interviewee’s home, Cambridge. interview: Name of Thomas Lean interviewer: Type of recorder: Marantz PMD661 on secure digital Recording format : WAV 24 bit 48 kHz Total no.
    [Show full text]
  • 07. 1957-2007: 50 Years of Higher Order Programming Languages
    JIOS, V OL . 33, N O. 1 (2009) SUBMITTED 10/08; A CCEPTED 02/09 UDC 004.432 Review Paper 1957-2007: 50 Years of Higher Order Programming Languages Alen Lovren ciˇ c´ [email protected] University of Zagreb Faculty of Organization and Informatics Mario Konecki [email protected] University of Zagreb Faculty of Organization and Informatics Tihomir Orehova ckiˇ [email protected] University of Zagreb Faculty of Organization and Informatics Abstract Fifty years ago one of the greatest breakthroughs in computer programming and in the history of computers happened – the appearance of FORTRAN, the first higher-order programming lan- guage. From that time until now hundreds of programming languages were invented, different programming paradigms were defined, all with the main goal to make computer programming easier and closer to as many people as possible. Many battles were fought among scientists as well as among developers around concepts of programming, programming languages and paradigms. It can be said that programming paradigms and programming languages were very often a trigger for many changes and improvements in computer science as well as in computer industry. Definitely, computer programming is one of the cornerstones of computer science. Today there are many tools that give a help in the process of programming, but there is still a programming tasks that can be solved only manually. Therefore, programming is still one of the most creative parts of interaction with computers. Programmers should chose programming language in accordance to task they have to solve, but very often, they chose it in accordance to their personal preferences, their beliefs and many other subjective reasons.
    [Show full text]
  • 503 Ultra High Speed Digital Computer for Science and Industry
    DIGITAL COMPUTER FOR SCIENCE AND INDUSTRY ELLIOTT 503 ULTRA HIGH SPEED DIGITAL COMPUTER FOR SCIENCE AND INDUSTRY zomputer ever produced. Yet the 503 is about one hundred times faster than this machine and costs less than twice as much! Elliott Brothers have developed the 503 to meet the demand for computers operating at much higher speeds than hitherto without a corresponding in- crease in cost. This computer will revolutionise the economics of computer usage in several ways The 503 is a general purpose computer of great speed and flexibility, intended mainly for the solu- (i) it will handle problems which were formerly tion of technical problems arising in science and more cheaply solved by manual methods. industry. It is essentially straightforward in design, but so exceptionally fast that high problem-solving (ii) it will provide computing facilities for organi- speeds are obtained. sations with a large number of individual users. Due to the high speed of the computer, and the simplified The computer incorporates many features unique programming and operating methods being de- among medium-sized data processing systems veloped, owners of 503 can run as many as zoo * ~oo,oooarithmetic operations per second. different programmes each day. * Large magnetic core store. (iii) it will tackle the most complex problems * Time-sharing ofperipheral data-transfers. arising in science and industry, formerly beyond the * Fixed andjoating point arithmetic. scope of small or medium-sized computers. * Direct connection of high-speed input and output equipment. As an illustration of the advance on currently * Compatibility with well-known 803 computer. available computers which the 503 represents, it is interesting to compare it with the 803.
    [Show full text]
  • Hints on Programming- Language Design
    THIRTEEN Hints on programming- language design This paper originated from Hoare's keynote address at the ACM SIGPLAN conference in Boston, October 1973 (although it did not appear in the proceedings, it was distributed at the conference). It was subsequently printed as a Stanford Artificial Intelligence Memo (AIM-224, STAN-CS-73-403) in December of that year. The version printed here was published as [43]. Hoare was active in committees working on the design and control of programming languages over many years: he made many contributions to the ALGOL Bulletin (e.g. [13]), was a member of IFIP's WG 2.1 (1962-74) and even chaired the ECMA TC10 group working on the standardization of PL/I. This paper is perhaps the most rounded of his published comments on language-design philosophy. The earlier [25] makes more pointed references (including a very positive one to APL); [40] and [57] make further points. This paper must clearly be read in the context of its date of composition (1973). The relative weight of comment on debugging and reasoning about programs clearly changed as a result of his own later research. Also, a richer notion of types would be appropriate today. But the sound advice in this paper transcends any minor aspects in which it might be considered to be out of date. (Many versions exist of the story about the Mariner I Venus probe. All of them blame software; they differ as to the precise details.) Subsequent to this publication, Hoare and Wirth consulted for SRI on their 'Yellow' language response to the 'Tinman' requirements.
    [Show full text]
  • IBM Corporation 3223 Wilshire Boulevard Santa Monica, California 90406
    277-4287 November 15, 1966 '.I'HE EVOLUTION OF COMPLIERS A paper covering the evolution of compliers, with emphasis on techniques for machine independent languages including Polish notation, operations for handling. strings, use of pushdowns, and scanning techniques. Introductions to the topics of re­ cursive subroutines, ALGOL, JOVIAL, SNOBOL, XTRAN, and the heuristic complier is given. An extensive Bibliography is Miss Marilyn M. Jensen included. IBM Corporation 3223 Wilshire Boulevard Santa Monica, California 90406 N "I "~ I'\) For IBM Internal Use Only CX> " IBM Cor/Jortttion. Technical Publications Dept., 112 E. Post Rciad. lf'/hite Plain.;. _\!. Y. 10601 TABLE OF CONTENTS IV. SYMBOL MANIPULATNE COMPILERS .•••.. Page 75 A. ALGOL............................. Page 76 I. INTRODUCTION.........................•.. Page 1 B. JOVIAL. Page 82 II. XTRAN.................................... Page 4 c. SNOBOL.. • . Page 89 A. INTRODUCTION....................... Page 5 D. NELIAC ..................•...•..•... Page 93 B. PUSHDOWN STACKS. Page 8 v. BIBLIOGRAPHY ..•.•......•...•.•....•.•.•. Page 94 c. STRING AND SYMBOL MANIPULATION Page 12 A. SUGGESTED READINGS .•............. Page 95 D. LANGUAGE 1. Page 18 B. REFERENG ES ..........•..•.•......•. Page 110 E. LANGUAGE 2 ..............•..•...•.. Page 26 F. ALGORITHMS FOR POLISH NOTATION Page 32 G. LANGUAGE AMBIGUITY ......•....•.. Page 34 H. COMPILER LOGIC. Page 44 I. SWITCH METHOD/SINGLE ADDRESS OUTPUT............................ Page 50 J. FORGING CODES AND ROUTINES. • Page 52 K. BACKUS NORMAL FORM .............. Page 62 III. HUERISTIC COMPILERS ...............•.... Page 63 A. INTRODUCTION. Page 64 B. INFORMATION PROCESSING LANGUAGE-V ........................ Page 67 G. GOMIT ......................•........ Page 70 D. SAINT .......•........................ Page 71 E. GIT ................................•. Page 72 F. LINE BALANCING.................... Page 73 INTRODUCTION Such languages facilitate storage allocation and give complete freedom for development and use of recursive subroutines.
    [Show full text]
  • NPL, ~Hgl~Nd M
    -3- During the Symposium in Rome from March 26th to 31st prof. van der Poel asked the present editor to accept the responsibility of the secre- tary of the Working Group. To this I answered that this I would accept provided that I might expect the basic support of some of the more influ- ential workers in the field, particularly professors F.L. Bauer and K. Samelson (both members of the original ALGOL comnittee, initiators of the ALCOR Grouo, prof. Bauer is the DARA representative to IFIP Tech. Comm. 2.). Prof. van der Poel consented in this condition and kindly accepted to put the question forward to professors Bauer and Samelson. The result of this mission was a flat refusal on their part to support me on the grounds that in their view the questionaire of AB 14 is biased. In view of these developments it is clear that the responsible bo- dies of IFIP, in establishing the Working Group, deliberately have chosen to ignore the existence of the ALGOL Bulletin and the information and o- pinions expressed in it. It is further clear that the attempt on the part of prof. van der Poelat establishing a working collaboration between the Working Group and the AB in an informal manner meets with an opposition which would make this collaboration ineffective in practise. Now, in en- couraging the ALGOL community to mske use of the ALGOL Bulletin for ex- pressing their views the editor must feel convinced that the views con- tained therein will indeed be taken properly into account when official action is taken.
    [Show full text]
  • Algol 60 Compilation and Assessment
    Algol 60 Compilation and Assessment B. A. Wichmann August 1973 ii Preface The ease and effectiveness of computer utilisation depend very heavily on the quality of the implementation of the programming language used. This book is dedicated to raising the quality of ALGOL 60 implementations. It gives an objective comparative assessment of over twenty existing compilers in accordance with numerical and non- numerical criteria, and describes in greater detail the techniques which contribute to high quality. The book is required reading for any programmer embarking on an implementa- tion of ALGOL 60; and is equally valuable for implementors of many subsequently designed languages. For users of ALGOL 60, it will not only assist in the selection of a high quality compiler, but it also shows how to use an existing compiler more effectively. Finally, for all designers and users of programming languages and other software, it gives an example of how the quality of software may be objectively de- fined and assessed. The first chapter considers the compilation of the more straightforward aspects of ALGOL, by using an illustrative one-address computer. It is clear that most inter- comparisons must depend upon statistical information of the use of ALGOL 60 and this is presented and analysed in chapter 2 to make it useful for performance assessment. These statistical data also give guide lines on the construction of efficient algorithms, which are detailed in chapter 3. The problem of syntax analysis of ALGOL 60 source text is not considered in de- tail, as this is handled very ably elsewhere. However, some difficulties are enumerated in chapter 4, since a few existing compilers are known to handle these matters incor- rectly.
    [Show full text]
  • Hints on Programming Language Design
    . 7--- _ _.--_ -I l STANFORD ARTIFICIAL INTELLIGENCE LABORATORY ‘ MEMO AIM-224 ‘STAN-CS-73-403 ’ . -- ‘,- _ .- _ ’ _” HINTS ON PROGRAMMING LANGUAGE DESIGN BY C. A. R. HOARE -= SUPPORTED BY ADVANCED RESEARCH PROJECTS AGENCY . ARPA ORDER NO. 24~4 PROJECT CODE 3D30 DECEMBER 1973 --- __ .-_ .-- COMPUTER SCIENCE DEPARTMENT / SC hool of Humanities and Scrences ANFORD UNIVERSITY 3 h. STANFORD ARTIFICIAL INTELLIGENCE LABORATORY OCTOBER 1973 MEMO AIM 224 L COMPUTER SCIENCE DEPARTMENT REPORT NO. CS-403 HINTS ON PROGRAMMING LANGUAGE DESIGN . C. A. R. Hoarey ABSTRACT: This paper (Based on a keynote address presented at the SIGACT/SIGPLAN c Symposium on Principles of Programming Languages, Boston, October 1-3, 1973) presents the view that a programming language is a tool which should assist the programmer in the most difficult aspects of his art, namely program design, documentation, and debugging. It discusses the objective c criteria for evaluating a language design, and illustrates them by application to language features of both high level languages and machine code programming. It concludes with an annotated reading list, recommended for all intending language designers. c c y On leave of absence from the Queen's University of‘ Belfast. The work on this paper was supported in part by the National Science Foundation under grant number GJ 36473X and by ARPA Research Contract DAHC lj-73-C-0435. The views expressed are those of the author. b Introduction I would like in this paper to present a philosophy of the design and evaluation of programming languages which I have adopted and developed over a number of years, namely that the primary purpose of a programming language is to help the programmer in the practice of his (c art.
    [Show full text]