PDF File on Using Lisp on Omega

Total Page：16

File Type：pdf, Size：1020Kb

Common Lisp is a high-level, all-purpose, object-oriented, dynamic, functional programming language. CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe University and Michael Stoll of Munich University, both in Germany. It mostly supports the Lisp described in the ANSI Common Lisp standard. CLISP includes an interpreter, a compiler, a debugger, and an X11 interface is available through CLX and Garnet. Command line editing is provided by GNU ReadLine. CLISP runs on microcomputers (Windows 95/98/2000/NT/XP, Linux) CLISP is Free Software and may be distributed under the terms of GNU GPL. You may obtain CLISP for free from http://sourceforge.net/projects/clisp or run it on your omega account. In order to login to your omega account visit http://oit.uta.edu/helpdesk/public/nos/unix/unixpwd/uxpwd0001.html After you login to omega, type “lisp” and “Enter” , wait for the “*” prompt. When “*” prompt is appeared you are ready to type in your commands. Example 1: * 7 7 * nil NIL * (+ (* 2 7) (- 8 1)) 24 Example 2: Suppose we type the following Lisp function (functions will be defined in detail later) and save the function in the file ``test.lisp'': (defun test (x) (* x (- x 1))) We can now load the file ``test.lisp'' into the Lisp environment. To load a file, use the load command as follows, putting the file name in quotes. * (load "test.lisp") T Notice that the load command returns the value T. Let's run the test function. * (test 20) 380 * Example 3: *(let ((x 3) (y (- 67 34))) (* x y)) 99 Example 4: *(defun factorial (n) (cond ((= n 0) 1) (t (* n (factorial (- n 1)))))) 24 (factorial 4) = (* 4 (factorial 3)) = (* 4 (* 3 (factorial 2))) = (* 4 (* 3 (* 2 (factorial 1)))) = (* 4 (* 3 (* 2 (* 1 (factorial 0))))) = (* 4 (* 3 (* 2 (* 1 1)))) = (* 4 (* 3 (* 2 1))) = (* 4 (* 3 2)) = (* 4 6) = 24 You can exit Lisp (by typing ``(quit)''). This concludes the introduction to CMU lisp. to read about CMU Common Lisp features. A complete CMU Common Lisp manual can be obtained at ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu- user.ps .

Copy Link

Recommended publications

