DOCSLIB.ORG

Appendix B FUNCTIONAL PROGRAMMING with SCHEME

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Appendix B FUNCTIONAL PROGRAMMING with SCHEME Appendix B FUNCTIONAL PROGRAMMING WITH SCHEME he languages usually studied in computer science—namely, Pascal, C, Modula-2, and Ada—are considered imperative languages because the T basic construct is a command. These languages are heavily influenced by the “von Neumann architecture” of computers, which includes a store (memory) and an instruction counter used to identify the next instruction to be fetched from the store. The computation model has control structures that determine the sequencing of instructions, which use assignments to make incremental modifications to the store. Imperative languages are characterized by the following properties: • The principal operation is the assignment of values to variables. • Programs are command oriented, and they carry out algorithms with state- ment level sequence control, usually by selection and repetition. • Programs are organized as blocks, and data control is dominated by scope rules. • Computing is done by effect, namely by changes to the store. The computing by effect intrinsic to imperative programming plays havoc with some of the mathematical properties that are essential to proving the correctness of programs. For example, is addition commutative in an im- perative program? Does “write(a+b)” always produce the same value as “write(b+a)”? Consider the following Pascal program: program P (output); var b : integer; function a : integer; begin b := b+2; a := 5 end; begin b := 10 write(a+b) or write(b+a) end. In fact, implementations of Pascal will most likely give different results for the two versions of this program, depending on the order of evaluation of 587 588 APPENDIX B FUNCTIONAL PROGRAMMING WITH SCHEME expressions. This anomaly is caused by the side effect in the expression be- ing evaluated, but programming by effect lies at the heart of imperative pro- gramming. If we depend on imperative programs, we must discard many of the basic properties of mathematics, such as associative and commuative laws of addition and multiplication and the distributive law for multiplica- tion over addition. The functional programming paradigm provides an alternative notion of pro- gramming that avoids the problems of side effects. Functional languages are concerned with data objects and values instead of variables. Values are bound to identifiers, but once made, these bindings cannot change. The principal operation is function application. Functions are treated as first-class objects that may be stored in data structures, passed as parameters, and returned as function results. A functional language supplies primitive functions, and the programmer uses function constructors to define new functions. Pro- gram execution consists of the evaluation of an expression, and sequence control depends primarily on selection and recursion. A pure functional lan- guage has no assignment command; values are communicated by the use of parameters to functions. These restrictions enforce a discipline on the pro- grammer that avoids side effects. We say that functional languages are refer- entially transparent. Principle of Refer ential T ranspar ency: The value of a function is deter- mined by the values of its arguments and the context in which the function application appears, and it is independent of the history of the execution. ❚ Since the evaluation of a function with the same argument produces the same value every time that it is invoked, an expression will produce the same value each time it is evaluated in a given context. Referential transparency guarantees the validity of the property of substituting equals for equals. Lisp Work on Lisp (List processing) started in 1956 with an artificial intelligence group at MIT under John McCarthy. The language was implemented by McCarthy and his students in 1960 on an IBM 704, which also had the first Fortran implementation. Lisp was an early example of interactive comput- ing, which played a substantial role in its popularity. The original develop- ment of Lisp used S-expressions (S standing for symbolic language) with the intention of developing an Algol-like version (Lisp 2) with M-expressions (M for metalanguage). When a Lisp interpreter was written in Lisp with S-ex- pressions, Lisp 2 was dropped. The principal versions, which are based on Lisp 1.5, include Interlisp, Franz Lisp, MacLisp, Common Lisp, and Scheme. SCHEME SYNTAX 589 Lisp has a high-level notation for lists. Functions are defined as expressions, and repetitive tasks are performed mostly by recursion. Parameters are passed to functions by value. A Lisp program consists of a set of function definitions followed by a list of expressions that may include function evaluations. Scheme Syntax The Scheme version of Lisp has been chosen here because of its small size and its uniform treatment of functions. In this appendix we introduce the fundamentals of functional programming in Scheme. When we say Scheme, we are referring to Lisp. The basic objects in Scheme, called S-expressions, consist of atoms and “dotted pairs”: <S-expr> ::= <atom> | ( <S-expr> . <S-expr> ) The only terminal symbols in these productions are the parentheses and the dot (period). The important characteristic of an S-expression is that it is an atom or a pair of S-expressions. The syntactic representation of a pair is not crucial to the basic notion of constructing pairs. Atoms serve as the elementary objects in Scheme. They are considered indi- visible with no internal structure. <atom> ::= <literal atom> | <numeric atom> <literal atom> ::= <letter> | <literal atom> <letter> | <literal atom> <digit> <numeric atom> ::= <numeral> | – <numeral> <numeral> ::= <digit> | <numeral> <digit> Literal atoms consist of a string of alphanumeric characters usually starting with a letter. Most Lisp systems allow any special characters in literal atoms as long as they cannot be confused with numbers. The numeric atoms de- fined here represent only integers, but most Lisp systems allow floating-point numeric atoms. Since S-expressions can have arbitrary nesting when pairs are constructed, Scheme programmers rely on a graphical representation of S-expressions to display their structure. Consider the following diagrams illustrating the S- expression (a . (b. c)): Lisp tree (or L-tree): a b c 590 APPENDIX B FUNCTIONAL PROGRAMMING WITH SCHEME Cell diagram (or box notation): a b c We prefer using the box notation for S-expressions. Atoms are represented as themselves, and if the same atom is used twice in an S-expression, a single value can be shared since atoms have unique occurrences in S-ex- pressions. Functions on S-expressions The simplicity of Scheme (and Lisp) derives from its dependence on several basic functions for constructing pairs and selecting components of a pair. Two selector functions are used to investigate a pair: car Applied to a nonatomic S-expression, car returns the left part. cdr Applied to a nonatomic S-expression, cdr returns the right part. On the IBM 704, car stood for “contents of address register” and cdr for “con- tents of decrement register”. Some authors have suggested that “head” and “tail” or “first” and “rest” are more suggestive names for these functions, but most Lisp programmers still use the traditional names. The following examples that use brackets [ ] to delimit arguments do not follow correct Scheme syntax, which will be introduced shortly: car [ ((a . b) . c) ] = (a . b) cdr [ ((a . b) . c) ] = c An error results if either function is applied to an atom. An abstract implementation of the selector functions can be explained in terms of a box diagram: car returns the left pointer. cdr returns the right pointer. c a b LISTS IN SCHEME 591 A single constructor function cons builds a pair given two S-expressions: cons Applied to two S-expressions, cons returns a dotted pair contain- ing them. For example: cons[ p , q ] = (p . q) cons[ (a . b) , (a . c) ] = ((a . b) . (a . c)) As an abstract implementation, we allocate a new cell and set its left and right components to point to the two arguments. Observe that the atom a is shared by the two pairs. (a . b) cons [ (a . b) , (a . c) ] a b (a . c) c Lists in Scheme The notion of an S-expression is too general for most computing tasks, so Scheme primarily deals with a subset of the S-expressions. A list in Scheme is an S-expression with one of two forms: 1. The special atom ( ) is a list representing the empty list. Note that ( ) is the only S-expression that is both an atom and a list. 2. A dotted pair is a list if its right (cdr) element is a list. S-expressions that are lists use special notation: (a . ( )) is represented by (a) (b . (a . ( ))) is represented by (b a) (c . (b . (a . ( )))) is represented by (c b a) Cell diagrams for lists are usually drawn with a horizontal “spine” that stretches from left to right. The spine contains as many boxes as the list has elements at its top level. 592 APPENDIX B FUNCTIONAL PROGRAMMING WITH SCHEME (a b c) abc( ) ((a b) (c) d) = ((a . (b . ( ))) . ((c . ( )) . (d . ( )))) d a b c Observe the abbreviation of a slash through the cell at the end of a list to represent a pointer to an empty list ( ). The elementary constructor and selectors for S-expressions have special prop- erties when applied to lists. car When applied to a nonempty list, car returns the first element of the list. cdr When applied to a nonempty list, cdr returns a copy of the list with the first element removed. cons When applied to an arbitrary S-expression and a list, cons re- turns the list obtained by appending the first argument onto the beginning of the list (the second argument). For example: car [ (a b c) ] = a cdr [ (a b c) ] = (b c) car [ ((a)) ] = (a) cdr [ ((a)) ] = ( ) cons [(a) , (b c) ] = ((a) b c) cons [ a , ( ) ] = (a) Syntax for Functions In Scheme, the application of a function to a set of arguments is expressed as a list: (function-name sequence-of-arguments) This prefix notation is known as Cambridge Polish For m since it was devel- oped at MIT in Cambridge.
Load more

