DOCSLIB.ORG

LISP - "List Processing"

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
LISP - LISP - "LISt Processing" PhD MEng Tomasz Białaszewski Department of Decision Systems Email: [email protected] http://www.eti.pg.gda.pl/katedry/ksd/pracownicy/Tomasz.Bialaszewski/ LISP 1 Introduction Types of computer programming languages Programming Imperative Declarative Functional Logical LISP 2 Introduction Imperative programming: • strongly associated with computer architecture (von Neuman model) • computation in terms of statements that change a program state • sequences of commands for the computer to perform • e.g. FORTRAN, ALGOL, COBOL, BASIC, Pascal, C/C++, JAVA, PHP LISP 3 Introduction Declarative programming: • what the program should accomplish without prescribing how to do it • clear correspondence to mathematical logic • lack side effects • funcional and logical programming LISP 4 Introduction Logic programming: • logic is used as a purely declarative representation language • Prolog is a general purpose logic programming language associated with artificial intelligence and computational linguistics • a program logic is expressed in terms of relations, represented as facts and rules LISP 5 Introduction Functional programming: • computation as the evaluation of mathematical functions • avoidance of state and mutable data • lambda calculus (λ-calculus) - a formal system designed to investigate functions and recursion LISP 6 Introduction λ-calculus (A. Church & S. C. Kleene, 1930): • a powerful and elegant model of computation • an idealized, minimalist programming language • abstraction for modeling computation (cousin of the Turing machine) • stateless LISP 7 Introduction (λ-calculus) • produce no side effects in 'state‘ • do not make alterations to incoming data • only three basic constructs: – definition – assignment – application • two special operators: – the ‘λ’ sign – the dot ‘’ LISP 8 Introduction (λ-calculus) Defintion of a function: λ x . Body A function which takes a single argument x, evaluates the body - usually an expression using x - and returns the result. Example. Defined doubles the value of the argument x and then adds 3: λ x . 2*x+3 LISP 9 Introduction LISP - LISt Processing (John McCarthy, 1958): • a family of computer programming languages • fully parenthesized syntax • second-oldest high-level programming language in widespread use today • lists are one of major data structures • source code is itself made up of lists LISP 10 Introduction (LISP) • a practical mathematical notation for computer programs (λ-calculus) • favored programming language for artificial intelligence (AI) research e.g.: – tree data structures – automatic storage management – dynamic typing – the self-hosting compiler LISP 11 Introduction (LISP) LISP program code: • a data structure • s-expressions, or parenthesized lists • a list with the function or operator's name first, and the arguments following (f arg1 arg2 arg3) LISP 12 Introduction (LISP) • First implementation: – Steve Russell on an IBM 704 computer • LISP interpreter - evaluate LISP expressions • Two assembly language macros for IBM 704 - primitive operations for lists: – car (Contents of the Address part of Register number) – cdr (Contents of the Decrement part of Register number) LISP 13 Introduction (LISP) • the term „Register” is used here to mean „Memory Register” („Memory Location”) • Lisp dialects still use car and cdr (pronounced /ˈkɑr/ and /ˈkʊdər/) • for the operations: – car returns the first item in a list – cdr returns the rest of the list LISP 14 Introduction (LISP) • a difficult system to implement with the compiler techniques and stock hardware of the 1970s • garbage collection routines (Daniel Edwards) – practical to run LISP on general-purpose computing systems – efficiency was still a problem • LISP machines: – dedicated hardware for running LISP environments and programs LISP 15 Introduction • LISP machines commercially pioneered many now-commonplace technologies: – effective garbage collection – laser printing – windowing systems – computer mice – high-resolution bit-mapped graphics – computer graphic rendering LISP 16 Introduction • A LISP dialects - many variations on the core theme of S-expression language • The major dialects of Lisp: – Scheme – Common Lisp – Clojure • Application as scripting languages: – Emacs Lisp in the Emacs editor – Visual Lisp in AutoCAD – Nyquist in Audacity LISP 17 Introduction Common Lisp: • a successor to MacLisp • a large language standard including many built-in data types, functions, macros etc. • an object system (Common Lisp Object System, CLOS) • borrowed certain features from Scheme such as lexical scoping and lexical closures LISP 18 Introduction Clojure: • a dynamic programming dialect of Lisp that targets the Java Virtual Machine (and CLR ) • a scripting language for multithreaded programming • a compiled language (directly to JVM bytecode) remains completely dynamic • every feature is supported at runtime LISP 19 Introduction Scheme (1975, Gerald Sussman & Guy Steele Jr.) • first dialect of LISP to fully support: – lexical scoping – first-class procedures and – continuations • in earliest form - a very small language intended primarily for research and teaching • supporting only a handful of predefined syntactic forms and procedures LISP 20 Introduction (Scheme) • early implementations of the language were interpreter-based and slow • some current Scheme implementations boast sophisticated compilers that generate code on par with code generated by the best optimizing compilers for lower-level languages such as C and Fortran LISP 21 Introduction (Scheme) • a more minimalist design • a much smaller set of standard features • certain implementation features: – tail-call optimization – full continuations (not necessarily found in Common Lisp) • a statically scoped and properly tail-recursive dialect of the Lisp programming language LISP 22 Introduction (Scheme) • an exceptionally clear and simple semantics • few different ways to form expressions • a wide variety of programming paradigms including: – imperative – functional – message passing styles • find convenient expression in Scheme LISP 23 Introduction (Scheme) • interpreter makes it particularly popular for embedded scripting: – SIOD and TinyScheme in the GIMP image processor („Script-fu“) – LIBREP (originally based on the Emacs Lisp) in the Sawfish window manager – Guile interpreter is used in GnuCash LISP 24 Scheme Syntax Scheme programs are made up of: • keywords • variables • structured forms • constant data (numbers, characters, strings, quoted vectors, quoted lists or symbols, etc.) • whitespace • comments LISP 25 Scheme Syntax Identifiers (keywords, variables, and symbols ) - formed from the set of characters: • the lower-case letters a through z • the upper-case letters A through Z • the digits 0 through 9 • the characters ?!.+-*/<=>:$%^&_~@ LISP 26 Scheme Syntax Identifiers cannot start with : • @ • any character that may start a number, i.e.: – a digit – plus sign ( + ) – minus sign ( - ) – or decimal point ( . ) Exceptions: +, -, ..., which are valid identifiers For example: hi, Hello, x, x3, ?$&*!!! LISP 27 Scheme Syntax Identifiers must be delimited by: • whitespace • parentheses • a string (double) quote ( " ) • the comment character ( ; ) Notice: all implementations must recognize as identifiers any sequences of characters that adhere to these rules LISP 28 Scheme Syntax • No limit on the length of a identifier • Usage as many characters as necessary • Identifiers may be written in any mix of upper- case and lower-case letters • The case is not important, in that two identifiers differing only in case are identical For example: abcde, Abcde, AbCdE, ABCDE all refer to the same identifier LISP 29 Scheme Syntax • Scheme systems typically print an identifier in either all upper-case or all lower-case letters regardless of the way it is entered • Structured forms and list constants are enclosed within parentheses, e.g.: (a b c) (* (- x 2) y) • The empty list is written () LISP 30 Scheme Syntax • Some implementations permit the use of brackets ([]) in place of parentheses, and brackets are sometimes used to set off particular subexpressions for readability • The boolean values representing true and false are written as #t and #f • Scheme conditional expressions actually treat #f as false and all other objects as true, so 3, (), "false", and nil all count as true. LISP 31 Scheme Syntax • Vectors - #(a vector of symbols) • Strings - "This is a string" • Characters are preceded by #\, e.g., #\a • Case is important within character and string constants, unlike within identifiers • Numbers: - 12, 1/2, 1.4, 1e2456, 1.3777-2.7i, -1.2@73 LISP 32 Scheme Syntax • Expressions may span several lines, and no explicit terminator is required • Since the number of whitespace characters (spaces and newlines) between expressions is not significant • Scheme programs are normally indented to show the structure of the code in a way that is pleasing to the author of the program LISP 33 Scheme Syntax Comments: • between a semicolon( ; ) and line end • placed at the same indentation level as the expression, on the line before the expression • explaining of procedures are normally placed before the procedures, without indentation • used to set off the latter kind of comment, e.g. ;;; The following procedures LISP 34 Scheme Naming Convention • Predicate names end in a question mark ( ? ) For example: eq?, zero?, and string? • Type predicate is created from the type name • The names of procedures start with the prefix char-, string-, vector- , list-
Load more

