Interpreting LISP by Gary D
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Writing Fast Fortran Routines for Python
Writing fast Fortran routines for Python Table of contents Table of contents ............................................................................................................................ 1 Overview ......................................................................................................................................... 2 Installation ...................................................................................................................................... 2 Basic Fortran programming ............................................................................................................ 3 A Fortran case study ....................................................................................................................... 8 Maximizing computational efficiency in Fortran code ................................................................. 12 Multiple functions in each Fortran file ......................................................................................... 14 Compiling and debugging ............................................................................................................ 15 Preparing code for f2py ................................................................................................................ 16 Running f2py ................................................................................................................................. 17 Help with f2py .............................................................................................................................. -
Scope in Fortran 90
Scope in Fortran 90 The scope of objects (variables, named constants, subprograms) within a program is the portion of the program in which the object is visible (can be use and, if it is a variable, modified). It is important to understand the scope of objects not only so that we know where to define an object we wish to use, but also what portion of a program unit is effected when, for example, a variable is changed, and, what errors might occur when using identifiers declared in other program sections. Objects declared in a program unit (a main program section, module, or external subprogram) are visible throughout that program unit, including any internal subprograms it hosts. Such objects are said to be global. Objects are not visible between program units. This is illustrated in Figure 1. Figure 1: The figure shows three program units. Main program unit Main is a host to the internal function F1. The module program unit Mod is a host to internal function F2. The external subroutine Sub hosts internal function F3. Objects declared inside a program unit are global; they are visible anywhere in the program unit including in any internal subprograms that it hosts. Objects in one program unit are not visible in another program unit, for example variable X and function F3 are not visible to the module program unit Mod. Objects in the module Mod can be imported to the main program section via the USE statement, see later in this section. Data declared in an internal subprogram is only visible to that subprogram; i.e. -
The Evolution of Lisp
1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp. -
(Pdf) of from Push/Enter to Eval/Apply by Program Transformation
From Push/Enter to Eval/Apply by Program Transformation MaciejPir´og JeremyGibbons Department of Computer Science University of Oxford [email protected] [email protected] Push/enter and eval/apply are two calling conventions used in implementations of functional lan- guages. In this paper, we explore the following observation: when considering functions with mul- tiple arguments, the stack under the push/enter and eval/apply conventions behaves similarly to two particular implementations of the list datatype: the regular cons-list and a form of lists with lazy concatenation respectively. Along the lines of Danvy et al.’s functional correspondence between def- initional interpreters and abstract machines, we use this observation to transform an abstract machine that implements push/enter into an abstract machine that implements eval/apply. We show that our method is flexible enough to transform the push/enter Spineless Tagless G-machine (which is the semantic core of the GHC Haskell compiler) into its eval/apply variant. 1 Introduction There are two standard calling conventions used to efficiently compile curried multi-argument functions in higher-order languages: push/enter (PE) and eval/apply (EA). With the PE convention, the caller pushes the arguments on the stack, and jumps to the function body. It is the responsibility of the function to find its arguments, when they are needed, on the stack. With the EA convention, the caller first evaluates the function to a normal form, from which it can read the number and kinds of arguments the function expects, and then it calls the function body with the right arguments. -
Remote Debugging and Reflection in Resource Constrained Devices Nikolaos Papoulias
Remote Debugging and Reflection in Resource Constrained Devices Nikolaos Papoulias To cite this version: Nikolaos Papoulias. Remote Debugging and Reflection in Resource Constrained Devices. Program- ming Languages [cs.PL]. Université des Sciences et Technologie de Lille - Lille I, 2013. English. tel-00932796 HAL Id: tel-00932796 https://tel.archives-ouvertes.fr/tel-00932796 Submitted on 17 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N° d’ordre : 41342 THESE présentée en vue d’obtenir le grade de DOCTEUR en Spécialité : informatique par Nikolaos Papoulias DOCTORAT DELIVRE CONJOINTEMENT PAR MINES DOUAI ET L’UNIVERSITE DE LILLE 1 Titre de la thèse : Remote Debugging and Reflection in Resource Constrained Devices Soutenue le 19/12/2013 à 10h devant le jury d’examen : Président Roel WUYTS (Professeur – Université de Leuven) Directeur de thèse Stéphane DUCASSE (Directeur de recherche – INRIA Lille) Rapporteur Marianne HUCHARD (Professeur – Université Montpellier 2) Rapporteur Alain PLANTEC (Maître-Conf-HDR – Université de Bretagne Occ.) Examinateur Serge STINCKWICH (Maître-Conf – Université de Caen) co-Encadrant Noury BOURAQADI (Maître-Assistant – Mines de Douai) co-Encadrant Marcus DENKER (Chargé de recherche – INRIA Lille) co-Encadrant Luc FABRESSE (Maître-Assistant – Mines de Douai) Laboratoire(s) d’accueil : Dépt. -
Stepping Ocaml
Stepping OCaml TsukinoFurukawa YouyouCong KenichiAsai Ochanomizu University Tokyo, Japan {furukawa.tsukino, so.yuyu, asai}@is.ocha.ac.jp Steppers, which display all the reduction steps of a given program, are a novice-friendly tool for un- derstanding program behavior. Unfortunately, steppers are not as popular as they ought to be; indeed, the tool is only available in the pedagogical languages of the DrRacket programming environment. We present a stepper for a practical fragment of OCaml. Similarly to the DrRacket stepper, we keep track of evaluation contexts in order to reconstruct the whole program at each reduction step. The difference is that we support effectful constructs, such as exception handling and printing primitives, allowing the stepper to assist a wider range of users. In this paper, we describe the implementationof the stepper, share the feedback from our students, and show an attempt at assessing the educational impact of our stepper. 1 Introduction Programmers spend a considerable amount of time and effort on debugging. In particular, novice pro- grammers may find this process extremely painful, since existing debuggers are usually not friendly enough to beginners. To use a debugger, we have to first learn what kinds of commands are available, and figure out which would be useful for the current purpose. It would be even harder to use the com- mand in a meaningful manner: for instance, to spot the source of an unexpected behavior, we must be able to find the right places to insert breakpoints, which requires some programming experience. Then, is there any debugging tool that is accessible to first-day programmers? In our view, the algebraic stepper [1] of DrRacket, a pedagogical programming environment for the Racket language, serves as such a tool. -
Subroutines – Get Efficient
Subroutines – get efficient So far: The code we have looked at so far has been sequential: Subroutines – getting efficient with Perl do this; do that; now do something; finish; Problem Bela Tiwari You need something to be done over and over, perhaps slightly [email protected] differently depending on the context Solution Environmental Genomics Thematic Programme Put the code in a subroutine and call the subroutine whenever needed. Data Centre http://envgen.nox.ac.uk Syntax: There are a number of correct ways you can define and use Subroutines – get efficient subroutines. One is: A subroutine is a named block of code that can be executed as many times #!/usr/bin/perl as you wish. some code here; some more here; An artificial example: lalala(); #declare and call the subroutine Instead of: a bit more code here; print “Hello everyone!”; exit(); #explicitly exit the program ############ You could use: sub lalala { #define the subroutine sub hello_sub { print "Hello everyone!\n“; } #subroutine definition code to define what lalala does; #code defining the functionality of lalala more defining lalala; &hello_sub; #call the subroutine return(); #end of subroutine – return to the program } Syntax: Outline review of previous slide: Subroutines – get efficient Syntax: #!/usr/bin/perl Permutations on the theme: lalala(); #call the subroutine Defining the whole subroutine within the script when it is first needed: sub hello_sub {print “Hello everyone\n”;} ########### sub lalala { #define the subroutine The use of an ampersand to call the subroutine: &hello_sub; return(); #end of subroutine – return to the program } Note: There are subtle differences in the syntax allowed and required by Perl depending on how you declare/define/call your subroutines. -
COBOL-Skills, Where Art Thou?
DEGREE PROJECT IN COMPUTER ENGINEERING 180 CREDITS, BASIC LEVEL STOCKHOLM, SWEDEN 2016 COBOL-skills, Where art Thou? An assessment of future COBOL needs at Handelsbanken Samy Khatib KTH ROYAL INSTITUTE OF TECHNOLOGY i INFORMATION AND COMMUNICATION TECHNOLOGY Abstract The impending mass retirement of baby-boomer COBOL developers, has companies that wish to maintain their COBOL systems fearing a skill shortage. Due to the dominance of COBOL within the financial sector, COBOL will be continually developed over at least the coming decade. This thesis consists of two parts. The first part consists of a literature study of COBOL; both as a programming language and the skills required as a COBOL developer. Interviews were conducted with key Handelsbanken staff, regarding the current state of COBOL and the future of COBOL in Handelsbanken. The second part consists of a quantitative forecast of future COBOL workforce state in Handelsbanken. The forecast uses data that was gathered by sending out a questionnaire to all COBOL staff. The continued lack of COBOL developers entering the labor market may create a skill-shortage. It is crucial to gather the knowledge of the skilled developers before they retire, as changes in old COBOL systems may have gone undocumented, making it very hard for new developers to understand how the systems work without guidance. To mitigate the skill shortage and enable modernization, an extraction of the business knowledge from the systems should be done. Doing this before the current COBOL workforce retires will ease the understanding of the extracted data. The forecasts of Handelsbanken’s COBOL workforce are based on developer experience and hiring, averaged over the last five years. -
A Practical Introduction to Python Programming
A Practical Introduction to Python Programming Brian Heinold Department of Mathematics and Computer Science Mount St. Mary’s University ii ©2012 Brian Heinold Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported Li- cense Contents I Basics1 1 Getting Started 3 1.1 Installing Python..............................................3 1.2 IDLE......................................................3 1.3 A first program...............................................4 1.4 Typing things in...............................................5 1.5 Getting input.................................................6 1.6 Printing....................................................6 1.7 Variables...................................................7 1.8 Exercises...................................................9 2 For loops 11 2.1 Examples................................................... 11 2.2 The loop variable.............................................. 13 2.3 The range function............................................ 13 2.4 A Trickier Example............................................. 14 2.5 Exercises................................................... 15 3 Numbers 19 3.1 Integers and Decimal Numbers.................................... 19 3.2 Math Operators............................................... 19 3.3 Order of operations............................................ 21 3.4 Random numbers............................................. 21 3.5 Math functions............................................... 21 3.6 Getting -
Subroutines and Control Abstraction
Subroutines and Control Abstraction CSE 307 – Principles of Programming Languages Stony Brook University http://www.cs.stonybrook.edu/~cse307 1 Subroutines Why use subroutines? Give a name to a task. We no longer care how the task is done. The subroutine call is an expression Subroutines take arguments (in the formal parameters) Values are placed into variables (actual parameters/arguments), and A value is (usually) returned 2 (c) Paul Fodor (CS Stony Brook) and Elsevier Review Of Memory Layout Allocation strategies: Static Code Globals Explicit constants (including strings, sets, other aggregates) Small scalars may be stored in the instructions themselves Stack parameters local variables temporaries bookkeeping information Heap 3 dynamic allocation(c) Paul Fodor (CS Stony Brook) and Elsevier Review Of Stack Layout 4 (c) Paul Fodor (CS Stony Brook) and Elsevier Review Of Stack Layout Contents of a stack frame: bookkeeping return Program Counter saved registers line number static link arguments and returns local variables temporaries 5 (c) Paul Fodor (CS Stony Brook) and Elsevier Calling Sequences Maintenance of stack is responsibility of calling sequence and subroutines prolog and epilog Tasks that must be accomplished on the way into a subroutine include passing parameters, saving the return address, changing the program counter, changing the stack pointer to allocate space, saving registers (including the frame pointer) that contain important values and that may be overwritten by the callee, changing the frame pointer to refer to the new frame, and executing initialization code for any objects in the new frame that require it. Tasks that must be accomplished on the way out include passing return parameters or function values, executing finalization code for any local objects that require it, deallocating the stack frame (restoring the stack pointer), restoring other saved registers (including the frame pointer), and restoring the program counter. -
Making a Faster Curry with Extensional Types
Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004]. -
A Subroutine's Stack Frames Differently • May Require That the Steps Involved in Calling a Subroutine Be Performed in Different Orders
Chapter 04: Instruction Sets and the Processor organizations Lesson 14 Use of the Stack Frames Schaum’s Outline of Theory and Problems of Computer Architecture 1 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Objective • To understand call and return, nested calls and use of stack frames Schaum’s Outline of Theory and Problems of Computer Architecture 2 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Calling a subroutine Schaum’s Outline of Theory and Problems of Computer Architecture 3 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Calls to the subroutines • Allow commonly used functions to be written once and used whenever they are needed, and provide abstraction, making it easier for multiple programmers to collaborate on a program • Important part of virtually all computer languages • Function calls in a C language program • Also included additional functions from library by including the header files Schaum’s Outline of Theory and Problems of Computer Architecture 4 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Difficulties when Calling a subroutine Schaum’s Outline of Theory and Problems of Computer Architecture 5 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Difficulties involved in implementing subroutine calls 1. Programs need a way to pass inputs to subroutines that they call and to receive outputs back from them Schaum’s Outline of Theory and Problems of Computer Architecture 6 Copyright © The McGraw-Hill Companies Inc. Indian Special Edition 2009 Difficulties involved in implementing subroutine calls 2. Subroutines need to be able to allocate space in memory for local variables without overwriting any data used by the subroutine-calling program Schaum’s Outline of Theory and Problems of Computer Architecture 7 Copyright © The McGraw-Hill Companies Inc.