DOCSLIB.ORG

The Bedrock Structured Programming System: Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Bedrock Structured Programming System: Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier The bedrock structured programming system: combining generative metaprogramming and hoare logic in an extensible program verifier The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Adam Chlipala. 2013. The bedrock structured programming system: combining generative metaprogramming and hoare logic in an extensible program verifier. SIGPLAN Not. 48, 9 (September 2013), 391-402. As Published http://dx.doi.org/10.1145/2500365.2500592 Publisher Association for Computing Machinery (ACM) Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/86042 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ The Bedrock Structured Programming System Combining Generative Metaprogramming and Hoare Logic in an Extensible Program Verifier Adam Chlipala MIT CSAIL [email protected] Abstract pend on. Examples include operating systems and runtime systems, We report on the design and implementation of an extensible pro- which today are almost exclusively written in C and its close rela- gramming language and its intrinsic support for formal verifica- tives. tion. Our language is targeted at low-level programming of infras- Need we always choose between performance and abstraction? tructure like operating systems and runtime systems. It is based on One approach to retaining both is metaprogramming, from basic a cross-platform core combining characteristics of assembly lan- cases of textual macro substitution as in the C preprocessor, to so- guages and compiler intermediate languages. From this founda- phisticated code generators like Yacc. Here we employ abstractions tion, we take literally the saying that C is a “macro assembly lan- that in a sense are compile-time only, running programs that gen- guage”: we introduce an expressive notion of certified low-level erate programs in C or other low-level languages. As a result, we macros, sufficient to build up the usual features of C and beyond incur no run-time cost to abstraction. as macros with no special support in the core. Furthermore, our Unfortunately, code generation is hard to get right. The C pre- macros have integrated support for strongest postcondition calcu- processor’s textual substitution mechanism allows for all sorts of lation and verification condition generation, so that we can provide scoping errors in macro definitions. There exist widely used alter- a high-productivity formal verification environment within Coq for natives, like the macro systems of Lisp/Scheme, OCaml (Camlp4), programs composed from any combination of macros. Our macro and Haskell (Template Haskell), which can enforce “hygiene” re- interface is expressive enough to support features that low-level quirements on lexical scoping in macro definitions. programs usually only access through external tools with no formal The functional programming community knows well the advan- guarantees, such as declarative parsing or SQL-inspired querying. tages of code generation with languages like Haskell and ML as The abstraction level of these macros only imposes a compile-time metalanguages for embedded domain-specific languages (DSLs). cost, via the execution of functional Coq programs that compute That is, one represents the programs of some object language, like programs in our intermediate language; but the run-time cost is C or CUDA, as data within the metalanguage, making it possible not substantially greater than for more conventional C code. We to compute programs of the object language at compile time using describe our experiences constructing a full C-like language stack all of the abstraction features of the metalanguage. using macros, with some experiments on the verifiability and per- There is a tower of static assurance levels for this kind of gener- formance of individual programs running on that stack. ative metaprogramming. Tools like Yacc receive little static assur- ance from their implementation languages, as they output source Categories and Subject Descriptors F.3.1 [Logics and meanings code as strings that the implementation language does not analyze. of programs]: Mechanical verification; D.3.4 [Programming Lan- Conventional macro systems, from primitive token substitution in guages]: Compilers C to hygienic Scheme macros, can provide stronger lexical guar- antees. Next in the tower are languages that allow for static typing Keywords generative metaprogramming; interactive proof assis- of macros, guaranteeing that any of their applications produce both tants; low-level programming languages; functional programming scope-safe and type-safe object-language code. Languages in this category include MetaML [30] and MacroML [13], for homoge- 1. Introduction neous metaprogramming where the meta and object languages are A fundamental tension in programming language design is between the same; and MetaHaskell [22], for heterogeneous metaprogram- performance and abstraction. Closer to the high-performance end ming where meta and object languages are different (e.g., Haskell of the spectrum, we have languages like C, which are often used and CUDA). Our contribution in this paper is to continue higher to implement low-level infrastructure that many applications de- up this tower of static guarantees: we support separate static check- ing of macros to guarantee that they always produce functionally correct object-language code. The programming language and associated verification tools Permission to make digital or hard copies of part or all of this work for personal or will need to provide a proof rule for each macro. A naive proof classroom use is granted without fee provided that copies are not made or distributed rule just expands macro applications using their definitions, pro- for profit or commercial advantage and that copies bear this notice and the full citation viding no abstraction benefit. We could ask instead that macro defi- on the first page. Copyrights for third-party components of this work must be honored. nitions include proof rules, and that the verification system requires For all other uses, contact the owner/author(s). programmers to prove that their macro definitions respect the as- ICFP ’13, September 25–27, 2013, Boston, MA, USA. Copyright is held by the owner/author(s). sociated proof rules. In effect, we have a macro system support- ACM 978-1-4503-2326-0/13/09. ing modularity in the style of well-designed functions, classes, or http://dx.doi.org/10.1145/2500365.2500592 libraries, with clear separation between implementation and inter- Constants c ::= [width-32 bitvectors] face. Code labels ` ::= ::: In this paper, we report on our experiences building such a Registers r ::= Sp j Rp j Rv macro system for a low-level language, intended as a replacement Addresses a ::= r j c j r + c for C in the systems programming domain. This macro system Lvalues L ::= r j [a]8 j [a]32 is part of the Bedrock library for the Coq proof assistant, which Rvalues R ::= L j c j ` provides an integrated environment for program implementation, Binops o ::= + j − j × specification, and verification. A prior publication [8] introduced Tests t ::= =j 6= j < j ≤ Bedrock’s support for proof automation, implementing example Instructions i ::= L R j L R o R programs using an earlier version of our macro system but not de- Jumps j ::= goto R j if (R t R) then ` else ` scribing it in detail. Since that paper was written, the macro system Specs S ::= ::: Blocks B ::= ` : fSg i∗; j has evolved, and we have used it to implement more interesting ∗ examples. We now present its design and implementation in detail, Modules M ::= B along with the higher-level language design principle that motivates it. Figure 1. Syntax of the Bedrock IL Our metalanguage is Gallina, the functional programming lan- guage in Coq’s logic. Our object language is a tiny compiler inter- mediate language. We build up the usual features of C via unpriv- prove correctness theorems within a framework for modular ver- ileged macros, and then we go further and implement features like ification, where we can verify libraries separately and then link declarative parsing and declarative querying of data structures as together their correctness theorems into whole-program correct- macros rather than ad-hoc external tools like Yacc and MySQL. ness theorems, without revisiting details of code implementation To support productive formal verification, we tag each macro or proof. This modularity holds even in the presence of a mutable with a proof rule. To be more precise, each macro contains a pred- heap that may hold callable code pointers, thanks to the XCAP [26] icate transformer, which evolves a logical assertion to reflect the program logic that sits at the base of our framework. effects of a program statement; and a verification condition gener- The remaining sections of this paper will walk through the steps ator, which outputs proof obligations associated with a use of the of building our stack of macros. We begin with a tiny assembly-like macro. These are some of the standard tools of highly automated language and proceed to introduce our notion of certified low-level program verification, and requiring them of all macros lets us build macros for it, build macros for basic C-like constructs, add support a generic verification environment that supports automated proofs for local variables and function calls, and culminate in the high- about programs built with macros drawn from diverse sources. We level macros for declarative parsing and querying. Next we evaluate call the central abstraction certified low-level macros. the effectiveness of our platform in terms of program verifiability and run-time performance, and we finish with a comparison to Our implementations and proofs have much in common with related work. compiler verification. For instance, CompCert [21] is a C com- Source code to both the Bedrock library and our example pro- piler implemented in Coq with a proof that it preserves program grams is available in the latest Bedrock source distribution at: semantics.
Load more