Recommended publications
  • At—At, Batch—Execute Commands at a Later Time
    at—at, batch—execute commands at a later time at [–csm] [–f script] [–qqueue] time [date] [+ increment] at –l [ job...] at –r job... batch at and batch read commands from standard input to be executed at a later time. at allows you to specify when the commands should be executed, while jobs queued with batch will execute when system load level permits. Executes commands read from stdin or a file at some later time. Unless redirected, the output is mailed to the user. Example A.1 1 at 6:30am Dec 12 < program 2 at noon tomorrow < program 3 at 1945 pm August 9 < program 4 at now + 3 hours < program 5 at 8:30am Jan 4 < program 6 at -r 83883555320.a EXPLANATION 1. At 6:30 in the morning on December 12th, start the job. 2. At noon tomorrow start the job. 3. At 7:45 in the evening on August 9th, start the job. 4. In three hours start the job. 5. At 8:30 in the morning of January 4th, start the job. 6. Removes previously scheduled job 83883555320.a. awk—pattern scanning and processing language awk [ –fprogram–file ] [ –Fc ] [ prog ] [ parameters ] [ filename...] awk scans each input filename for lines that match any of a set of patterns specified in prog. Example A.2 1 awk '{print $1, $2}' file 2 awk '/John/{print $3, $4}' file 3 awk -F: '{print $3}' /etc/passwd 4 date | awk '{print $6}' EXPLANATION 1. Prints the first two fields of file where fields are separated by whitespace. 2. Prints fields 3 and 4 if the pattern John is found.
    [Show full text]
  • TDS) EDEN PG MV® Pigment Ink for Textile
    Technical Data Sheet (TDS) EDEN PG MV® Pigment Ink for Textile Product Description: Applications: EDEN PG MV water based pigment Ink is ideal for high-speed direct digital printing on all standard fabrics available on the market. The ink prints on all types of fabrics with equal quality and coverage without color shifts or patches. EDEN PG MV Pigment Ink may be used on cotton, cotton blends, polyester, polyamide (nylon) and treated & untreated fabrics. EDEN PG MV is ideal for a wide range of applications including sportswear, footwear, fashion, home décor and home textile and is designed for indoor and outdoor applications. This ink is manufactured using cutting edge technology and • Home textile • Bags • Indoor furnishing high-performance pigments, for optimal ink fluidity and • Décor • Sport apparel • Fashion & apparel printability through piezo printheads without bleeding or • Footwear migration. Compatible Print Head Technology: Ricoh Gen 4 & Gen 5 Industrial print heads based printers. Pre-treatment: The use of Bordeaux EDEN PG™ OS® (pretreatment liquid) is Product Line: recommended in order to achieve higher chemical attributes (see table below for comparison). The pretreatment process for fabrics is done offline using a standard textile padder. Red Cleaning Print procedure: Cyan Magenta Yellow Black Magenta Liquid The printing process can be done either inline or in individual segments. Inline printing allows the printed fabric to be fed Material Compatibility: through a standard textile dryer directly. Alternatively, if the printing stage is separated from the drying stage, drying is • Cotton required before rolling the fabric. • Viscose • Polyester • Lycra Drying Working Parameters: • Silk Recommended drying time: 3 minutes • Polyamide Recommended temperature: 150°C (302°F) • Leather • Synthetic leather Post-treatment: No chemical post treatment is needed.
    [Show full text]
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • 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.
    [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]
  • 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]
  • Relational Constraint Driven Test Case Synthesis for Web Applications
    Relational Constraint Driven Test Case Synthesis for Web Applications Xiang Fu Hofstra University Hempstead, NY 11549 [email protected] This paper proposes a relational constraint driven technique that synthesizes test cases automatically for web applications. Using a static analysis, servlets can be modeled as relational transducers, which manipulate backend databases. We present a synthesis algorithm that generates a sequence of HTTP requests for simulating a user session. The algorithm relies on backward symbolic image computation for reaching a certain database state, given a code coverage objective. With a slight adaptation, the technique can be used for discovering workflow attacks on web applications. 1 Introduction Modern web applications usually rely on backend database systems for storing important system infor- mation or supporting business decisions. The complexity of database queries, however, often complicates the task of thoroughly testing a web application. To manually design test cases involves labor intensive initialization of database systems, even with the help of unit testing tools such as SQLUnit [25] and DBUnit [8]. It is desirable to automatically synthesize test cases for web applications. There has been a strong interest recently in testing database driven applications and database man- agement systems (see e.g., [12, 4, 20]). Many of them are query aware, i.e., given a SQL query, an initial database (DB) instance is generated to make that query satisfiable. The DB instance is fed to the target web application as input, so that a certain code coverage goal is achieved. The problem we are trying to tackle is one step further – it is a synthesis problem: given a certain database state (or a relational constraint), a call sequence of web servlets is synthesized to reach the given DB state.
    [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]
  • 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]
  • 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]
  • Published with the Approbation of the Board of Trustees
    JOHNS HOPKINS UNIVERSITY CIRCULARS Published with the approbation of the Board of Trustees VOL. V.—No. 46.] BALTIMORE, JANUARY, 1886. [PRICE, 10 CENTS. RECENT PUBLICATIONS. Photograph of the Normal Solar Spectrum. Made Reproduction in Phototype of a Syriac Manuscript by PROFESSOR H. A. ROWLAND. (Baltimore, Johns Hopkins University, 1886). (Williams MS.) with the Antilegomena Epistles. Edited by IsAAC H. HALL. (Baltimore, Johns Hopkins University, 1886). [Froma letter to Science, New York, December 18, 1885]. The photographic map of the spectrum, upon which Professor Rowland [Froman article by I. H. Hall in the Journal of the Society of Biblical Literature and has expended so much hard work during the past three years, is nearly Exegesis for 1885, with additions]. ready for publication. The map is issued in a series of seven plates, cover- In September last (1884) I announced in The Independent the discovery ing the region from wave-length 3100 to 5790. Each plate is three feet of a manuscript of the Acts and Epistles, among which occur also the long and one foot wide, and contains two strips of the spectrum, except Epistles that were antilegomena among the Syrians; namely the Second plate No. 2, which contains three. Most of the plates are on a scalethree Epistle of Peter, the Second and Third Epistles of John, and the Epistle of times that of Angstrdm’s map, and in definition are more than equal to any Jude, in the version usually printed with our Peshitto New Testaments. It map yet published, at least to wave-length 5325. The 1474 line is widely is well known that the printed copies of these Epistles in that version all double, as also are b rest upon one manuscriptonly, in the Bodleian Library at Oxford, England, 3 and b4, while E may be recognized as double by the from which they were first published by Edward Pococke (Leyden, Elzevirs) expert.
    [Show full text]
  • A History of Clojure
    A History of Clojure RICH HICKEY, Cognitect, Inc., USA Shepherd: Mira Mezini, Technische Universität Darmstadt, Germany Clojure was designed to be a general-purpose, practical functional language, suitable for use by professionals wherever its host language, e.g., Java, would be. Initially designed in 2005 and released in 2007, Clojure is a dialect of Lisp, but is not a direct descendant of any prior Lisp. It complements programming with pure functions of immutable data with concurrency-safe state management constructs that support writing correct multithreaded programs without the complexity of mutex locks. Clojure is intentionally hosted, in that it compiles to and runs on the runtime of another language, such as the JVM. This is more than an implementation strategy; numerous features ensure that programs written in Clojure can leverage and interoperate with the libraries of the host language directly and efficiently. In spite of combining two (at the time) rather unpopular ideas, functional programming and Lisp, Clojure has since seen adoption in industries as diverse as finance, climate science, retail, databases, analytics, publishing, healthcare, advertising and genomics, and by consultancies and startups worldwide, much to the career-altering surprise of its author. Most of the ideas in Clojure were not novel, but their combination puts Clojure in a unique spot in language design (functional, hosted, Lisp). This paper recounts the motivation behind the initial development of Clojure and the rationale for various design decisions and language constructs. It then covers its evolution subsequent to release and adoption. CCS Concepts: • Software and its engineering ! General programming languages; • Social and pro- fessional topics ! History of programming languages.
    [Show full text]