An Implementation of Python for Racket
An Implementation of Python for Racket Pedro Palma Ramos António Menezes Leitão INESC-ID, Instituto Superior Técnico, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Universidade de Lisboa Rua Alves Redol 9 Rua Alves Redol 9 Lisboa, Portugal Lisboa, Portugal [email protected] [email protected] ABSTRACT Keywords Racket is a descendent of Scheme that is widely used as a Python; Racket; Language implementations; Compilers first language for teaching computer science. To this end, Racket provides DrRacket, a simple but pedagogic IDE. On the other hand, Python is becoming increasingly popular 1. INTRODUCTION in a variety of areas, most notably among novice program- The Racket programming language is a descendent of Scheme, mers. This paper presents an implementation of Python a language that is well-known for its use in introductory for Racket which allows programmers to use DrRacket with programming courses. Racket comes with DrRacket, a ped- Python code, as well as adding Python support for other Dr- agogic IDE [2], used in many schools around the world, as Racket based tools. Our implementation also allows Racket it provides a simple and straightforward interface aimed at programs to take advantage of Python libraries, thus signif- inexperienced programmers. Racket provides different lan- icantly enlarging the number of usable libraries in Racket. guage levels, each one supporting more advanced features, that are used in different phases of the courses, allowing Our proposed solution involves compiling Python code into students to benefit from a smoother learning curve. Fur- semantically equivalent Racket source code. For the run- thermore, Racket and DrRacket support the development of time implementation, we present two different strategies: additional programming languages [13].
[Show full text]
GNU Readline Library
GNU Readline Library Edition 2.1, for Readline Library Version 2.1. March 1996 Brian Fox, Free Software Foundation Chet Ramey, Case Western Reserve University This do cument describ es the GNU Readline Library, a utility which aids in the consistency of user interface across discrete programs that need to provide a command line interface. Published by the Free Software Foundation 675 Massachusetts Avenue, Cambridge, MA 02139 USA Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this p ermission notice are preserved on all copies. Permission is granted to copy and distribute mo di ed versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a p ermission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the ab ove conditions for mo di ed versions, except that this p ermission notice may b e stated in a translation approved by the Foundation. c Copyright 1989, 1991 Free Software Foundation, Inc. Chapter 1: Command Line Editing 1 1 Command Line Editing This chapter describ es the basic features of the GNU command line editing interface. 1.1 Intro duction to Line Editing The following paragraphs describ e the notation used to representkeystrokes. i h i h C-k is read as `Control-K' and describ es the character pro duced when the k The text key is pressed while the Control key is depressed. h i The text M-k is read as `Meta-K' and describ es the character pro duced when the meta h i key if you have one is depressed, and the k key is pressed.
[Show full text]
MELT a Translated Domain Specific Language Embedded in the GCC
MELT a Translated Domain Specific Language Embedded in the GCC Compiler Basile STARYNKEVITCH CEA, LIST Software Safety Laboratory, boˆıte courrier 94, 91191 GIF/YVETTE CEDEX, France [email protected] [email protected] The GCC free compiler is a very large software, compiling source in several languages for many targets on various systems. It can be extended by plugins, which may take advantage of its power to provide extra specific functionality (warnings, optimizations, source refactoring or navigation) by processing various GCC internal representations (Gimple, Tree, ...). Writing plugins in C is a complex and time-consuming task, but customizing GCC by using an existing scripting language inside is impractical. We describe MELT, a specific Lisp-like DSL which fits well into existing GCC technology and offers high-level features (functional, object or reflexive programming, pattern matching). MELT is translated to C fitted for GCC internals and provides various features to facilitate this. This work shows that even huge, legacy, software can be a posteriori extended by specifically tailored and translated high-level DSLs. 1 Introduction GCC1 is an industrial-strength free compiler for many source languages (C, C++, Ada, Objective C, Fortran, Go, ...), targetting about 30 different machine architectures, and supported on many operating systems. Its source code size is huge (4.296MLOC2 for GCC 4.6.0), heterogenous, and still increasing by 6% annually 3. It has no single main architect and hundreds of (mostly full-time) contributors, who follow strict social rules 4. 1.1 The powerful GCC legacy The several GCC [8] front-ends (parsing C, C++, Go .
[Show full text]
Bringing GNU Emacs to Native Code
Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
[Show full text]
Version 7.8-Systemd
Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
[Show full text]
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.
[Show full text]
Lisp Tutorial
Gene Kim 9/9/2016 CSC 2/444 Lisp Tutorial About this Document This document was written to accompany an in-person Lisp tutorial. Therefore, the information on this document alone is not likely to be sufficient to get a good understanding of Lisp. However, the functions and operators that are listed here are a good starting point, so you may look up specifications and examples of usage for those functions in the Common Lisp HyperSpec (CLHS) to get an understanding of their usage. Getting Started Note on Common Lisp Implementations I will use Allegro Common Lisp since it is what is used by Len (and my research). However, for the purposes of this class we won’t be using many (if any) features that are specific to common lisp implementations so you may use any of the common lisp implementations available in the URCS servers. If you are using any libraries that are implementation-specific for assignments in this class, I would strongly urge you to rethink your approach if possible. If we (the TAs) deem any of these features to be solving to much of the assigned problem, you will not receive full credit for the assignment. To see if a function is in the Common Lisp specifications see the Common Lisp HyperSpec (CLHS). Simply google the function followed by “clhs” to see if an entry shows up. Available Common Lisp implementations (as far as I know): - Allegro Common Lisp (acl or alisp will start an Allegro REPL) - CMU Common Lisp (cmucl or lisp will start a CMUCL REPL) - Steel Bank Common Lisp (sbcl will start an SBCL REPL) IDE/Editor It is not important for this class to have an extensive IDE since we will be working on small coding projects.
[Show full text]
Installation Guide for the UNIX Versions
Appendix A: Installation Guide for the UNIX Versions 1. Required tools. Compiling PARI requires an ANSI C or a C++ compiler. If you do not have one, we suggest that you obtain the gcc/g++ compiler. As for all GNU software mentioned afterwards, you can find the most convenient site to fetch gcc at the address http://www.gnu.org/order/ftp.html (On Mac OS X, this is also provided in the Xcode tool suite.) You can certainly compile PARI with a different compiler, but the PARI kernel takes advantage of optimizations provided by gcc. This results in at least 20% speedup on most architectures. Optional packages. The following programs and libraries are useful in conjunction with gp, but not mandatory. In any case, get them before proceeding if you want the functionalities they provide. All of them are free. • GNU MP library. This provides an alternative multiprecision kernel, which is faster than PARI's native one, but unfortunately binary incompatible. To enable detection of GMP, use Con- figure --with-gmp. You should really do this if you only intend to use GP, and probably also if you will use libpari unless you have backwards compatibility requirements. • GNU readline library. This provides line editing under GP, an automatic context-dependent completion, and an editable history of commands. Note that it is incompatible with SUN com- mandtools (yet another reason to dump Suntools for X Windows). • GNU gzip/gunzip/gzcat package enables GP to read compressed data. • GNU emacs. GP can be run in an Emacs buffer, with all the obvious advantages if you are familiar with this editor.
[Show full text]
$SPAD/Lsp Makefile
$SPAD/lsp Makefile The Axiom Team December 3, 2016 Abstract 1 Contents 1 The Makefile 3 2 Gnu Common Lisp 2.6.7 3 3 Gnu Common Lisp 2.6.7pre 3 3.1 run-process patch . 3 4 Gnu Common Lisp 2.6.6 3 4.1 run-process patch . 3 5 Gnu Common Lisp 2.6.5w 4 5.1 mingw.defs . 4 5.2 alloc.c . 4 5.3 mingfile.c . 4 5.4 unixfsys.c . 4 6 Gnu Common Lisp 2.6.5 5 6.1 gmp wrappers patch . 5 7 Gnu Common Lisp 2.5.2 5 7.0.1 socket patch . 5 7.0.2 read.d patch . 9 7.0.3 fortran patch . 9 7.0.4 libspad patch . 10 7.0.5 toploop patch . 12 7.0.6 object to float patch . 14 7.0.7 in-package patch . 15 7.0.8 EXIT and MAX STACK SIZE patchs . 15 7.0.9 tail-recursive patch . 16 7.0.10 collectfn fix . 17 7.1 The GCL-2.5.2 stanza . 21 7.1.1 Configure and Make GCL . 21 7.2 The GCL-2.6.1 stanza . 23 7.3 The GCL-2.6.2 stanza . 24 7.4 Directory move . 25 7.5 The GCL-2.6.2a stanza . 25 7.6 Directory move . 26 7.7 The GCL-2.6.3 stanza . 26 7.8 The GCL-2.6.5 stanza . 27 7.9 The GCL-2.6.5w stanza . 28 7.10 The GCL-2.6.6 stanza .
[Show full text]
Gnu Libiberty September 2001 for GCC 3
gnu libiberty September 2001 for GCC 3 Phil Edwards et al. Copyright c 2001 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. i Table of Contents 1 Using ............................................ 1 2 Overview ........................................ 2 2.1 Supplemental Functions ........................................ 2 2.2 Replacement Functions ......................................... 2 2.2.1 Memory Allocation ........................................ 2 2.2.2 Exit Handlers ............................................. 2 2.2.3 Error Reporting ........................................... 2 2.3 Extensions ..................................................... 3 3 Obstacks......................................... 4 3.1 Creating Obstacks.............................................. 4 3.2 Preparing for Using Obstacks................................... 4 3.3 Allocation in an Obstack ....................................... 5 3.4 Freeing Objects in an Obstack.................................. 6 3.5 Obstack Functions and Macros ................................. 7 3.6 Growing Objects ............................................... 8 3.7 Extra Fast Growing Objects ...................................
[Show full text]
Latexsample-Thesis
INTEGRAL ESTIMATION IN QUANTUM PHYSICS by Jane Doe A dissertation submitted to the faculty of The University of Utah in partial fulﬁllment of the requirements for the degree of Doctor of Philosophy Department of Mathematics The University of Utah May 2016 Copyright c Jane Doe 2016 All Rights Reserved The University of Utah Graduate School STATEMENT OF DISSERTATION APPROVAL The dissertation of Jane Doe has been approved by the following supervisory committee members: Cornelius L´anczos , Chair(s) 17 Feb 2016 Date Approved Hans Bethe , Member 17 Feb 2016 Date Approved Niels Bohr , Member 17 Feb 2016 Date Approved Max Born , Member 17 Feb 2016 Date Approved Paul A. M. Dirac , Member 17 Feb 2016 Date Approved by Petrus Marcus Aurelius Featherstone-Hough , Chair/Dean of the Department/College/School of Mathematics and by Alice B. Toklas , Dean of The Graduate School. ABSTRACT Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.
[Show full text]
A Lisp Oriented Architecture by John W.F
A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1994 © John W.F. McClain, 1994 The author hereby grants to MIT permission to reproduce and to distribute copies of this thesis document in whole or in part. Signature of Author ...... ;......................... .............. Department of Electrical Engineering and Computer Science August 5th, 1994 Certified by....... ......... ... ...... Th nas F. Knight Jr. Principal Research Scientist 1,,IA £ . Thesis Supervisor Accepted by ....................... 3Frederic R. Morgenthaler Chairman, Depattee, on Graduate Students J 'FROM e ;; "N MfLIT oARIES ..- A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science on August 5th, 1994, in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering Abstract In this thesis I describe LOOP, a new architecture for the efficient execution of pro- grams written in Lisp like languages. LOOP allows Lisp programs to run at high speed without sacrificing safety or ease of programming. LOOP is a 64 bit, long in- struction word architecture with support for generic arithmetic, 64 bit tagged IEEE floats, low cost fine grained read and write barriers, and fast traps. I make estimates for how much these Lisp specific features cost and how much they may speed up the execution of programs written in Lisp.
[Show full text]