LISP 1.5 Programmer's Manual
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 .............................................................................................................................. -
Document Number Scco24
Stanford University Libraries Dept. of Special Cr*l!«ctkjns &>W Title Box Series I Fol 5C Fo<. Title " LISP/360 REFERENCE MANUAL FOURTH EDITION # CAMPUS COMPUTER FACILITY STANFORD COMPUTATION CENTER STANFORD UNIVERSITY STANFORD, CALIFORNIA DOCUMENT NUMBER SCCO24 " ■ " PREFACE This manual is intended to provide the LISP 1.5 user with a reference manual for the LISP 1.5 interpreter, assembler, and compiler on the Campus Facility 360/67. It assumes that the reader has a working knowledge by of LISP 1.5 as described in the LISP_I.is_Primer Clark Weissman, and that the reader has a general knowledge of the operating environment of OS 360. Beginning users of LISP will find the sections The , Functions, LI SRZIi O_Syst em , Organiz ation_of_St orage tlSP_Job_Set-]i£» and t.tsp/360 System Messages Host helpful in obtaining a basic understanding of the LISP system. Other sections of the manual are intended for users desiring a more extensive knowledge of LISP. The particular implementation to which this reference manual is directed was started by Mr. J. Kent while he was at the University of Waterloo. It is modeled after his implemention of LISP 1.5 for the CDC 3600. Included in this edition is information on the use of the time-shared LISP system available on the 360/67 which was implemented by Mr. Robert Berns of the " Computer staff. Campus Facility " II TABLE OF CONTENTS Section PREFACE " TABLE OF CONTENTS xxx 1. THE LISP/360 SYSTEM 1 2. ORGANIZATION OF STORAGE 3 2.1 Free Cell Storage (FCS) 3 2.1.1 Atoms 5 2.1.2 Numbers 8 2.1.3 Object List 9 2.2 Push-down Stack (PDS) 9 2.3 System Functions 9 2.4 Binary Program Space (BPS) 9 W 2.5 Input/Output Buffers 9 10 3. -
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. -
Implementing a Vau-Based Language with Multiple Evaluation Strategies
Implementing a Vau-based Language With Multiple Evaluation Strategies Logan Kearsley Brigham Young University Introduction Vau expressions can be simply defined as functions which do not evaluate their argument expressions when called, but instead provide access to a reification of the calling environment to explicitly evaluate arguments later, and are a form of statically-scoped fexpr (Shutt, 2010). Control over when and if arguments are evaluated allows vau expressions to be used to simulate any evaluation strategy. Additionally, the ability to choose not to evaluate certain arguments to inspect the syntactic structure of unevaluated arguments allows vau expressions to simulate macros at run-time and to replace many syntactic constructs that otherwise have to be built-in to a language implementation. In principle, this allows for significant simplification of the interpreter for vau expressions; compared to McCarthy's original LISP definition (McCarthy, 1960), vau's eval function removes all references to built-in functions or syntactic forms, and alters function calls to skip argument evaluation and add an implicit env parameter (in real implementations, the name of the environment parameter is customizable in a function definition, rather than being a keyword built-in to the language). McCarthy's Eval Function Vau Eval Function (transformed from the original M-expressions into more familiar s-expressions) (define (eval e a) (define (eval e a) (cond (cond ((atom e) (assoc e a)) ((atom e) (assoc e a)) ((atom (car e)) ((atom (car e)) (cond (eval (cons (assoc (car e) a) ((eq (car e) 'quote) (cadr e)) (cdr e)) ((eq (car e) 'atom) (atom (eval (cadr e) a))) a)) ((eq (car e) 'eq) (eq (eval (cadr e) a) ((eq (caar e) 'vau) (eval (caddr e) a))) (eval (caddar e) ((eq (car e) 'car) (car (eval (cadr e) a))) (cons (cons (cadar e) 'env) ((eq (car e) 'cdr) (cdr (eval (cadr e) a))) (append (pair (cadar e) (cdr e)) ((eq (car e) 'cons) (cons (eval (cadr e) a) a)))))) (eval (caddr e) a))) ((eq (car e) 'cond) (evcon. -
Mccarthy.Pdf
HISTORY OF LISP John McCarthy A rtificial Intelligence Laboratory Stanford University 1. Introduction. 2. LISP prehistory - Summer 1956 through Summer 1958. This paper concentrates on the development of the basic My desire for an algebraic list processing language for ideas and distinguishes two periods - Summer 1956 through artificial intelligence work on the IBM 704 computer arose in the Summer 1958 when most of the key ideas were developed (some of summer of 1956 during the Dartmouth Summer Research Project which were implemented in the FORTRAN based FLPL), and Fall on Artificial Intelligence which was the first organized study of AL 1958 through 1962 when the programming language was During this n~eeting, Newell, Shaa, and Fimon described IPL 2, a implemented and applied to problems of artificial intelligence. list processing language for Rand Corporation's JOHNNIAC After 1962, the development of LISP became multi-stranded, and different ideas were pursued in different places. computer in which they implemented their Logic Theorist program. There was little temptation to copy IPL, because its form was based Except where I give credit to someone else for an idea or on a JOHNNIAC loader that happened to be available to them, decision, I should be regarded as tentatively claiming credit for It and because the FORTRAN idea of writing programs algebraically or else regarding it as a consequence of previous decisions. was attractive. It was immediately apparent that arbitrary However, I have made mistakes about such matters in the past, and subexpressions of symbolic expressions could be obtained by I have received very little response to requests for comments on composing the functions that extract immediate subexpresstons, and drafts of this paper. -
(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. -
Obstacles to Compilation of Rebol Programs
Obstacles to Compilation of Rebol Programs Viktor Pavlu TU Wien Institute of Computer Aided Automation, Computer Vision Lab A-1040 Vienna, Favoritenstr. 9/183-2, Austria [email protected] Abstract. Rebol’s syntax has no explicit delimiters around function arguments; all values in Rebol are first-class; Rebol uses fexprs as means of dynamic syntactic abstraction; Rebol thus combines the advantages of syntactic abstraction and a common language concept for both meta-program and object-program. All of the above are convenient attributes from a programmer’s point of view, yet at the same time pose severe challenges when striving to compile Rebol into reasonable code. An approach to compiling Rebol code that is still in its infancy is sketched, expected outcomes are presented. Keywords: first-class macros, dynamic syntactic abstraction, $vau calculus, fexpr, Ker- nel, Rebol 1 Introduction A meta-program is a program that can analyze (read), transform (read/write), or generate (write) another program, called the object-program. Static techniques for syntactic abstraction (macro systems, preprocessors) resolve all abstraction during compilation, so the expansion of abstractions incurs no cost at run-time. Static techniques are, however, conceptionally burdensome as they lead to staged systems with phases that are isolated from each other. In systems where different syntax is used for the phases (e. g., C++), it results in a multitude of programming languages following different sets of rules. In systems where the same syntax is shared between phases (e. g., Lisp), the separa- tion is even more unnatural: two syntactically largely identical-looking pieces of code cannot interact with each other as they are assigned to different execution stages. -
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