Introduction to Programming in Lisp
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Programming Languages
Programming Languages Recitation Summer 2014 Recitation Leader • Joanna Gilberti • Email: [email protected] • Office: WWH, Room 328 • Web site: http://cims.nyu.edu/~jlg204/courses/PL/index.html Homework Submission Guidelines • Submit all homework to me via email (at [email protected] only) on the due date. • Email subject: “PL– homework #” (EXAMPLE: “PL – Homework 1”) • Use file naming convention on all attachments: “firstname_lastname_hw_#” (example: "joanna_gilberti_hw_1") • In the case multiple files are being submitted, package all files into a ZIP file, and name the ZIP file using the naming convention above. What’s Covered in Recitation • Homework Solutions • Questions on the homeworks • For additional questions on assignments, it is best to contact me via email. • I will hold office hours (time will be posted on the recitation Web site) • Run sample programs that demonstrate concepts covered in class Iterative Languages Scoping • Sample Languages • C: static-scoping • Perl: static and dynamic-scoping (use to be only dynamic scoping) • Both gcc (to run C programs), and perl (to run Perl programs) are installed on the cims servers • Must compile the C program with gcc, and then run the generated executable • Must include the path to the perl executable in the perl script Basic Scope Concepts in C • block scope (nested scope) • run scope_levels.c (sl) • ** block scope: set of statements enclosed in braces {}, and variables declared within a block has block scope and is active and accessible from its declaration to the end of the block -
Chapter 5 Names, Bindings, and Scopes
Chapter 5 Names, Bindings, and Scopes 5.1 Introduction 198 5.2 Names 199 5.3 Variables 200 5.4 The Concept of Binding 203 5.5 Scope 211 5.6 Scope and Lifetime 222 5.7 Referencing Environments 223 5.8 Named Constants 224 Summary • Review Questions • Problem Set • Programming Exercises 227 CMPS401 Class Notes (Chap05) Page 1 / 20 Dr. Kuo-pao Yang Chapter 5 Names, Bindings, and Scopes 5.1 Introduction 198 Imperative languages are abstractions of von Neumann architecture – Memory: stores both instructions and data – Processor: provides operations for modifying the contents of memory Variables are characterized by a collection of properties or attributes – The most important of which is type, a fundamental concept in programming languages – To design a type, must consider scope, lifetime, type checking, initialization, and type compatibility 5.2 Names 199 5.2.1 Design issues The following are the primary design issues for names: – Maximum length? – Are names case sensitive? – Are special words reserved words or keywords? 5.2.2 Name Forms A name is a string of characters used to identify some entity in a program. Length – If too short, they cannot be connotative – Language examples: . FORTRAN I: maximum 6 . COBOL: maximum 30 . C99: no limit but only the first 63 are significant; also, external names are limited to a maximum of 31 . C# and Java: no limit, and all characters are significant . C++: no limit, but implementers often impose a length limitation because they do not want the symbol table in which identifiers are stored during compilation to be too large and also to simplify the maintenance of that table. -
High-Level Language Features Not Found in Ordinary LISP. the GLISP
DOCUMENT RESUME ED 232 860 SE 042 634 AUTHOR Novak, Gordon S., Jr. TITLE GLISP User's Manual. Revised. INSTITUTION Stanford Univ., Calif. Dept. of Computer Science. SPONS AGENCY Advanced Research Projects Agency (DOD), Washington, D.C.; National Science Foundation, Washington, D.C. PUB DATE 23 Nov 82 CONTRACT MDA-903-80-c-007 GRANT SED-7912803 NOTE 43p.; For related documents, see SE 042 630-635. PUB TYPE Guides General (050) Reference Materials General (130) EDRS PRICE MF01/PCO2 Plus Postage. DESCRIPTORS *Computer Programs; *Computer Science; Guides; *Programing; *Programing Languages; *Resource Materials IDENTIFIERS *GLISP Programing Language; National Science Foundation ABSTRACT GLISP is a LISP-based language which provides high-level language features not found in ordinary LISP. The GLISP language is implemented by means of a compiler which accepts GLISP as input and produces ordinary LISP as output. This output can be further compiled to machine code by the LISP compiler. GLISP is available for several ISP dialects, including Interlisp, Maclisp, UCI Lisp, ELISP, Franz Lisp, and Portable Standard Lisp. The goal of GLISP is to allow structured objects to be referenced in a convenient, succinct language and to allow the structures of objects to be changed without changing the code which references the objects. GLISP provides both PASCAL-like and English-like syntaxes; much of the power and brevity of GLISP derive from the compiler features necessary to support the relatively informal, English-like language constructs. Provided in this manual is the documentation necessary for using GLISP. The documentation is presented in the following sections: introduction; object descriptions; reference to objects; GLISP program syntax; messages; context rules and reference; GLISP and knowledge representation languages; obtaining and using GLISP; GLISP hacks (some ways of doing things in GLISP which might not be entirely obvious at first glance); and examples of GLISP object declarations and programs. -
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. -
Programming Language Concepts/Binding and Scope
Programming Language Concepts/Binding and Scope Programming Language Concepts/Binding and Scope Onur Tolga S¸ehito˘glu Bilgisayar M¨uhendisli˘gi 11 Mart 2008 Programming Language Concepts/Binding and Scope Outline 1 Binding 6 Declarations 2 Environment Definitions and Declarations 3 Block Structure Sequential Declarations Monolithic block structure Collateral Declarations Flat block structure Recursive declarations Nested block structure Recursive Collateral Declarations 4 Hiding Block Expressions 5 Static vs Dynamic Scope/Binding Block Commands Static binding Block Declarations Dynamic binding 7 Summary Programming Language Concepts/Binding and Scope Binding Binding Most important feature of high level languages: programmers able to give names to program entities (variable, constant, function, type, ...). These names are called identifiers. Programming Language Concepts/Binding and Scope Binding Binding Most important feature of high level languages: programmers able to give names to program entities (variable, constant, function, type, ...). These names are called identifiers. definition of an identifier ⇆ used position of an identifier. Formally: binding occurrence ⇆ applied occurrence. Programming Language Concepts/Binding and Scope Binding Binding Most important feature of high level languages: programmers able to give names to program entities (variable, constant, function, type, ...). These names are called identifiers. definition of an identifier ⇆ used position of an identifier. Formally: binding occurrence ⇆ applied occurrence. Identifiers are declared once, used n times. Programming Language Concepts/Binding and Scope Binding Binding Most important feature of high level languages: programmers able to give names to program entities (variable, constant, function, type, ...). These names are called identifiers. definition of an identifier ⇆ used position of an identifier. Formally: binding occurrence ⇆ applied occurrence. Identifiers are declared once, used n times. -
PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P
DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report. -
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. -
Allegro CL User Guide
Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format -
1+1=1: an Optimizing Caml Compiler
1+1=1 : an optimizing Caml compiler Manuel Serrano, Pierre Weis To cite this version: Manuel Serrano, Pierre Weis. 1+1=1 : an optimizing Caml compiler. [Research Report] RR-2301, INRIA. 1994. inria-00074372 HAL Id: inria-00074372 https://hal.inria.fr/inria-00074372 Submitted on 24 May 2006 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. ¢¡¤£¦¥§ ¨¥ © ¥ ¡ ¥§ ¢¡ § ¡ ¡¤ !" ¥§ ¢#© $%¥& ¤©§¥ !" ¥§ ¢#© ' ( ' ) '+*-,&. /10+2§3¦4 3653¦.$7 89,&4 :<;=/>4 0?3¦:A@CB DFE§G%HJIKI¦LNMOQP RSEQTUHJV¢W X Y[Z"\"]_^ `baQVdc¨cdHJegfJhbhji k§lmonplqorrst uwvyxwz¦v{¢|¦}S~Jvy¦z K K u}}pu¨yK w§w¦yvyKyxy6v apport de recherche 1994 ISSN 0249-6399 ¢¡£ ¥¤ §¦©¨ ¨ ! " #$©%'& DFE¤G%HJI I LNMQOP§RSEQTUHJV¢W!( k*),+.-/)1023254 t6$7§08:9<;=8?>A@B2DCE+.8GF:H.;I4.JK=),+.-.)<02320L,FG+M4NLO-QP4NMIFR4'8G+.-/F:9<FG4N8 k*),+S<4NL,>"TA9<>,8:0=J=7)AFG>,L108 lO0K=KE+.),L"UB4')A49,V=4W)19,V=4MYXJt.Z/[=\]6$^.;IFR8G8G4NL'\_/_`a6$Z.[ Kb0c-.4N> d#egfWhjikblh/monp4§K=),4N>A4WMqL'0YMI4Nrs7§0c258b9t+.25KIFR8G4N)jJr§V=F:9,V5r§0>+.C=L<0FGM=4U#CB@50M5+/)AFG-.FGMb0c8b0KIK=)A+B0.9,Vvu 0O>AFG23K=8G4wKIFRKE4N8GFGM=4Cb4NLxr4N4NMDLxr+"4tyzFG>,LAFGM=-Y9<+.23K=FG8G4N)A>jJ4j0.9,V+/M=4§UB4N{.+/LA4U -
HOWTO Débuter Sous Emacs
HOWTO D´ebuter sous Emacs Jeremy D. Zawodny, [email protected] v1.7, 14 Octobre 1999 Ce document est une aide aux d´ebutants sous l’´editeur Emacs. Il prend pour acquis la manipula- tion de vi ou d’un ´editeur similaire. La derni`ere version de ce document est aussi disponible sur http://www.wcnet.org/jzawodn/emacs/ Contents 1 Introduction 3 1.1 Copyright ............................................... 3 1.2 Public et Dessein .......................................... 3 1.3 Qu’est ce qu’Emacs? ........................................ 3 1.3.1 Portages et Versions ..................................... 4 1.3.2 Obtenir Emacs ........................................ 4 2 Ex´ecuter Emacs 4 2.1 Lancer & quitter Emacs ....................................... 4 2.1.1 Ce que vous allez voir .................................... 5 2.2 Quelques Terminologies ....................................... 5 2.2.1 Tampons & Fichiers ..................................... 6 2.2.2 Points & Regions ....................................... 6 2.2.3 Fenˆetres ........................................... 6 2.2.4 Frames ............................................ 6 2.3 Les commandes de bases au clavier ................................. 7 2.3.1 Les touches de commandes(Meta, Esc, Control, and Alt) ................ 7 2.3.2 Se d´eplacer dans un Buffer ................................. 7 2.3.3 Commandes Principales q .................................. 8 2.3.4 La Compl´etionpar la touche Tab ............................. 9 2.4 Tutorials, Aides, & Informations ................................. -
S Allegro Common Lisp Foreign Function Interface
Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based -
LISP in Max: Exploratory Computer-Aided Composition in Real-Time
LISP in Max: Exploratory Computer-Aided Composition in Real-Time Julien Vincenot Composer, PhD candidate Harvard University [email protected] ABSTRACT The author describes a strategy to implement Common Lisp applications for computer-aided composition within Max, to enrich the possibilities offered by the bach library. In parallel, a broader discussion is opened on the current state of the discipline, and some applications are presented. 1. 1. INTRODUCTION Computer-aided composition (CAC), as we know it, has been around for decades. Following the pioneers of algo- rithmic music, the emergence of the first relevant graphi- cal interfaces allowed the discipline to expand in several directions. CAC exists today under a variety of forms, languages and tools available to composers. This tendency has crystallized around visual program- ming environments such as OpenMusic (OM) and PWGL, both derived from the program PatchWork (or PW) developed by Mikael Laurson since the late 1980s [5]. A Figure 1. A Score object in PWGL and specificity of this family of programs, but also many its inner representation as a Lisp linked-list or tree. others since then1, is that they were all built on top of the same language: Common Lisp2. dedicated to traditional notation, concern a small popula- Since the early days of artificial intelligence, Lisp has tion of musicians. always been considered a special language, and its Nevertheless, we can observe today a real interest in popularity is quite uneven among professional program- renewing those paradigms. The discipline of CAC is mers. However, the interest among musicians never com- going through a phase of transition, with the emergence pletely declined.