Recommended publications
  • Benjamin, Gesammelte Schriften, ,Mter Mitwirkung Von Theodor \\'1
    alter SELECTED WRITINGS VOLUME 1 1913-1926 Edited by Marcus Bullock and Michael W. Jennings THE BELKNAP PRESS OF HARVARD UNIVERSITY PRESS Cambridge, Massachusetts London, England , . I Contents Copyright © 1996 by the President and Fellows of Harvard College All rights rese rved Printed in the United States of America y l Second printing, 1997 METAPHYSICS OF "Experience" 3 This work is a transla tion of selec tions from Walter Benjamin, Gesammelte Schriften, ,mter Mitwirkung von Theodor \\'1. Adorno und Gershom Sch olem, heraltSgegeben von Rolf Tiedemann lind Hermann The Metaphysics of You Schweppenhiiuser, copyright © 1972, 1974, 1977, 1982, 1985, 1989 by Suh rkamp Verlag. "The Task of rhe Tra nslator" originally appeared in English in Wal ter Benjamin, Illuminations, ed ited by Hannah Two Poems by Friedrich Are nd t, English translation copyright © 1968 by Harcourt Brace Jovanovich, Inc. "On Language as Such The Life of Students 3' and the Language of Man," "Fate and Cha racter," "Critique of Violen,?;" " Nap les," and "One-Way Street" originally appeared in English in Walter Benjamin, Reflections, English translation copyright Aphorisms on Imaginati © 1978 by Harcoun Brace Jovanovich, Inc . Published by arrangement with Harc ourt Brace Jovanovich, Inc. "One-Way Street" also appeared i.n Walter Benjamin, "One-Way Street " and Other Writings (Lon­ A Child's View of ColOl don: NLBNerso, 1979, 1985). "Socrates" and "On the Program of the Coming Philosophy" originally appeared in English in The Philosophical Forum 15, nos. 1-2 (1983-1984). Socrates 52 Publication of this book has been aided by a grant from Inter Nationes, Bonn.
    [Show full text]
  • End-User Debugging for E-Commerce
    End-User Debugging for E-Commerce Henry Lieberman Earl Wagner MIT Media Lab 20 Ames St, Cambridge, MA 02139 USA {lieber, ewagner}@media.mit.edu ABSTRACT another phone number to be dialed. It might ask for card numbers or transaction numbers that aren’t readily at hand, and have to One of the biggest unaddressed challenges for the digital looked up offline. If someone in customer service is successfully economy is what to do when electronic transactions go wrong. reached, that person (often a low-paid worker in a high-pressure Consumers are frustrated by interminable phone menus, and long call center) may specify a tedious process to be performed. They delays to problem resolution. Businesses are frustrated by the may not be empowered to actually understand or fix the problem high cost of providing quality customer service. themselves. Customers find themselves bounced endlessly from We believe that many simple problems, such as mistyped one support person to another. All of us have had these kinds of numbers or lost orders, could be easily diagnosed if users were experiences. supplied with end-user debugging tools, analogous to tools for Customer service problems are incredibly frustrating. Not only do software debugging. These tools can show the history of actions they cause frustration about the immediate transaction, they also and data, and provide assistance for keeping track of and testing poison the relationship between customers and vendors. hypotheses. These tools would benefit not only users, but Customers feel like they are being deflected, that they are not businesses as well by decreasing the need for customer service.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Structured Programming - Retrospect and Prospect Harlan D
    University of Tennessee, Knoxville Trace: Tennessee Research and Creative Exchange The aH rlan D. Mills Collection Science Alliance 11-1986 Structured Programming - Retrospect and Prospect Harlan D. Mills Follow this and additional works at: http://trace.tennessee.edu/utk_harlan Part of the Software Engineering Commons Recommended Citation Mills, Harlan D., "Structured Programming - Retrospect and Prospect" (1986). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/20 This Article is brought to you for free and open access by the Science Alliance at Trace: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The aH rlan D. Mills Collection by an authorized administrator of Trace: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. mJNDAMNTL9JNNEPTS IN SOFTWARE ENGINEERING Structured Programming. Retrospect and Prospect Harlan D. Mills, IBM Corp. Stnuctured program- 2 ' dsger W. Dijkstra's 1969 "Struc- mon wisdom that no sizable program Ste red .tured Programming" articlel could be error-free. After, many sizable ming haxs changed ho w precipitated a decade of intense programs have run a year or more with no programs are written focus on programming techniques that has errors detected. since its introduction fundamentally alteredhumanexpectations and achievements in software devel- Impact of structured programming. two decades ago. opment. These expectations and achievements are However, it still has a Before this decade of intense focus, pro- not universal because of the inertia of lot of potentialfor gramming was regarded as a private, industrial practices. But they are well- lot of fo puzzle-solving activity ofwriting computer enough established to herald fundamental more change.
    [Show full text]
  • TITLE Kansas State Capitol Guide for Young People. Curriculum Packet for Teachers of Grades 4-7. INSTITUTION Kansas State Historical Society, Topeka.; Kansas State Dept
    DOCUMENT RESUME ED 477 746 SO 034 927 TITLE Kansas State Capitol Guide for Young People. Curriculum Packet for Teachers of Grades 4-7. INSTITUTION Kansas State Historical Society, Topeka.; Kansas State Dept. of Education, Topeka. PUB DATE 2002-00-00 NOTE 27p.; Prepared by the Education and Outreach Division. Intended to supplement the "Kansas State Capitol Guide for Young People." AVAILABLE FROM Kansas State Historical Society, 6425 S.W. 6th Avenue, Topeka, KS 66615. Tel: 785-272-8681; Fax: 785-272-8682; Web site: http://www.kshs.org/. For full text: http://www.kshs.org/teachers/ classroom/capitolguide.htm. PUB TYPE Guides Classroom Teacher (052) EDRS PRICE EDRS Price MF01/PCO2 Plus Postage. DESCRIPTORS Elementary Education; Guides; *Historic Sites; *Social Studies; *State Government; *State History IDENTIFIERS Indicators; *Kansas; *State Capitals ABSTRACT This curriculum packet is about the Kansas state capitol. The packet contains six graphic organizers for students to complete. The packets are divided into three sections (with their accompanying graphic organizers): (1) "Symbolism of the Kansas Capitol Dome Statue" (Who Are the Kansa?; Finding Your Way; Say It Again); (2) "Topping the Dome: Selecting a Symbol" (What Are They Saying?; What's on Top?); and (3)"Names as Symbols" (Native American Place Names). For each section, the teacher is provided with a main point and background information for the lesson. Answers for the graphic organizers, when necessary, are provided. (BT) Reproductions supplied by EDRS are the best that can be made from the original document. Guide for Your\g,Dori@ Ad Astra, the statue by Richard Bergen, was placed on the Capitol Cr) dome October 2002 CD Curriculum Packet O For Teachers of Grades 4-7 © 2002 Kansas State Historical Society Prepared in consultation with the KA.NSAS Kansas State Department of Education STATE HISTORICAL SOCIETY U.S.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Relationships Between Category Theory and Functional Programming with an Application
    Turkish Journal of Mathematics Turk J Math (2019) 43: 1566 – 1577 http://journals.tubitak.gov.tr/math/ © TÜBİTAK Research Article doi:10.3906/mat-1807-189 Relationships between category theory and functional programming with an application Alper ODABAŞ∗,, Elis SOYLU YILMAZ, Department of Mathematics and Computer Sciences, Faculty of Arts and Sciences, Eskişehir Osmangazi University, Eskişehir, Turkey Received: 25.07.2018 • Accepted/Published Online: 08.04.2019 • Final Version: 29.05.2019 Abstract: The most recent studies in mathematics are concerned with objects, morphisms, and the relationship between morphisms. Prominent examples can be listed as functions, vector spaces with linear transformations, and groups with homomorphisms. Category theory proposes and constitutes new structures by examining objects, morphisms, and compositions. Source and target of a morphism in category theory corresponds to input and output in programming language. Thus, a connection can be obtained between category theory and functional programming languages. From this point, this paper constructs a small category implementation in a functional programming language called Haskell. Key words: Category theory, functional programming, Haskell 1. Introduction Eilenberg and MacLane ([7]) are the pioneers who built the structures of the categories, functors, and natural transformations which are revealed first in 1945. A broader literature review reveals an important connection between homology and theoretical homology theory. These findings relieve mathematics from theoretical constraint and enables branches of science to involve the above relationship. The most significant transition in computer science is between category theory and computation. Oneof the most important aspects of computation is composing the new functions or modules by using the primitive functions, recursive structures, etc.
    [Show full text]
  • The Language of Fraud Cases. by Roger Shuy. New York: Oxford University Press, 2015
    1012 LANGUAGE, VOLUME 92, NUMBER 4 (2016) Jackendoff, Ray. 2002 . Foundations of language: Brain, meaning, grammar, evolution . Oxford: Oxford University Press. Newmeyer, Frederick J. 2005 . Possible and probable languages: A generative perspective on linguistic ty - pology . Oxford: Oxford University Press. Pinker, Steven, and Paul Bloom. 1990 . Natural language and natural selection. Behavioral and Brain Sci - ences 13.4.707–84. DOI: 10.1017/S0140525X00081061 . Progovac, Ljiljana . 1998a. Structure for coordination (part I). GLOT International 3.7.3–6. Progovac, Ljiljana . 1998b. Structure for coordination (part II). GLOT International 3.8.3–9. Department of Linguistics University of Washington–Seattle PO Box 352425 Seattle, WA 98195-2425 [[email protected]] The language of fraud cases. By Roger Shuy. New York: Oxford University Press, 2015. Pp. 301. ISBN 9780190270643. $99 (Hb). Reviewed by Lawrence M. Solan, Brooklyn Law School Most of Roger Shuy’s book , The language of fraud cases , describes cases in which S was in - volved as a linguistic expert, called by parties who were accused of some kind of fraud. Written in a journalistic style to engage readers from multiple disciplines, the book is a recent addition to a series of books that S has written over the past decade, describing his experiences as an expert witness. Other books in the series describe murder cases (2014) , bribery cases (2013), sexual mis - conduct cases (2012), perjury cases (2011), and defamation cases (2010). The case narratives most often describe a hypervigilant investigator or cooperating witness in - terpreting the target’s ambiguous or incomplete statements to confirm the suspicion that the target of the investigation has indeed committed a fraud.
    [Show full text]
  • Graceful Language Extensions and Interfaces
    Graceful Language Extensions and Interfaces by Michael Homer A thesis submitted to the Victoria University of Wellington in fulfilment of the requirements for the degree of Doctor of Philosophy Victoria University of Wellington 2014 Abstract Grace is a programming language under development aimed at ed- ucation. Grace is object-oriented, imperative, and block-structured, and intended for use in first- and second-year object-oriented programming courses. We present a number of language features we have designed for Grace and implemented in our self-hosted compiler. We describe the design of a pattern-matching system with object-oriented structure and minimal extension to the language. We give a design for an object-based module system, which we use to build dialects, a means of extending and restricting the language available to the programmer, and of implementing domain-specific languages. We show a visual programming interface that melds visual editing (à la Scratch) with textual editing, and that uses our dialect system, and we give the results of a user experiment we performed to evaluate the usability of our interface. ii ii Acknowledgments The author wishes to acknowledge: • James Noble and David Pearce, his supervisors; • Andrew P. Black and Kim B. Bruce, the other designers of Grace; • Timothy Jones, a coauthor on a paper forming part of this thesis and contributor to Minigrace; • Amy Ruskin, Richard Yannow, and Jameson McCowan, coauthors on other papers; • Daniel Gibbs, Jan Larres, Scott Weston, Bart Jacobs, Charlie Paucard, and Alex Sandilands, other contributors to Minigrace; • Gilad Bracha, Matthias Felleisen, and the other (anonymous) review- ers of papers forming part of this thesis; • the participants in his user study; • David Streader, John Grundy, and Laurence Tratt, examiners of the thesis; • and Alexandra Donnison, Amy Chard, Juanri Barnard, Roma Kla- paukh, and Timothy Jones, for providing feedback on drafts of this thesis.
    [Show full text]
  • On the Cognitive Prerequisites of Learning Computer Programming
    On the Cognitive Prerequisites of Learning Computer Programming Roy D. Pea D. Midian Kurland Technical Report No. 18 ON THE COGNITIVE PREREQUISITES OF LEARNING COMPUTER PROGRAMMING* Roy D. Pea and D. Midian Kurland Introduction Training in computer literacy of some form, much of which will consist of training in computer programming, is likely to involve $3 billion of the $14 billion to be spent on personal computers by 1986 (Harmon, 1983). Who will do the training? "hardware and software manu- facturers, management consultants, -retailers, independent computer instruction centers, corporations' in-house training programs, public and private schools and universities, and a variety of consultants1' (ibid.,- p. 27). To date, very little is known about what one needs to know in order to learn to program, and the ways in which edu- cators might provide optimal learning conditions. The ultimate suc- cess of these vast training programs in programming--especially toward the goal of providing a basic computer programming compe- tency for all individuals--will depend to a great degree on an ade- quate understanding of the developmental psychology of programming skills, a field currently in its infancy. In the absence of such a theory, training will continue, guided--or to express it more aptly, misguided--by the tacit Volk theories1' of programming development that until now have served as the underpinnings of programming instruction. Our paper begins to explore the complex agenda of issues, promise, and problems that building a developmental science of programming entails. Microcomputer Use in Schools The National Center for Education Statistics has recently released figures revealing that the use of micros in schools tripled from Fall 1980 to Spring 1983.
    [Show full text]
  • A Historical and Phonetic Study of Negro Dialect. T
    Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1937 A Historical and Phonetic Study of Negro Dialect. T. Earl Pardoe Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Part of the Speech and Rhetorical Studies Commons Recommended Citation Pardoe, T. Earl, "A Historical and Phonetic Study of Negro Dialect." (1937). LSU Historical Dissertations and Theses. 7790. https://digitalcommons.lsu.edu/gradschool_disstheses/7790 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact [email protected]. A Historioal and phonetic Study of Negro Dialect* A Dissertation Submitted in Partial Fulfillment of the Requirements for the Degree of Dootor of Philosophy in Louisiana State University* By T. Earl pardoe 1937 UMI Number: DP69168 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. UMI Dissertation Publishing UMI DP69168 Published by ProQuest LLC (2015). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProOuest ProQuest LLC. 789 East Eisenhower Parkway P.O.
    [Show full text]
  • A Comparative Analysis of Structured and Object-Oriented Programming Methods
    JASEM ISSN 1119-8362 Full-text Available Online at J. Appl. Sci. Environ. Manage. December, 2008 All rights reserved www.bioline.org.br/ja Vol. 12(4) 41 - 46 A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS. Department of Computer Science, University of Port Harcourt, Port Harcourt, Nigeria. [email protected], [email protected]. 08056023566 ABSTRACT: The concepts of structured and object-oriented programming methods are not relatively new but these approaches are still very much useful and relevant in today’s programming paradigm. In this paper, we distinguish the features of structured programs from that of object oriented programs. Structured programming is a method of organizing and coding programs that can provide easy understanding and modification, whereas object- oriented programming (OOP) consists of a set of objects, which can vary dynamically, and which can execute by acting and reacting to each other, in much the same way that a real-world process proceeds (the interaction of real- world objects). An object-oriented approach makes programs more intuitive to design, faster to develop, more amenable to modifications, and easier to understand. With the traditional, procedural-oriented/structured programming, a program describes a series of steps to be performed (an algorithm). In the object-oriented view of programming, instead of programs consisting of sets of data loosely coupled to many different procedures, object- oriented programs
    [Show full text]