DOCSLIB.ORG

GNU Emacs Lisp Bytecode Reference Manual

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
GNU Emacs Lisp Bytecode Reference Manual GNU Emacs Lisp Bytecode Reference Manual Collated and edited by Rocky Bernstein with contibutions from Pipcet, Chris Wellons, Stefan Monnier, Hallvard Breien Furuseth, Vladimir Kazanov, Andrea Corallo, and the Emacs community. 1 i Short Contents 1 Introduction to Emacs Lisp Byte Code and LAP :::::::::::: 1 2 Emacs Lisp Bytecode Environment ::::::::::::::::::::::: 7 3 Emacs Lisp Bytecode Instructions ::::::::::::::::::::::: 39 4 Instruction Changes Between Emacs Releases ::::::::::::: 166 5 Opcode Table ::::::::::::::::::::::::::::::::::::::: 174 A :::::::::::::::::::::::::::::::::::::::::::::::::: 183 ii Table of Contents 1 Introduction to Emacs Lisp Byte Code and LAP :::::::::::::::::::::::::::::::::::: 1 1.1 Why is Emacs Lisp Bytecode Important and How is Emacs as a Program Different? :::::::::::::::::::::::::::::::::::: 2 1.2 Emacs Lisp Bytecode and LAP ::::::::::::::::::::::::::::::::: 3 Example showing use of byte-compile-lapcode :::::::::::::::::: 3 1.3 Emacs Lisp Virtual Machine :::::::::::::::::::::::::::::::::::: 4 1.4 Wither Bytecode - Its Future ::::::::::::::::::::::::::::::::::: 5 2 Emacs Lisp Bytecode Environment :::::::::::: 7 2.1 Emacs Lisp Bytecode Objects::::::::::::::::::::::::::::::::::: 8 2.1.1 Function Parameter (lambda) List ::::::::::::::::::::::::: 8 2.1.2 Bytecode Unibyte String :::::::::::::::::::::::::::::::::: 10 2.1.3 Constants Vector ::::::::::::::::::::::::::::::::::::::::: 11 2.1.4 Maximum Stack Usage ::::::::::::::::::::::::::::::::::: 12 2.1.5 Docstring::::::::::::::::::::::::::::::::::::::::::::::::: 12 2.1.6 \Interactive" Specification :::::::::::::::::::::::::::::::: 12 Examples showing the \interactive" specification ::::::::::::::::: 13 2.2 Emacs Lisp Bytecode Compiler :::::::::::::::::::::::::::::::: 14 2.3 Emacs Lisp Bytecode Interpreter :::::::::::::::::::::::::::::: 15 2.4 Emacs Lisp Bytecode Bytes ::::::::::::::::::::::::::::::::::: 16 2.5 Emacs Lisp Bytecode Files :::::::::::::::::::::::::::::::::::: 17 2.6 Functions and Commands for working with LAP and Bytecode :: 19 2.6.1 aref ::::::::::::::::::::::::::::::::::::::::::::::::::::: 19 2.6.2 batch-byte-compile ::::::::::::::::::::::::::::::::::::: 20 2.6.3 batch-byte-recompile-directory::::::::::::::::::::::: 20 2.6.4 byte-code ::::::::::::::::::::::::::::::::::::::::::::::: 20 2.6.5 byte-compile :::::::::::::::::::::::::::::::::::::::::::: 20 2.6.6 byte-compile-file :::::::::::::::::::::::::::::::::::::: 21 2.6.7 byte-compile-sexp :::::::::::::::::::::::::::::::::::::: 21 2.6.8 byte-recalc-examples :::::::::::::::::::::::::::::::::: 22 2.6.9 byte-recompile-directory :::::::::::::::::::::::::::::: 22 2.6.10 byte-recompile-file::::::::::::::::::::::::::::::::::: 23 2.6.11 compile-defun:::::::::::::::::::::::::::::::::::::::::: 23 2.6.12 disassemble :::::::::::::::::::::::::::::::::::::::::::: 23 2.6.13 disassemble-file :::::::::::::::::::::::::::::::::::::: 24 2.6.14 disassemble-full :::::::::::::::::::::::::::::::::::::: 24 2.6.15 display-call-tree ::::::::::::::::::::::::::::::::::::: 24 2.6.16 emacs-lisp-byte-compile :::::::::::::::::::::::::::::: 24 2.6.17 functionp :::::::::::::::::::::::::::::::::::::::::::::: 24 2.6.18 make-byte-code :::::::::::::::::::::::::::::::::::::::: 25 2.6.19 symbol-function ::::::::::::::::::::::::::::::::::::::: 26 iii 2.7 Source and Bytecode Optimization :::::::::::::::::::::::::::: 28 2.7.1 Source-to-source Transformations ::::::::::::::::::::::::: 28 2.7.2 Peephole Optimization:::::::::::::::::::::::::::::::::::: 29 2.7.3 Adding an Optimizing Transformation :::::::::::::::::::: 30 2.7.4 Constant Folding ::::::::::::::::::::::::::::::::::::::::: 31 2.7.5 Dead Code Elimination ::::::::::::::::::::::::::::::::::: 32 2.7.6 Strength Reduction ::::::::::::::::::::::::::::::::::::::: 33 2.8 LAP Decompiler :::::::::::::::::::::::::::::::::::::::::::::: 33 2.8.1 It's GNU Emacs, so of course I have the source code!:::::: 34 2.8.2 Isn't it simpler to just disassemble? ::::::::::::::::::::::: 34 3 Emacs Lisp Bytecode Instructions :::::::::::: 39 3.1 Instruction-Description Format :::::::::::::::::::::::::::::::: 39 3.1.1 Instruction Jargon :::::::::::::::::::::::::::::::::::::::: 39 3.1.2 Instruction Description Fields::::::::::::::::::::::::::::: 40 3.2 Argument-Packing Instructions :::::::::::::::::::::::::::::::: 42 stack-ref (1{7) :::::::::::::::::::::::::::::::::::::::::::::::: 42 varref (8{15) ::::::::::::::::::::::::::::::::::::::::::::::::::: 44 varset (16{23) :::::::::::::::::::::::::::::::::::::::::::::::::: 45 varbind (24{31)::::::::::::::::::::::::::::::::::::::::::::::::: 46 call (32{39) :::::::::::::::::::::::::::::::::::::::::::::::::::: 47 unbind (40{47) :::::::::::::::::::::::::::::::::::::::::::::::::: 49 3.3 Constants-Vector Retrieval Instructions :::::::::::::::::::::::: 50 constant (192{255) ::::::::::::::::::::::::::::::::::::::::::::: 50 constant2 (129) :::::::::::::::::::::::::::::::::::::::::::::::: 51 3.4 Exception-Handling Instructions ::::::::::::::::::::::::::::::: 52 pophandler (48) :::::::::::::::::::::::::::::::::::::::::::::::: 52 pushconditioncase (49) :::::::::::::::::::::::::::::::::::::::: 53 pushcatch (50):::::::::::::::::::::::::::::::::::::::::::::::::: 54 3.5 Control-Flow Instructions:::::::::::::::::::::::::::::::::::::: 55 goto (130) :::::::::::::::::::::::::::::::::::::::::::::::::::::: 55 goto-if-nil (131) :::::::::::::::::::::::::::::::::::::::::::::: 56 goto-if-not-nil (132) ::::::::::::::::::::::::::::::::::::::::: 57 goto-if-nil-else-pop (133) ::::::::::::::::::::::::::::::::::: 58 goto-if-not-nil-else-pop (134) ::::::::::::::::::::::::::::::: 59 return (135) :::::::::::::::::::::::::::::::::::::::::::::::::::: 60 switch (183) :::::::::::::::::::::::::::::::::::::::::::::::::::: 61 3.6 Function-Call Instructions ::::::::::::::::::::::::::::::::::::: 62 3.6.1 Lisp Function Instructions :::::::::::::::::::::::::::::::: 62 symbolp (57) ::::::::::::::::::::::::::::::::::::::::::::::::: 62 consp (58) ::::::::::::::::::::::::::::::::::::::::::::::::::: 63 stringp (59) ::::::::::::::::::::::::::::::::::::::::::::::::: 64 listp (60) ::::::::::::::::::::::::::::::::::::::::::::::::::: 65 eq (61) ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 66 memq (62) :::::::::::::::::::::::::::::::::::::::::::::::::::: 67 not (63):::::::::::::::::::::::::::::::::::::::::::::::::::::: 68 symbol-value (74) ::::::::::::::::::::::::::::::::::::::::::: 69 iv symbol-function (75) ::::::::::::::::::::::::::::::::::::::: 70 set (76):::::::::::::::::::::::::::::::::::::::::::::::::::::: 71 fset (77) :::::::::::::::::::::::::::::::::::::::::::::::::::: 72 get (78):::::::::::::::::::::::::::::::::::::::::::::::::::::: 73 equal (154) :::::::::::::::::::::::::::::::::::::::::::::::::: 74 member (157) ::::::::::::::::::::::::::::::::::::::::::::::::: 75 assq (158) ::::::::::::::::::::::::::::::::::::::::::::::::::: 76 numberp (167) :::::::::::::::::::::::::::::::::::::::::::::::: 77 integerp (168)::::::::::::::::::::::::::::::::::::::::::::::: 78 3.6.2 List Function Instructions :::::::::::::::::::::::::::::::: 79 nth (56):::::::::::::::::::::::::::::::::::::::::::::::::::::: 79 car (64):::::::::::::::::::::::::::::::::::::::::::::::::::::: 80 cdr (65):::::::::::::::::::::::::::::::::::::::::::::::::::::: 81 cons (66) :::::::::::::::::::::::::::::::::::::::::::::::::::: 82 list1 (67) ::::::::::::::::::::::::::::::::::::::::::::::::::: 83 list2 (68) ::::::::::::::::::::::::::::::::::::::::::::::::::: 84 list3 (69) ::::::::::::::::::::::::::::::::::::::::::::::::::: 85 list4 (70) ::::::::::::::::::::::::::::::::::::::::::::::::::: 86 listN (175) :::::::::::::::::::::::::::::::::::::::::::::::::: 87 length (71) :::::::::::::::::::::::::::::::::::::::::::::::::: 88 aref (72) :::::::::::::::::::::::::::::::::::::::::::::::::::: 89 aset (73) :::::::::::::::::::::::::::::::::::::::::::::::::::: 90 nthcdr (155) ::::::::::::::::::::::::::::::::::::::::::::::::: 91 elt (156) :::::::::::::::::::::::::::::::::::::::::::::::::::: 92 nreverse (159)::::::::::::::::::::::::::::::::::::::::::::::: 93 setcar (160) ::::::::::::::::::::::::::::::::::::::::::::::::: 94 setcdr (161) ::::::::::::::::::::::::::::::::::::::::::::::::: 95 car-safe (162)::::::::::::::::::::::::::::::::::::::::::::::: 96 cdr-safe (163)::::::::::::::::::::::::::::::::::::::::::::::: 97 nconc (164) :::::::::::::::::::::::::::::::::::::::::::::::::: 98 3.6.3 Arithmetic Function Instructions:::::::::::::::::::::::::: 99 sub1 (83) :::::::::::::::::::::::::::::::::::::::::::::::::::: 99 add1 (84) ::::::::::::::::::::::::::::::::::::::::::::::::::: 100 eqlsign (85) :::::::::::::::::::::::::::::::::::::::::::::::: 101 gtr (86) :::::::::::::::::::::::::::::::::::::::::::::::::::: 102 lss (87) :::::::::::::::::::::::::::::::::::::::::::::::::::: 103 leq (88) :::::::::::::::::::::::::::::::::::::::::::::::::::: 104 geq (89) :::::::::::::::::::::::::::::::::::::::::::::::::::: 105 diff (90) ::::::::::::::::::::::::::::::::::::::::::::::::::: 106 negate (91) ::::::::::::::::::::::::::::::::::::::::::::::::: 107 plus (92) ::::::::::::::::::::::::::::::::::::::::::::::::::: 108 mult (95) ::::::::::::::::::::::::::::::::::::::::::::::::::: 109 max (93) :::::::::::::::::::::::::::::::::::::::::::::::::::: 110 min (94) :::::::::::::::::::::::::::::::::::::::::::::::::::: 111 quo (165) ::::::::::::::::::::::::::::::::::::::::::::::::::: 112 rem (166) ::::::::::::::::::::::::::::::::::::::::::::::::::: 113 3.6.4 String Function Instructions ::::::::::::::::::::::::::::: 114 substring (79) ::::::::::::::::::::::::::::::::::::::::::::: 114 v concat2
Load more

Recommended publications
  • The Hexadecimal Number System and Memory Addressing
    C5537_App C_1107_03/16/2005 APPENDIX C The Hexadecimal Number System and Memory Addressing nderstanding the number system and the coding system that computers use to U store data and communicate with each other is fundamental to understanding how computers work. Early attempts to invent an electronic computing device met with disappointing results as long as inventors tried to use the decimal number sys- tem, with the digits 0–9. Then John Atanasoff proposed using a coding system that expressed everything in terms of different sequences of only two numerals: one repre- sented by the presence of a charge and one represented by the absence of a charge. The numbering system that can be supported by the expression of only two numerals is called base 2, or binary; it was invented by Ada Lovelace many years before, using the numerals 0 and 1. Under Atanasoff’s design, all numbers and other characters would be converted to this binary number system, and all storage, comparisons, and arithmetic would be done using it. Even today, this is one of the basic principles of computers. Every character or number entered into a computer is first converted into a series of 0s and 1s. Many coding schemes and techniques have been invented to manipulate these 0s and 1s, called bits for binary digits. The most widespread binary coding scheme for microcomputers, which is recog- nized as the microcomputer standard, is called ASCII (American Standard Code for Information Interchange). (Appendix B lists the binary code for the basic 127- character set.) In ASCII, each character is assigned an 8-bit code called a byte.
    [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]
  • Midterm-2020-Solution.Pdf
    HONOR CODE Questions Sheet. A Lets C. [6 Points] 1. What type of address (heap,stack,static,code) does each value evaluate to Book1, Book1->name, Book1->author, &Book2? [4] 2. Will all of the print statements execute as expected? If NO, write print statement which will not execute as expected?[2] B. Mystery [8 Points] 3. When the above code executes, which line is modified? How many times? [2] 4. What is the value of register a6 at the end ? [2] 5. What is the value of register a4 at the end ? [2] 6. In one sentence what is this program calculating ? [2] C. C-to-RISC V Tree Search; Fill in the blanks below [12 points] D. RISCV - The MOD operation [8 points] 19. The data segment starts at address 0x10000000. What are the memory locations modified by this program and what are their values ? E Floating Point [8 points.] 20. What is the smallest nonzero positive value that can be represented? Write your answer as a numerical expression in the answer packet? [2] 21. Consider some positive normalized floating point number where p is represented as: What is the distance (i.e. the difference) between p and the next-largest number after p that can be represented? [2] 22. Now instead let p be a positive denormalized number described asp = 2y x 0.significand. What is the distance between p and the next largest number after p that can be represented? [2] 23. Sort the following minifloat numbers. [2] F. Numbers. [5] 24. What is the smallest number that this system can represent 6 digits (assume unsigned) ? [1] 25.
    [Show full text]
  • 2018-19 MAP 160 Byte File Layout Specifications
    2018-19 MAP 160 Byte File Layout Specifications OVERVIEW: A) ISAC will provide an Eligibility Status File (ESF) record for each student to all schools listed as a college choice on the student’s Student Aid Report (SAR). The ESF records will be available daily as Record Type = 7. ESF records may be retrieved via the File Extraction option in MAP. B) Schools will transmit Payment Requests to ISAC via File Transfer Protocol (FTP) using the MAP 160byte layout and identify these with Record Type = 4. C) When payment requests are processed, ISAC will provide payment results to schools through the MAP system. The payment results records can be retrieved in the 160 byte format using the MAP Payment Results File Extraction Option. MAP results records have a Record Type = 5. The MAP Payment Results file contains some eligibility status data elements. Also, the same student record may appear on both the Payment Results and the Eligibility Status extract files. Schools may also use the Reports option in MAP to obtain payment results. D) To cancel Payment Requests, the school with the current Payment Results record on ISAC's Payment Database must transmit a matching record with MAP Payment Request Code = C, with the Requested Award Amount field equal to zero and the Enrollment Hours field equal to 0 along with other required data elements. These records must be transmitted to ISAC as Record Type = 4. E) Summary of Data Element Changes, revision (highlighted in grey) made to the 2018-19 layout. NONE 1 2018-19 MAP 160 Byte File Layout Specifications – 9/17 2018-19 MAP 160 Byte File Layout Specifications F) The following 160 byte record layout will be used for transmitting data between schools and ISAC.
    [Show full text]
  • The Pros of Cons: Programming with Pairs and Lists
    The Pros of cons: Programming with Pairs and Lists CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College Racket Values • booleans: #t, #f • numbers: – integers: 42, 0, -273 – raonals: 2/3, -251/17 – floang point (including scien3fic notaon): 98.6, -6.125, 3.141592653589793, 6.023e23 – complex: 3+2i, 17-23i, 4.5-1.4142i Note: some are exact, the rest are inexact. See docs. • strings: "cat", "CS251", "αβγ", "To be\nor not\nto be" • characters: #\a, #\A, #\5, #\space, #\tab, #\newline • anonymous func3ons: (lambda (a b) (+ a (* b c))) What about compound data? 5-2 cons Glues Two Values into a Pair A new kind of value: • pairs (a.k.a. cons cells): (cons v1 v2) e.g., In Racket, - (cons 17 42) type Command-\ to get λ char - (cons 3.14159 #t) - (cons "CS251" (λ (x) (* 2 x)) - (cons (cons 3 4.5) (cons #f #\a)) Can glue any number of values into a cons tree! 5-3 Box-and-pointer diagrams for cons trees (cons v1 v2) v1 v2 Conven3on: put “small” values (numbers, booleans, characters) inside a box, and draw a pointers to “large” values (func3ons, strings, pairs) outside a box. (cons (cons 17 (cons "cat" #\a)) (cons #t (λ (x) (* 2 x)))) 17 #t #\a (λ (x) (* 2 x)) "cat" 5-4 Evaluaon Rules for cons Big step seman3cs: e1 ↓ v1 e2 ↓ v2 (cons) (cons e1 e2) ↓ (cons v1 v2) Small-step seman3cs: (cons e1 e2) ⇒* (cons v1 e2); first evaluate e1 to v1 step-by-step ⇒* (cons v1 v2); then evaluate e2 to v2 step-by-step 5-5 cons evaluaon example (cons (cons (+ 1 2) (< 3 4)) (cons (> 5 6) (* 7 8))) ⇒ (cons (cons 3 (< 3 4))
    [Show full text]
  • POINTER (IN C/C++) What Is a Pointer?
    POINTER (IN C/C++) What is a pointer? Variable in a program is something with a name, the value of which can vary. The way the compiler and linker handles this is that it assigns a specific block of memory within the computer to hold the value of that variable. • The left side is the value in memory. • The right side is the address of that memory Dereferencing: • int bar = *foo_ptr; • *foo_ptr = 42; // set foo to 42 which is also effect bar = 42 • To dereference ted, go to memory address of 1776, the value contain in that is 25 which is what we need. Differences between & and * & is the reference operator and can be read as "address of“ * is the dereference operator and can be read as "value pointed by" A variable referenced with & can be dereferenced with *. • Andy = 25; • Ted = &andy; All expressions below are true: • andy == 25 // true • &andy == 1776 // true • ted == 1776 // true • *ted == 25 // true How to declare pointer? • Type + “*” + name of variable. • Example: int * number; • char * c; • • number or c is a variable is called a pointer variable How to use pointer? • int foo; • int *foo_ptr = &foo; • foo_ptr is declared as a pointer to int. We have initialized it to point to foo. • foo occupies some memory. Its location in memory is called its address. &foo is the address of foo Assignment and pointer: • int *foo_pr = 5; // wrong • int foo = 5; • int *foo_pr = &foo; // correct way Change the pointer to the next memory block: • int foo = 5; • int *foo_pr = &foo; • foo_pr ++; Pointer arithmetics • char *mychar; // sizeof 1 byte • short *myshort; // sizeof 2 bytes • long *mylong; // sizeof 4 byts • mychar++; // increase by 1 byte • myshort++; // increase by 2 bytes • mylong++; // increase by 4 bytes Increase pointer is different from increase the dereference • *P++; // unary operation: go to the address of the pointer then increase its address and return a value • (*P)++; // get the value from the address of p then increase the value by 1 Arrays: • int array[] = {45,46,47}; • we can call the first element in the array by saying: *array or array[0].
    [Show full text]
  • An Evaluation of Go and Clojure
    An evaluation of Go and Clojure A thesis submitted in partial satisfaction of the requirements for the degree Bachelors of Science in Computer Science Fall 2010 Robert Stimpfling Department of Computer Science University of Colorado, Boulder Advisor: Kenneth M. Anderson, PhD Department of Computer Science University of Colorado, Boulder 1. Introduction Concurrent programming languages are not new, but they have been getting a lot of attention more recently due to their potential with multiple processors. Processors have gone from growing exponentially in terms of speed, to growing in terms of quantity. This means processes that are completely serial in execution will soon be seeing a plateau in performance gains since they can only rely on one processor. A popular approach to using these extra processors is to make programs multi-threaded. The threads can execute in parallel and use shared memory to speed up execution times. These multithreaded processes can significantly speed up performance, as long as the number of dependencies remains low. Amdahl‘s law states that these performance gains can only be relative to the amount of processing that can be parallelized [1]. However, the performance gains are significant enough to be looked into. These gains not only come from the processing being divvied up into sections that run in parallel, but from the inherent gains from sharing memory and data structures. Passing new threads a copy of a data structure can be demanding on the processor because it requires the processor to delve into memory and make an exact copy in a new location in memory. Indeed some studies have shown that the problem with optimizing concurrent threads is not in utilizing the processors optimally, but in the need for technical improvements in memory performance [2].
    [Show full text]
  • The Use of UML for Software Requirements Expression and Management
    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
    [Show full text]
  • Programming with GNU Emacs Lisp
    Programming with GNU Emacs Lisp William H. Mitchell (whm) Mitchell Software Engineering (.com) GNU Emacs Lisp Programming Slide 1 Copyright © 2001-2008 by William H. Mitchell GNU Emacs Lisp Programming Slide 2 Copyright © 2001-2008 by William H. Mitchell Emacs Lisp Introduction A little history GNU Emacs Lisp Programming Slide 3 Copyright © 2001-2008 by William H. Mitchell Introduction GNU Emacs is a full-featured text editor that contains a complete Lisp system. Emacs Lisp is used for a variety of things: • Complete applications such as mail and news readers, IM clients, calendars, games, and browsers of various sorts. • Improved interfaces for applications such as make, diff, FTP, shells, and debuggers. • Language-specific editing support. • Management of interaction with version control systems such as CVS, Perforce, SourceSafe, and StarTeam. • Implementation of Emacs itself—a substantial amount of Emacs is written in Emacs Lisp. And more... GNU Emacs Lisp Programming Slide 4 Copyright © 2001-2008 by William H. Mitchell A little history1 Lisp: John McCarthy is the father of Lisp. The name Lisp comes from LISt Processing Language. Initial ideas for Lisp were formulated in 1956-1958; some were implemented in FLPL (FORTRAN-based List Processing Language). The first Lisp implementation, for application to AI problems, took place 1958-1962 at MIT. There are many dialects of Lisp. Perhaps the most commonly used dialect is Common Lisp, which includes CLOS, the Common Lisp Object System. See http://www-formal.stanford.edu/jmc/history/lisp/lisp.html for some interesting details on the early history of Lisp. 1 Don't quote me! GNU Emacs Lisp Programming Slide 5 Copyright © 2001-2008 by William H.
    [Show full text]
  • 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
    [Show full text]
  • Java for Scientific Computing, Pros and Cons
    Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language.
    [Show full text]
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications
    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
    [Show full text]