diff --git a/content/en/history/glossary/_index.md b/content/en/history/glossary/_index.md index 69c3cbf3..66642057 100644 --- a/content/en/history/glossary/_index.md +++ b/content/en/history/glossary/_index.md @@ -13,6 +13,9 @@ For general computer terminology and lore see [The Hacker's Dictionary](https:// ## Vocabulary and relationships +Advice (Advising) +: A facility for modifying an existing function without editing its definition by wrapping it with code that runs before or after the function and can inspect or change its arguments or return value. Advice can be added to and removed from a function independently, so a programmer can instrument or adapt code temporarily and leave the original definition intact. Also called advising. + AltoLisp : An experimental microcoded implementation of Interlisp on an Alto personal computer. @@ -53,12 +56,18 @@ as a graphics terminal. Dorado Lisp : The reimplementation of the AltoLisp microcode on the Dorado – a research prototype. +DWIM +: Do-What-I-Mean. An Interlisp error-recovery facility that intercepts errors such as undefined functions, unset variables, and misspellings, using heuristics and context-sensitive spelling lists to suggest or apply corrections and continue execution. When a correction is uncertain, DWIM can ask the user to approve it; when the user is away, it can apply a default after a delay. DWIM can also repair some structural errors, such as a number typed in place of a parenthesis, so the computation can proceed without restarting. + Fugue : An obsolete named release of Interlisp-D. Harmony : An obsolete named release of Interlisp-D. +History package +: An Interlisp facility that records the commands and expressions entered during a session, together with messages displayed during their execution, so they can be reviewed, replayed with substitutions, or undone. Each recorded event also keeps the information needed to reverse its side effects, which makes the history list the basis for UNDO. The history can be searched and selectively replayed, so a user can reuse or correct an earlier operation without retyping it. + Intermezzo : An obsolete named release of Interlisp-D. @@ -123,12 +132,27 @@ as a graphics terminal. - Informally, a collection of utilities or submodule in Interlisp (the "break package", q.v.; the "file package", a facility for managing code changes; the "record package", a record data type; and so on) - A feature of Commmon Lisp symbol support; the package system allows the combining of Interlisp symbols (written with `IL:` prefix) and Common Lisp symbols (written with a `LISP:` prefix). +Prettyprint +: A Lisp utility that prints programs with indentation and line breaks that reflect their list structure, making code easier to read and debug. Because Lisp programs are lists, a prettyprinter can lay out nested expressions according to their depth and width instead of printing them as one long line. It is used both to display code and to produce readable listings or files. + SDL : Structured Design Language. +Spaghetti stack +: An Interlisp execution stack that remains available as a structured list rather than a contiguous array, so each frame can still be reached through the list structure. This lets programs and debugging tools search frames, inspect values in caller contexts, and perform non-local returns. Because the stack can be traversed and its frames examined, it supports debugging, error recovery, and control operations that would be difficult with a conventional call stack. + +Structure editor +: An editor that operates directly on a program's list structure rather than its printed text. Because Lisp programs are lists, commands can move through and modify a function's tree in place without leaving Lisp. Editing commands select list elements, descend into sublists, and insert, delete, or replace structures, so the edit changes the program itself rather than a separate text file. This allows a running program to be inspected, modified, and re-evaluated in the same environment. + Sysout : A file containing the saved state of Interlisp virtual memory. +Trace +: A Lisp debugging facility that redefines a function so that selected information, by default its arguments and return value, is printed when the function is entered and exited. Tracing can be applied to one function or several and remains in effect until the function is untraced. It gives a running account of calls and results without requiring the programmer to stop the program or insert print statements by hand. + +UNDO +: A command in the Interlisp Programmer’s Assistant that reverses the side effects of operations recorded on its history list. It supports selective undo—reversing an earlier operation without undoing later ones—as well as undoing assignments and whole edit sessions. A user can also make a user-defined function undoable by recording the information needed to reverse its effects. Undoing an operation can itself be undone, and related commands can redo or reuse recorded events. + X11 : The X Window System. diff --git a/content/en/history/timeline/_index.md b/content/en/history/timeline/_index.md index 5db694e7..575b8e80 100644 --- a/content/en/history/timeline/_index.md +++ b/content/en/history/timeline/_index.md @@ -30,13 +30,13 @@ Teitelman’s experience with his Ph.D. work led him to the notion of building a The term “programming environment” was meant to suggest not only the usual specifics of both a programming system and language but also more elusive and subjective considerations such as ease of use and level of interaction, “forgiveness” of errors, human engineering, and system “initiative.” The programmer’s environment influences and to a large extent determines, what sort of problems they can (and will want to) tackle, how far they can go, and how fast. If the environment is “cooperative” and “helpful”, then the programmer can be more ambitious and productive. If not, they will spend most of their time and energy “fighting” the system, which at times seems bent on frustrating one’s best efforts. -In 1965, there were very few tools for developing Lisp programs, and those that were available were very primitive. +In 1965, there were very few tools for developing Lisp programs, and those that were available were very primitive. These included [Prettyprint](/history/glossary/#prettyprint), which printed Lisp programs with indentation reflecting their list structure, and a [Trace](/history/glossary/#trace) facility, which modified functions to print their input parameters on entry and their value on exit. ### 1966 - MIT EE Dept PDP-36 [LISP manual](/history/bibliography/6m8iseul/) -Teitelman started at Bolt, Beranek and Newman in Cambridge. At the time, [BBN](/history/glossary/#bbn)’s computer was a DEC PDP-1, and Daniel Murphy had written a version of Lisp 1.5 for it using ideas from Deutch’s work. This Lisp was really just a toy – single user, slow, small address space, but Teitelman started with Break and Prettyprint from MIT on his pursuit of a Lisp programming environment. +Teitelman started at Bolt, Beranek and Newman in Cambridge. At the time, [BBN](/history/glossary/#bbn)’s computer was a DEC PDP-1, and Daniel Murphy had written a version of Lisp 1.5 for it using ideas from Deutch’s work. This Lisp was really just a toy – single user, slow, small address space, but Teitelman obtained copies of the MIT Break and Prettyprint utilities and brought them to BBN-LISP in his pursuit of a Lisp programming environment. - http://www.softwarepreservation.org/projects/LISP/bbnlisp/BBN-LISP-System_Feb1966.pdf#page=49 @@ -46,7 +46,7 @@ In 1967, BBN purchased an SDS 940 computer from Scientific Data Systems and bega - [Improvements to the 940 LISP Library](/history/bibliography/6m8iseul/) -Advising was a means of allowing the user to treat a particular function as a black box without knowing what was inside the box, wrap “advice” around it that could operate before the function ran, potentially changing its input parameters, after it ran, possibly changing its value, or call PrettyPrint, which printed out a nicely formatted representation of Lisp programs, using indentation to indicate depth of structure. A Trace facility was also available which modified specified functions to print on the terminal their input parameters on entry and their value on exit. You could think of this as a special case of Advising. There was also a [Break package](/history/glossary/#break-package) which enabled the user to cause program execution to halt at the entry point to specific functions. The user could then examine the value of the function’s input parameters, and even change them, then cause the function to run, and again gain control so as to examine the value that the function returned or side effects of the function’s operation. The user could change input parameters and re-execute the function, or manually specify the desired value and have it be returned to the caller as though it had been the value produced by that function. +[Advising](/history/glossary/#advising) was a means of allowing the user to treat a particular function as a black box without knowing what was inside the box, wrap “advice” around it that could operate before the function ran, potentially changing its input parameters, after it ran, possibly changing its value, or call PrettyPrint, which printed out a nicely formatted representation of Lisp programs, using indentation to indicate depth of structure. A Trace facility was also available which modified specified functions to print on the terminal their input parameters on entry and their value on exit. You could think of this as a special case of Advising. There was also a [Break package](/history/glossary/#break-package) which enabled the user to cause program execution to halt at the entry point to specific functions. The user could then examine the value of the function’s input parameters, and even change them, then cause the function to run, and again gain control so as to examine the value that the function returned or side effects of the function’s operation. The user could change input parameters and re-execute the function, or manually specify the desired value and have it be returned to the caller as though it had been the value produced by that function. Teitelman memo to [SDS 940 LISP Users](/history/bibliography/6m8iseul/). @@ -54,10 +54,12 @@ Teitelman memo to [SDS 940 LISP Users](/history/bibliography/6m8iseul/). Work on Demand Paging software virtual memory was focused on supporting Lisp. -Peter Deutsch wrote a **structure editor** in Lisp for editing Lisp programs. Prior to this, Lisp source was prepared and edited offline in textual form and read into the Lisp system. Peter’s editor enabled the user to edit Lisp programs without ever leaving Lisp. The editor provided operations for moving up, down, left or right in the list structure definition of a Lisp function, and to make insertions, deletions, or replacements, e.g. (-3 X) to insert X in front of the 3rd item in the current list, 2 to descend into the second item in the current list, 0 to ascend one level, etc. Other more sophisticated commands were soon added, such as a find command to search through all levels of the function being edited looking for a specified string or pattern, a mark command to mark, i.e. save, the current location, and a command to restore the context to one that had previously been marked, an ability to define macros, etc. +Peter Deutsch began a **[structure editor](/history/glossary/#structure-editor)** in Lisp in 1965; Daniel Bobrow and Warren Teitelman later extended it at BBN. Prior to the editor, Lisp source was prepared and edited offline in textual form and read into the Lisp system. By 1968 Peter’s editor enabled the user to edit Lisp programs without ever leaving Lisp. The editor provided operations for moving up, down, left or right in the list structure definition of a Lisp function, and to make insertions, deletions, or replacements, e.g. (-3 X) to insert X in front of the 3rd item in the current list, 2 to descend into the second item in the current list, 0 to ascend one level, etc. Other more sophisticated commands were soon added, such as a find command to search through all levels of the function being edited looking for a specified string or pattern, a mark command to mark, i.e. save, the current location, and a command to restore the context to one that had previously been marked, an ability to define macros, etc. The ability to edit a Lisp program in situ meant that a user could modify a running program and continue execution. For example, the user might be at a Break, evaluate the current function, identify a problem, edit the definition using the structure editor, and reevaluate the current, now modified function and go on. +- Peter Deutsch, [Preliminary Guide to the LISP Editor](/history/bibliography/zk7mfmne/) (1967) + ### 1969 Alice K. Hartley took over Dan Murphy’s role in BBN-LISP. A number of new data types were added to augment lists and numbers: arrays, strings, large numbers, floating-point numbers. @@ -68,9 +70,9 @@ Alice K. Hartley took over Dan Murphy’s role in BBN-LISP. A number of new data As Lisp users began to write larger and larger programs, performance began to be an issue. A compiler had been available for Lisp programs since the early sixties. -In 1970, Danny Bobrow and Alice Hartley designed and implemented the “spaghetti stack”. This enabled running programs to search the current execution stack, e.g., find the second occurrence up the stack of the function FOO, and return the name of the function that called FOO, to alter the normal flow of control, e.g., return from a specified stack pointer a specified value (very useful when debugging programs in order to manually bypass a known problem), and to evaluate an expression or variable in a specified context, e.g., what is the value of x as of six function calls back up the stack. +In 1970, Danny Bobrow and Alice Hartley designed and implemented the “[spaghetti stack](/history/glossary/#spaghetti-stack)”. This enabled running programs to search the current execution stack, e.g., find the second occurrence up the stack of the function FOO, and return the name of the function that called FOO, to alter the normal flow of control, e.g., return from a specified stack pointer a specified value (very useful when debugging programs in order to manually bypass a known problem), and to evaluate an expression or variable in a specified context, e.g., what is the value of x as of six function calls back up the stack. -**DWIM**, the most well known, and in some cases reviled, feature of BBN-LISP was introduced in 1970. DWIM stands for Do-What-I-Mean and embodies Teitelman’s view that people's time was more valuable/expensive than computer time. (This was a radical idea at the time.) When Teitelman first started programming in FORTRAN in 1960, he was appalled at receiving the error message, “on line 70, DIMENSION is misspelled”. If the FORTRAN compiler knew this to be the case, why didn’t it accept this and go on and compile his program? +**[DWIM](/history/glossary/#dwim)**, the most well known, and in some cases reviled, feature of BBN-LISP was introduced in 1970. DWIM stands for Do-What-I-Mean and embodies Teitelman’s view that people's time was more valuable/expensive than computer time. (This was a radical idea at the time.) When Teitelman first started programming in FORTRAN in 1960, he was appalled at receiving the error message, “on line 70, DIMENSION is misspelled”. If the FORTRAN compiler knew this to be the case, why didn’t it accept this and go on and compile his program? The BBN-LISP interpreter was modified so that rather than signal an error when an undefined function or unset variable was encountered, DWIM would use various heuristics to identify and attempt to correct the error. Spelling correction was the most common scenario. An algorithm was implemented that took advantage of the most common types of errors made by a touch typist, e.g., doubled characters, transpositions, case error, etc. @@ -82,12 +84,18 @@ DWIM could also handle the case where the user typed a number instead of ‘(‘ Spelling correction was also used in contexts besides evaluating Lisp expressions. For example, there was a spelling list of edit commands that was used to correct a mistyped editor command. When loading a file where the file name was not found, a spelling list of previously encountered file names would be used. -Another innovation introduced to BBN-LISP in 1970 was the History package. The idea was rather than simply performing the operations requested by the user, call functions, edit expressions, perform break commands, etc., and discarding that information, to have an agent that would record what the user entered so that the user could examine the history, and replay portions of it, possibly with substitutions. (The history feature of the UNIX C-shell introduced in the late 70’s was patterned after the Interlisp history package.) The history also contained any messages displayed to the user during the execution of the corresponding event, e.g., any DWIM corrections, or messages about global variables being reset or functions being redefined, etc. As with DWIM, the History package grew out of the desire to offload manual tasks to the computer. +Another innovation introduced to BBN-LISP in 1970 was the [History package](/history/glossary/#history-package). The idea was rather than simply performing the operations requested by the user, call functions, edit expressions, perform break commands, etc., and discarding that information, to have an agent that would record what the user entered so that the user could examine the history, and replay portions of it, possibly with substitutions. (The history feature of the UNIX C-shell introduced in the late 70’s was patterned after the Interlisp history package.) The history also contained any messages displayed to the user during the execution of the corresponding event, e.g., any DWIM corrections, or messages about global variables being reset or functions being redefined, etc. As with DWIM, the History package grew out of the desire to offload manual tasks to the computer. -Perhaps the most important piece of information stored in each history event was the information required to UNDO that operation. This was especially valuable in the context of editing. UNDO is functionality that every user now expects in an editor, but it was first introduced in BBN-LISP in 1970. The UNDO functionality provided in BBN-LISP still surpasses that available in today’s editors in that the user could UNDO operations out of order. For example, after performing a series of four or five editing operations, the user could realize that the information deleted in the first operation is needed, and would be able to UNDO just that operation by explicitly referring to that operation using the history package, without affecting the intervening operations. +Perhaps the most important piece of information stored in each history event was the information required to [UNDO](/history/glossary/#undo) that operation. This was especially valuable in the context of editing. UNDO is functionality that every user now expects in an editor, but it was first introduced in BBN-LISP in 1970. The UNDO functionality provided in BBN-LISP still surpasses that available in today’s editors in that the user could UNDO operations out of order. For example, after performing a series of four or five editing operations, the user could realize that the information deleted in the first operation is needed, and would be able to UNDO just that operation by explicitly referring to that operation using the history package, without affecting the intervening operations. In addition to being able to UNDO edit operations, the user could also UNDO operations that were typed in at the top level or in a Break. This was most frequently used to undo assignments. It could also be used to undo an entire edit session, rather than undoing one command at a time, sort of a revert operation for S-expressions. The user could also arrange to have functions that they defined to be undoable by storing information on the history list. +The history list stored each event’s input, value, side effects, messages, and errors, discarding the oldest events as new ones arrived. UNDO could itself be undone; the related commands REDO and USE re-ran recorded events. The July 1971 BBN-LISP TENEX Reference Manual documents UNDO. + +- Warren Teitelman, [“Automated programmering: the programmer’s assistant”](/history/bibliography/qwkix8dw/) (1972) +- [BBN-LISP, TENEX Reference Manual](/history/bibliography/jcvvquvd/) (July 1971) +- Warren Teitelman, [“History of Interlisp”](/history/bibliography/dvgrz62h/) (2008) + ### 1971 The **File Package** was added in 1971. This was essentially a “make” for Lisp. The user could specify the set of functions, global variables, property lists, etc., to be contained in a specified file, and then “make” that file. When the file was loaded in a subsequent session, this information would be recorded and available. Whenever a component known to be in a specified file was modified, the system would know that the corresponding file needed to be rewritten. A cleanup function was provided that would write out all files that contained components that had been changed. The user would be informed about any items created or modified during the course of their session that did not appear in any of the user’s files, and therefore might be lost if the user abandoned their session without saving them somewhere. The only thing missing from the File Package that would be provided in UNIX Make was the notion of dependencies. @@ -196,7 +204,7 @@ The ADVISE/advice idea and names carried through to the Aspect/J system, and on **MEDLEY** Medley provides a rich software development environment, including a debugger, a list structure editor, a file package, a compiler, text-editing facilities, and other useful tools. With any interactive computer language, the user interacts with the system through an "executive," which interprets and executes commands. Medley includes three such executives: Common Lisp, Xerox Common Lisp, and Interlisp. Medley is a programming system, containing not only a programming language but also many predefined programs and specialized programming tools. -Medley's interactive window-based *debugger* automatically appears when an error occurs. You can enter the debugger through a program execution error, a user-entered keyboard interrupt, or a programmer-specified break. When execution is halted for one of these reasons, the user can reset the system and unwind the stack, or enter the debugger. The break window is an executive window; you can perform any activity here that you can in other executive windows, including looking at the program's current state, changing data structures, evaluating expressions changing a function, and calling the editor. These break facilities, familiar to Interlisp users, are now in the common Lisp executive as well. +Medley's interactive window-based *debugger* automatically appears when an error occurs. You can enter the debugger through a program execution error, a user-entered keyboard interrupt, or a programmer-specified break. When execution is halted for one of these reasons, the user can reset the system and unwind the stack, or enter the debugger. The break window is an executive window; you can perform any activity here that you can in other executive windows, including looking at the program's current state, changing data structures, evaluating expressions changing a function, and calling the editor. These break facilities, familiar to Interlisp users, are now in the Common Lisp executive as well. In Medley, TRACE is implemented as a special case of BREAK, and UNBREAK restores functions modified by BREAK, TRACE, or BREAKIN ([Medley Language Reference](/history/bibliography/zq6d9yhu/)). The *programmer's assistant*. This tracks the user's actions during a session, allowing them to be replayed, undone, or altered. The most common interaction with the programmer's assistant occurs at the top level read-evaluate-print loop or in a break, where the user types in expressions for evaluation and sees the value printed out.