Recommended publications
  • Programming Paradigms & Object-Oriented
    4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Syllabus Content: 4.3.1 Programming paradigms Show understanding of what is meant by a programming paradigm Show understanding of the characteristics of a number of programming paradigms (low- level, imperative (procedural), object-oriented, declarative) – low-level programming Demonstrate an ability to write low-level code that uses various address modes: o immediate, direct, indirect, indexed and relative (see Section 1.4.3 and Section 3.6.2) o imperative programming- see details in Section 2.3 (procedural programming) Object-oriented programming (OOP) o demonstrate an ability to solve a problem by designing appropriate classes o demonstrate an ability to write code that demonstrates the use of classes, inheritance, polymorphism and containment (aggregation) declarative programming o demonstrate an ability to solve a problem by writing appropriate facts and rules based on supplied information o demonstrate an ability to write code that can satisfy a goal using facts and rules Programming paradigms 1 4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Programming paradigm: A programming paradigm is a set of programming concepts and is a fundamental style of programming. Each paradigm will support a different way of thinking and problem solving. Paradigms are supported by programming language features. Some programming languages support more than one paradigm. There are many different paradigms, not all mutually exclusive. Here are just a few different paradigms. Low-level programming paradigm The features of Low-level programming languages give us the ability to manipulate the contents of memory addresses and registers directly and exploit the architecture of a given processor.
    [Show full text]
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • High-Level Language Features Not Found in Ordinary LISP. the GLISP
    DOCUMENT RESUME ED 232 860 SE 042 634 AUTHOR Novak, Gordon S., Jr. TITLE GLISP User's Manual. Revised. INSTITUTION Stanford Univ., Calif. Dept. of Computer Science. SPONS AGENCY Advanced Research Projects Agency (DOD), Washington, D.C.; National Science Foundation, Washington, D.C. PUB DATE 23 Nov 82 CONTRACT MDA-903-80-c-007 GRANT SED-7912803 NOTE 43p.; For related documents, see SE 042 630-635. PUB TYPE Guides General (050) Reference Materials General (130) EDRS PRICE MF01/PCO2 Plus Postage. DESCRIPTORS *Computer Programs; *Computer Science; Guides; *Programing; *Programing Languages; *Resource Materials IDENTIFIERS *GLISP Programing Language; National Science Foundation ABSTRACT GLISP is a LISP-based language which provides high-level language features not found in ordinary LISP. The GLISP language is implemented by means of a compiler which accepts GLISP as input and produces ordinary LISP as output. This output can be further compiled to machine code by the LISP compiler. GLISP is available for several ISP dialects, including Interlisp, Maclisp, UCI Lisp, ELISP, Franz Lisp, and Portable Standard Lisp. The goal of GLISP is to allow structured objects to be referenced in a convenient, succinct language and to allow the structures of objects to be changed without changing the code which references the objects. GLISP provides both PASCAL-like and English-like syntaxes; much of the power and brevity of GLISP derive from the compiler features necessary to support the relatively informal, English-like language constructs. Provided in this manual is the documentation necessary for using GLISP. The documentation is presented in the following sections: introduction; object descriptions; reference to objects; GLISP program syntax; messages; context rules and reference; GLISP and knowledge representation languages; obtaining and using GLISP; GLISP hacks (some ways of doing things in GLISP which might not be entirely obvious at first glance); and examples of GLISP object declarations and programs.
    [Show full text]
  • Functional Languages
    Functional Programming Languages (FPL) 1. Definitions................................................................... 2 2. Applications ................................................................ 2 3. Examples..................................................................... 3 4. FPL Characteristics:.................................................... 3 5. Lambda calculus (LC)................................................. 4 6. Functions in FPLs ....................................................... 7 7. Modern functional languages...................................... 9 8. Scheme overview...................................................... 11 8.1. Get your own Scheme from MIT...................... 11 8.2. General overview.............................................. 11 8.3. Data Typing ...................................................... 12 8.4. Comments ......................................................... 12 8.5. Recursion Instead of Iteration........................... 13 8.6. Evaluation ......................................................... 14 8.7. Storing and using Scheme code ........................ 14 8.8. Variables ........................................................... 15 8.9. Data types.......................................................... 16 8.10. Arithmetic functions ......................................... 17 8.11. Selection functions............................................ 18 8.12. Iteration............................................................. 23 8.13. Defining functions ...........................................
    [Show full text]
  • Higher-Order Functions 15-150: Principles of Functional Programming – Lecture 13
    Higher-order Functions 15-150: Principles of Functional Programming { Lecture 13 Giselle Reis By now you might feel like you have a pretty good idea of what is going on in functional program- ming, but in reality we have used only a fragment of the language. In this lecture we see what more we can do and what gives the name functional to this paradigm. Let's take a step back and look at ML's typing system: we have basic types (such as int, string, etc.), tuples of types (t*t' ) and functions of a type to a type (t ->t' ). In a grammar style (where α is a basic type): τ ::= α j τ ∗ τ j τ ! τ What types allowed by this grammar have we not used so far? Well, we could, for instance, have a function below a tuple. Or even a function within a function, couldn't we? The following are completely valid types: int*(int -> int) int ->(int -> int) (int -> int) -> int The first one is a pair in which the first element is an integer and the second one is a function from integers to integers. The second one is a function from integers to functions (which have type int -> int). The third type is a function from functions to integers. The two last types are examples of higher-order functions1, i.e., a function which: • receives a function as a parameter; or • returns a function. Functions can be used like any other value. They are first-class citizens. Maybe this seems strange at first, but I am sure you have used higher-order functions before without noticing it.
    [Show full text]
  • 15-150 Lectures 27 and 28: Imperative Programming
    15-150 Lectures 27 and 28: Imperative Programming Lectures by Dan Licata April 24 and 26, 2012 In these lectures, we will show that imperative programming is a special case of functional programming. We will also investigate the relationship between imperative programming and par- allelism, and think about what happens when the two are combined. 1 Mutable Cells Functional programming is all about transforming data into new data. Imperative programming is all about updating and changing data. To get started with imperative programming, ML provides a type 'a ref representing mutable memory cells. This type is equipped with: • A constructor ref : 'a -> 'a ref. Evaluating ref v creates and returns a new memory cell containing the value v. Pattern-matching a cell with the pattern ref p gets the contents. • An operation := : 'a ref * 'a -> unit that updates the contents of a cell. For example: val account = ref 100 val (ref cur) = account val () = account := 400 val (ref cur) = account 1. In the first line, evaluating ref 100 creates a new memory cell containing the value 100, which we will write as a box: 100 and binds the variable account to this cell. 2. The next line pattern-matches account as ref cur, which binds cur to the value currently in the box, in this case 100. 3. The next line updates the box to contain the value 400. 4. The final line reads the current value in the box, in this case 400. 1 It's important to note that, with mutation, the same program can have different results if it is evaluated multiple times.
    [Show full text]
  • Typescript Language Specification
    TypeScript Language Specification Version 1.8 January, 2016 Microsoft is making this Specification available under the Open Web Foundation Final Specification Agreement Version 1.0 ("OWF 1.0") as of October 1, 2012. The OWF 1.0 is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. TypeScript is a trademark of Microsoft Corporation. Table of Contents 1 Introduction ................................................................................................................................................................................... 1 1.1 Ambient Declarations ..................................................................................................................................................... 3 1.2 Function Types .................................................................................................................................................................. 3 1.3 Object Types ...................................................................................................................................................................... 4 1.4 Structural Subtyping ....................................................................................................................................................... 6 1.5 Contextual Typing ............................................................................................................................................................ 7 1.6 Classes .................................................................................................................................................................................
    [Show full text]
  • Scala Tutorial
    Scala Tutorial SCALA TUTORIAL Simply Easy Learning by tutorialspoint.com tutorialspoint.com i ABOUT THE TUTORIAL Scala Tutorial Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. Scala has been created by Martin Odersky and he released the first version in 2003. Scala smoothly integrates features of object-oriented and functional languages. This tutorial gives a great understanding on Scala. Audience This tutorial has been prepared for the beginners to help them understand programming Language Scala in simple and easy steps. After completing this tutorial, you will find yourself at a moderate level of expertise in using Scala from where you can take yourself to next levels. Prerequisites Scala Programming is based on Java, so if you are aware of Java syntax, then it's pretty easy to learn Scala. Further if you do not have expertise in Java but you know any other programming language like C, C++ or Python, then it will also help in grasping Scala concepts very quickly. Copyright & Disclaimer Notice All the content and graphics on this tutorial are the property of tutorialspoint.com. Any content from tutorialspoint.com or this tutorial may not be redistributed or reproduced in any way, shape, or form without the written permission of tutorialspoint.com. Failure to do so is a violation of copyright laws. This tutorial may contain inaccuracies or errors and tutorialspoint provides no guarantee regarding the accuracy of the site or its contents including this tutorial. If you discover that the tutorialspoint.com site or this tutorial content contains some errors, please contact us at [email protected] TUTORIALS POINT Simply Easy Learning Table of Content Scala Tutorial ..........................................................................
    [Show full text]
  • Functional and Imperative Object-Oriented Programming in Theory and Practice
    Uppsala universitet Inst. för informatik och media Functional and Imperative Object-Oriented Programming in Theory and Practice A Study of Online Discussions in the Programming Community Per Jernlund & Martin Stenberg Kurs: Examensarbete Nivå: C Termin: VT-19 Datum: 14-06-2019 Abstract Functional programming (FP) has progressively become more prevalent and techniques from the FP paradigm has been implemented in many different Imperative object-oriented programming (OOP) languages. However, there is no indication that OOP is going out of style. Nevertheless the increased popularity in FP has sparked new discussions across the Internet between the FP and OOP communities regarding a multitude of related aspects. These discussions could provide insights into the questions and challenges faced by programmers today. This thesis investigates these online discussions in a small and contemporary scale in order to identify the most discussed aspect of FP and OOP. Once identified the statements and claims made by various discussion participants were selected and compared to literature relating to the aspects and the theory behind the paradigms in order to determine whether there was any discrepancies between practitioners and theory. It was done in order to investigate whether the practitioners had different ideas in the form of best practices that could influence theories. The most discussed aspect within FP and OOP was immutability and state relating primarily to the aspects of concurrency and performance. ​ ​ ​ ​ ​ ​ This thesis presents a selection of representative quotes that illustrate the different points of view held by groups in the community and then addresses those claims by investigating what is said in literature.
    [Show full text]
  • Smalltalk Smalltalk
    3/8/2008 CSE 3302 Programming Languages Smalltalk Everyygthing is obj ect. Obj ects communicate by messages. Chengkai Li Spring 2008 Lecture 14 – Smalltalk, Spring Lecture 14 – Smalltalk, Spring CSE3302 Programming Languages, UT-Arlington 1 CSE3302 Programming Languages, UT-Arlington 2 2008 ©Chengkai Li, 2008 2008 ©Chengkai Li, 2008 Object Hierarchy Object UndefinedObject Boolean Magnitude Collection No Data Type. True False Set … There is only Class. Char Number … Fraction Integer Float Lecture 14 – Smalltalk, Spring Lecture 14 – Smalltalk, Spring CSE3302 Programming Languages, UT-Arlington 3 CSE3302 Programming Languages, UT-Arlington 4 2008 ©Chengkai Li, 2008 2008 ©Chengkai Li, 2008 Syntax • Smalltalk is really “small” – Only 6 keywords (pseudo variables) – Class, object, variable, method names are self explanatory Sma llta lk Syn tax is Simp le. – Only syntax for calling method (messages) and defining method. • No syntax for control structure • No syntax for creating class Lecture 14 – Smalltalk, Spring Lecture 14 – Smalltalk, Spring CSE3302 Programming Languages, UT-Arlington 5 CSE3302 Programming Languages, UT-Arlington 6 2008 ©Chengkai Li, 2008 2008 ©Chengkai Li, 2008 1 3/8/2008 Expressions Literals • Literals • Number: 3 3.5 • Character: $a • Pseudo Variables • String: ‘ ’ (‘Hel’,’lo!’ and ‘Hello!’ are two objects) • Symbol: # (#foo and #foo are the same object) • Variables • Compile-time (literal) array: #(1 $a 1+2) • Assignments • Run-time (dynamic) array: {1. $a. 1+2} • Comment: “This is a comment.” • Blocks • Messages Lecture 14 – Smalltalk, Spring Lecture 14 – Smalltalk, Spring CSE3302 Programming Languages, UT-Arlington 7 CSE3302 Programming Languages, UT-Arlington 8 2008 ©Chengkai Li, 2008 2008 ©Chengkai Li, 2008 Pseudo Variables Variables • Instance variables.
    [Show full text]
  • Implementation Notes
    IMPLEMENTATION NOTES XEROX 3102464 lyric Release June 1987 XEROX COMMON LISP IMPLEMENTATION NOTES 3102464 Lyric Release June 1987 The information in this document is subject to change without notice and should not be construed as a commitment by Xerox Corporation. While every effort has been made to ensure the accuracy of this document, Xerox Corporation assumes no responsibility for any errors that may appear. Copyright @ 1987 by Xerox Corporation. Xerox Common Lisp is a trademark. All rights reserved. "Copyright protection claimed includes all forms and matters of copyrightable material and information now allowed by statutory or judicial law or hereinafter granted, including, without limitation, material generated from the software programs which are displayed on the screen, such as icons, screen display looks, etc. " This manual is set in Modern typeface with text written and formatted on Xerox Artificial Intelligence workstations. Xerox laser printers were used to produce text masters. PREFACE The Xerox Common Lisp Implementation Notes cover several aspects of the Lyric release. In these notes you will find: • An explanation of how Xerox Common Lisp extends the Common Lisp standard. For example, in Xerox Common Lisp the Common Lisp array-constructing function make-array has additional keyword arguments that enhance its functionality. • An explanation of how several ambiguities in Steele's Common Lisp: the Language were resolved. • A description of additional features that provide far more than extensions to Common Lisp. How the Implementation Notes are Organized . These notes are intended to accompany the Guy L. Steele book, Common Lisp: the Language which represents the current standard for Co~mon Lisp.
    [Show full text]
  • Unit 2 — Imperative and Object-Oriented Paradigm
    Programming Paradigms Unit 2 — Imperative and Object-oriented Paradigm J. Gamper Free University of Bozen-Bolzano Faculty of Computer Science IDSE PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 1/38 Outline 1 Imperative Programming Paradigm 2 Abstract Data Types 3 Object-oriented Approach PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 2/38 Imperative Programming Paradigm Outline 1 Imperative Programming Paradigm 2 Abstract Data Types 3 Object-oriented Approach PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 3/38 Imperative Programming Paradigm Imperative Paradigm/1 The imperative paradigm is the oldest and most popular paradigm Based on the von Neumann architecture of computers Imperative programs define sequences of commands/statements for the computer that change a program state (i.e., set of variables) Commands are stored in memory and executed in the order found Commands retrieve data, perform a computation, and assign the result to a memory location Data ←→ Memory CPU (Data and Address Program) ←→ The hardware implementation of almost all Machine code computers is imperative 8B542408 83FA0077 06B80000 Machine code, which is native to the C9010000 008D0419 83FA0376 computer, and written in the imperative style B84AEBF1 5BC3 PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 4/38 Imperative Programming Paradigm Imperative Paradigm/2 Central elements of imperative paradigm: Assigment statement: assigns values to memory locations and changes the current state of a program Variables refer
    [Show full text]