DOCSLIB.ORG

Performance of Programs Written in Different Programming Languages Ryan Stansifer Florida Institute of Technology the Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Performance of Programs Written in Different Programming Languages Ryan Stansifer Florida Institute of Technology the Languages Performance of Programs Written in Different Programming Languages Ryan Stansifer Florida Institute of Technology The Languages • Ada (GNAT) • Haskell (GHC) • C (GNU) • Java • C++ (GNU) • Lua • C# (Mono) • Pascal • Fortran (GNU) • Python 2 • Go • Python 3 • Scala A is for Ada Ada is a structured, statically typed, imperative, high-level computer programming language, extended from Pascal and other languages. It has language support for design-by-contract, strong typing, explicit concurrency, offering tasks, synchronous message passing, protected objects, and non-determinism. C is for C C is a general-purpose, imperative computer programming language, supporting structured programming, lexical variable scope and recursion. C provides constructs that map efficiently to typical machine instructions. C is for C++ C++ is a middle-level programming language developed by Bjarne Stroustrup starting in 1979 at Bell Labs. C++ runs on a variety of platforms, such as Windows, Mac OS, and the various versions of UNIX. C is for C# C# is a general-purpose, object-oriented programming language. It was developed by Microsoft within its .NET initiative. F is for Fortran Fortran is an imperative programming language suited for numeric and scientific computation that has gone through many decades of revisions. F is for F# F# is developed by the F# Software Foundation, Microsoft and open contributors. An open source, cross-platform compiler for F# is available. F# is also a fully supported language in Visual Studio and Xamarin Studio. Other tools supporting F# development include Mono. F# originated as .NET implementation of a core of the OCaml programming language. G is for Go Go is an open source programming language created at Google in 2007. It is a compiled, statically typed language in the tradition of Algol and C, with garbage collection, memory safety features and CSP-style concurrent programming features added. H is for Haskell Haskell is a standardized, general-purpose purely functional programming language, with non-strict semantics and strong static typing. It is named after logician Haskell Curry. J is for Java Java is an imperative, object-oriented programming language designed as an improvement over C++. L is for Lua Lua (LOO-ə, from Portuguese: meaning moon) is a lightweight multi- paradigm programming language designed primarily for embedded systems and clients. O is for OCaml OCaml, originally known as Objective Caml, is the main implementation of the Caml programming language. OCaml is a free open source project managed and principally maintained by INRIA. Many newer languages have drawn elements from OCaml, most notably F# and Scala. P is for Pascal Pascal is a historically influential imperative and procedural programming language, designed in 1968–69 and published in 1970 by Niklaus Wirth as a small and efficient language intended to encourage good programming practices using structured programming and data structuring. P is for Python Python is a widely used high-level, general-purpose, interpreted, dynamic programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than would be possible in other. R is for Rust Rust is a general-purpose, multi-paradigm, compiled programming language sponsored by Mozilla Research. It is designed to be a "safe, concurrent, practical language", supporting pure-functional, imperative- procedural, and object-oriented styles. S is for Scala Scala is object-oriented, and uses a curly-brace syntax reminiscent of the C programming language. Scala has many features of functional programming languages like Scheme, Standard ML and Haskell, including currying, type inference, immutability, lazy evaluation, and pattern matching. It also has an advanced type system supporting algebraic data types, covariance and contravariance, higher-order types, and anonymous types. Hardware on hc210-059044 Processors 8 Model name Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz Cpu cores 4 Bogomips 7183.69 Hardware on ip-172-31-11-81 Amazon Cloud Processors 2 Model name Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz Cpu cores 1 Bogomips 5800.13 Versions on hc210-059044 Language Version Ada (Gnat) GNATMAKE GPL 2015 (20150428-49) C/C++/Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 C# (Mono) Mono C# compiler version 3.2.8.0 Go go version go1.2.1 linux/amd64 Haskell (ghc) The Glorious Glasgow Haskell Compilation System, version 7.6.3 Java javac 1.8.0_91 Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) Lua Lua 5.2.3 Copyright (C) 1994-2013 Lua.org, PUC-Rio Pascal (fpc) 2014/01/22 2.6.2-8 Python 2 Python 2.7.6 Python 3 Python 3.4.3 Scala Scala compiler version 2.12.0-M2 -- Copyright 2002-2013, LAMP/EPFL Scala code runner version 2.12.0-M2 -- Copyright 2002-2013, LAMP/EPFL Versions on ip-172-31-11-81 Language Version Ada (Gnat) GNATMAKE 4.6 C/C++/Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 C# (mono) Mono C# compiler version 3.2.8.0 Go go version go1.2.1 linux/amd64 Haskell (ghc) The Glorious Glasgow Haskell Compilation System, version 7.6.3 Java javac 1.8.0_66 Java(TM) SE Runtime Environment (build 1.8.0_66-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) Lua Lua 5.2.3 Copyright (C) 1994-2013 Lua.org, PUC-Rio Pascal (fpc) 2014/01/22 2.6.2-8 Python 2 Python 2.7.6 Python 3 Python 3.4.3 Scala Scala compiler version 2.11.7-M2 -- Copyright 2002-2013, LAMP/EPFL Scala code runner version 2.11.7-M2 -- Copyright 2002-2013, LAMP/EPFL Compiler Flags/Options Ada (Gnat) gnatmake –f is –O2 {exec} {file} C (clang) clang –o {exec} {file} C (GNU) gcc –std=gnul11 –O2 –w –o {exec} {file} C++ (GNU) g++ -O2 –w –o {exec} {file} C# (Mono) mcs –out:{exec} {file} Fortran (GNU) gfortran –O2 –o {exec} {file} Go go build –o {exec} {file} Haskell (ghc) ghc –fforce-recomp –O2 –outputdir ./build –o {exec} {file} Java javac –d ./build {file}; jar cevf {base} {exec} –C ./build java –jar {exec} Pascal (fpc) fpc –O2 –Sa –o{exec} {file} Scala scalac –deprecation –d {exec} {file} scala {exec} Methodology: Python wall-clock time • Python script start_time = time.time() subprocess.call (<run command>, stdin=<test case>, stdout=NULL, stderr=NULL, timeout=100) clocktime = time.time()-start_time The Problems Tag Source Title Note balancing USACO, February 2016 Load Balancing O(n^3) / scan / Fenwick Trees (617,619,624) heart ACM ICPC SER, 2008 Heart of the County Iterative fixed point lawrence ACM ICPC SER, 2008 Lawrence of Arabia DP, precomputation, partial sums rare ACM ICPC World Finals, 1990 Rare Order Topological sort cheese ACM ICPC World Finals, 2015 Cutting Cheese Binary search, 3D geometry sort O(n log n) quadratic O(n^2) cubic O(n^3) Results Old Results Generally consistent even though completely different version and platform Time Compared with to C 512 256 128 64 Python3 Python2 32 Lua Haskell C# 16 Scala Pascal 8 Java Ada Number of times Number times of compared C to C 4 C++ Fortran 2 1 0.5 200 250 300 350 400 450 500 N, the size of the problem instance "Lawrence of Arabia" Time Compared to C for "Heart of the Country" 128 64 Haskell Python3 32 Lua Java 16 Fortran Python2 Scala 8 Ada C++ times times the C program C# 4 C Pascal 2 1 0.5 0 100 200 300 400 500 600 700 800 900 1000 "Heart of the Country" Ratio Program Time (seconds) 1.00 C gcc 1.73 1.00 Pascal Free Pascal #3 1.73 1.00 Rust 1.76 The Computer Language Benchmarks Game 1.10 Fortran Intel #3 1.92 pidigits 1.10 Lua #5 1.94 1.30 Racket #2 2.18 1.30 Python 3 #5 2.20 1.30 C++ g++ #3 2.29 1.30 Ada 2005 GNAT #2 2.29 1.30 C gcc #4 2.30 1.60 Haskell GHC #4 2.83 1.70 Go 2.85 1.70 Scala #4 2.97 1.80 Java #2 3.11 6.50 F# Mono #3 11.19 The Computer Language Benchmarks Game: Python 3 versus C (Gnu) Benchmark Python C Ratio Pidigits 2.20 1.73 1.28 Regex-dna 10.58 2.46 4.30 Reverse-complement 3.11 0.62 5.02 K-nucleotide 76.50 12.53 6.11 Binary-trees 152.06 3.26 46.64 Mandlebrot 293.92 5.92 49.65 Fannkuch-redux 567.35 8.97 63.25 Fasta 111.44 1.36 81.94 N-body 923.74 9.56 96.63 Future Work • F#, Rust, OCaml, … • Java 8 – streams • Haskell – lazy dynamic programming • Lazy versus eager functional programming • Clang • Compiler options On-line Repository • A trusting person can repeat the experiment wget https://ser.cs.fit.edu/testing/time.sh | /bin/sh • (This takes a very long time.) • This also downloads all the source code and all the test cases • John Clevenger, “Performance Analysis of Virtual vs. Physical Machines for Automated Judging in Programming Contests”, Competitive Learning Institute, 2015. • The Computer Language Benchmarks Game, http://benchmarksgame.alioth.debian.org/.
Load more

