DOCSLIB.ORG

'Volume 1, Number 6 April-May-June 1988

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
'Volume 1, Number 6 April-May-June 1988 'VOLUME 1, NUMBER 6 APRIL-MAY-JUNE 1988 TABLE UP CONTENlS EDITORIAL BOARD ***EDITOR, MAILING LIST*** ***TILE SCHEME OF TttlNGS*** Mary S. Van Deusen Will Clinger IBM Watson Research Semantic Microsystems, Inc. P.O. Box 704 4470 SW Hall Blvd, Suite 340 Yorktown Heights, NY 10598 Beaverton, OR 97005 (914) 789-7845 (503) 643-4539 (914) 232-7490 wiUc%tekchips.tek.com at tektronix.es.net (617) 384-2526 [email protected] ***QUERY-IO*** Patrick Dussud ***LISP IMPLEMENTATIONS*** Texas Instruments Walter van Roggen 12501 Research Boulevard DEC AITG MS 2201 290 Donald Lynch Blvd. Austin, TX 78759 DLB5-2/B I0 (512) 250-7483 Marlboro, MA 01752 dussud%jenner%ti-csl.csnet@csnet-relay (617) 490-8012 vanroggen @hudson.dec.corn ***INT'L NEWS*** Christian Queinnec ***X3JI3*** LITP Robert F. Mathis 4 Place Jussieu 9712 Ceralene Drive F-75252, Paris Cedex 05 Fairfax, VA 22032 FRANCE (703) 425-5923 tel: +33 (1) 43 36 25 25 x 5251 [email protected] UUCP: ..!seismo !mcvax!infia!queinnec INTERNET: queinnec @infia.inria.fr ***TECHNICAL ARTICLES*** JonL White ***ALGORITIIMS*** Lucid, Inc. Pavel Curtis 707 Laurel Street Xerox AIS Menlo Park, CA 94025 3333 Coyote Hill Rd. (415) 329-8400 Palo Alto, CA 94304 [email protected] ***PROGRAMMING ENVIRONMENTS*** John Foderaro Franz Inc. 1995 University Avenue #275 Berkeley, Ca. 94704 (415) 548-3600 jkf%franz.uucp @berkeley .edu This issue Of the Lisp Pointers newsletter has been funded by I.N.R.I.A. and The Mitre Corporation. Neither corporation has directed or controlled its publication. The opinions expressed herein are solely those of the authors, editors, publisher and other contributors and do not necessarily reflect the opinions of I.N.R.I.A or The Mitre Corporation or the opinions of companies affiliated with individuals involved with this effort. Dear Colleague, Here we are again, blooming along with the lilacs. Although Christian Quiennec and Patrick Dussud are taking a rest from their departments this issue, you'll still find them represented with a puzzle and a technical article. We've added a new section this issue. Pavel Curtis is joining us with a department describing (Algorithms). This is in answer to all those who claim that Lispers don't write, they just code. Now none of you can escape us as potential contributors. You might also notice that I've started a news column. Cyril Alberga came up with the name. Dribble File. Blame him. Contributions, however, should come to me. We're always looking for frier items, art, cartoons, etc. There are few things as threatening a.~ an entire page of white. It occurs to me that reviews of video tapes of Lisp, Scheme, AI, or expert systems might also fit within our purview. I am especially reminded of a video done at MIT showing the solution to the Towers of llanoi problem. A professor was intercut with students in saffron robes moving very large disks. At the end of his leclure, the professor described the legend behind the tower and said that the monks believed that the world would end when the last disk was moved. As he was saying this, the video went back to the students laying the last disk and the screen suddenly went black. Wonderful video! Our thanks to Mitre Corporation and I.N.R.I.A. for sponsoring this issue. There is a call for sponsors for future issues (starting with July-August-September). I.N.R.I.A. has been kind enough to sponsor all non-US mailings. This means that we only need sponsorship for the US mailings. The bottom line for those who don't want to read the page of text is that you can work out the costs of sponsorship for US subscribers by looking at what it costs your duplicating department to make 1300 copies of this issue and what it costs your mail room to mail I100 copies. Contact me if you have any additional questions. Sincerely, Mary S. Van Deusen, Editor LP I-6.1 DRIBBLE FILE Scheme Release Notes The MIT AI Lab is sponsoring a series of notes on Scheme. The first one describes the "Avail- ability of the Scheme Programming Language." For further information, contact: Scheme Development Team c/o MIT Artificial Intelligence Laboratory 545 Technology Square Cambridge, MA 02139 AI Conference The International Computer Science Conference '88 will be held in |Iong Kong, December 19-21, 1988. The topic will be "Artificial Intelligence: Theory and Applications." The conference is sponsored by the Computer Society of the IEEE, llong Kong Chapter. Paper submissions are due June 15, 1988. For submission information, contact: Jean-Louis Lassez IBM Watson Research PO Box 704 (ttI-AI2) Yorktown tteights, NY 10598 For conference information, contact: Computer Society of IEEE, ttong Kong Chapter G.P.O. Box 5318 Hong Kong Lisp Puzzles Christian Queinnec J~r6me Chailloux April 16, 1988 1 First Puzzle J~rSme and I asked our students at ]~cole Polytechnique to program the following function (xpl '(a b c d)) --~ ((a) (a b) (a b c) (a b c d)) Given a list, xpl returns the list of all its initial segments ordered by increasing length. We got seven different solutions, more than expected. We propose you to program xpl and compare, elsewhere in this issue, your own solution with ours. Good luck !!! LP 1-6.2 1988 ACM Conference on LISP AND FUNCTIONAL PROGRAMMING Snowbird, Utah, July 25-27, 1988 The 1988 ACM Conference on LISP and Functional Programming is the fifth in a series of biennial conferences devoted to the theory, design, and implementation of programming languages and systems that support symbolic computation. The conference is jointly sponsored by ACM SIGPLAN, SIGACT, and SIGART. The major topics that have been addressed at previous conferences include: 1) programming language concepts and facilities 2) implementation methods 3) machine architectures 4) semantic foundations 5) programming logics 6) program development environments 7) applications of symbolic computation The conference ~ite at Snowbird, Utah is a resort located in the rugged Wasatch mountain range approximately 35 miles from Salt Lake City. Summer activities include hiking, climbing, swimming, tennis, and wildflower photography. Program Committee Chairman Program Committee Robert (Corky) Cartwfight llarold Abelson, MIT Attn: LFP 88 Richard Bird, Oxford University Rice University Luca Cardelli, DEC Systems Res. Ctr. Department of Computer Science Robert Cartwright, Rice University P. O. Box 1892 Richard Gabriel, Lucid Inc. Houston, TX 77251-1892 Christopher ttaynes, Indiana University (713) 527-4834 Gerard ltuet, INRIA Rocquencourt [email protected] Gilles Kahn, INRIA Sophia Antipolis David Moon, Symbolics Inc. Guy Steele, Thinking Machines Corp. Carolyn Talcott, Stanford University General Chairman Local Arrangements Chairman Jerome Chailloux Robert Kessler INRIA University of Utah Domaine de Voluceau-Rocquencourt Department of Computer Science B.P. 105 3190 M.E.B. Le Chesnay Cedex Salt l_xtke City, Utah 84112 France [email protected] chaillou @inria.inria.fr LP I-6.30 SPONSORSHIP OF LISP POINTERS Lisp Pointers is a non-profit publication created by the Lisp community for the Lisp community. Currently, Lisp Pointers is not affilated with any organization. For this reason, it is dependent upon the sponsorship of companies interested in l,isp for its publication. The following companies have in the past, or are currently, sponsoring Lisp Pointers: IBM Thomas J. Watson Research lnstitut National De Rechere En hfformatique Et En Automatique (I.N.R.I.A.) Xerox Pare Microelectronics and Computer Technology Corporation (MCC) Texas Instruments Digital Equipment Corporation Mitre Corporation Lisp Pointers is a newsletter, that is, it contains technical articles which are not refereed and which, therefore, may be republished in other technically refereed journals later. Lisp Pointers is a forum for preliminary papers, as well as for the fast interchange of ideas. As well as technical articles, Lisp Pointers contains columns and departments, such as the following: Query IO - The Scheme of Things - International News - Programming Environments Book Reviews - Lisp Implementations - ((lambda (discussions) (report on X3JI3))) Sponsors are permanently listed on the back cover of Lisp Pointers. We do this to thank those companies who have joined us in producing a publication which we think is both needed and wanted by this important research and production community. Because no organization is involved, the board running Lisp Pointers tends to be very conservative both legally and financially. A disclaimer for a sponsor company appears on the inside front cover. The disclaimer for the first issue reads as follows: This issue of the Lisp Pointers newsletter has been funded by the IBM Corporation. The IBM Corporation has not directed or controlled its publication. The opinions expressed herein are solely those of the authors, editors, publisher and other contribu- tors and do not necessarily reflect the opinions of the sponsoring company, the IBM Corporation, or the opinions of companies affiliated with individuals involved with this effort. Sponsorship involves the commitment to cover cost and work involved in the printing and dis- tribution of a single issue of Lisp Pointers. The editor creates a camera-ready copy which is sent to the sponsoring company. The sponsor arranges for the duplication and mailing of the issue. Cost to the sponsoring company is dependent upon the size of the mailing list, which will increase over time, the access to in.house duplication facilities, the size of the issue, and the cost of mailing to subscribers within the US. INRIA has accepted permanent sponsorship of all non-US subscribers. The number of US subscribers has grown from 500 to approximately 1100 over six issues and it can be assumed that that growth will continue for at least the next year. In addition to the number printed and mailed, the sponsor is asked to print an additional 150-200 copies which are used to satisfy requests for backorders.
Load more

Recommended publications
  • 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]
  • An Optimized R5RS Macro Expander
    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
    [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]
  • 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
    [Show full text]
  • Structured Foreign Types
    Ftypes: Structured foreign types Andrew W. Keep R. Kent Dybvig Indiana University fakeep,[email protected] Abstract When accessing scalar elements within an ftype, the value of the High-level programming languages, like Scheme, typically repre- scalar is automatically marshaled into the equivalent Scheme rep- sent data in ways that differ from the host platform to support resentation. When setting scalar elements, the Scheme value is consistent behavior across platforms and automatic storage man- checked to ensure compatibility with the specified foreign type, and agement, i.e., garbage collection. While crucial to the program- then marshaled into the equivalent foreign representation. Ftypes ming model, differences in data representation can complicate in- are well integrated into the system, with compiler support for ef- teraction with foreign programs and libraries that employ machine- ficient access to foreign data and debugger support for convenient dependent data structures that do not readily support garbage col- inspection of foreign data. lection. To bridge this gap, many high-level languages feature for- The ftype syntax is convenient and flexible. While it is similar in eign function interfaces that include some ability to interact with some ways to foreign data declarations in other Scheme implemen- foreign data, though they often do not provide complete control tations, and language design is largely a matter of taste, we believe over the structure of foreign data, are not always fully integrated our syntax is cleaner and more intuitive than most. Our system also into the language and run-time system, and are often not as effi- has a more complete set of features, covering all C data types along cient as possible.
    [Show full text]
  • Chez Scheme Version 5 Release Notes Copyright C 1994 Cadence Research Systems All Rights Reserved October 1994 Overview 1. Funct
    Chez Scheme Version 5 Release Notes Copyright c 1994 Cadence Research Systems All Rights Reserved October 1994 Overview This document outlines the changes made to Chez Scheme for Version 5 since Version 4. New items include support for syntax-case and revised report high-level lexical macros, support for multiple values, support for guardians and weak pairs, support for generic ports, improved trace output, support for shared incremental heaps, support for passing single floats to and returning single floats from foreign procedures, support for passing structures to and returning structures from foreign procedures on MIPS-based computers, and various performance enhancements, including a dramatic improvement in the time it takes to load Scheme source and object files on DEC Ultrix MIPS-based computers. Overall performance of generated code has increased by an average of 15–50 percent over Version 4 depending upon optimize level and programming style. Programs that make extensive use of locally-defined procedures will benefit more than programs that rely heavily on globally-defined procedures, and programs compiled at higher optimize levels will improve more than programs compiled at lower optimize levels. Compile time is approximately 25 percent faster. Refer to the Chez Scheme System Manual, Revision 2.5 for detailed descriptions of the new or modified procedures and syntactic forms mentioned in these notes. Version 5 is available for the following platforms: • Sun Sparc SunOS 4.X & Solaris 2.X • DEC Alpha AXP OSF/1 V2.X • Silicon Graphics IRIX 5.X • Intel 80x86 NeXT Mach 3.2 • Motorola Delta MC88000 SVR3 & SVR4 • Decstation/Decsystem Ultrix 4.3A • Intel 80x86 BSDI BSD/386 1.1 • Intel 80x86 Linux This document contains four sections describing (1) functionality enhancements, (2) performance enhance- ments, (3) bugs fixed, and (4) compatibility issues.
    [Show full text]
  • 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 .................................
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • Supplementary Material Forrebuilding Racket on Chez Scheme
    Supplementary Material for Rebuilding Racket on Chez Scheme (Experience Report) MATTHEW FLATT, University of Utah, USA CANER DERICI, Indiana University, USA R. KENT DYBVIG, Cisco Systems, Inc., USA ANDREW W. KEEP, Cisco Systems, Inc., USA GUSTAVO E. MASSACCESI, Universidad de Buenos Aires, Argentina SARAH SPALL, Indiana University, USA SAM TOBIN-HOCHSTADT, Indiana University, USA JON ZEPPIERI, independent researcher, USA All benchmark measurements were performed on an Intel Core i7-2600 3.4GHz processor running 64-bit Linux. Except as specifically noted, we used Chez Scheme 9.5.3 commit 7df2fb2e77 at github:cicso/ChezScheme, modified as commit 6d05b70e86 at github:racket/ChezScheme, and Racket 7.3.0.3 as commit ff95f1860a at github:racket/racket. 1 TRADITIONAL SCHEME BENCHMARKS The traditional Scheme benchmarks in figure1 are based on a suite of small programs that have been widely used to compare Scheme implementations. The benchmark sources are in the "common" directory of the racket-benchmarks package in the Racket GitHub repository. The results are in two groups, where the group starting with scheme-c uses mutable pairs, so they are run in Racket as #lang r5rs programs; for Racket CS we expect overhead due to the use of a record datatype for mutable pairs, instead of Chez Scheme’s built-in pairs. The groups are sorted by the ratio of times for Chez Scheme and the current Racket imple- mentation. Note that the break-even point is near the end of the first group. The racket collatz benchmark turns out to mostly measure the performance of the built-in division operator for rational numbers, while fft and nucleic benefit from flonum unboxing.
    [Show full text]
  • 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.
    [Show full text]
  • 23 Things I Know About Modules for Scheme
    23 things I know about modules for Scheme Christian Queinnec Université Paris 6 — Pierre et Marie Curie LIP6, 4 place Jussieu, 75252 Paris Cedex — France [email protected] ABSTRACT difficult to deliver (or even rebuild) stand-alone systems. The benefits of modularization are well known. However, Interfaces as collection of names — If modules are about shar- modules are not standard in Scheme. This paper accompanies ing, what should be shared ? Values, locations (that is an invited talk at the Scheme Workshop 2002 on the current variables), types, classes (and their cortege` of accessors, state of modules for Scheme. Implementation is not addressed, constructors and predicates) ? only linguistic features are covered. Cave lector, this paper only reflects my own and instanta- The usual answer in Scheme is to share locations with neous biases! (quite often) two additional properties: (i) these loca- tions can only be mutated from the body of their defin- ing modules (this favors block compilation), (ii) they 1. MODULES should hold functions (and this should be statically (and The benefits of modularization within conventional languages easily) discoverable). This restricts linking with other are well known. Modules dissociate interfaces and implemen- (foreign) languages that may export locations holding tations; they allow separate compilation (or at least indepen- non-functional data (the errno location for instance). dent compilation a` la C). Modules tend to favor re-usability, This is not a big restriction since modern interfaces (Corba common libraries and cross language linkage. for example) tend to exclusively use functions (or meth- Modules discipline name spaces with explicit names expo- ods).
    [Show full text]
  • Programming Languages As Operating Systems
    Programming Languages as Op erating Systems (or Revenge of the Son of the Lisp Machine) Matthew Flatt Rob ert Bruce Findler Shriram Krishnamurthi Matthias Felleisen Department of Computer Science Rice University Houston, Texas 77005-1892 reclaim the program's resources|even though the program Abstract and DrScheme share a single virtual machine. The MrEd virtual machine serves b oth as the implementa- To address this problem, MrEd provides a small set of tion platform for the DrScheme programming environment, new language constructs. These constructs allow a program- and as the underlying Scheme engine for executing expres- running program, suchasDrScheme, to run nested programs sions and programs entered into DrScheme's read-eval-print directly on the MrEd virtual machine without sacri cing lo op. We describ e the key elements of the MrEd virtual control over the nested programs. As a result, DrScheme machine for building a programming environment, and we can execute a copyofDrScheme that is executing its own step through the implementation of a miniature version of copy of DrScheme (see Figure 1). The inner and middle DrScheme in MrEd. More generally,weshowhow MrEd de- DrSchemes cannot interfere with the op eration of the outer nes a high-level op erating system for graphical programs. DrScheme, and the middle DrScheme cannot interfere with the outer DrScheme's control over the inner DrScheme. In this pap er, we describ e the key elements of the MrEd 1 MrEd: A Scheme Machine virtual machine, and we step through the implementation of a miniature version of DrScheme in MrEd. More gen- The DrScheme programming environment [10] provides stu- erally,weshowhow MrEd de nes a high-level op erating dents and programmers with a user-friendly environment system (OS) for graphical programs.
    [Show full text]