DOCSLIB.ORG

Pushdown Automata

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Pushdown Automata Pushdown Automata Machines for Context-Free Languages Wednesday, November 11, 2009 Reading: Sipser 2.2; Kozen 23 CS235 Languages and Automata Department of Computer Science Wellesley College Goals • Complete the analogy: regular expression : finite automaton :: context-free grammar : ??? ??? = pushdown automaton • Study/design some nondeterministic pushdown automata (NPDAs). • Discuss the relationship between CFGs and NPDAs. • Discuss nondeterministic vs. deterministic PDAs. Pushdown Automata 27-2 1 Finite Automata Review A finite automaton accepts/rejects input tape strings that can be viewed as a t 1 t2 t3 t4 t5 t6 … read-onlyyp tape of sy mbols read by a tape head that can move only left to left-to-right, Finite-State right, as controlled by a finite-state read-only Control controller. Comes in many flavors (Stoughton): FA = transitions between states are relations involving arbitrary strings. EFA = transitions are relations involving strings of length 1. NFA = transitions are relations involving strings of length 1. DFA = transitions are functions involving strings of length 1. Other authors define such machines in slightly different ways, sometimes with different names. Pushdown Automata 27-3 Pushdown Automata input tape t1 t2 t3 t4 t t6 … A pushdown automaton is a finite 5 automaton + a stack of symbols that left-to-right, can be pushed/popped on each Finite-State read-only transition. The finite-state Control controller can read only the top push/pop, symbol of the stack, which can can only read top affect the transition. sn top S Comes in many flavors (Sipser/Kozen): n-1 … Nondeterministic Pushdown Automata (Sipser’s PDA, Kozen’s NPDA) = Stoug hton’ s EFA + read top of stack and s2 push/pop stack symbols on each transition. s1 bottom Deterministic Pushdown Automata (DPDA) = Stoughton’s DFA + stack operations + end-of-input symbol . Definitions differ slightly from author to author. Pushdown Automata 27-4 2 An NPDA for On1n Example Execution State Input Stack A A 000111 % B 000111 $ %, % → $ read no input and push B 00111 0$ bottom-of-stack marker $ B 0111 00$ B 0, % → 0 read 0 from input and push 0 onto stack B 111 000$ %, % → % transition to 1-reading state C 111 000$ without reading input C 11 00$ C 1, 0 → % read 1 from input C 1 0$ and pop 0 from stack C % $ %, $ → % read no input and pop $ from stack D % % (Note: not necessary to D pop $ since stack needn’t Each row of table is a be empty at end) machine configuration. * Note: Where we use %, % → $, Transitions go from one Sipser uses , → $. configuration to another. Pushdown Automata 27-5 Formally Defining NPDAs Definitions differ among authors. This one is similar to Sipser’s: A Nondeterministic Pushdown Automaton (NPDA)* in a sextuple: (1) A set of states Q (2) An input alphabet (not containing the empty string symbol %) (3) A stack alphabet (4) A start state s Q (5) A set of final states F Q (6) A transition relation T (Q x ( U %) x ( U %)) x (Q x ( U %)) This is similar to Stoughton’s EFA except: • The input alphabet is explicit (rather than implicitly being Sym) •The stack alphabet is new • The transition relation allows pushing/popping a stack symbol (Stoughton’s transition relation T (Q x ( U %) x Q). ) * Sipser calls it a Pushdown Automaton (PDA) Pushdown Automata 27-6 3 Defining Acceptance for NPDAs A configuration is a triple in Q x *x*. Let p,q in Q; t in ( U %); x, y in *; k,k’ in ( U %); and G in *. We define the step relation, , on configurations: (p, ty, kG) (q, y, k’G) iff ( (p, t, k), (q, k’) ) T A NPDA accepts a string x iff (s, x, %) * (p, %, G) (for some stack G; it needn’t be empty) where s is the start state and p the final states F. Example for 0n1n NPDA (A, 000111, %) (B, 000111, $) (B, 00111, 0$) (B, 0111, 00$) (B, 111, 000$) (C, 111, 000$) (C, 11, 00$) (C, 1, 0$) (C, %, $) (D, %, %) Pushdown Automata 27-7 An NPDA for {Om1n | m > n} How do we complete the following NPDA to do the right thing? (Hint: stack needn’t be empty in accepting state.) State Input Stack A A 000011 % %, % → $ B 000011 $ B 00011 0$ B 0, % → 0 B 0011 00$ B 011 000$ %, % → % B 11 0000$ C 1, 0 → % C 11 0000$ C 1 000$ C % 00$ Pushdown Automata 27-8 4 An NPDA for {w | w {0,1}* and #0s = #1s} Create an NPDA for this language. State Input Stack 11000110 % Pushdown Automata 27-9 An NPDA for {0i1j2k | i = j or i = k} Create an NPDA for this language (use nondeterminism!) State Input Stack 0011122 % Pushdown Automata 27-10 5 An NPDA for {wwR | w {0,1}*} Create an NPDA for this language (use nondeterminism!) State Input Stack 100001 % Pushdown Automata 27-11 NPDAs are Equivalent to CFGs It can be shown that: (()1) A CFG can be converted to an NPDA. Context-Free I.e., every context-free language Languages (CFLs) (the language of some CFG) is the language accepted by some NPDA. CFGs NPDAs (2) An NPDA can be converted to a CFG. Regular Languages I.e., the language accepted by an FAs NPDA is context-free. regular expressions EFAs NFAs For details, see Sipser 2.2 or Kozen 24-25. right-linear grammars DFAs Pushdown Automata 27-12 6 Deterministic PDAs (DPDAs) Like an NPDA except: • Have a special symbol ( ) for the end of input. • Transition relation must be a function (no choices/guessing!) Effectively a DPDA = DFA + stack operations, except that some transitions might not read any input (and instead perform stack operations). For details, see Kozen Supplementary Lecture F. Pushdown Automata 27-13 Where do DPDAs Fit In? The language of a DPDA is a Context-Free Languages (CFLs) Deterministic Context-Free Language (DCFL). CFGs NPDAs DCFLs are a proper subset of CFLs. Deterministic Context-Free Languages (DCFLs) I.e., there are CFLs that are DPDAs not DCFLS. E.g. {aibjck | i = j or i = k} Regular Languages R FAs {ww | w in {0, 1}*} regular EFAs I.e. DPDAs are strictly less expressions powerful than NPDAs. NFAs right-linear DFAs Unlike CFLs, DCFLs are closed under grammars complement. Pushdown Automata 27-14 7.
Load more

Recommended publications
  • More Concise Representation of Regular Languages by Automata and Regular Expressions
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector Information and Computation 208 (2010)385–394 Contents lists available at ScienceDirect Information and Computation journal homepage: www.elsevier.com/locate/ic More concise representation of regular languages by automata ୋ and regular expressions Viliam Geffert a, Carlo Mereghetti b,∗, Beatrice Palano b a Department of Computer Science, P. J. Šafárik University, Jesenná 5, 04154 Košice, Slovakia b Dipartimento di Scienze dell’Informazione, Università degli Studi di Milano, via Comelico 39, 20135 Milano, Italy ARTICLE INFO ABSTRACT Article history: We consider two formalisms for representing regular languages: constant height pushdown Received 12 February 2009 automata and straight line programs for regular expressions. We constructively prove that Revised 27 July 2009 their sizes are polynomially related. Comparing them with the sizes of finite state automata Available online 18 January 2010 and regular expressions, we obtain optimal exponential and double exponential gaps, i.e., a more concise representation of regular languages. Keywords: © 2010 Elsevier Inc. All rights reserved. Pushdown automata Regular expressions Straight line programs Descriptional complexity 1. Introduction Several systems for representing regular languages have been presented and studied in the literature. For instance, for the original model of finite state automaton [11], a lot of modifications have been introduced: nondeterminism [11], alternation [4], probabilistic evolution [10], two-way input head motion [12], etc. Other important formalisms for defining regular languages are, e.g., regular grammars [7] and regular expressions [8]. All these models have been proved to share the same expressive power by exhibiting simulation results.
    [Show full text]
  • 15-122: Principles of Imperative Computation, Fall 2014 Lab 11: Strings in C
    15-122: Principles of Imperative Computation, Fall 2014 Lab 11: Strings in C Tom Cortina(tcortina@cs) and Rob Simmons(rjsimmon@cs) Monday, November 10, 2014 For this lab, you will show your TA your answers once you complete your activities. Autolab is not used for this lab. SETUP: Make a directory lab11 in your private 15122 directory and copy the required lab files to your lab11 directory: cd private/15122 mkdir lab11 cp /afs/andrew.cmu.edu/usr9/tcortina/public/15122-f14/*.c lab11 1 Storing and using strings using C Load the file lab11ex1.c into a text editor. Read through the file and write down what you think the output will be before you run the program. (The ASCII value of 'a' is 97.) Then compile and run the program. Be sure to use all of the required flags for the C compiler. Answer the following questions on paper: Exercise 1. When word is initially printed out character by character, why does only one character get printed? Exercise 2. Change the program so word[3] = 'd'. Recompile and rerun. Explain the change in the output. Run valgrind on your program. How do the messages from valgrind correspond to the change we made? Exercise 3. Change word[3] back. Uncomment the code that treats the four character array word as a 32-bit integer. Compile and run again. Based on the answer, how are bytes of an integer stored on the computer where you are running your code? 2 Arrays of strings Load the file lab11ex2.c into a text editor.
    [Show full text]
  • Unibasic 9.3 Reference Guide
    Unibasic - Dynamic Concepts Wiki 6/19/17, 1244 PM Unibasic From Dynamic Concepts Wiki Contents 1 UniBasic 2 About this Guide 2.1 Conventions 3 Installation & Configuration 3.1 Configuring Unix for UniBasic 3.1.1 Number of Processes 3.1.2 Number of Open Files 3.1.3 Number of Open i-nodes 3.1.4 Number of Locks 3.1.5 Message Queues 3.2 Unix Accounting & Protection System 3.3 Creating a Unix Account for UniBasic 3.4 UniBasic Security & Licensing 3.4.1 Software Licensing 3.4.2 Hardware Licensing 3.5 Loading the Installation File 3.5.1 Loading the UniBasic Installation File 3.5.2 Loading the UniBasic Development File 3.6 ubinstall - Installing UniBasic Packages 3.6.1 Errors During Installation 3.7 Configuring a UniBasic Environment 3.7.1 Directories and Paths 3.7.2 Filenames and Pathnames 3.7.3 Organizing Logical Units and Packnames 3.7.4 Environment Variables 3.7.5 Setting up .profile for Multiple Users 3.8 Command Line Interpreter 3.9 Launching UniBasic From Unix 3.10 Terminating a UniBasic Process 3.11 Licensing a New Installation 3.12 Changing the SSN Activation Key 3.13 Launching UniBasic Ports at Startup 3.14 Configuring Printer Drivers 3.15 Configuring Serial Printers 3.16 Configuring Terminal Drivers 3.17 Creating a Customized Installation Media 4 Introduction To UniBasic 4.1 Data 4.1.1 Numeric Data 4.1.1.1 Numeric Precision 4.1.1.2 Special Notes on %3 and %6 Numerics https://engineering.dynamic.com/mediawiki/index.php?title=Unibasic&printable=yes Page 1 of 397 Unibasic - Dynamic Concepts Wiki 6/19/17, 1244 PM 4.1.1.3 Integers Stored in Floating-Point
    [Show full text]
  • Iterated Stack Automata and Complexity Classes
    INFORMATION AND COMPUTATION 95, 2 1-75 ( t 99 1) Iterated Stack Automata and Complexity Classes JOOST ENCELFRIET Department of Computer Science, Leiden University. P.O. Box 9.512, 2300 RA Leiden, The Netherlands An iterated pushdown is a pushdown of pushdowns of . of pushdowns. An iterated exponential function is 2 to the 2 to the to the 2 to some polynomial. The main result presented here is that the nondeterministic 2-way and multi-head iterated pushdown automata characterize the deterministic iterated exponential time complexity classes. This is proved by investigating both nondeterministic and alternating auxiliary iterated pushdown automata, for which similar characteriza- tion results are given. In particular it is shown that alternation corresponds to one more iteration of pushdowns. These results are applied to the l-way iterated pushdown automata: (1) they form a proper hierarchy with respect to the number of iterations, and (2) their emptiness problem is complete in deterministic iterated exponential time. Similar results are given for iterated stack (checking stack, non- erasing stack, nested stack, checking stack-pushdown) automata. ? 1991 Academic Press. Inc INTRODUCTION It is well known that several types of 2-way and multi-head pushdown automata and stack automata have the same power as certain time or space bounded Turing machines; see, e.g., Chapter 14 of (Hopcroft and Ullman, 1979), or Sections 13 and 20.2 of (Wagner and Wechsung, 1986). For the deterministic and nondeterministic case such characterizations were given by Fischer (1969) for checking stack automata, by Hopcroft and Ullman (1967b) for nonerasing stack automata, by Cook (1971) for auxiliary pushdown and 2-way stack automata, by Ibarra (1971) for auxiliary (nonerasing and erasing) stack automata, by Beeri (1975) for 2-way and auxiliary nested stack automata, and by van Leeuwen (1976) for auxiliary checking stack-pushdown automata.
    [Show full text]
  • IBM Education Assistance for Z/OS V2R1
    IBM Education Assistance for z/OS V2R1 Item: ASCII Unicode Option Element/Component: UNIX Shells and Utilities (S&U) Material is current as of June 2013 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option Agenda ■ Trademarks ■ Presentation Objectives ■ Overview ■ Usage & Invocation ■ Migration & Coexistence Considerations ■ Presentation Summary ■ Appendix Page 2 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Version Trademarks ■ See url http://www.ibm.com/legal/copytrade.shtml for a list of trademarks. Page 3 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Presentation Objectives ■ Introduce the features and benefits of the new z/OS UNIX Shells and Utilities (S&U) support for working with ASCII/Unicode files. Page 4 of 19 © 2013 IBM Corporation Filename: zOS V2R1 USS S&U ASCII Unicode Option IBM Presentation Template Full Version Overview ■ Problem Statement –As a z/OS UNIX Shells & Utilities user, I want the ability to control the text conversion of input files used by the S&U commands. –As a z/OS UNIX Shells & Utilities user, I want the ability to run tagged shell scripts (tcsh scripts and SBCS sh scripts) under different SBCS locales. ■ Solution –Add –W filecodeset=codeset,pgmcodeset=codeset option on several S&U commands to enable text conversion – consistent with support added to vi and ex in V1R13. –Add –B option on several S&U commands to disable automatic text conversion – consistent with other commands that already have this override support. –Add new _TEXT_CONV environment variable to enable or disable text conversion.
    [Show full text]
  • Bidirectional Programming Languages
    University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations Winter 2009 Bidirectional Programming Languages John Nathan Foster University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/edissertations Part of the Databases and Information Systems Commons, and the Programming Languages and Compilers Commons Recommended Citation Foster, John Nathan, "Bidirectional Programming Languages" (2009). Publicly Accessible Penn Dissertations. 56. https://repository.upenn.edu/edissertations/56 This paper is posted at ScholarlyCommons. https://repository.upenn.edu/edissertations/56 For more information, please contact [email protected]. Bidirectional Programming Languages Abstract The need to edit source data through a view arises in a host of applications across many different areas of computing. Unfortunately, few existing systems provide support for updatable views. In practice, when they are needed, updatable views are usually implemented using two separate programs: one that computes the view from the source and another that handles updates. This rudimentary design is tedious for programmers, difficult to reason about, and a nightmare to maintain. This dissertation presents bidirectional programming languages, which provide an elegant and effective mechanism for describing updatable views. Unlike programs written in an ordinary language, which only work in one direction, programs in a bidirectional language can be run both forwards and backwards: from left to right, they describe functions that map sources to views, and from right to left, they describe functions that map updated views back to updated sources. Besides eliminating redundancy, these languages can be designed to ensure correctness, guaranteeing by construction that the two functions work well together. Starting from the foundations, we define a general semantic space of well-behaved bidirectional transformations called lenses.
    [Show full text]
  • Reference Manual for the Icon Programming Language Version 5 (( Implementation for Limx)*
    Reference Manual for the Icon Programming Language Version 5 (( Implementation for liMX)* Can A. Contain. Ralph £ Grixwoltl, and Stephen B. Watnplcr "RSI-4a December 1981, Corrected July 1982 Department of Computer Science The University of Arizona Tucson, Arizona 85721 This work was supported by the National Science Foundation under Grant MCS79-03890. Copyright © 1981 by Ralph E. Griswold All rights reserved. No part of this work may be reproduced, transmitted, or stored in any form or by any means without the prior written consent of the copyright owner. CONTENTS Chapter i Introduction 1.1 Background I 1.2 Scope ol the Manual 2 1.3 An Overview of Icon 2 1.4 Syntax Notation 2 1.5 Organization ol the Manual 3 Chapter 2 Basic Concepts and Operations 2.1 Types 4 2.2 Expressions 4 2.2.1 Variables and Assignment 4 2.2.2 Keywords 5 2.2.3 Functions 5 2.2.4 Operators 6 2.3 Evaluation of Expressions 6 2.3.1 Results 6 2.3.2 Success and Failure 7 2.4 Basic Control Structures 7 2.5 Compound Expressions 9 2.6 Loop Control 9 2.7 Procedures 9 Chapter 3 Generators and Expression Evaluation 3.1 Generators 11 3.2 Goal-Directed Evaluation 12 }.?> Evaluation of Expres.sions 13 3.4 I he Extent ol Backtracking 14 3.5 I he Reversal ol Effects 14 Chapter 4 Numbers and Arithmetic Operations 4.1 Integers 15 4.1.1 literal Integers 15 4.1.2 Integer Arithmetic 15 4.1.3 Integer Comparison 16 4.2 Real Numbers 17 4.2.1 literal Real Numbers 17 4.2.2 Real Arithmetic 17 4.2.3 Comparison of Real Numbers IS 4.3 Mixed-Mode Arithmetic IX 4.4 Arithmetic Type Conversion 19
    [Show full text]
  • 2 Context-Free Grammars and Pushdown Automata
    2 Context-free Grammars and Pushdown Automata As we have seen in Exercise 15, regular languages are not even sufficient to cover well-balanced brackets. In order even to treat the problem of parsing a program we have to consider more powerful languages. Our aim in this section is to generalize the concept of a regular language to cover this example (and others like it), and to find ways of describing such languages. The analogue of a regular expression is a context-free grammar while finite state machines are generalized to pushdown automata. We establish the correspondence between the two and then finish by describing the kinds of languages that are not captured by these more general methods. 2.1 Context-free grammars The question of recognizing well-balanced brackets is the same as that of dealing with nesting to arbitrary depths, which certainly occurs in all programming languages. To cover these examples we introduce the following definition. Definition 11 A context-free grammar is given by the following: • an alphabet Σ of terminal symbols, also called the object alphabet; • an alphabet N of non-terminal symbols, the elements of which are also referred to as auxiliary characters, placeholders or, in some books, variables, where N \ Σ = ;;7 • a special non-terminal symbol S 2 N called the start symbol; • a finite set of production rules, that is strings of the form R ! Γ where R 2 N is a non- terminal symbol and Γ 2 (Σ [ N)∗ is an arbitrary string of terminal and non-terminal symbols, which can be read as `R can be replaced by Γ'.8 You will meet grammars in more detail in the other part of the course, when examining parsers.
    [Show full text]
  • Software II: Principles of Programming Languages
    Software II: Principles of Programming Languages Lecture 6 – Data Types Some Basic Definitions • A data type defines a collection of data objects and a set of predefined operations on those objects • A descriptor is the collection of the attributes of a variable • An object represents an instance of a user- defined (abstract data) type • One design issue for all data types: What operations are defined and how are they specified? Primitive Data Types • Almost all programming languages provide a set of primitive data types • Primitive data types: Those not defined in terms of other data types • Some primitive data types are merely reflections of the hardware • Others require only a little non-hardware support for their implementation The Integer Data Type • Almost always an exact reflection of the hardware so the mapping is trivial • There may be as many as eight different integer types in a language • Java’s signed integer sizes: byte , short , int , long The Floating Point Data Type • Model real numbers, but only as approximations • Languages for scientific use support at least two floating-point types (e.g., float and double ; sometimes more • Usually exactly like the hardware, but not always • IEEE Floating-Point Standard 754 Complex Data Type • Some languages support a complex type, e.g., C99, Fortran, and Python • Each value consists of two floats, the real part and the imaginary part • Literal form real component – (in Fortran: (7, 3) imaginary – (in Python): (7 + 3j) component The Decimal Data Type • For business applications (money)
    [Show full text]
  • Pushdown Automata
    Pushdown Automata Announcements ● Problem Set 5 due this Friday at 12:50PM. ● Late day extension: Using a 72-hour late day now extends the due date to 12:50PM on Tuesday, February 19th. The Weak Pumping Lemma ● The Weak Pumping Lemma for Regular Languages states that For any regular language L, There exists a positive natural number n such that For any w ∈ L with |w| ≥ n, There exists strings x, y, z such that For any natural number i, w = xyz, w can be broken into three pieces, y ≠ ε where the middle piece isn't empty, where the middle piece can be xyiz ∈ L replicated zero or more times. Counting Symbols ● Consider the alphabet Σ = { 0, 1 } and the language L = { w ∈ Σ* | w contains an equal number of 0s and 1s. } ● For example: ● 01 ∈ L ● 110010 ∈ L ● 11011 ∉ L ● Question: Is L a regular language? The Weak Pumping Lemma L = { w ∈ {0, 1}*| w contains an equal number of 0s and 1s. } 1 0 0 1 An Incorrect Proof Theorem: L is regular. Proof: We show that L satisfies the condition of the pumping lemma. Let n = 2 and consider any string w ∈ L such that |w| ≥ 2. Then we can write w = xyz such that x = z = ε and y = w, so y ≠ ε. Then for any natural number i, xyiz = wi, which has the same number of 0s and 1s. Since L passes the conditions of the weak pumping lemma, L is regular. ■ The Weak Pumping Lemma ● The Weak Pumping Lemma for Regular Languages states that ThisThis sayssays nothingnothing aboutabout For any regular language L, languageslanguages thatthat aren'taren't regular!regular! There exists a positive natural number n such that For any w ∈ L with |w| ≥ n, There exists strings x, y, z such that For any natural number i, w = xyz, w can be broken into three pieces, y ≠ ε where the middle piece isn't empty, where the middle piece can be xyiz ∈ L replicated zero or more times.
    [Show full text]
  • Input Finite State Control Accept Or Reject Stack
    Pushdown Automata CS351 Just as a DFA was equivalent to a regular expression, we have a similar analogy for the context-free grammar. A pushdown automata (PDA) is equivalent in power to context- free grammars. We can give either a context-free grammar generating a context-free language, or we can give a pushdown automaton. Certain languages are more easily described in forms of one or the other. A pushdown automata is quite similar to a nondeterministic finite automata, but we add the extra component of a stack. The stack is of infinite size, and this is what will allow us to recognize some of the non-regular languages. We can visualize the pushdown automata as the following schematic: Finite input Accept or reject State Control Stack The finite state control reads inputs, one symbol at a time. The pushdown automata makes transitions to new states based on the input symbol, current state, and the top of the stack. In the process we may manipulate the stack. Ultimately, the control accepts or rejects the input. In one transition the PDA may do the following: 1. Consume the input symbol. If ε is the input symbol, then no input is consumed. 2. Go to a new state, which may be the same as the previous state. 3. Replace the symbol at the top of the stack by any string. a. If this string is ε then this is a pop of the stack b. The string might be the same as the current stack top (does nothing) c. Replace with a new string (pop and push) d.
    [Show full text]
  • Standard TECO (Text Editor and Corrector)
    Standard TECO TextEditor and Corrector for the VAX, PDP-11, PDP-10, and PDP-8 May 1990 This manual was updated for the online version only in May 1990. User’s Guide and Language Reference Manual TECO-32 Version 40 TECO-11 Version 40 TECO-10 Version 3 TECO-8 Version 7 This manual describes the TECO Text Editor and COrrector. It includes a description for the novice user and an in-depth discussion of all available commands for more advanced users. General permission to copy or modify, but not for profit, is hereby granted, provided that the copyright notice is included and reference made to the fact that reproduction privileges were granted by the TECO SIG. © Digital Equipment Corporation 1979, 1985, 1990 TECO SIG. All Rights Reserved. This document was prepared using DECdocument, Version 3.3-1b. Contents Preface ............................................................ xvii Introduction ........................................................ xix Preface to the May 1985 edition ...................................... xxiii Preface to the May 1990 edition ...................................... xxv 1 Basics of TECO 1.1 Using TECO ................................................ 1–1 1.2 Data Structure Fundamentals . ................................ 1–2 1.3 File Selection Commands ...................................... 1–3 1.3.1 Simplified File Selection .................................... 1–3 1.3.2 Input File Specification (ER command) . ....................... 1–4 1.3.3 Output File Specification (EW command) ...................... 1–4 1.3.4 Closing Files (EX command) ................................ 1–5 1.4 Input and Output Commands . ................................ 1–5 1.5 Pointer Positioning Commands . ................................ 1–5 1.6 Type-Out Commands . ........................................ 1–6 1.6.1 Immediate Inspection Commands [not in TECO-10] .............. 1–7 1.7 Text Modification Commands . ................................ 1–7 1.8 Search Commands .
    [Show full text]