Recommended publications
  • CSCI 2041: Lazy Evaluation
    CSCI 2041: Lazy Evaluation Chris Kauffman Last Updated: Wed Dec 5 12:32:32 CST 2018 1 Logistics Reading Lab13: Lazy/Streams I Module Lazy on lazy Covers basics of delayed evaluation computation I Module Stream on streams A5: Calculon Lambdas/Closures I Arithmetic language Briefly discuss these as they interpreter pertain Calculon I 2X credit for assignment I 5 Required Problems 100pts Goals I 5 Option Problems 50pts I Eager Evaluation I Milestone due Wed 12/5 I Lazy Evaluation I Final submit Tue 12/11 I Streams 2 Evaluation Strategies Eager Evaluation Lazy Evaluation I Most languages employ I An alternative is lazy eager evaluation evaluation I Execute instructions as I Execute instructions only as control reaches associated expression results are needed code (call by need) I Corresponds closely to I Higher-level idea with actual machine execution advantages and disadvantages I In pure computations, evaluation strategy doesn’t matter: will produce the same results I With side-effects, when code is run matter, particular for I/O which may see different printing orders 3 Exercise: Side-Effects and Evaluation Strategy Most common place to see differences between Eager/Lazy eval is when functions are called I Eager eval: eval argument expressions, call functions with results I Lazy eval: call function with un-evaluated expressions, eval as results are needed Consider the following expression let print_it expr = printf "Printing it\n"; printf "%d\n" expr; ;; print_it (begin printf "Evaluating\n"; 5; end);; Predict results and output for both Eager and Lazy Eval strategies 4 Answers: Side-Effects and Evaluation Strategy let print_it expr = printf "Printing it\n"; printf "%d\n" expr; ;; print_it (begin printf "Evaluating\n"; 5; end);; Evaluation > ocamlc eager_v_lazy.ml > ./a.out Eager Eval # ocaml’s default Evaluating Printing it 5 Lazy Eval Printing it Evaluating 5 5 OCaml and explicit lazy Computations I OCaml’s default model is eager evaluation BUT.
    [Show full text]
  • Scala−−, a Type Inferred Language Project Report
    Scala−−, a type inferred language Project Report Da Liu [email protected] Contents 1 Background 2 2 Introduction 2 3 Type Inference 2 4 Language Prototype Features 3 5 Project Design 4 6 Implementation 4 6.1 Benchmarkingresults . 4 7 Discussion 9 7.1 About scalac ....................... 9 8 Lessons learned 10 9 Language Specifications 10 9.1 Introdution ......................... 10 9.2 Lexicalsyntax........................ 10 9.2.1 Identifiers ...................... 10 9.2.2 Keywords ...................... 10 9.2.3 Literals ....................... 11 9.2.4 Punctions ...................... 12 9.2.5 Commentsandwhitespace. 12 9.2.6 Operations ..................... 12 9.3 Syntax............................ 12 9.3.1 Programstructure . 12 9.3.2 Expressions ..................... 14 9.3.3 Statements ..................... 14 9.3.4 Blocksandcontrolflow . 14 9.4 Scopingrules ........................ 16 9.5 Standardlibraryandcollections. 16 9.5.1 println,mapandfilter . 16 9.5.2 Array ........................ 16 9.5.3 List ......................... 17 9.6 Codeexample........................ 17 9.6.1 HelloWorld..................... 17 9.6.2 QuickSort...................... 17 1 of 34 10 Reference 18 10.1Typeinference ....................... 18 10.2 Scalaprogramminglanguage . 18 10.3 Scala programming language development . 18 10.4 CompileScalatoLLVM . 18 10.5Benchmarking. .. .. .. .. .. .. .. .. .. .. 18 11 Source code listing 19 1 Background Scala is becoming drawing attentions in daily production among var- ious industries. Being as a general purpose programming language, it is influenced by many ancestors including, Erlang, Haskell, Java, Lisp, OCaml, Scheme, and Smalltalk. Scala has many attractive features, such as cross-platform taking advantage of JVM; as well as with higher level abstraction agnostic to the developer providing immutability with persistent data structures, pattern matching, type inference, higher or- der functions, lazy evaluation and many other functional programming features.
    [Show full text]
  • Type-Safe Multi-Tier Programming with Standard ML Modules
    Experience Report: Type-Safe Multi-Tier Programming with Standard ML Modules Martin Elsman Philip Munksgaard Ken Friis Larsen Department of Computer Science, iAlpha AG, Switzerland Department of Computer Science, University of Copenhagen, Denmark [email protected] University of Copenhagen, Denmark [email protected] kfl[email protected] Abstract shared module, it is now possible, on the server, to implement a We describe our experience with using Standard ML modules and module that for each function responds to a request by first deseri- Standard ML’s core language typing features for ensuring type- alising the argument into a value, calls the particular function and safety across physically separated tiers in an extensive web applica- replies to the client with a serialised version of the result value. tion built around a database-backed server platform and advanced Dually, on the client side, for each function, the client code can client code that accesses the server through asynchronous server serialise the argument and send the request asynchronously to the requests. server. When the server responds, the client will deserialise the re- sult value and apply the handler function to the value. Both for the server part and for the client part, the code can be implemented in 1. Introduction a type-safe fashion. In particular, if an interface type changes, the The iAlpha Platform is an advanced asset management system programmer will be notified about all type-inconsistencies at com- featuring a number of analytics modules for combining trading pile
    [Show full text]
  • The Scala Experience Safe Programming Can Be Fun!
    The Scala Programming Language Mooly Sagiv Slides taken from Martin Odersky (EPFL) Donna Malayeri (CMU) Hila Peleg (Technion) Modern Functional Programming • Higher order • Modules • Pattern matching • Statically typed with type inference • Two viable alternatives • Haskel • Pure lazy evaluation and higher order programming leads to Concise programming • Support for domain specific languages • I/O Monads • Type classes • ML/Ocaml/F# • Eager call by value evaluation • Encapsulated side-effects via references • [Object orientation] Then Why aren’t FP adapted? • Education • Lack of OO support • Subtyping increases the complexity of type inference • Programmers seeks control on the exact implementation • Imperative programming is natural in certain situations Why Scala? (Coming from OCaml) • Runs on the JVM/.NET • Can use any Java code in Scala • Combines functional and imperative programming in a smooth way • Effective libraries • Inheritance • General modularity mechanisms The Java Programming Language • Designed by Sun 1991-95 • Statically typed and type safe • Clean and Powerful libraries • Clean references and arrays • Object Oriented with single inheritance • Interfaces with multiple inheritance • Portable with JVM • Effective JIT compilers • Support for concurrency • Useful for Internet Java Critique • Downcasting reduces the effectiveness of static type checking • Many of the interesting errors caught at runtime • Still better than C, C++ • Huge code blowouts • Hard to define domain specific knowledge • A lot of boilerplate code •
    [Show full text]
  • 1 Ocaml for the Masses
    PROGRAMMING LANGUAGES OCaml for the Masses Why the next language you learn should be functional Yaron Minsky, Jane Street Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function. - John Carmack Functional programming is an old idea with a distinguished history. Lisp, a functional language inspired by Alonzo Church’s lambda calculus, was one of the first programming languages developed at the dawn of the computing age. Statically typed functional languages such as OCaml and Haskell are newer, but their roots go deep—ML, from which they descend, dates back to work by Robin Milner in the early ’70s relating to the pioneering LCF (Logic for Computable Functions) theorem prover. Functional programming has also been enormously influential. Many fundamental advances in programming language design, from garbage collection to generics to type inference, came out of the functional world and were commonplace there decades before they made it to other languages. Yet functional languages never really made it to the mainstream. They came closest, perhaps, in the days of Symbolics and the Lisp machines, but those days seem quite remote now. Despite a resurgence of functional programming in the past few years, it remains a technology more talked about than used. It is tempting to conclude from this record that functional languages don’t have what it takes. They may make sense for certain limited applications, and contain useful concepts to be imported into other languages; but imperative and object-oriented languages are simply better suited to the vast majority of software engineering tasks.
    [Show full text]
  • An Overview of the Scala Programming Language
    An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips.
    [Show full text]
  • How to Run Your Favorite Language on Web Browsers
    Benjamin Canou, Emmanuel Chailloux and Jérôme Vouillon Laboratoire d'Informatique de Paris 6 (LIP6) Laboratoire Preuves Programmes et Systèmes (PPS) How to Run your Favorite. Language on Browsers The Revenge of Virtual Machines WWW 2012, Lyon, France Introduction. Introduction . 3/20 What ? I You have a favorite language I You have just designed or extended one I You want to run it on a Web browser Why ? I To program a new Web app I To program your client with the same language than your server I To run an online demo of an existing app Introduction . 4/20 How ? I Use applets I Write an interpreter in JavaScript I Write a compiler to JavaScript Or as we present in this talk: I Reuse the language bytecode compiler I Write a bytecode interpreter in JavaScript I Write a bytecode to JavaScript expander Introduction . 5/20 An experiment report: I Project Ocsigen: use OCaml to code entire Web apps I OBrowser: an OCaml bytecode interpreter I js_of_ocaml: an OCaml bytecode expander Retrospectively, a good approach: I Reasonable time to obtain a first platform I Good performance achievable I Fidelity to language/concurrency models Core techniques. Bytecode interpretation (1/3). 7/20 Main method: 1. Make the bytecode file network compliant (ex. JSON array) 2. Choose/implement the representation of values 3. Write a minimal runtime and standard library 4. Write the main interpretation loop 5. Run tests and extend the library as needed Possible improvements: I Use core, well supported/optimized JavaScript control structures I Use simple, array based memory representation I Preliminary bytecode cleanup pass Bytecode interpretation (2/3).
    [Show full text]
  • Four Lectures on Standard ML
    Mads Tofte March Lab oratory for Foundations of Computer Science Department of Computer Science Edinburgh University Four Lectures on Standard ML The following notes give an overview of Standard ML with emphasis placed on the Mo dules part of the language The notes are to the b est of my knowledge faithful to The Denition of Standard ML Version as regards syntax semantics and terminology They have b een written so as to b e indep endent of any particular implemen tation The exercises in the rst lectures can b e tackled without the use of a machine although having access to an implementation will no doubt b e b enecial The pro ject in Lecture presupp oses access to an implementation of the full language including mo dules At present the Edinburgh compiler do es not fall into this category the author used the New Jersey Standard ML compiler Lecture gives an introduction to ML aimed at the reader who is familiar with some programming language but do es not know ML Both the Core Language and the Mo dules are covered by way of example Lecture discusses the use of ML mo dules in the development of large programs A useful metho dology for programming with functors signatures and structures is presented Lecture gives a fairly detailed account of the static semantics of ML mo dules for those who really want to understand the crucial notions of sharing and signature matching Lecture presents a one day pro ject intended to give the student an opp ortunity of mo difying a nontrivial piece of software using functors signatures and structures
    [Show full text]
  • Lisp: Final Thoughts
    20 Lisp: Final Thoughts Both Lisp and Prolog are based on formal mathematical models of computation: Prolog on logic and theorem proving, Lisp on the theory of recursive functions. This sets these languages apart from more traditional languages whose architecture is just an abstraction across the architecture of the underlying computing (von Neumann) hardware. By deriving their syntax and semantics from mathematical notations, Lisp and Prolog inherit both expressive power and clarity. Although Prolog, the newer of the two languages, has remained close to its theoretical roots, Lisp has been extended until it is no longer a purely functional programming language. The primary culprit for this diaspora was the Lisp community itself. The pure lisp core of the language is primarily an assembly language for building more complex data structures and search algorithms. Thus it was natural that each group of researchers or developers would “assemble” the Lisp environment that best suited their needs. After several decades of this the various dialects of Lisp were basically incompatible. The 1980s saw the desire to replace these multiple dialects with a core Common Lisp, which also included an object system, CLOS. Common Lisp is the Lisp language used in Part III. But the primary power of Lisp is the fact, as pointed out many times in Part III, that the data and commands of this language have a uniform structure. This supports the building of what we call meta-interpreters, or similarly, the use of meta-linguistic abstraction. This, simply put, is the ability of the program designer to build interpreters within Lisp (or Prolog) to interpret other suitably designed structures in the language.
    [Show full text]
  • A Separate Compilation Extension to Standard ML
    A Separate Compilation Extension to Standard ML David Swasey Tom Murphy VII Karl Crary Robert Harper Carnegie Mellon {swasey,tom7,crary,rwh}@cs.cmu.edu Abstract The goal of this work is to consolidate and synthesize previ- We present an extension to Standard ML, called SMLSC, to support ous work on compilation management for ML into a formally de- separate compilation. The system gives meaning to individual pro- fined extension to the Standard ML language. The extension itself gram fragments, called units. Units may depend on one another in a is syntactically and conceptually very simple. A unit is a series of way specified by the programmer. A dependency may be mediated Standard ML top-level declarations, given a name. To the current by an interface (the type of a unit); if so, the units can be compiled top-level declarations such as structure and functor we add an separately. Otherwise, they must be compiled in sequence. We also import declaration that is to units what the open declaration is to propose a methodology for programming in SMLSC that reflects structures. An import declaration may optionally specify an inter- code development practice and avoids syntactic repetition of inter- face for the unit, in which case we are able to compile separately faces. The language is given a formal semantics, and we argue that against that dependency; with no interface we must compile incre- this semantics is implementable in a variety of compilers. mentally. Compatibility with existing compilers, including whole- program compilers, is assured by making no commitment to the Categories and Subject Descriptors D.3.3 [Programming Lan- precise meaning of “compile” and “link”—a compiler is free to guages]: Language Constructs and Features—Modules, pack- limit compilation to elaboration and type checking, and to perform ages; D.3.1 [Programming Languages]: Formal Definitions and code generation as part of linking.
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • Control Flow
    Control Flow COMS W4115 Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science Control Flow “Time is Nature’s way of preventing everything from happening at once.” Scott identifies seven manifestations of this: 1. Sequencing foo(); bar(); 2. Selection if (a) foo(); 3. Iteration while (i<10) foo(i); 4. Procedures foo(10,20); 5. Recursion foo(int i) { foo(i-1); } 6. Concurrency foo() jj bar() 7. Nondeterminism do a -> foo(); [] b -> bar(); Ordering Within Expressions What code does a compiler generate for a = b + c + d; Most likely something like tmp = b + c; a = tmp + d; (Assumes left-to-right evaluation of expressions.) Order of Evaluation Why would you care? Expression evaluation can have side-effects. Floating-point numbers don’t behave like numbers. Side-effects int x = 0; int foo() { x += 5; return x; } int a = foo() + x + foo(); What’s the final value of a? Side-effects int x = 0; int foo() { x += 5; return x; } int a = foo() + x + foo(); GCC sets a=25. Sun’s C compiler gave a=20. C says expression evaluation order is implementation-dependent. Side-effects Java prescribes left-to-right evaluation. class Foo { static int x; static int foo() { x += 5; return x; } public static void main(String args[]) { int a = foo() + x + foo(); System.out.println(a); } } Always prints 20. Number Behavior Basic number axioms: a + x = a if and only if x = 0 Additive identity (a + b) + c = a + (b + c) Associative a(b + c) = ab + ac Distributive Misbehaving Floating-Point Numbers 1e20 + 1e-20 = 1e20 1e-20 1e20 (1 + 9e-7) + 9e-7 6= 1 + (9e-7 + 9e-7) 9e-7 1, so it is discarded, however, 1.8e-6 is large enough 1:00001(1:000001 − 1) 6= 1:00001 · 1:000001 − 1:00001 · 1 1:00001 · 1:000001 = 1:00001100001 requires too much intermediate precision.
    [Show full text]