Tugboat, Volume 40 (2019), No. 2 119 Quickref: Common Lisp

Total Page:16

File Type:pdf, Size:1020Kb

Tugboat, Volume 40 (2019), No. 2 119 Quickref: Common Lisp TUGboat, Volume 40 (2019), No. 2 119 Quickref: Common Lisp reference extensible than its industrial competitors such as documentation as a stress test for Texinfo C++ or Java. Interestingly enough, the technical strengths of Didier Verna the language bring serious drawbacks to its commu- Abstract nity of programmers (a phenomenon affecting all the dialects). These problems are known and have been Quickref is a global documentation project for the discussed many times [4, 7]. They may explain, at Common Lisp ecosystem. It creates reference manu- least partly, why in spite of its technical potential, als automatically by introspecting libraries and gen- the Lisp family of languages never really took over, erating corresponding documentation in Texinfo for- and probably never will. The situation can be sum- mat. The Texinfo files may subsequently be con- marized as follows: Lisp usually makes it so easy verted into PDF or HTML. Quickref is non-intrusive: to \hack" things away that every Lisper ends up de- software developers do not have anything to do to veloping his or her own solution, inevitably leading get their libraries documented by the system. to a paradox of choice. The result is a plethora of Quickref may be used to create a local website solutions for every single problem that every single documenting your current, partial, working environ- programmer faces. Most of the time, these solutions ment, but it is also able to document the whole work, but they are either half-baked or targeted Common Lisp ecosystem at once. The result is a to the author's specific needs and thus not general website containing almost two thousand reference enough. Furthermore, it is difficult to assert their manuals. Quickref provides a Docker image for an quality, and they are usually not (well) documented. easy recreation of this website, but a public version As this situation is well known, the commu- is also available and actively maintained. nity has been attempting to \consolidate" itself in Quickref constitutes an enormous and success- various ways. Several websites aggregate resources ful stress test for Texinfo. In this paper, we give related to the language or its usage (books, tuto- an overview of the design and architecture of the rials, implementations, development environments, system, describe the challenges and difficulties in applications, etc.). The Common Lisp Foundation generating valid Texinfo code automatically, and put (cl-foundation.org) provides technical, sometimes some emphasis on the currently remaining problems even financial, support and infrastructure for project and deficiencies. authors. Once a year, the European Lisp Sympo- sium (european-lisp-symposium.org) gathers the international community, open equally to researchers 1 Introduction and practitioners, newcomers and experts. Lisp is a high level, general purpose, multi-paradigm From a more technical standpoint, solving the programming language created in 1958 by John Mc- paradox of choice, that is, deciding on official solu- Carthy [2]. We owe to Lisp many of the programming tions for doing this or that, is much more problem- concepts that are still considered fundamental today atic | there is no such thing as an official authority (functional programming, garbage collection, inter- in the community. On the other hand, some libraries active development, etc.). Over the years, Lisp has do impose themselves as de facto standards. Two of evolved as a family of dialects (including Scheme, them are worth mentioning here. Most non-trivial Racket, and Clojure, to name a few) rather than as a Common Lisp packages today use ASDF for structur- single language. Another Lisp descendant of notable ing themselves (fig.1 has an example). ASDF allows importance is Common Lisp, a language targeting you to define your package architecture in terms of the industry, which was standardized in 1994 [5]. source files and directories, dependencies and other The Lisp family of languages is mostly known metadata. It automates the process of compiling and for two of its most prominent (and correlated) char- loading (dependencies included). The second one is acteristics: a minimalist syntax and a very high level Quicklisp (quicklisp.org). Quicklisp is both a cen- of expressiveness and extensibility. The root of the tral repository for Common Lisp libraries (not unlike latter, right from the early days, is the fact that CTAN) and a programmatic interface for it. With code and data are represented in the same way (a Quicklisp, downloading, installing, compiling and property known as homoiconicity [1, 3]). This makes loading a specific package on your machine (again, de- meta-programming not only possible but also trivial. pendencies included) essentially becomes a one-liner. Being a Lisp, Common Lisp not only maintains this One remaining problem is that of documenta- property, but also provides an unprecedented arsenal tion. Of course, it is impossible to force a library of paradigms making it much more expressive and author to properly document his or her work. One Quickref: Common Lisp reference documentation as a stress test for Texinfo 120 TUGboat, Volume 40 (2019), No. 2 (asdf:defsystem :net.didierverna.declt :long-name "Documentation Extractor from Common Lisp to Texinfo" :description "A reference manual generator for Common Lisp libraries" :author "Didier Verna" :mailto "[email protected]" :homepage "http://www.lrde.epita.fr/~didier/software/lisp/" :source-control "https://github.com/didierverna/declt" :license "BSD" ...) Figure 1: ASDF system definition excerpt could consider writing the manuals they miss for the 2.2 Documentation items third-party libraries they use, but this never happens Reference manuals generated by Quickref contain in practice. There is still something that we can do to information collected from various sources. First of mitigate the issue, however. Because Common Lisp all, many libraries provide a README file of some is highly reflexive, it is relatively straightforward to sort, which can make for a nice introductory chapter. retrieve the information necessary to automatically In addition to source files and dependencies, ASDF create and typeset reference manuals (as opposed to offers ways to specify project-related metadata in the user manuals). Several such projects exist already so-called system definition form. Figure 1 illustrates (remember the paradox of choice). In this paper this. Such information can be easily (programmati- we present our own, probably the most complete cally) retrieved and used. Next, Lisp itself has some Common Lisp documentation generator to date. built-in support for documentation, in the form of Enter Quickref. so-called docstrings. As their name suggests, doc- strings are (optional) documentation strings that may be attached to various language constructs such 2 Overview as functions, variables, methods and so on. Figure 2 Quickref is a global documentation project for the has an example. When available, docstrings greatly Common Lisp ecosystem. It generates reference man- contribute to the completeness of reference manu- uals for libraries available in Quicklisp automatically. als, and again, may be retrieved programmatically Quickref is non-intrusive, in the sense that software through a simple standard function call. developers do not have anything to do to get their li- braries documented by the system: mere availability (defmacro @defconstant (name &body body) in Quicklisp is the only requirement. In this sec- "Execute BODY within a @defvr Constant. tion, we provide a general overview of the system's NAME is escaped for Texinfo prior to rendering. features, design, and implementation. BODY should render on *standard-output*." `(@defvr "Constant" ,name ,@body)) 2.1 Features Figure 2: Common Lisp docstring example Quickref may be used to create a local website docu- menting your current, partial, working environment, As for the rest, the solution is less straightfor- but it is also able to document the whole Quicklisp ward. We want our reference manuals to advertise world at once, which means that almost two thousand as many software components as possible (functions, reference manuals are generated. Creating a local variables, classes, packages, etc.). In general there documentation website can be done in two different are two main strategies for collecting this informa- ways: either by using the provided Docker image tion. (the most convenient solution for an exhaustive web- Code walking. The first one, known as code walk- site), or directly via the programmatic interface, from ing, consists of statically analyzing the source code. within a running Lisp environment (when only the A code walker is usually at least as complicated as documentation for the local, partial, installation is the syntax of the target language, because it requires required). If you don't want to run Quickref yourself, a parser for it. Because of Lisp's minimalist syn- a public website is also provided and actively main- tax, using a code walker is a very tempting solution. tained at quickref.common-lisp.net. It always On the other hand, Lisp is extremely dynamic in contains the result of a full run of the system on the nature, meaning that many of the final program's latest Quicklisp distribution. components may not be directly visible in the source Didier Verna TUGboat, Volume 40 (2019), No. 2 121 Quicklisp foo/ Declt foo.texi Makeinfo foo.html Figure 3: Quickref pipeline ( Main thread, External Process) code. On top of that, programs making syntactic documentation can in turn be generated in many extensions to the language would not be directly different forms (notably PDF and HTML). Fi- parsable. In short, it is practically impossible to nally, it includes very convenient built-in anchor- collect all the required information by code walking ing, cross-referencing, and indexing capabilities. alone. Therefore, we do not use that approach. Quickref essentially runs this pipeline on the Introspection. Our preferred approach is by in- required libraries. Some important remarks need to trospection. Here, the idea is to actually compile be made about this process.
Recommended publications
  • The Clon User Manual the Command-Line Options Nuker, Version 1.0 Beta 25 "Michael Brecker"
    The Clon User Manual The Command-Line Options Nuker, Version 1.0 beta 25 "Michael Brecker" Didier Verna <[email protected]> Copyright c 2010{2012, 2015, 2017, 2020, 2021 Didier Verna Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled \Copy- ing" is included exactly as in the original. Permission is granted to copy and distribute translations of this manual into an- other language, under the above conditions for modified versions, except that this permission notice may be translated as well. Cover art by Alexis Angelidis. i Table of Contents Copying ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1 Introduction :::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2 Installation:::::::::::::::::::::::::::::::::::::::::::::::::::::: 5 3 Quick Start ::::::::::::::::::::::::::::::::::::::::::::::::::::: 7 3.1 Full Source :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 7 3.2 Explanation ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 7 4 Using Clon :::::::::::::::::::::::::::::::::::::::::::::::::::: 11 4.1 Synopsis Definition ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 4.1.1 Synopsis Items ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 4.1.1.1 Text ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • A Concurrent PASCAL Compiler for Minicomputers
    512 Appendix A DIFFERENCES BETWEEN UCSD'S PASCAL AND STANDARD PASCAL The PASCAL language used in this book contains most of the features described by K. Jensen and N. Wirth in PASCAL User Manual and Report, Springer Verlag, 1975. We refer to the PASCAL defined by Jensen and Wirth as "Standard" PASCAL, because of its widespread acceptance even though no international standard for the language has yet been established. The PASCAL used in this book has been implemented at University of California San Diego (UCSD) in a complete software system for use on a variety of small stand-alone microcomputers. This will be referred to as "UCSD PASCAL", which differs from the standard by a small number of omissions, a very small number of alterations, and several extensions. This appendix provides a very brief summary Of these differences. Only the PASCAL constructs used within this book will be mentioned herein. Documents are available from the author's group at UCSD describing UCSD PASCAL in detail. 1. CASE Statements Jensen & Wirth state that if there is no label equal to the value of the case statement selector, then the result of the case statement is undefined. UCSD PASCAL treats this situation by leaving the case statement normally with no action being taken. 2. Comments In UCSD PASCAL, a comment appears between the delimiting symbols "(*" and "*)". If the opening delimiter is followed immediately by a dollar sign, as in "(*$", then the remainder of the comment is treated as a directive to the compiler. The only compiler directive mentioned in this book is (*$G+*), which tells the compiler to allow the use of GOTO statements.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • Open Office Specification 1.0
    Open Office Specification 1.0 Committee Draft 1, 22 Mar 2004 Document identifier: office-spec-1.0-cd-1.sxw Location: http://www.oasis-open.org/committees/office/ Editors: Michael Brauer, Sun Microsystems <[email protected]> Gary Edwards <[email protected]> Daniel Vogelheim, Sun Microsystems <[email protected]> Contributors: Doug Alberg, Boeing <[email protected]> Simon Davis, National Archive of Australia <[email protected]> Patrick Durusau, Society of Biblical Literature <[email protected]> David Faure, <[email protected]> Paul Grosso, Arbortext <[email protected]> Tom Magliery, Blast Radius <[email protected]> Phil Boutros, Stellent <[email protected]> John Chelsom, CSW Informatics <[email protected]> Jason Harrop, SpeedLegal <[email protected]> Mark Heller, New York State Office of the Attorney General <[email protected]> Paul Langille, Corel <[email protected]> Monica Martin, Drake Certivo <[email protected]> Uche Ogbuji <[email protected]> Lauren Wood <[email protected]> Abstract: This is the specification of Open Office XML, an open, XML-based file format for office applications, based on OpenOffice.org XML [OOo]. Status: This document is a draft, and will be updated periodically on no particular schedule. Send comments to the editors. Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to office- [email protected] with the word "subscribe" as the body of the message.
    [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]
  • From JSON to JSEN Through Virtual Languages of the Creative Commons Attribution License (
    © 2021 by the authors; licensee RonPub, Lübeck, Germany. This article is an open access article distributed under the terms and conditions A.of Ceravola, the Creative F. Joublin:Commons From Attribution JSON to license JSEN through(http://c reativecommons.org/licenses/by/4Virtual Languages .0/). Open Access Open Journal of Web Technology (OJWT) Volume 8, Issue 1, 2021 www.ronpub.com/ojwt ISSN 2199-188X From JSON to JSEN through Virtual Languages Antonello Ceravola, Frank Joublin Honda Research Institute Europe GmbH, Carl Legien Str. 30, Offenbach/Main, Germany, {Antonello.Ceravola, Frank.Joublin}@honda-ri.de ABSTRACT In this paper we describe a data format suitable for storing and manipulating executable language statements that can be used for exchanging/storing programs, executing them concurrently and extending homoiconicity of the hosting language. We call it JSEN, JavaScript Executable Notation, which represents the counterpart of JSON, JavaScript Object Notation. JSON and JSEN complement each other. The former is a data format for storing and representing objects and data, while the latter has been created for exchanging/storing/executing and manipulating statements of programs. The two formats, JSON and JSEN, share some common properties, reviewed in this paper with a more extensive analysis on what the JSEN data format can provide. JSEN extends homoiconicity of the hosting language (in our case JavaScript), giving the possibility to manipulate programs in a finer grain manner than what is currently possible. This property makes definition of virtual languages (or DSL) simple and straightforward. Moreover, JSEN provides a base for implementing a type of concurrent multitasking for a single-threaded language like JavaScript.
    [Show full text]
  • California Forest Insect and Disease Training Manual
    California Forest Insect and Disease Training Manual This document was created by US Forest Service, Region 5, Forest Health Protection and the California Department of Forestry and Fire Protection, Forest Pest Management forest health specialists. The following publications and references were used for guidance and supplemental text: Forest Insect and Disease Identification and Management (training manual). North Dakota Forest Service, US Forest Service, Region 1, Forest Health Protection, Montana Department of Natural Resources and Conservation and Idaho Department of Lands. Forest Insects and Diseases, Natural Resources Institute. US Forest Service, Region 6, Forest Health Protection. Forest Insect and Disease Leaflets. USDA Forest Service Furniss, R.L., and Carolin, V.M. 1977. Western forest insects. USDA Forest Service Miscellaneous Publication 1339. 654 p. Goheen, E.M. and E.A. Willhite. 2006. Field Guide to Common Disease and Insect Pests of Oregon and Washington Conifers. R6-NR-FID-PR-01-06. Portland, OR. USDA Forest Service, Pacific Northwest Region. 327 p. M.L. Fairweather, McMillin, J., Rogers, T., Conklin, D. and B Fitzgibbon. 2006. Field Guide to Insects and Diseases of Arizona and New Mexico. USDA Forest Service. MB-R3-16-3. Pest Alerts. USDA Forest Service. Scharpf, R. F., tech coord. 1993. Diseases of Pacific Coast Conifers. USDA For. Serv. Ag. Hndbk. 521. 199 p.32, 58. Tree Notes Series. California Department of Forestry and Fire Protection. Wood, D.L., T.W. Koerber, R.F. Scharpf and A.J. Storer, Pests of the Native California Conifers, California Natural History Series, University of California Press, 2003. Cover Photo: Don Owen. 1978. Yosemite Valley.
    [Show full text]
  • Basic Lisp Techniques
    Basic Lisp Techniques David J. Cooper, Jr. February 14, 2011 ii 0Copyright c 2011, Franz Inc. and David J. Cooper, Jr. Foreword1 Computers, and the software applications that power them, permeate every facet of our daily lives. From groceries to airline reservations to dental appointments, our reliance on technology is all-encompassing. And, it’s not enough. Every day, our expectations of technology and software increase: • smart appliances that can be controlled via the internet • better search engines that generate information we actually want • voice-activated laptops • cars that know exactly where to go The list is endless. Unfortunately, there is not an endless supply of programmers and developers to satisfy our insatiable appetites for new features and gadgets. Every day, hundreds of magazine and on-line articles focus on the time and people resources needed to support future technological expectations. Further, the days of unlimited funding are over. Investors want to see results, fast. Common Lisp (CL) is one of the few languages and development options that can meet these challenges. Powerful, flexible, changeable on the fly — increasingly, CL is playing a leading role in areas with complex problem-solving demands. Engineers in the fields of bioinformatics, scheduling, data mining, document management, B2B, and E-commerce have all turned to CL to complete their applications on time and within budget. CL, however, no longer just appropriate for the most complex problems. Applications of modest complexity, but with demanding needs for fast development cycles and customization, are also ideal candidates for CL. Other languages have tried to mimic CL, with limited success.
    [Show full text]
  • Nesting Forward-Mode AD in a Functional Framework Jeffrey M
    Purdue University Purdue e-Pubs ECE Technical Reports Electrical and Computer Engineering 1-1-2008 Nesting Forward-Mode AD in a Functional Framework Jeffrey M. Siskind Purdue University, [email protected] Barak A. Pearlmutter NUI Maynooth Co. Kildare, [email protected] Follow this and additional works at: http://docs.lib.purdue.edu/ecetr Part of the Electrical and Computer Engineering Commons Siskind, Jeffrey M. and Pearlmutter, Barak A., "Nesting Forward-Mode AD in a Functional Framework" (2008). ECE Technical Reports. Paper 377. http://docs.lib.purdue.edu/ecetr/377 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. Purdue ECE TR-08-09 Nesting Forward-Mode AD in a Functional Framework Jeffrey Mark Siskind School of Electrical & Computer Engineering Purdue University 465 Northwestern Avenue West Lafayette, IN 47907-2035 USA +1 765 496 3197 [email protected] Barak A. Pearlmutter Hamilton Institute NUI Maynooth Co. Kildare Ireland +353 1 708 6100 [email protected] Abstract We discuss the augmentation of a functional-programming language with a derivative- taking operator implemented with forward-mode automatic differentiation (AD). The primary technical difficulty in doing so lies in ensuring correctness in the face of nested invocation of that operator, due to the need to distinguish perturbations introduced by distinct invocations. We exhibit a series of implementations of a referentially- transparent forward-mode-AD derivative-taking operator, each of which uses a different non-referentially-transparent mechanism to distinguish perturbations. Even though the forward-mode-AD derivative-taking operator is itself referentially transparent, we hypothesize that one cannot correctly formulate this operator as a function definition in current pure dialects of Haskell.
    [Show full text]
  • Measuring Spreadsheet Formula Understandability
    Measuring Spreadsheet Formula Understandability Felienne Hermans , Martin Pinzger & Arie van Deursen Mekelweg 4, Delft {f.f.j.hermans, m.pinzger, arie.vandeursen}@tudelft.nl ABSTRACT Spreadsheets are widely used in industry, because they are flexible and easy to use. Sometimes they are even used for business-critical applications. It is however difficult for spreadsheet users to correctly assess the quality of spreadsheets, especially with respect to their understandability. Understandability of spreadsheets is important, since spreadsheets often have a long lifespan, during which they are used by several users. In this paper, we establish a set of spreadsheet understandability metrics. We start by studying related work and interviewing 40 spreadsheet professionals to obtain a set of characteristics that might contribute to understandability problems in spreadsheets. Based on those characteristics we subsequently determine a number of understandability metrics. To evaluate the usefulness of our metrics, we conducted a series of experiments in which professional spreadsheet users performed a number of small maintenance tasks on a set of spreadsheets from the EUSES spreadsheet corpus. We subsequently calculate the correlation between the metrics and the performance of subjects on these tasks. The results clearly indicate that the number of ranges, the nesting depth and the presence of conditional operations in formulas significantly increase the difficulty of understanding a spreadsheet. 1 INTRODUCTION Spreadsheets are used extensively in business, for all sorts of tasks and purposes. While other assets of companies---like software products and processes---are strongly guarded, spreadsheets are usually not structurally checked. This lack of control contrasts their impact, which can be very large, as previous studies have shown.
    [Show full text]
  • Learn Pascal.Pdf
    Index • Introduction • History of Pascal • Pascal Compilers • Hello, world. • Basics o Program Structure o Identifiers o Constants o Variables and Data Types o Assignment and Operations o Standard Functions o Punctuation and Indentation o Programming Assignment o Solution • Input/Output o Input o Output o Formatting output o Files o EOLN and EOF o Programming Assignment o Solution • Program Flow o Sequential control o Boolean Expressions o Branching . IF . CASE o Looping . FOR..DO . WHILE..DO . REPEAT..UNTIL o Programming Assignments: Fibonacci Sequence and Powers of Two o Solutions • Subprograms o Procedures o Parameters o Functions o Scope o Recursion o Forward Referencing o Programming Assignment: the Towers of Hanoi o Solution • Data types o Enumerated types o Subranges o 1-dimensional arrays o Multidimensional arrays o Records o Pointers • Final words 2 Introduction Welcome to Learn Pascal! This tutorial is an introduction to the Pascal simple, yet complete, introduction to the Pascal programming language. It covers all of the syntax of standard Pascal, including pointers. I have tried to make things are clear as possible. If you don't understand anything, try it in your Pascal compiler and tweak things a bit. Pascal was designed for teaching purposes, and is a very structured and syntactically-strict language. This means the compiler will catch more beginner errors and yield more beginner-friendly error messages than with a shorthand-laden language such as C or PERL. This tutorial was written for beginner programmers, so assumes no knowledge. At the same time, a surprising number of experienced programmers have found the tutorial a useful reference source for picking up Pascal.
    [Show full text]
  • Openoffice.Org for Dummies.Pdf
    542222 FM.qxd 11/6/03 3:29 PM Page i OpenOffice.org FOR DUMmIES‰ by Gurdy Leete, Ellen Finkelstein, and Mary Leete 542222 FM.qxd 11/6/03 3:29 PM Page iv 542222 FM.qxd 11/6/03 3:29 PM Page i OpenOffice.org FOR DUMmIES‰ by Gurdy Leete, Ellen Finkelstein, and Mary Leete 542222 FM.qxd 11/6/03 3:29 PM Page ii OpenOffice.org For Dummies® Published by Wiley Publishing, Inc. 111 River Street Hoboken, NJ 07030-5774 Copyright © 2004 by Wiley Publishing, Inc., Indianapolis, Indiana Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, e-mail: [email protected]. Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc.
    [Show full text]