DOCSLIB.ORG

Introduction and Scheme

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction and Scheme Principles of Programming Languages (S) Matteo Pradella September 17, 2019 Matteo Pradella Principles of Programming Languages (S) September 17, 2019 1 / 105 Overview 1 Introduction 2 Basic concepts of programming languages, using Scheme 3 More advanced Scheme concepts 4 Object-oriented programming Matteo Pradella Principles of Programming Languages (S) September 17, 2019 2 / 105 Main coordinates email [email protected] office DEIB, Politecnico di Milano via Golgi 42, building 22, floor 3, room 322 phone 3495 web-page http://home.deib.polimi.it/pradella/PL.html twitter @bzoto, tag #corsopl Matteo Pradella Principles of Programming Languages (S) September 17, 2019 3 / 105 Motivation and preliminaries programming languages are tools for writing software i.e. tools for talking to the machine but not only to the machine: often code is created also to be read by human beings (debugging, pair programming, modifications/extensions) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 4 / 105 Motivation and preliminaries (cont.) several levels of abstraction in a computer: hw, operating system, network, applications, daemons, virtual machines, frameworks, web, clouds, . no "holy grail" language different languages are to be used for programming at different levels close to human: abstract, hard to "control" close to machine: too many details, hard to understand what is going on various (often conflicting) aspects: expressiveness and conciseness; ease of use; ease to control; efficiency of compiled code . Matteo Pradella Principles of Programming Languages (S) September 17, 2019 5 / 105 Motivation and preliminaries (cont.) why is a language successful? sometimes right tool at the right time; often hype, good marketing, good tools, luck, who knows. e.g. often is better a so-so language with great compilers, than a very nice language with a partial implementation (thanks especially to the Internet and open source software:) many new languages, strong evolution in recent years but often the concepts are those introduced 30+ years ago! Matteo Pradella Principles of Programming Languages (S) September 17, 2019 6 / 105 Motivation and preliminaries (cont.) Recent, competitive technologies are based on new languages, especially w.r.t. the Web e.g. Ruby on Rails, Node.js more and more new technologies and language-based frameworks emerge (or re-emerge, think about Objective-C and then Swift) Hence, we need to know and understand not particular languages, but their main principles and concepts Matteo Pradella Principles of Programming Languages (S) September 17, 2019 7 / 105 An incomplete timeline of PLs 1957 Fortran (Formula Translator) 1958 LISP (LISt Processor) 1959 COBOL (Common Business Oriented Language) 1960 ALGOL 60 (Algorithmic Language) 1964 BASIC (Beginner’s All-purpose Symbolic Instruction Code) 1967 Simula (first object-oriented lang.) 1970 Pascal, Forth 1972 C, Prolog, Smalltalk 1975 Scheme (Lisp + Algol) 1978 ML (Meta-Language) 1980 Ada Matteo Pradella Principles of Programming Languages (S) September 17, 2019 8 / 105 An incomplete timeline of PLs (cont.) 1983 C++, Objective-C 1984 Common Lisp (Lisp + OO) 1986 Erlang 1987 Perl 1990 Haskell 1991 Python 1995 Java, JavaScript, Ruby, PHP 2001 C# 2002 F# 2003 Scala 2007 Clojure 2009 Go; ’11 Dart, ’12 Rust, ’14 Swift . Matteo Pradella Principles of Programming Languages (S) September 17, 2019 9 / 105 Matteo Pradella Principles of Programming Languages (S) September 17, 2019 10 / 105 Pre-(and post-)requisites Good knowledge of procedural and object-oriented programming (I assume at least with C and Java, respectively) Exam: written exercises, small programs, translations from different paradigms. Emphasis on concepts and elegance of the chosen approach; no code obfuscation contest! Matteo Pradella Principles of Programming Languages (S) September 17, 2019 11 / 105 Map of used languages Scheme, for basics, memory management, introduction to functional programming and object orientation, meta-stuff Haskell, for static type systems and algebraic data types, functional “purity” Erlang, for concurrency-oriented programming Some of them are “academic” languages (but with reference with more mainstream ones): they are simpler, more orthogonal and with less "cruft" We need to understand the concepts and to be able to adapt and learn to new languages with little effort. (It is useless to focus on one particular, temporarily successful language.) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 12 / 105 Map of concepts dynamic (S) Type discipline Procedural programming (S) parametric polymorphism Abstract Data Types static (H) call by value (S)(H*) ad-hoc polymorphism Evaluation type inference call by reference (S) call by need (S*) 1st class functions (S) PL Concepts call by name (H) memoizaion (S*) (tail) recursion (S)(H) Functional programming Continuations (S) purity (H) monads (H)(S*) Exceptions (S)(H) quoting + macros (S) general principles DSL (S) Meta programming Object-oriented programming (S) prototype-based Actor model communication and synchronization Concurrent Programming (E) data sharing Matteo Pradella Principles of Programming Languages (S) September 17, 2019 13 / 105 Scheme: Why? Scheme is a language of the ancient and glorious Lisp Family [Scheme is intended to] allow researchers to use the language to explore the design, implementation, and semantics of programming languages. (From the R6RS standard) It is unique because it has extremely simple and flexible syntax and semantics, very few basic ideas Good to understand and experiment new concepts/constructs We will build new constructs and an OO language with it Matteo Pradella Principles of Programming Languages (S) September 17, 2019 14 / 105 A fast and incomplete introduction to Scheme Main (and free) material: We will use the Racket dialect of Scheme, which has a very good implementation and environment: http://racket-lang.org/ The last standard is "The Revised7 Report on the Algorithmic Language Scheme" (aka R7RS). A good book: http://www.scheme.com/tspl4/ (R6RS) #lang directive at the beginning of the file to choose the Scheme dialect that we are using (in our case #lang racket) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 15 / 105 The obligatory quotes on Lisp Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days. – Marvin Minsky If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. – Guy Steele A Lisp programmer knows the value of everything, but the cost of nothing. – Alan Perlis Matteo Pradella Principles of Programming Languages (S) September 17, 2019 16 / 105 Syntax (I hope you really like parentheses) The typical procedure call f (x; y); (C/Java) is written like this: (f x y) No special syntax for expressions, no infix operators, no precedence rules. E.g. x == y + 3*x + z; is written (= x (+ y (* 3 x) z)) Such expressions are called s-expressions Matteo Pradella Principles of Programming Languages (S) September 17, 2019 17 / 105 Basic types Booleans: #t, #f Numbers: 132897132989731289713, 1.23e+33, 23/169, 12+4i Characters: #\a, #\Z Symbols: a-symbol, another-symbol?, indeed! Vectors: #(1 2 3 4) Strings: "this is a string" Pairs and Lists: (1 2 #\a), (a . b), () (we’ll see later) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 18 / 105 Expressions Scheme is mainly a functional language, so every program is an expression, and computation is based on evaluating expressions (no statements). Evaluation of an expression produces a value (if it terminates) Evaluation of an expression (e1 e2 e3 :::) is based on the evaluation of e1, which identifies an operation f (e.g. is the name of a procedure). The other sub-expressions (i.e. ei , i > 1) are evaluated, and their values are passed to f . The evaluation order of ei , i ≥ 1 is unspecified, e.g. e4 could be evaluated before e2. Matteo Pradella Principles of Programming Languages (S) September 17, 2019 19 / 105 Procedures and the λ-calculus ancestry lambdas are unnamed procedures: (lambda (x y); this isa comment (+ (* x x) (* y y))) example usage ((lambda (x y) (+ (* x x) (* y y))) 2 3) =) 13 i.e. (λ(x; y) := x 2 + y 2)(2; 3) Lambdas are called blocks in Smalltalk, Ruby, Objective-C, and are present in many languages (e.g. in C++11, Java 8). Procedures are values in Scheme, hence are first class objects. λ-calculus introduced by Alonzo Church in the ’30s, theory of computable functions based on recursion (i.e. recursive functions) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 20 / 105 Variables and binding let is used for binding variables: (let ((x 2); in Scheme (y 3)) ...) { intx=2,y=3;// inC ...} Scoping rules are static (or lexical): traditional/old Lisps are dynamic (e.g. Emacs Lisp). Scheme was the first Lisp taking static scoping from Algol. Matteo Pradella Principles of Programming Languages (S) September 17, 2019 21 / 105 With static scoping rules, it prints 1; with dynamic scoping rules, 2. A few interpreted languages are still based on dynamic scoping. Some languages can optionally support it (e.g. Common Lisp, Perl). In Perl “my” variables are static, while “local” are dynamic. Static vs Dynamic scoping Consider this code: (let ((a 1)) (let ((f (lambda () (display a)))) (let ((a 2)) (f )))) Matteo Pradella Principles of Programming Languages (S) September 17, 2019 22 / 105 Static vs Dynamic scoping Consider this code: (let ((a 1)) (let ((f (lambda () (display a)))) (let ((a 2)) (f )))) With static scoping rules, it prints 1; with dynamic scoping rules, 2. A few interpreted languages are still based on dynamic scoping. Some languages can optionally support it (e.g. Common Lisp, Perl). In Perl “my” variables are static, while “local” are dynamic. Matteo Pradella Principles of Programming Languages (S) September 17, 2019 22 / 105 let, again let binds variables “in parallel”, e.g.: (let ((x 1) (y 2)) (let ((x y); swapx andy (y x)) ..
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]
  • A Feature Model of Actor, Agent, Functional, Object, and Procedural Programming Languages
    Accepted Manuscript A feature model of actor, agent, functional, object, and procedural programming languages H.R. Jordan, G. Botterweck, J.H. Noll, A. Butterfield, R.W. Collier PII: S0167-6423(14)00050-1 DOI: 10.1016/j.scico.2014.02.009 Reference: SCICO 1711 To appear in: Science of Computer Programming Received date: 9 March 2013 Revised date: 31 January 2014 Accepted date: 5 February 2014 Please cite this article in press as: H.R. Jordan et al., A feature model of actor, agent, functional, object, and procedural programming languages, Science of Computer Programming (2014), http://dx.doi.org/10.1016/j.scico.2014.02.009 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. Highlights • A survey of existing programming language comparisons and comparison techniques. • Definitions of actor, agent, functional, object, and procedural programming concepts. • A feature model of general-purpose programming languages. • Mappings from five languages (C, Erlang, Haskell, Jason, and Java) to this model. A Feature Model of Actor, Agent, Functional, Object, and Procedural Programming Languages H.R. Jordana,∗, G. Botterwecka, J.H. Nolla, A. Butterfieldb, R.W. Collierc aLero, University of Limerick, Ireland bTrinity College Dublin, Dublin 2, Ireland cUniversity College Dublin, Belfield, Dublin 4, Ireland Abstract The number of programming languages is large [1] and steadily increasing [2].
    [Show full text]
  • Unfold/Fold Transformations and Loop Optimization of Logic Programs
    Unfold/Fold Transformations and Loop Optimization of Logic Programs Saumya K. Debray Department of Computer Science The University of Arizona Tucson, AZ 85721 Abstract: Programs typically spend much of their execution time in loops. This makes the generation of ef®cient code for loops essential for good performance. Loop optimization of logic programming languages is complicated by the fact that such languages lack the iterative constructs of traditional languages, and instead use recursion to express loops. In this paper, we examine the application of unfold/fold transformations to three kinds of loop optimization for logic programming languages: recur- sion removal, loop fusion and code motion out of loops. We describe simple unfold/fold transformation sequences for these optimizations that can be automated relatively easily. In the process, we show that the properties of uni®cation and logical variables can sometimes be used to generalize, from traditional languages, the conditions under which these optimizations may be carried out. Our experience suggests that such source-level transformations may be used as an effective tool for the optimization of logic pro- grams. 1. Introduction The focus of this paper is on the static optimization of logic programs. Speci®cally, we investigate loop optimization of logic programs. Since programs typically spend most of their time in loops, the generation of ef®cient code for loops is essential for good performance. In the context of logic programming languages, the situation is complicated by the fact that iterative constructs, such as for or while, are unavailable. Loops are usually expressed using recursive procedures, and loop optimizations have be considered within the general framework of inter- procedural optimization.
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • CSE421 Midterm Solutions —SOLUTION SET— 09 Mar 2012
    CSE421 Midterm Solutions —SOLUTION SET— 09 Mar 2012 This midterm exam consists of three types of questions: 1. 10 multiple choice questions worth 1 point each. These are drawn directly from lecture slides and intended to be easy. 2. 6 short answer questions worth 5 points each. You can answer as many as you want, but we will give you credit for your best four answers for a total of up to 20 points. You should be able to answer the short answer questions in four or five sentences. 3. 2 long answer questions worth 20 points each. Please answer only one long answer question. If you answer both, we will only grade one. Your answer to the long answer should span a page or two. Please answer each question as clearly and succinctly as possible. Feel free to draw pic- tures or diagrams if they help you to do so. No aids of any kind are permitted. The point value assigned to each question is intended to suggest how to allocate your time. So you should work on a 5 point question for roughly 5 minutes. CSE421 Midterm Solutions 09 Mar 2012 Multiple Choice 1. (10 points) Answer all ten of the following questions. Each is worth one point. (a) In the story that GWA (Geoff) began class with on Monday, March 4th, why was the Harvard student concerned about his grade? p He never attended class. He never arrived at class on time. He usually fell asleep in class. He was using drugs. (b) All of the following are inter-process (IPC) communication mechanisms except p shared files.
    [Show full text]
  • Bringing GNU Emacs to Native Code
    Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
    [Show full text]
  • A Right-To-Left Type System for Value Recursion
    1 A right-to-left type system for value recursion 61 2 62 3 63 4 Alban Reynaud Gabriel Scherer Jeremy Yallop 64 5 ENS Lyon, France INRIA, France University of Cambridge, UK 65 6 66 1 Introduction Seeking to address these problems, we designed and imple- 7 67 mented a new check for recursive definition safety based ona 8 In OCaml recursive functions are defined using the let rec opera- 68 novel static analysis, formulated as a simple type system (which we 9 tor, as in the following definition of factorial: 69 have proved sound with respect to an existing operational seman- 10 let rec fac x = if x = 0 then 1 70 tics [Nordlander et al. 2008]), and implemented as part of OCaml’s 11 else x * (fac (x - 1)) 71 type-checking phase. Our check was merged into the OCaml distri- 12 Beside functions, let rec can define recursive values, such as 72 bution in August 2018. 13 an infinite list ones where every element is 1: 73 Moving the check from the middle end to the type checker re- 14 74 let rec ones = 1 :: ones stores the desirable property that compilation of well-typed programs 15 75 Note that this “infinite” list is actually cyclic, and consists of asingle does not go wrong. This property is convenient for tools that reuse 16 76 cons-cell referencing itself. OCaml’s type-checker without performing compilation, such as 17 77 However, not all recursive definitions can be computed. The MetaOCaml [Kiselyov 2014] (which type-checks quoted code) and 18 78 following definition is justly rejected by the compiler: Merlin [Bour et al.
    [Show full text]
  • Precise Garbage Collection for C
    Precise Garbage Collection for C Jon Rafkind Adam Wick John Regehr Matthew Flatt University of Utah Galois, Inc. University of Utah University of Utah [email protected] [email protected] [email protected] mfl[email protected] Abstract no-ops. The resulting program usually runs about as well as before, Magpie is a source-to-source transformation for C programs that but without the ongoing maintenance burden of manual memory enables precise garbage collection, where precise means that inte- management. In our experience, however, conservative GC works gers are not confused with pointers, and the liveness of a pointer poorly for long-running programs, such as a web server, a program- is apparent at the source level. Precise GC is primarily useful for ming environment, or an operating system kernel. For such pro- long-running programs and programs that interact with untrusted grams, conservative GC can trigger unbounded memory use due to components. In particular, we have successfully deployed precise linked lists [Boehm 2002] that manage threads and continuations; GC in the C implementation of a language run-time system that was this problem is usually due to liveness imprecision [Hirzel et al. originally designed to use conservative GC. We also report on our 2002], rather than type imprecision. Furthermore, the programs experience in transforming parts of the Linux kernel to use precise are susceptible to memory-exhaustion attack from malicious code GC instead of manual memory management. (e.g., user programs or untrusted servlets) that might be otherwise restricted through a sandbox [Wick and Flatt 2004]. Categories and Subject Descriptors D.4.2 [Storage Manage- This paper describes our design of and experience with a GC ment]: Garbage Collection for C that is less conservative.
    [Show full text]
  • Man Pages Section 3 Library Interfaces and Headers
    man pages section 3: Library Interfaces and Headers Part No: 816–5173–16 September 2010 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related software documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are “commercial computer software” or “commercial technical data” pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms setforth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
    [Show full text]
  • Hop Client-Side Compilation
    Chapter 1 Hop Client-Side Compilation Florian Loitsch1, Manuel Serrano1 Abstract: Hop is a new language for programming interactive Web applications. It aims to replace HTML, JavaScript, and server-side scripting languages (such as PHP, JSP) with a unique language that is used for client-side interactions and server-side computations. A Hop execution platform is made of two compilers: one that compiles the code executed by the server, and one that compiles the code executed by the client. This paper presents the latter. In order to ensure compatibility of Hop graphical user interfaces with popular plain Web browsers, the client-side Hop compiler has to generate regular HTML and JavaScript code. The generated code runs roughly at the same speed as hand- written code. Since the Hop language is built on top of the Scheme program- ming language, compiling Hop to JavaScript is nearly equivalent to compiling Scheme to JavaScript. SCM2JS, the compiler we have designed, supports the whole Scheme core language. In particular, it features proper tail recursion. How- ever complete proper tail recursion may slow down the generated code. Despite an optimization which eliminates up to 40% of instrumentation for tail call in- tensive benchmarks, worst case programs were more than two times slower. As a result Hop only uses a weaker form of tail-call optimization which simplifies recursive tail-calls to while-loops. The techniques presented in this paper can be applied to most strict functional languages such as ML and Lisp. SCM2JS can be downloaded at http://www-sop.inria.fr/mimosa/person- nel/Florian.Loitsch/scheme2js/.
    [Show full text]
  • SI 413, Unit 3: Advanced Scheme
    SI 413, Unit 3: Advanced Scheme Daniel S. Roche ([email protected]) Fall 2018 1 Pure Functional Programming Readings for this section: PLP, Sections 10.7 and 10.8 Remember there are two important characteristics of a “pure” functional programming language: • Referential Transparency. This fancy term just means that, for any expression in our program, the result of evaluating it will always be the same. In fact, any referentially transparent expression could be replaced with its value (that is, the result of evaluating it) without changing the program whatsoever. Notice that imperative programming is about as far away from this as possible. For example, consider the C++ for loop: for ( int i = 0; i < 10;++i) { /∗ some s t u f f ∗/ } What can we say about the “stuff” in the body of the loop? Well, it had better not be referentially transparent. If it is, then there’s no point in running over it 10 times! • Functions are First Class. Another way of saying this is that functions are data, just like any number or list. Functions are values, in fact! The specific privileges that a function earns by virtue of being first class include: 1) Functions can be given names. This is not a big deal; we can name functions in pretty much every programming language. In Scheme this just means we can do (define (f x) (∗ x 3 ) ) 2) Functions can be arguments to other functions. This is what you started to get into at the end of Lab 2. For starters, there’s the basic predicate procedure?: (procedure? +) ; #t (procedure? 10) ; #f (procedure? procedure?) ; #t 1 And then there are “higher-order functions” like map and apply: (apply max (list 5 3 10 4)) ; 10 (map sqrt (list 16 9 64)) ; '(4 3 8) What makes the functions “higher-order” is that one of their arguments is itself another function.
    [Show full text]
  • A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems
    A FORMAL COMPONENT-BASED SOFTWARE ENGINEERING APPROACH FOR DEVELOPING TRUSTWORTHY SYSTEMS MUBARAK SAMI MOHAMMAD A THESIS IN THE DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING PRESENTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) CONCORDIA UNIVERSITY MONTREAL´ ,QUEBEC´ ,CANADA APRIL 2009 °c MUBARAK SAMI MOHAMMAD, 2009 CONCORDIA UNIVERSITY School of Graduate Studies This is to certify that the thesis prepared By: Mr. Mubarak Sami Mohammad Entitled: A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems and submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Science) (Computer Science) complies with the regulations of this University and meets the accepted standards with re- spect to originality and quality. Signed by the final examining committee: Chair Dr. External Examiner Dr. Nicholas Graham External to Program Dr. Jamal Bentahar Examiner Dr. Joey Paquet Examiner Dr. Juergen Rilling Supervisor Dr. Vasu Alagar Co-supervisor Dr. Olga Ormandjieva Approved Chair of Department or Graduate Program Director 20 Dr. Robin A.L. Drew, Dean Faculty of Engineering and Computer Science Abstract A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems Mubarak Sami Mohammad, Ph.D. Concordia University, 2009 Software systems are increasingly becoming ubiquitous, affecting the way we experience the world. Embedded software systems, especially those used in smart devices, have be- come an essential constituent of the technological infrastructure of modern societies. Such systems, in order to be trusted in society, must be proved to be trustworthy. Trustworthiness is a composite non-functional property that implies safety, timeliness, security, availability, and reliability.
    [Show full text]