the nuprl proof development system, version 5 reference ... · ematical knowledge as well as for...

The Nuprl Proof Development System, Version 5

Reference Manual and User’s Guide

Christoph Kreitz

Department of Computer Science, Cornell-UniversityIthaca, NY 14853-7501, U.S.A.

[email protected]

mailto:[email protected]?subject=Nuprl-Manual

Preface

This manual is a reference manual for version 5 of the Nuprl proof development system. Asthe Nuprl system is constantly under development, this manual will always be incomplete. Inparticular, it is missing information about recent advanced features of the system and about certainextensions of Nuprl’s type theory that are currently being added to the system. More recentinformation and the system itself can be found at the Nuprl web pages http://www.nuprl.org.

From its beginnings in the 1980s, the PRL project has been guided by Robert Constable. Overthe years, many researchers and students at Cornell have contributed to the theoretical foundations,the design, and the implementation of the Nuprl system.

The major developers of Nuprl 5 are Stuart Allen, Rich Eaton and Lori Lorigo. They haveprovided explanations for many of the new system features and added new ones that are helpfulfor novice users while this manual was written. Mark Bickford has used and tested the systemextensively and designed many extensions that are currently being added to the system.

Although the architecture of the Nuprl system has significantly changed in release 5, the basicstructure of the proof and term editors, of abstractions and display forms, of the metalanguageML, and of rules and tactics is largely compatible with previous releases. The Nuprl 4 manuals[Jac93a, Jac93b], written by Paul Jackson, served as a foundation for the corresponding chapters.

Ithaca, December 17, 2002

ii

http://www.nuprl.org

Contents

1 Introduction 11.1 The Nuprl 5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Tips for Beginning Nuprl 5 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Structure of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 A Quick Overview 72.1 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Running Nuprl 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Using the Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Creating Theorem Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Proving Theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Adding Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Printing Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Shutting Nuprl down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Running Nuprl 5 213.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Retrieving and Installing Nuprl 5 . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 User-specific Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Starting Nuprl 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.1 Starting the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Starting the Refiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Starting the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Exiting Nuprl 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Hints on Using the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 The Navigator and the Top Loops 314.1 The Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Library Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.2 The Library Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.3 User Interaction with the Library . . . . . . . . . . . . . . . . . . . . . . . . 34

iii

4.2 Nuprl Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.1 The Navigator Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 The ML Top Loop Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.3 The Process Top Loop Windows . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Library Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.1 Browsing the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.2 Operations on objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.3 Theory Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.4 Miscellaneous Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 The ML Top Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.1 Top loop command buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.2 The command line zone editor . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.3 Top Loop Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.5 Process Top Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.6 Recovering from Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Editing Terms 675.1 Uniform Term Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Structured Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2.1 Term Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2.2 Editor Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2.3 Term and Text Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3 Term Editor Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4 Entering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.1 Inserting Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4.2 Adding and Removing Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4.3 Inserting Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.4.4 Adding New Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.4.5 Exploded Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.5 Cursor and Window Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.5.1 Screen Oriented Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.5.2 Tree Oriented Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.5.3 Mouse Commmands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.5.4 Search for Subterms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.6 Cutting and Pasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.6.1 Basic Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.6.2 Cutting and Pasting Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.6.3 Mouse Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.7 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.8 Customizing the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Interactive Proof Development 856.1 Proof Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.1 Sequents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.1.2 Proof Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.1.3 Refinement Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 The Proof Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

iv

6.2.1 Proof Window Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.2.2 Proof Motion Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.3 Stating and Proving Theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.3.1 Editing The Main Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.3.2 Refining Proof Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.3 Generating Extract Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4 Advanced Editing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.4.1 Modifying existing refinements . . . . . . . . . . . . . . . . . . . . . . . . . . 936.4.2 Proof History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.3 Backup Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.4 Views of Proofs and Refinements . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.5 Miscellaneous Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.5 Customizing the Proof Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7 Definition and Presentation of Terms 997.1 Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.1.1 Bindings in Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.1.2 Parameters in Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.1.3 Attributed Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.1.4 Editor Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.2 Term Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.2.1 Editing Display Form Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.2.2 Right-hand-side Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.2.3 Format Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.2.4 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.2.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8 Rules and Tactics 1118.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8.1.1 Representation of Inference Rules . . . . . . . . . . . . . . . . . . . . . . . . . 1128.1.2 Rule Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128.1.3 Converting rules into tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8.2 Introduction to Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.2.1 Tactic Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178.2.2 Optional Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.2.3 Proof Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.2.4 Soft Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.2.5 Universal Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.3 Basic Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.3.1 Single-Step Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.3.2 Structural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.3.3 Decision procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.3.4 Autotactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.4 Forward and Backward Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.5 Case Splits and Induction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.6 Simple Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

v

8.6.1 Folding and Unfolding Abstractions . . . . . . . . . . . . . . . . . . . . . . . 1308.6.2 Evaluating Subexpressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.6.3 Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.6.4 Generic Rewrite Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8.7 Miscellaneous Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328.8 Tacticals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

8.8.1 Basic Tacticals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.8.2 Label Sensitive Tacticals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.8.3 Multiple Clause Tacticals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.9 The Rewrite Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358.9.1 Introduction to Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368.9.2 Atomic Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418.9.3 Composite Direct Computation Conversions . . . . . . . . . . . . . . . . . . . 1448.9.4 Conversionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448.9.5 Macro Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

A The Basic Nuprl Type Theory 147A.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

A.1.1 Operator Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147A.1.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149A.1.3 Binding Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149A.1.4 Injection of Variables and Numbers . . . . . . . . . . . . . . . . . . . . . . . . 149A.1.5 Term Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

A.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150A.2.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150A.2.2 Judgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

A.3 Inference rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153A.3.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154A.3.2 Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155A.3.3 Disjoint Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156A.3.4 Universes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157A.3.5 Equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158A.3.6 Void . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159A.3.7 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160A.3.8 Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161A.3.9 Less Than Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164A.3.10 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.3.11 Inductive Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166A.3.12 Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167A.3.13 Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168A.3.14 Quotient Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169A.3.15 Direct Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171A.3.16 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

vi

B Introduction to Nuprl ML 173B.1 The History of ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

B.1.1 Preface to ‘The ML Handbook’ . . . . . . . . . . . . . . . . . . . . . . . . . . 174B.1.2 Preface to ‘Edinburgh LCF’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

B.2 Introduction and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175B.2.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175B.2.2 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175B.2.3 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176B.2.4 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177B.2.5 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178B.2.6 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178B.2.7 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179B.2.8 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179B.2.9 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180B.2.10 Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180B.2.11 Lambda-expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181B.2.12 Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181B.2.13 Type abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183B.2.14 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183B.2.15 Type constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

B.3 Syntax of ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185B.3.1 Syntax equations for ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186B.3.2 Identifiers and other lexical matters . . . . . . . . . . . . . . . . . . . . . . . 188

B.4 Semantics of ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189B.4.1 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190B.4.2 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

B.5 ML Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194B.5.1 Types and objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194B.5.2 Typing of ML phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196B.5.3 Discussion of type constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 198B.5.4 Type abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200B.5.5 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

B.6 Primitive ML Identifier Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201B.6.1 Predeclared ordinary identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 202B.6.2 Predeclared dollared identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 203

B.7 General Purpose and List Processing Functions . . . . . . . . . . . . . . . . . . . . . 204B.7.1 General purpose functions and combinators . . . . . . . . . . . . . . . . . . . 204B.7.2 Miscellaneous list processing functions . . . . . . . . . . . . . . . . . . . . . . 206B.7.3 List mapping and iterating functions . . . . . . . . . . . . . . . . . . . . . . . 207B.7.4 List searching functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208B.7.5 List transforming functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209B.7.6 Functions for lists representing sets . . . . . . . . . . . . . . . . . . . . . . . . 210B.7.7 Miscellaneous string processing functions . . . . . . . . . . . . . . . . . . . . 211B.7.8 Failure handling functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

vii

List of Figures

1.1 Nuprl 5 distributed open architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Initial Nuprl 5 screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Nuprl 5 Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Initial Nuprl 5 screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Pattern-based name search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Path stack command zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4 Creating Objects: Initial template and resulting update to the library . . . . . . . . 414.5 Creating Definitions: Initial template and resulting update to the library . . . . . . 424.6 Creating Recursive Definitions: code object and created definition objects . . . . . . 434.7 Creating Recursive Modules: code object and created directory . . . . . . . . . . . . 454.8 Editing Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.9 Commenting an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.10 Creating Theories: initial template and generated static reference environment . . . 514.11 Checking a theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.12 Creating Object Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.13 Standard Milling Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.14 The ML Top Loop and the Evaluator History Window . . . . . . . . . . . . . . . . . 61

6.1 Proof window on refined and unrefined proof node . . . . . . . . . . . . . . . . . . . 89

7.1 Display Object Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

ix

List of Tables

4.1 Navigator Motion Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2 Navigator command buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3 Command line zone editor commands and bindings . . . . . . . . . . . . . . . . . . . 61

5.1 Nuprl special character codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2 All key and mouse commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Term-editor fragment of the standard mykeys.macro file . . . . . . . . . . . . . . . . 83

6.1 Proof Editor Keyboard Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.1 Soft abstractions in Nuprl’s basic libraries . . . . . . . . . . . . . . . . . . . . . . . 1218.2 Iterated decomposition tactics and the connectives they decompose . . . . . . . . . . 1238.3 Format of Tokens in Rewrite Control Strings . . . . . . . . . . . . . . . . . . . . . . 132

A.1 Basic operators of Nuprl’s Type Theory . . . . . . . . . . . . . . . . . . . . . . . . . 148A.2 Redex–Contracta Table for Nuprl’s Type Theory . . . . . . . . . . . . . . . . . . . . 150A.3 Type semantics table for Nuprl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.4 Member semantics table for Nuprl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

B.1 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186B.2 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186B.3 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186B.4 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187B.5 ML Type Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

xi

Chapter 1

Introduction

The Nuprl proof development system is a framework for the development of formalized math-ematical knowledge as well as for the synthesis, verification, and optimization of software. It isbased on a significant extension of Martin-Lof’s intuitionistic Type Theory [ML84], which includesformalizations of the fundamental concepts of mathematics, data types, and programming. Thesystem itself supports interactive and tactic-based reasoning, decision procedures, evaluation ofprograms, language extensions through user-defined concepts, and an extendable library of verifiedknowledge from various domains.

Since its first release in 1984 [CAB+86], the system has been undergone several significantmodifications to meet the growing demands for formal knowledge and tools in programming andmathematics, the most recent being a complete redesign of its architecture, discussed in [ACE+00].The Nuprl 5 system, which is documented in this manual, features an open, distributed architec-ture that integrates all its key subsystems as independent components and uses a flexible knowledgebase as its central component.

1.1 The Nuprl 5 Architecture

Figure 1.1 illustrates the architecture of Nuprl 5. The system is organized as a collection of com-municating processes that are centered around a common knowledge base, called the library . The

GUI

Evaluator

Translator

GUI GUI

Evaluator

Evaluator

Evaluator

Translator

InferenceEngine

InferenceEngine

InferenceEngine

InferenceEngine

InferenceEngine

Java OCaml

Maude

MetaPRL

SoS (Lisp)

Structure

Library Nuprl Refiner

MetaPRL

JProver

PVS

MinLog

WebEditor

Emacs Mode

PRL

(PVS)(HOL)

....

....

....THEORY

defs, thms, tacticsrules, structure, code

rules, structure, code

rules, structure, codedefs, thms, tactics defs, thms, tactics

rules, structure, code

rules, structure, codedefs, thms, tactics

rules, structure, codedefs, thms, tactics

defs, thms, tactics

THEORY

THEORY

THEORY THEORY

THEORY

Figure 1.1: Nuprl 5 distributed open architecture

1

library contains definitions, theorems, inference rules, meta-level code (e.g. tactics), and structureobjects that can be used to provide a modular structure for the library’s contents. Inference en-gines (refiners), user interfaces (editors), rewrite engines (evaluators), and translators are startedas independent processes that can connect to the library at any time.

The library can communicate with arbitrarily many other processes. This allows the user toconnect several refiners and evaluators simultaneously, e.g. the Nuprl and MetaPRL [Met] refin-ers, proof systems like HOL [GM93] or PVS [ORR+96], first-order provers like JProver [SLKN01],Otter [WWM+90], EQP [McC97], or Setheo [LSBB92], proof-based program generators like Min-Log [BBS+98], rewrite engines like Maude [CDE+99a], computer algebra systems like Mathemat-ica [Wol88] or Maple [Map], decision procedures [NO79, Sho84, SVC], and model checkers [McM93,Dil96, Hol97], and even to make them cooperate. It is also possible to run different refiners inparallel on the same proof goal or several instances of the same refiner on different proof goals.

Providing several editors enables several users to work in parallel on the same formal theorywhile using their favorite interface. At the same time external users can access the system throughthe Web without having to start the whole system themselves.

Translators between the formal knowledge stored in the library and, for instance, programminglanguages like Java or Ocaml [Kre97, KHH98, Kre03] allow the formal reasoning tools to supplementreal-world software from various domains.

Nuprl 5 is highly configurable. In its current standard configuration, which is described in thismanual, the system essentially provides an extended functionality of the Nuprl 4 system [Jac94].It consists of the library, the Nuprl 5 editor, and the Nuprl 5 refiner.

The Knowledge Base

The knowledge base is based on a transaction model for entering and modifying objects. All changesto objects, e.g. the effects of editor commands or inference steps, are immediately committed to thepersistent library. The knowledge base also provides the option to undo changes, redo transactions,or to have several processes view or work on the same object – essentially following the sameprotocols as databases. However, changes do not overwrite an object but instead create a newversion. The previous version is preserved until it is explicitly destroyed in a garbage collectionprocess. A version control mechanism allows the user to recover previous versions of an object.

To account for the validity of library objects, the knowledge base supports dependency tracking ,which will enable a user to check if theorems are valid wrt. a specific set of rules, axioms, andproof procedures.

In principle, the library does not impose any predefined structure. All visible structure, e.g. thedirectory structure as observed by the Nuprl 5 navigator (See Chapter 4), is generated by structureobjects that are explicitly present in the library and can be customized by the user.

To prevent name clashes, the library distinguishes between objects and the names that userschoose to denote them. The latter are just display versions of internal names. The can be changedwithout affecting the object itself.

User Interfaces

The main user interface of Nuprl 5 is the navigator . It communicates with the knowledge base bysending and receiving abstract terms. While displaying and editing these terms it presents themas directories, theorems, definitions, proofs, or mathematical expressions – depending on structuralinformation found in the library. For the user, it provides the functionality of a structure editor :the user can mark subterms and edit slots in the displayed term and then cause the navigator to

2

send the result back to the library, which processes the result while the user may continue to workwith the editor. Again, structural information in the library determines whether the abstract termsreceived by the knowledge base are interpreted as a commands to store or retrieve data, as tacticscalling a refiner, or as utility functions.

In addition to the navigator, Nuprl 5 provides emulations of the editors used in the Nuprl 4system, as well as valuable extensions for facilitating proof browsing, merging, replaying and ac-counting. There is also a web front end [Nau98] that allows external users to browse the Nuprllibrary remotely.

Inference Engines

The Nuprl 5 inference engine refines proof goals by executing ML code that may include referencesto library objects, particularly to the inference rules and tactics stored in the knowledge base. Itapplies the code to a given proof goal that it receives as an abstract term and returns the resultinglist of subgoals back to the library. Based on the validations given in the rule objects it can alsoextract programs from proofs and evaluate them. The inference mechanism is fairly straightforwardand compatible with the one in Nuprl 4.

As an alternative one may invoke the MetaPRL refiner [Met], a modularized version of Nuprl’sinference engine implemented in OCaml, which is significantly faster due to improvements in rewrit-ing and evaluation. The communication between Nuprl 5 and MetaPRL utilizes the MathBusdesign [Mat].

We are in the process of connecting a variety of external refiners such as a constructive first-order theorem prover [KOSP00], the HOL system (via Maude [CDE+99b]), Mathematica, and Isabelle[Nau99]. We will also emulate the refiner of Nuprl 3 in order to be able to restore older theoriesthat did not survive the transition from Nuprl 3 to Nuprl 4.

1.2 Purpose of this Manual

This manual is a reference manual for version 5 of the Nuprl system. It is aimed at beginningand intermediate users of the system. Nuprl 5 is written mostly in Common Lisp, but uses someextensions that require Lucid or Allegro Lisp. It runs on Unix-based workstations that use the Xwindow system.

Note, that this manual is still under development and incomplete. Additional online docu-mentation can be found on the Web at the URL http://www.nuprl.org/html/nuprldocs.html,in the directory /home/nuprl/nuprl5/doc/ of the installed system, and in objects such asdoc: ref editor and doc: navigator use, while the system is running.

The original Nuprl book Implementing Mathematics with the Nuprl Proof Development Sys-tem [CAB+86], also available on the Web at the URL http://www.nuprl.org/book/doc.htmlis still a good background reference. However, one has to keep in mind that the system itself hasbeen changed and extended substantially since the book was published. None of the tutorials givenin the book will work in Nuprl 5. The “reference” portion of the book is superseded by thisreference manual, but contains some useful examples and discussions of tactic writing that are notreproduced here. The “advanced” portion of the book deals with application methodology, givessome extended examples of mathematics formalized in Nuprl, and also describes some extensionsto the type theory which have not been implemented.

3

http://www.nuprl.org/html/nuprldocs.html

http://www.nuprl.org/book/doc.html

1.3 Tips for Beginning Nuprl 5 Users

We recommend that you run through the brief tutorial in chapter 2 before trying to do anythingelse with the system.

In learning to use the navigator as well as the proof and term editors, check out all the mousecommands and the buttons that are provided. Many editing operations can be done most easilywith the mouse and the buttons. Familiarize yourself with the standard Nuprl theories that arealready present in the library. Existing theories are an excellent resource for learning about howto structure theories and how to write proofs.

The Nuprl ML manual in Appendix B contains a tutorial in the use of ML (Appendix B.2).Use this as an introduction to ML. Daring users may also take a look at the .ml-files in the directory/home/nuprl/nuprl5/lib/ml/standard, which contain the implementation of the existing tacticscollection and can be used as examples for writing tactics.

We recommend that fairly early on, you at least browse through this manual, familiarizingyourself with the general contents of each chapter. This will help you know where to look if youhave questions.

1.4 Conventions

We give the conventions we use in this manual for presenting user input and Nuprl output. Inputwhich you should type is presented typewriter font. For example this is in typewriter font.The following symbols are also used:

• spc for the space-bar.

• | for the Return key (sometimes marked as Enter).

• lfd for the linefeed key.

• | !| for the Tab key.

• del for the delete key (sometimes marked as Rubout). On some keyboards the backspacehas the same effect.

• left , middle , and right for the left, middle, and right mouse button.

Modified keys are presented as follows:

• 〈C-x〉 read as “control x”. Hold down a control key and simultaneously press key x.

• 〈M-x〉 read as “meta x”. Hold down a meta key and simultaneously press key x.

• 〈C-M-x〉 read as “control meta x”. Hold down both a control key and a meta key, andsimultaneously press key x.

• 〈S-x〉 read as “shift x”. Hold down a shift key and simultaneously press key x.

Note that x can be either a keyboard key or a mouse button; for example both 〈C-a〉 and〈M- right 〉 are valid modified keys. On some keyboard’s (for example, those of Sparc-stations)the usual meta keys are the keys marked 3 either side of the space-bar, while on PC keyboardsthis key is often marked as Alt. The 〈S-x〉 modifier is only used with non-printing characters (forexample, | ).

When we say “click left ” on some part of a window, we mean that the mouse cursor shouldbe pointed at that part, and then the left button should be pressed.

4

Be aware that occasionally Nuprl can be quite slow to respond to keystrokes, sometimes takingseveral seconds. Don’t hold keys down till you get a response. You might easily make the keysautorepeat, which could be rather annoying.

For clarity when presenting input which a user might type, or output which Nuprl generates,we sometimes enclose the text in special xy quotes. For example xthis is example outputy.

1.5 Structure of this Manual

Chapter 2 gives a tutorial-like overview of the essential features of the Nuprl 5 system. Noviceusers should run through this tutorial before trying to do anything else.

Chapter 3 describes how to install, start, and exit the system. It also give a few hints oncustomization and basic troubleshooting.

Nuprl’s windows are at the “top-level” in the X environment and come with their own context-specific editors. The two main windows – the navigator and the ML top loop – are described inChapter 4 while Chapters 5 and 6 describe the editors for term and for proof windows.

The following chapters describe Nuprl’s support for the formalization of mathematical conceptsand proofs. In chapter 7 we explain how to extend the logical language of Nuprl by abstractdefinitions and how to modify the visual presentation of formal material through display forms.Chapter 8 describes the structure of basic inferences in Nuprl as well as the most important tacticsfor automated reasoning.

The appendices describe important background information such as the type theory of Nuprl(Appendix A) and Nuprl’s meta-language ML (Appendix B).

5

Chapter 2

A Quick Overview

The Nuprl 5 system is organized as a collection of communicating processes that are centeredaround a library , which contains definitions, theorems, inference rules, tactics, structure objects,comments, etc. Inference engines (refiners), user interfaces (editors), rewrite engines (evaluators),and translators are started as independent processes that can connect to the library at any time.

2.1 Preparation

We assume that the Nuprl 5 system has already been installed (see Section 3.2.1) and canbe found in the directory /home/nuprl/nuprl5. We also assume that the Nuprl 5 binariescan be found in /home/nuprl/bin/ and that the Nuprl fonts are installed in the directory/home/nuprl/fonts/bdf.

Make sure that your Unix path includes /home/nuprl/bin/ and that the X-server has Nuprl‘sfonts loaded. Create a file .nuprl.config in your home directory with the following entries:

(libhost "hostname")(dbpath "/home/nuprl/nuprl5/NuprlDB")(libenv "standard")

The hostname for the libhost configuration should be the name of the host running the libraryprocess. The values for dbpath and the libenv describe the physical and logical location of thestandard library. Optional settings like specific colors and fonts for the Nuprl windows may alsobe given in that file.

Copy the file /home/nuprl/nuprl5/mykeys.macro to your home directory. Nuprl reads thefile ˜/mykeys.macro to determine the key bindings that will be used in various windows. You needit to initialize the key combinations described in this manual and to customize them according toyour own preferences later.

2.2 Running Nuprl 5

For the basic Nuprl 5 configuration you need to run three processes: a library, an editor, and arefiner. The library (nulib) should be started first. The editor (nuedd) and the refiner (nuref)can then be started in any order. Generally it is a good idea to run these processes in separateemacs frames: there will be interactive top loops, so editing capabilities are sometimes useful.

7

Figure 2.1: Initial Nuprl 5 screen

Once the processes have started, entering (top) at the Lisp prompt will start the ML system.

USER(1): (top)

Enter go. at the prompt to initialize the corresponding Nuprl process.

ML[(ORB)]> go.

It is important to initialize the library before the editor and the refiner. The editor process willtake few minutes and then pop up two windows: a navigator and a top loop.

Figure 2.1 shows a typical initial Nuprl 5 screen. The window on the left is the Nuprl 5navigator. The three emacs windows on the upper right run interactive top loops for the library,editor and the refiner. The Nuprl 5 top loop is shown in the window below. In contrast to thecorresponding emacs top loops, the Nuprl 5 top loop incorporates the Nuprl 5 term editor. It isbetter suited for editing object-level terms but do not support the full editing capabilities of emacs.Unless there is a need to interact with the top ML level, one usually iconifies these four windowsto create some space for the windows that will pop up while working with the system.

2.3 Using the Navigator

The navigator is the main user interface of Nuprl 5. It can be used to browse the library andto create, delete, or edit objects by initiating the appropriate editors. Figure 2.2 shows navigatorwindow shown in its initial state. As in most Nuprl 5 windows, the upper part of the navigatorwindow contains several buttons, which are indicated by a * at the end of a word. Clicking abutton with the left mouse will trigger some action or pop up a template to be filled in. The lowerpart of the navigator window shows the current directory (here ROOT) and a listing of the type,status, and name of some of the objects in the directory. There is also a distinguished object, thenav point), which is marked by an arrow (the navigation pointer). When the edit point is in theScroll position field (use the left mouse), the arrow keys on the keyboard can be used to movethe through the directory tree.

↑ up move navigation pointer one step up↓ down move navigation pointer one step down← left move navigation pointer to next higher directory→ right open object at navigation pointer in a new window

(enter sub-directory if object is of type DIR)

8

- TERM: Navigator

Activate* deActivate* NameSearch* PathStack* Clone* RaiseTopLoopsMill* SaveObj* commentObj* CountClosure* ObidCollector*MkLink* MkObj* MkDir* mkTHM* CpObj* reNameObj* EditProperty*RmLink* RmObj* RmDir* RmGroup*

↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><

Navigator: [ROOT]

Scroll position : 0

List Scroll : Total 4, Point 0, Visible : 4-----------------------------------------------> DIR TTF theories

DIR TTF system-auxDIR TTF localDIR TTF system

----------------------------------------------

Figure 2.2: Nuprl 5 Navigator

The navigator window also contains arrow buttons for faster navigation through a directory.↑↑ and ↓↓ scroll half a screen, ↑↑↑ and ↓↓↓ scroll a full screen, and ↑↑↑↑ and ↓↓↓↓ move to thetop and bottom of the directory. In addition to buttons and arrow keys, there are also a variety ofspecial key combinations that can be used to manipulate objects in the library. These are describedin Chapter 4.

To begin working with the Nuprl system, one will usually move into the theories directory.Leaving the initial state will cause additional buttons to become visible.

- TERM: Navigator

MkTHY* MkThyDir* ExportThy* OpenThy* CloseThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*

Mill* ObidCollector* NameSearch* PathStack* RaiseTopLoops*

PrintObjTerm* PrintObj* MkThyDocObj* ProofHelp* ProofStats* showRefEnvs* FindTheoriesMin*CpObj* reNameObj* EditProperty* SaveObj* RmLink* MkLink* RmGroup*

ShowRefenv* SetRefenvSibling* SetRefenv* ProveRR* SetInOBJ*Activate* DeActivate* MkObj*

↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><

Navigator: [theories]

Scroll position : 0

List Scroll : Total 13, Point 0, Visible : 10-----------------------------------------------> DIR TTF General

DIR TTF pre-utilsDIR TTF initial reference environmentDIR TTF standardTERM TTF check theories controlDIR TTF ObviousDIR TTF userDIR TTF detritusDIR TTF utilsDIR TTF .help

----------------------------------------------

Usually, Nuprl users will work within their own sub-directory within the directory user andoccasionally browse the standard sub-directory, which contains the Nuprl type theory and a fewstandard libraries of formalized mathematical knowledge.

9

A new user-directory can be created by clicking the MkThyDir* button. This will open a templatefor entering the name of the new directory and move the edit point to the [name] slot.

- TERM: NavigatorOK* Cancel*

create new directory : [name]

----------------------------------------




ShowRefenv* SetRefenvSibling* SetRefenv* ProveRR* SetInOBJ*MkTHM* MkML* AddDef* AddRecDef* AddRecMod* AddDefDisp* AbReduce* NavAtAp*Act* DeAct* MkThyDir* RmThyObj* MvThyObj*

↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><

Navigator: [user; theories]

Scroll position : 0

List Scroll : Total 1, Point 0, Visible : 1-----------------------------------------------> CODE TTF RE init user----------------------------------------------

- TERM: NavigatorMkTHY* MkThyDir* ExportThy* OpenThy* CloseThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 1

List Scroll : Total 2, Point 1, Visible : 2----------------------------------------------

CODE TTF RE init user-> DIR TTF kreitz----------------------------------------------

Enter the name of the directory and click OK* (or press | twice). This will create the newdirectory object, place it immediately below the previous nav point, and move the navigationpointer to it, as shown in the right window.

2.4 Creating Theorem Objects

Before one can prove a theorem in Nuprl one has to create an object that contains it. Clicking theMkTHM* button (after moving into the user directory) will open a template for entering the nameand kind of a new library object.1 The edit point will be in the [name] slot.

- TERM: NavigatorOK* Cancel*ToggleRefenvRelationship* SetRelativeRefenv*

create new thm : [name]

(* creates a thm after current object *)

----------------------------------------





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><

Navigator: [kreitz; user; theories]

Scroll position : 0


----------------------------------------------





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 1, Point 0, Visible : 1-----------------------------------------------> STM FFF not over and----------------------------------------------

As example theorem we take x∀A,B:P. (¬A) ∨(¬B) ⇒ ¬(A ∧B)y, one of the DeMorgan lawsfor propositional logic. Enter the name of the theorem not over and and click OK*, or press | twice. This will create a new statement object named not over and.

2.5 Proving Theorems

To state and prove a theorem, one has to open the corresponding object. Pressing the right arrowkey when the nav point is a statement object pops up a new window that shows the contents ofthis object. If the theorem has not been stated yet, there will be a [goal] slot in the upper partof the window and the rule slot next to the keyword BY below will be empty. The # in the upperleft corner means that the theorem is not complete yet, while the top next to it indicates that thetop node of the proof tree is being displayed.

1Right now, the creation of a theorem object requires the current directory to contain at least one object.

10

↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0


- PRF: not over and# top[goal]

BY

Move the mouse cursor into the new window and click left in the [goal] slot. This initializesthe Nuprl 5 term editor in this slot. The goal is now entered in a structural top-down fashion.Entering xall |y creates the template for the universal quantifier.

- PRF: not over and# top

∀[var]:[type]. [prop]

BY

The [var] slot of the all template is a text slot and will not be interpreted. Entering xA |yinserts the character ‘A’ in the variable slot and moves the edit point to the next slot.

The [type] and [prop] slots are term slots, which means that input will be interpreted andmay open new templates. Entering xprop | i | all |y inserts the propositional universe term(whose name prop has nothing to do with the prop in the [prop] place-holder) into the [type]slot, and another template for the universal quantifier in the [prop] slot.

- PRF: not over and# top

∀A:P. ∀[var]:[type]. [prop]

BY

Entering xB | prop | i |y fills the second quantifier. Notice that the two quantifiers getcontracted, as A and B have the same type P.

- PRF: not over and# top∀A,B:P. [prop]

BY

Entering the rest of the theorem is straightforward. Typing ximplies |y creates the implicationtemplate. Entering xor | not | A | not | B |y generates (¬A) ∨(¬B) and ¬(A ∧B) is generatedby xnot | and | A | B |y.

Before a statement can be used in a proof it must be committed to the permanent library. Thiscan be done by using the key combination 〈C-M-g〉.2

- PRF: not over and

# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

2Actually, pressing 〈C-M-g〉 is not necessary when entering a statement for the first time, since it will be committedafter the first execution of a proof tactic. However, subsequent modifications of the statement will not be committedwithout pressing 〈C-M-g〉. Thus it is better to make using this key combination a habit.

11

To begin with the proof, press the down arrow key once or use the left mouse to move the editpoint into the empty rule slot next to the BY.

- PRF: not over and# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

The most common proof tactic is the single step decomposition tactic D (see chapter 8 fordetails). It requires as argument the index of the proof hypothesis to which it shall be applied or azero if it shall be applied to the conclusion. To enter this tactic, type xD 0 〈C- | 〉y.

Pressing 〈C- | 〉 when in a rule slot refines the goal at current node with the corresponding tac-tic. In this (synchronous) mode you have to wait for the refinement process to be complete. Pressing〈C-M- | 〉 instead initializes asynchronous refinement , which allows you to continue working whilethe proof goal is being refined. Once a refinement is completed the proof window gets updated andshows the subgoals that were generated by applying the tactic.

- PRF: not over and# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY D 0

# 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

# 2

.....wf.....P ∈ U’BY

To prove the first subgoal, press the down arrow key. This will move into the first sub-node ofthe theorem, indicated by a top 1.

- PRF: not over and# top 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

To move into the second subgoal, press the right arrow key. As indicated by the .....wf.....annotation, the second subgoal is a well-formedness goal , stating that P is a well-formed type theo-retical expression. Most goals of this kind can be dealt with automatically. Typing xAuto 〈C- | 〉ywill complete this subproof: no subgoals are generated and the status marker changes into a *.

- PRF: not over and* top 2.....wf.....P ∈ U’BY Auto

Pressing the left arrow key will bring you back into the first subgoal. Alternatively you canpress 〈C-M-j〉, which causes the editor to jump to the next unproven subgoal.

Proving the first subgoal requires more efforts. Typing xAuto 〈C- | 〉y will decompose theuniversal quantifier, the implication, and deal with the corresponding well-formedness subgoals.The result will be a subgoal with two additional hypotheses: a declaration of the variable B and theassumption (¬A) ∨(¬B).

12

To prove this goal both the conclusion (D 0) and the third hypothesis (D 3) need to be decom-posed. Auto does neither of these two steps automatically but can deal with the resulting subgoals.These steps can be combined into a single one by using the tactical THEN.

- PRF: not over and# top 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY Auto

* 1 1

2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY

Clicking the left mouse next to the BY allows you to enter the tactic into an empty rule slot with-out having to move into the corresponding sub-node. Typing xD 0 THEN D 3 THEN Auto 〈C- | 〉yresults in a complete proof of the subgoal.

- PRF: not over and* top 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY Auto

* 1 1

2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0 THEN D 3 THEN Auto

Using the up arrow key will get you back to the parent node, which now shows the complete proof.

- PRF: not over and* top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY D 0

* 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY Auto

* 1 1

2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)


* 2

.....wf.....P ∈ U’BY Auto

The proof has already been saved in the library. To close the proof window press 〈C-Q〉. Thiskey combination will always close the current window.

If a theorem shall be used as lemma in other proofs, it has to be activated . Many tactics use a listof active theorems which are searched through when attempting to prove a theorem automatically.For this purpose you have to click the Act* button, which changes the object status of not over andfrom FFF to TFF.

13

- TERM: Navigator





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 1, Point 0, Visible : 1-----------------------------------------------> STM TFF not over and----------------------------------------------

A theorem can also be activated by closing the proof window with 〈C-Z〉 instead of 〈C-Q〉. Thiswill cause Nuprl to create the extract term of the proof (a λ-term describing its computationalcontent) and to store it along with the theorem object. The status of that theorem will then be TTF.

2.6 Adding Definitions

Besides proving theorems, the most common activity in mathematics is introducing new concepts,which are defined in terms of already existing ones. This makes the formulation of theorems crisperand easier to comprehend. Nuprl supports such an enhancement of the formal language through adefinition mechanism. This mechanism allows a user to introduce new terms that are definitionallyequal to other terms.

As an example consider the ∃! quantifier, which states the existence of a unique element x ∈Tthat satisfies a property P. A typical definition for this quantifier is the following:

∃!x:T. P[x] ≡ ∃x:T. P[x] ∧ (∀y:T. P[y] ⇒ y=x ∈T).This definition actually presents two aspects of a newly defined term. It first states that a new

abstract term, say exists uni is to be introduced, which has two subterms (T and P) and bindsoccurrences of x in P. Secondly, it states that the term is to be presented as ∃!x:T. P.

In Nuprl a formal definition requires the creation of two new objects: an abstraction, whichdefines the abstract term, and a display form, which defines its syntactical appearance (see Chapters7.1 and 7.2). In addition to that, it is advisable to prove a well-formedness theorem, which describesthe type of the newly introduced term. All three objects can be created with the AddDef mechanism.

To initialize this mechanism, click the AddDef* button with the left mouse. This will open atemplate for defining the abstract term.


add def : [lhs] ==[rhs]

----------------------------------------





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 1, Point 0, Visible : 0-----------------------------------------------> STM TFF not over and----------------------------------------------

14

To enter the new term on the left hand side of the definition, you have to provide its name (orobject identifier) and a list of subterms. The ∃! has two subterms, T and P, and binds one variablein the second. To create a template for entering the details, type xexists uni(0;1)y.

- TERM: Navigator

OK* Cancel*

add def : exists uni\(0;1[rhs]

- TERM: Navigator

OK* Cancel*

add def : exists uni([term]; [binding].[term]) ==[rhs]

This tells the system to create a term called exists uni, whose first term has no bound variablesand whose second term has one bound variable The template, shown on the right, appears as soonas you have entered the right parenthesis that closes the subterm list. Pressing | then moves theedit point into the first term slot.

- TERM: Navigator

OK* Cancel*

add def : exists uni([term]; [binding].[term]) ==[rhs]

Enter xT | x | so var1 |y. This puts T into the first term slot, makes x the binding variable in thesecond, and states that the second term will be a second order variable of arity 1 (see Chapter 7.1).

- TERM: Navigator

OK* Cancel*

add def : exists uni(T; x.[variable-id][[term]]) ==[rhs]

Note that Nuprl’s term editor treats any unknown name as variable name, while names that canbe linked to (active) object identifiers (and display forms) will cause the corresponding templateto appear. Thus T will be inserted as variable name, while so var1 creates a new template. x hadbeen entered into a binding slot and is thus viewed as variable.

Should you mistype so var1 and actually enter an identifier that is unknown to Nuprl, saysovar1, the identifier will appear as variable name in the term slot.

- TERM: Navigator

OK* Cancel*

add def : exists uni(T; x.sovar1) ==[rhs]

There are two ways to correct that mistake. You may delete the term xsovar1y by clicking left overit, pressing 〈M-P〉 to mark the full term and then 〈C-K〉 to cut it. Afterwards you enter so var1 |

to get the correct template. Note that 〈C-k〉 saves the term in a cut buffer and that you can pastethis term with 〈C-Y〉. To delete a term without saving it, you need to press 〈C-C〉.

Alternatively, you may use Nuprl’s generic undo command 〈C- 〉, which will restore the emptyterm slot. Move the edit cursor into that slot either by pressing | or by clicking left over it andthen enter enter so var1 | .

Entering xP | x |y next generates P[x] and moves the edit point into the right hand side ofthe definition.

- TERM: Navigator

OK* Cancel*

add def : exists uni(T; x.P[x]) ==[rhs]

15

To enter the right hand side of the definition, you have to proceed in a structural top-down fashion.Type xexists | x | T | and | so var1 | P | x |y

- TERM: Navigator

OK* Cancel*

add def : exists uni(T; x.P[x]) ==∃x:T. (P[x] ∧ [prop]

and then xall | y | T | implies | so var1 | P | y | equal | x | y | T |y.- TERM: Navigator

OK* Cancel*

add def : exists uni(T; x.P[x]) ==∃x:T. (P[x] ∧ ∧ (∀y:T. (P[y] ⇒ y=x∈T)))

The definition is now complete. To save it to the library click OK* or press | again. This closesthe AddDef template and creates a display form exists uni df of kind DISP, an abstraction objectexists uni of kind ABS, and a well-formedness theorem exists uni wf of kind STM. The navigationpointer is still where it has been before.





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 4, Point 0, Visible : 4-----------------------------------------------> STM TFF not over and

DISP TTF exists uni dfABS TTF exists uniSTM TFF exists uni wf

----------------------------------------------

The abstraction object contains exactly what has been typed into the AddDef template and usuallydoes not have to be edited anymore. The display form has been generated from the left hand side ofthe AddDef template and currently causes the term exists uni to be displayed in exactly this way.The well-formedness theorem is empty but already activated, which enables the general tactics toaccess it whenever they have to deal with exists uni.

To view the abstraction, move the navigation pointer down 2 steps then open the objectexists uni by pressing the right arrow key.





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 2


STM TFF not over andDISP TTF exists uni df

-> ABS TTF exists uniSTM TFF exists uni wf

----------------------------------------------

- ABS: exists uni

exists uni(T; x.P[x]) ==∃x:T. (P[x] ∧ (∀y:T. (P[y] ⇒ y=x∈T)))

The abstraction object shows on the right hand side the term that defines the meaning ofexists uni(T;x.P[x]) and on the left hand side the form in which exists uni(T;x.P[x]) iscurrently displayed. Right now, this is identical to the abstract term form. To close the abstractionobject again press 〈C-q〉.

16

To change the appearance of the term exists uni(T;x.P[x]) to ∃!x:T. P[x] you have to editthe accompanying display form. For this purpose, move the nav point one step up and open theobject exists uni df.





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 1


STM TFF not over and-> DISP TTF exists uni df

ABS TTF exists uniSTM TFF exists uni wf

----------------------------------------------

- DISP: exists uni dfEdAlias exists uni ::exists uni(<T:T:*>;<x:var>.<P:P:*>) ==exists uni(<T>; <x>.)

The display form consists of a list of attributes (in this case only the name that can be used to openthe template), a template that determines the outer appearance of a term, and the term that is tobe represented by that template. Both the template and the term contain slots that are markedwith <..> and describe the name of a placeholder, a description that will appear whenever thetemplate is initiated, and information about parenthesizing. Chapter 7.2 describes how to createdisplay forms from scratch, but usually copying and pasting is sufficient.

To edit the template click mouse over the exist uni in the second line and erase the textexist uni( using backspace and delete keys. Notice that you can’t delete the slot <T:T:*> withthese keys. Type x〈C-#〉163!y to generate the ∃ symbol (see table 5.1 on page 73 for a list of allspecial characters) and the exclamation mark. Delete the semicolon and the dot between the termslots and also the right parenthesis.

- DISP: exists uni dfEdAlias exists uni ::∃!<T:T:*><x:var><P:P:*> ==exists uni(<T>; <x>.)

To rearrange the order of the slots click left over <T:T:*> press 〈M-p〉 to mark the full slot, and〈C-k〉 to cut it. Then move the mouse to the immediate right of <x:var:*> and press 〈C-y〉. Adda colon between <x:var:*> and <T:T:*>, a dot and a space between <T:T:*> and <P:P:*>.

- DISP: exists uni dfEdAlias exists uni ::∃!<x:var>:<T:T:*>. <P:P:*> ==exists uni(<T>; <x>.)

In principle, the display form is now complete. However it is advisable to edit the slot descriptionof T and P. Click right of the second T in <T:T:*>, remove it and enter xtypey instead. In the sameway change the second P in <P:P:*> to prop. This makes sure that meaningful descriptions fortheses slots will show up whenever the template for exists uni is opened.

- DISP: exists uni dfEdAlias exists uni ::∃!<x:var>:<T:type:*>. <P:prop:*> ==exists uni(<T>; <x>.)

To commit the completed display form to the library, press 〈C-Z〉. This will also close the windowagain. Do not use 〈C-Q〉 unless you want all your changes to be ignored. 〈C-Q〉 will always close awindow without saving its contents to the library.

17

To check the display form, open the abstraction exists uni again. You will notice that thedisplay of the abstract term exists uni(T;x.P[x]) has now been replaced by ∃!x:T. P[x].





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 2


STM TFF not over andDISP TTF exists uni df

-> ABS TTF exists uniSTM TFF exists uni wf

----------------------------------------------

- ABS: exists uni

∃!x:T. P[x] ==∃x:T. (P[x] ∧ (∀y:T. (P[y] ⇒ y=x∈T)))

The abstraction and the display form are sufficient for using a newly defined term in formal the-orems and other abstractions. However, many proofs involving an instance of exists uni willinvolve checking the type of this term. This can be done automatically if well-formedness theoremis provided describes the type of the newly defined term.

A unique existence quantifier ∃!x:T. P[x] is a proposition, provided that T is a type and P isa predicate on T. In other words, the type of ∃!x:T. P[x] is P if T is an element of the universe Uof types and P ∈ T→P. Formally, you need to prove ∀T:U. ∀P:T→P. ∃!x:T. P[x] ∈ P.

To state this theorem, open the object exists uni wf and enter

xall | T | univ | i | all | P | fun | T | prop | member |yinto the goal template.

- PRF: exists uni wf# top∀T:U. ∀P:T→P. ([term] ∈ [type])

BY

Continue with xexists uni | x | T | so apply1 | P | x | prop | 〈C-M-g〉y to complete the goaland commit it to the library.

The proof of this theorem is fairly simple, since it can be handled almost completely by Nuprl’stactic Auto. However, since Auto does not unfold a definition unless it is explicitly declared asautomatically unfoldable, you need to unfold the definition of exists uni in the first step.

Typing xUnfold ‘exists uni‘ 0 THEN Autoy into the rule slot will result in a proof of thewell-formedness theorem for exists uni.





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 3


STM TFF not over andDISP TTF exists uni dfABS TTF exists uni

-> STM TFF exists uni wf----------------------------------------------

- PRF: exists uni wf# top∀T:U. ∀P:T→P. (∃!x:T. P[x] ∈ P)BY Unfold ‘exists uni‘ 0 THEN Auto

This completes all necessary steps for adding a unique existence quantifier to the formal languageof Nuprl. Close the well-formedness theorem with 〈C-Q〉.

18

2.7 Printing Snapshots

To print a snapshot of a particular object, simply click the PrintObj* button. This will create aprint representation of the object at the nav point and write it into a file ˜/nuprlprint/object-name.prl. This file can be inspected with any 8bit capable editor that has the Nuprl fonts loaded.It will also create a LATEX-version and write it to ˜/nuprlprint/object-name.tex. The directory˜/nuprlprint must already exist. Otherwise clicking the PrintObj* button will result in an error.

The button PrintCollection will create a print representation of a whole range of objects,while the buttons PrintThyLong and PrintThyShort will create a print representation of thedirectory at the nav point. The long version shows the complete proofs of theorems while the shortversion only prints the theorem statement and the extract of the proof, that is a term representingits computational content.

2.8 Troubleshooting

Since the Nuprl library never destroys information, typos and almost all commands can be undoneby entering the key combination 〈C- 〉. The undo history, however, is limited and recovering froman error that was made many steps ago is more difficult.

Should you accidentally close the navigator window you may open it again by typing the com-mand win. into the editor process top loop. This will open all the windows of the initial screen.

If the editor hangs for an unusually long time, one of the three main processes (editor, refiner,or library) may be broken. In this case there will be an error message in the corresponding (emacs)top loop. Often, evaluating the expression (fooe) will recover the process. Sometimes, typing theLisp command :cont will help as well. In the worst case, kill the process and then restart it. Thelibrary process will detect the link going dead and clean it up automatically.

2.9 Shutting Nuprl down

In principle, there is no need to shutdown Nuprl, as all data are saved immediately and updatesmay be integrated by by loading patches into the running process. However the Nuprl 5 are quitedemanding as far as cpu and memory are concerned.

To shutdown gracefully you should first close the refiner and the editor and then the library.Enter stop. at the corresponding ML prompt.

ML[(ORB)]> stop.

As a result, the editor and refiner will communicate to the library that they will disconnect nowand then stop the respective ML and Lisp processes. The library process will cleanly shut down theknowledge base and then stop as well.

Instead of shutting down gracefully you may also simply kill all three processes to stop Nuprl 5,although this is not recommended.

19

Chapter 3

Running Nuprl 5

3.1 System Requirements

Nuprl 5 is written mostly in Common Lisp, but uses some extensions that require Lucid, Allegroor LCMU Common Lisp and a Unix-based X window system. The implementation of CMU CommonLisp is freely available. Other Lisp versions require a license. CMUCL is faster with smaller memoryfootprint but currently Allegro is a bit more stable.

The Nuprl homepage provides an executable copies of the CMUCL version of Nuprl 5 runningunder Linux. Executable copies for Allegro can be provided upon request. The source code as well asinstructions for installing Nuprl 5 to run under other Lisp and Unix versions will be made availableas soon as the system has stabilized.

The Linux release of Nuprl 5 contains 3 binary executables (the library, the editor, and the re-finer) that altogether require 120 MegaBytes of disk space for the CMUCL version and 40 MegaBytesfor the Allegro Version. The standard library initially requires an additional 120 MegaBytes of diskspace and quickly grows to 500 MegaBytes or more.

It is recommended to run Nuprl 5 on systems that have at least 256MB of RAM, 512MB ofswap space, and 800MB of disk space available. Due to its implementation in Lisp, Nuprl runsmore efficiently if more memory is available. In large applications it can utilize several GigaBytesof RAM. Nuprl 5 can also profit from multiple processors or a network of computers, because thelibrary, editor, and refiner run as independent processes,

3.2 Preparation

Before Nuprl 5 can be started for the first time, it needs to be installed properly and certainconfiguration files must be set up for each user.

3.2.1 Retrieving and Installing Nuprl 5

The executable copy of Nuprl 5 running under Linux can be found by going to the Nuprl 5web page http://www.nuprl.org/nuprl5/index.html and following the link to the downloadpages for the actual Nuprl 5 release.1 To retrieve Nuprl 5, read the instructions in the variousREADME files for up-to-date information.

1Currently, the release can be found at the URL ftp://ftp.cs.cornell.edu/pub/nuprl/nuprl5 but this direc-tory may be moved in the future.

21

http://www.nuprl.org/nuprl5/index.html

ftp://ftp.cs.cornell.edu/pub/nuprl/nuprl5

Currently you have to download the following files.

install.tgznuprltop.tgznuprl5.tgzstandard-db.tgznuprl5-linux-cmucl-run.tgz

If you run Solaris instead of Linux, download the file nuprl5-solaris-cmucl-run.tgz instead ofnuprl5-linux-cmucl-run.tgz. Experienced users who want to build their own Nuprl binaries ormodify system tactics may also want to download the file nuprl5-source.tgz.

For a single-user installation, it is best to build the Nuprl system within a subdirectory of theuser’s home directory. For a default installation, this subdirectory should be called nuprl. For amulti-user installation, it is recommended to build Nuprl in a directory /home/nuprl and to createa user nuprl and a group nuprl that gives users controlled access to this directory.

In the following we describe the default single-user installation for Linux. Instructions for acustom installation can be found in the file README.install.

Move all the downloaded .tgz files into your home directory and then untar the file install.tgzusing the commands

shell-prompt> cd ~shell-prompt> tar -xzf install.tgz

This will build a directory /nuprl in which you will find an installation script install-nuprl5.plas well as a file README.install with instructions for building Nuprl 5. As the installation proce-dure may change in the future, it is advisable to read these instructions before starting the actualinstallation.Enter the nuprl subdirectory and execute the installation script.

shell-prompt> cd ~/nuprlshell-prompt> ./install-nuprl5.pl

This will untar the other .tgz files in your home directory and build the Nuprl system withinthe current directory. The Nuprl knowledge base will be installed at ~/nuprl/nuprl5/NuPrlDB.

The library, editor, and refiner processes as well as several utilities can be found in ~/nuprl/bin.To run Nuprl 5, the directory for Nuprl binaries must be included in the user’s Unix load path.To do so, add the following line to your .chsrc or .login file

set path = ( /nuprl/bin $path)

The syntax is slightly different for other Unix shells.

To support the use of special mathematical symbols in formal theorems, the Nuprl sys-tem requires some special font files to be installed. These files are contained in the directory~/nuprl/fonts/bdf and must be included in the font search path of the X server controllingyour display.2 Add the following lines to your .xinitrc file

xset fp+ /nuprl/fonts/bdfxset fp rehash

These commands tell X the font path to the Nuprl fonts when the X server is first started. Onemay also run them interactively in some shell to add the font path to the current X environment.

2It is not sufficient to have the Nuprl-fonts available on the system that runs Nuprl 5. This may cause somecomplications when running Nuprl 5 remotely, particularly when the Exceed X server under Windows (NT/98/2000)is used as terminal.

22

Most X windows systems understand bdf font files. However, one may also compile the font filesinto machine-specific fonts to allow faster reading. To compile fonts, one has to use the commandbdftosnf on Sparc stations and bdftopcf on Linux-PCs. After the fonts have been compiled,, onehas to execute the command mkfontdir to make the font directory.

Sometimes the X-server has limited access to the file system. In this case the fonts files mayneed to be placed in a public directory. Your system administrator should be able to advise youin this case.

3.2.2 User-specific Configuration

Upon startup Nuprl 5 expects to find a file ~/.nuprl.config in the user’s home directory todetermine how the individual Nuprl processes will communicate. If this file is missing, Nuprl 5will use the configuration that was present at compile time and may not be able to establish thecommunication. The structure of a typical .nuprl.config file is as follows.

;; ------------------------------------------------------------;; Which server runs the library process?;; ------------------------------------------------------------(libhost "hostname")

;; ------------------------------------------------------------;; Where is the location of the Nuprl Library?;; ------------------------------------------------------------(dbpath "database-path")

;; ------------------------------------------------------------;; What environment within the Nuprl Library shall be used?;; ------------------------------------------------------------(libenv "standard-library")

;; ------------------------------------------------------------;; Optional settings;; ------------------------------------------------------------;; Which X-server shall be used to display the Nuprl windows?;; ------------------------------------------------------------;; (eddhost "localhost" 0)

;; ------------------------------------------------------------;; What sockets shall be used for communication?;; ------------------------------------------------------------;; (sockets socket1 socket2)

;; ------------------------------------------------------------;; How to identify the user?;; ------------------------------------------------------------;; (iam "user-name")

;; ------------------------------------------------------------;; Color and size of displayed windows;; ------------------------------------------------------------;; (foreground "foreground-color’’);; (background "background-color");; (font "font-name")

The hostname for the libhost configuration should be the name of the host running the libraryprocess. Currently even a stand-alone machine needs a host name.

The values for dbpath and the libenv describe the physical and logical location of the standardlibrary. In the default single-user installation, it should be ~/nuprl/nuprl5/NuPrlDB. In a multi-user installation, it is usually /home/nuprl/nuprl5/NuPrlDB. The value of standard-library isusually standard.

23

All other entries of in the .nuprl.config file are optional. Users may redirect the Nuprlwindows to a specific X server or choose a specific set of sockets for communication between theNuprl processes. If several users shall work with the same library, the socket numbers should beidentical to the ones used by the joint library process. Specific users can be identified by the system,which will be necessary for granting controlled access to certain parts of the library.

The foreground and background colors set the colors for the Nuprl windows and can bechosen according to personal preferences. Users may also chose a font for the Nuprl windows. Bydefault, nuprl-13 is being used but users may also select any other Nuprl fonts or other fontsthat are consistent with them.3

The Nuprl 5 editor will read the file ~/mykeys.macro to determine any user key bindingsfor motion and macro commands. If this file is missing, the key bindings that were present atcompile time will be used. The standard bindings of the Nuprl 5 system are listed in the file~/nuprl/nuprl5/sys/macro/keys.macro. Users who wish to customize their Nuprl 5 key bind-ings may copy this file into the file ~/mykeys.macro and modify it according to their needs.

It is helpful for the user to become familiar with an editor like emacs (version 19 and higher)that supports 8-bit fonts and has a capability for starting sub-shells. The editor should be run withone of the nuprl fonts. This is not strictly necessary, but is a good idea for several reasons:

• Each Nuprl process runs a “top loop” in the same window as the one from which it wasstarted up. It accepts input from that window and frequently writes output to it. If Nuprl isstarted up from an editor sub-shell, it becomes easy to review this output and save portionsof it to files. Editing capabilities for the input are sometimes useful as well.

• Some of Nuprl’s output is in Nuprl’s 8-bit font.

• Listings of theory files use Nuprl’s 8-bit font. These files contain definitions, theorems andproofs, and it is often useful to be able to browse them.

3.3 Starting Nuprl 5

The basic Nuprl 5 configuration consists of three separate processes: a library, an editor, and arefiner. In single-user mode you have to start all three processes. In multi-user mode you will connectto an already running library process and only have to start an editor and an optional refiner4 aftersetting up your .nuprl.config file accordingly. It is important to initialize the library before theeditor and the refiner.

Generally it is a good idea to run the Nuprl 5 processes in separate emacs frames. In additionto editor support for the corresponding top loops this also allows you to define an interactive emacscommand that starts all three processes and initializes them correctly. The Nuprl distributionprovides a few utilities for starting the Nuprl 5 processes from within emacs buffers. Consult thefile README.running-nuprl for instructions how to use them.

The next three subsections describe three interactive emacs commands nulib, nuedit, andnurefine. If you add these and the following definition of the emacs command nuprl5 to your.emacs file, you may start Nuprl 5 from emacs by typing x〈M-x〉nuprl5 |y.

3The table of Nuprl’s special characters (Table 5.1 on page 73) is actually based on a font nuprl-8x13, whichextends nuprl-13 by a few special characters with code 204 and higher.

4Actually, it may not even be necessary to start a new Nuprl 5 refiner, as the editor will connect to refiners thatare already running. However, this would mean that you need to share that refiner with other users, which may causeunnecessary delays if the refiner is busy. Generally, it is recommended that you start your own refiner unless you onlyintend to browse the library.

24

(defun nuprl5 ()(interactive)(message "Starting NuPRL 5 Library, Editor, and Refiner ...")(nulib)(sleep-for 5)(nuedit)(nurefine)

)

It will take several minutes until all the Nuprl editor windows will begin to pop up, becauseinitially there is a lot of communication between the editor and the library.

3.3.1 Starting the Library

The library process should be started first because both the editor and the refiner rely on informa-tion that is explicitly stored in the knowledge base (to simplify customization of these processes).In a shell, enter the command xnulib |y.

shell-prompt> nulib

A Lisp session will start, followed by system messages. At the Lisp USER prompt enter x(top) |y.USER(1): (top)

This will start an ML top loop with some library-specific commands preloaded. At the ML prompt,enter xgo. |y to initialize the Nuprl 5 library.

CURRENT TIME : time and date

ML[(ORB)]> go.

The library process will now use the information in the file .nuprl.config to load the desiredlibrary environment and to open the sockets for communication. It will write some system messagesto the process window and then wait for other processes to connect.

The following emacs script defines an interactive function nulib that performs all the abovesteps in a new emacs shell. Using the function nuprl-frame it pops up a new frame at a specificposition on the screen, opens a shell process *NuLibrary* in it, and then subsequently sends theabove command to that process.

(defun nuprl-frame (bufname height top-corner cmd)(save-excursion

(set-buffer (make-comint bufname "/bin/csh" nil "-v"))(switch-to-buffer-other-frame (concat "*" bufname "*" ))(let ((NuPRLframe (car (cadr (current-frame-configuration)))))

(set-frame-size NuPRLframe 81 height)(set-frame-position NuPRLframe 515 top-corner)

)(set-default-font "6x10")(while (= (buffer-size) 0) (sleep-for 1))(comint-send-string bufname "limit coredumpsize 0\n")(comint-send-string bufname cmd)

) )

(defun nulib ()(interactive)(nuprl-frame "NuLibrary" 10 76 "nulib\n")(message "Starting Library ...")(set-foreground-color "Red")(set-background-color "#ddddff")(comint-send-string "NuLibrary" "(top)\n")(comint-send-string "NuLibrary" "go.\n")

)

25

The shell script is designed for an XGA (1024x786) display and uses a fairly small font. Youneed to adjust the frame position on larger displays and if a larger font is chosen. The colors arechosen to distinguish the library frame from the other windows.

Experienced users can make further use of the function comint-send-string to send additionalcommands to the Nuprl 5 process at their convenience.

3.3.2 Starting the Refiner

Starting the refiner is similar to starting the library. In a shell, enter the command xnuref |y.shell-prompt> nuref

At the Lisp USER prompt enter x(top) |y.USER(1): (top)

At the ML prompt, enter xgo. |y to initialize the Nuprl 5 refiner.

ML[(ORB)]> go.

Although it is not necessary to wait for the library process before starting the refiner it is importantto enter the refiner’s go. command after the library’s go.. The library contains informations abouttactics and rules that the refiner needs in order to operate properly. Initially there will be only littleexchange between the library and the refiner. The refiner process will return quickly with anotherprompt ML[(ORB)]>.

The following emacs script defines an interactive function nurefine that performs the abovesteps in a new emacs shell. It pops up a *NuRefine* window immediately below the editor windowand starts the Nuprl 5 refiner in it.

(defun nurefine ()(interactive)(nuprl-frame "NuRefine" 10 280 "nuref\n")(message "Starting Refiner ...")(set-foreground-color "Green4")(set-background-color "#ffffbb")(comint-send-string "NuRefine" "(top)\n")(comint-send-string "NuRefine" "go.\n")

)

It should be noted that the emacs functions nulib, nuedit, and nurefine can be invokedindependently from each other. This may be helpful if one of the processes breaks and has to becompletely restarted or if several refiners and/or editors shall be started.

3.3.3 Starting the Editor

To start the editor, enter the command xnuedd |y into a shell and then proceed as before.

shell-prompt> nuedd

USER(1): (top)

ML[(ORB)]> go.

Again, the library’s go. command must precede that of the editor. The library contains a varietyof explicit set up information that the editor needs to receive in order to determine how to displaydata, e.g. how to present the directory structure of the knowledge base, when and how to pop upwindows, the location and meaning of editor buttons, etc.

26

Because of the amount of communication between the editor and the library it takes severalminutes until the editor process is set up correctly. When it is ready, it will return with anotherprompt ML[(ORB)]>.Enter xwin. |y to have the editor pop up Nuprl 5 windows.

ML[(ORB)]> win.

The editor will establish a connection to the X-windows system and then pop up two windows: anavigator and a top loop, which will be explained in detail in Chapter 4. Afterwards it will returnwith another prompt ML[(ORB)]>.

The Nuprl top loop can be used for issuing commands to the library, refiner, and editorprocesses and provides support for editing Nuprl 5 terms (see Section 5.3). Users may safely iconifythe emacs windows of the library, refiner, and editor processes at this point. A typical Nuprl 5session will have many Nuprl windows open at the same time, so it is advisable to create somespace for this, particularly when using medium-sized or larger fonts. The library, refiner, and editorprocess windows will only be needed for issuing low-level system commands and dealing with errorsituations that cause one of the Nuprl processes to break.

The following emacs script defines an interactive function nuedit that performs all the abovesteps in a new emacs shell. It pops up a *NuEditor* window immediately below the library windowand starts the Nuprl 5 editor in it.

(defun nuedit ()(interactive)(nuprl-frame "NuEditor" 10 178 "nuedd\n")(message "Starting Editor ... please be patient")(set-foreground-color "midnightblue")(set-background-color "#ffd8ff")(comint-send-string "NuEditor" "(top)\n")(comint-send-string "NuEditor" "go.\n")(comint-send-string "NuEditor" "win.\n")

)

If you run the Nuprl 5 editor on a remote machine, make sure that its display is directed toyour local machine before nuedd is entered. This is usually done by setting the environment variableDISPLAY. In a cshell you can do this with the following command

cshell-prompt> setenv DISPLAY local-host-name:0.0

In the emacs script you would have to insert the line

(comint-send-string bufname "setenv DISPLAY local-host-name:0.0\n’")into the definition of nuprl-frame, immediately before (comint-send-string bufname cmd).

Alternatively you may change the eddhost setting in you .nuprl.config file to redirect theNuprl windows to your local machine’s X server.

3.4 Exiting Nuprl 5

When you are ready to stop, first stop the editor and refiner process, and lastly the library. Toshutdown gracefully, enter xstop. |y at the ML prompts of the three processes.

ML[(ORB)]> stop.

As a result, the editor and refiner will communicate to the library that they will disconnect nowand then stop the respective ML and Lisp processes. The library process will cleanly shut down the

27

knowledge base and then stop as well. Depending on the size of the knowledge base this may takebetween a few seconds and several minutes.

It is important that you explicitly terminate the three Nuprl processes rather than just quittingout of the editor Nuprl 5 is running under. In the latter case, the Lisp process can be left floatingaround in a hung state, hogging memory resources. This could also happen if your editor crashesor if you kill the shell (or emacs buffer) in which Nuprl 5 runs. You can use the Unix commandps to check for a hung Lisp process and the command kill to kill it.

The interactive emacs command nuxit, described below, is a safe way to terminate Nuprl 5.

(defun nuxit ()(interactive)(message "Shutting Down NuPRL 5 Library, Editor, and Refiner ...")(comint-send-string "NuEditor" "stop.\n")(comint-send-string "NuRefine" "stop.\n")(sleep-for 5)

)

Advanced emacs users may want to add to this script commands that kill the respective buffersand emacs frames after the library process has terminated.

Instead of shutting down gracefully you may also simply kill all three processes to stop Nuprl 5.In this case the library process will clean up the knowledge base when it is started the next time.This method for exiting Nuprl, however, is is not recommended.

3.5 Hints on Using the System

Nuprl’s windows are at the “top-level” in the X environment. The windows can be managed (posi-tioned, sized, etc.) in the same way as other top-level applications such as X-terminals. Creation anddestruction of Nuprl windows, and manipulation of window contents, is done solely via commandsinterpreted by Nuprl.

Nuprl will receive mouse clicks and keyboard strokes whenever the input focus is on any ofits windows. Any input event will make this window active, which is identified by the presenceof Nuprl’s cursor . This cursor appears either as a thin vertical bar between characters or as ahighlighted (reverse video) region. The specific location of the cursor determines the semanticsof keyboard strokes and mouse clicks, and is – like in most editors – independent of the currentlocation of the mouse cursor.

The two main windows – the navigator window and the Nuprl 5 top loop – are intendedto remain throughout the session. You may kill and reopen them at any time although it is notrecommended to do so. You may create multiple clones of the navigator but not of the top loops.Chapter 4 describes the use of these windows as well as the kinds of objects that can be found inthe library.

There are two other kinds of windows; term editor windows and proof editor windows. Bothare used for editing objects in the library. The structure of Nuprl terms and the term editor isdescribed in Chapter 5. The proof editor is described in Chapter 6.

If the system appears to be inexplicably stuck, check the Lisp windows; it is very possible thatLisp is garbage-collecting. This sometimes takes a few minutes.

Most Lisp versions allow computations to be interrupted. This is usually done by sending 〈C-C〉to the Lisp process, or 〈C-C〉〈C-C〉 if Lisp is started up from an emacs sub-shell. (Sometimes Lisp

28

catches the first two or three interrupt requests.) This will cause Lisp to enter its debugger , fromwhich the computation can be resumed or aborted. Section 3.6 below describes how to use the Lispdebugger, and in particular, what to do if a Nuprl 5 process crashes. Nuprl is a continually-evolving experimental research system, and it is inevitable that it will contain bugs.

Aborting either of the three Nuprl 5 processes is always safe, since changes to objects, e.g. theeffects of editor commands or inference steps, are immediately committed to the persistent li-brary. When a Nuprl 5 process is restarted, the state should be exactly as it was before theprocess was killed.

Please report any behavior you think is due to a bug, or inconsistencies between the operationof the system and the documentation. Also report any break-points that you hit; they have eitherbeen left in the code accidentally, or they are there to help track down the source of bugs. Wewelcome suggestions for improvement. Send e-mail to [email protected].

3.6 Troubleshooting

In this section we discuss problem situations that need to be resolved on the system level. Recoveringfrom errors within either of the editors or the navigator is discusses in the respective chapters.

All system and error messages are directed to the emacs windows containing the three Nuprl 5processes. It is recommended to check these windows if the system seems to be stuck or if otherproblems occur.

In most cases where the system appears to be stuck, one of the three Lisp processes is garbage-collecting. Depending on processor speed and available memory this may take a few minutes.

If the editor hangs for an unusually long time, one of the three main processes may have beenthrown into the Lisp debugger. This may happen if a breakpoint was mistakenly left in the Nuprlcode or if you hit a bug. You may also have accidentally interrupted Lisp. In either there will bean error message in the corresponding (Lisp) top loop. The particular debugger appearance andcommands given below are for Allegro Common Lisp. Other Lisps should be similar.

The initial message put out by the debugger should tell you what caused it to be invoked. Thefollowing message, for instance appears after a keyboard interrupt

Error: Received signal number 2 (Keyboard interrupt)[condition type: INTERRUPT-SIGNAL]

Restart actions (select using :continue):0: continue computation

[changing package from "COMMON-LISP-USER" to "NUPRL5"][1c] NUPRL5(2):

To resume after an interrupt or breakpoint, enter x:cont |y.[1c] NUPRL5(2): :cont

ML[(edd)]>

If the ML prompt appears again, the process has successfully resumed. In some cases, Lisp cannotsimply resume and will print another error message, as in the following case

Error: Non-structure argument NIL passed to structure-ref[1] NUPRL5(3): :contError: Can’t continue and no restarts.[2] NUPRL5(4):

In most of these cases, entering the expression x(fooe) |y will reset and restart the process.

29

[2] NUPRL5(4): (fooe)

ML[(edd)]>

In the worst case, kill the process by entering x:exit |y and then restart it from scratch. The otherprocesses will detect the link going dead and clean it up automatically.

If you kill a Nuprl window using window manager commands instead of the appropriate Nuprleditor commands, you will break the X connection and crash the editor. Future releases of Nuprl 5will automatically repair the editor process but until then you have to recover at the lisp debugprompt using the following command sequence.

[2] NUPRL5(4): (ml-text "nuprl oed reset()")

[2] NUPRL5(5): (fooe)

ML[(edd)]> win.

If you kill the library process while it is shutting down the knowledge base, the knowledge basemay end up in an unstable state and you may not be able to restart the system anymore. In thiscase you have to enter the directory containing the knowledge base (e.g. ~/nuprl/nuprl5/NuPrlDB)and move the most recent subdirectories out of it, preserving them in some temporary directory.

The system will usually come up properly afterwards and return the knowledge base into awell-defined state but you will lose all the modifications recorded in the subdirectories that youmoved out of the main directory, so it may be useful to move them out one at a time, until theNuprl system starts again.

If you run into the same type of unrecoverable error twice, you may want to send a bug reportto [email protected]. In this case type x:zoom |y into the Lisp process before killing itand copy the output, together with the initial error messages into you bug report. Also, mentionbriefly what you were doing at the time of the crash. This will help the Nuprl programmers toidentify the cause for the problem and fix it.

3.7 Customization

Experienced users will probably want to create their own initialization procedures for Nuprl. Thesecould allow customizations such as:

• Changing key-bindings for the term and proof editors.

• Loading more / different tactics.

Currently, these initialization can only be run after starting up the pre-prepared disksaves for theNuprl 5 library, editor, or refiner. You probably will want to put all your initialization commandsinto a Lisp file that is automatically loaded whenever a disksave is started up.

Note that Nuprl runs in the nuprl package. All symbols entered in Lisp will be interpretedrelative to this package. The package inherits all the symbols of Common Lisp, but does not containthe various implementation-specific utilities found in the package user (or common-lisp-user). Torefer to these other symbols, either change packages using (in-package "USER"), or explicitlyqualify the symbols with a package prefix. If you change packages, you can change back to theNuprl package using (in-package "NUPRL").

The key bindings for the navigator and the term and proof editors can be altered by creatingyour own key macro files. The Nuprl 5 editor will look for a file ~/mykeys.macro to determineany user-defined key bindings.

30

Chapter 4

The Navigator and the Top Loops

The navigator and the interactive ML top loops provide interfaces to the library, the editor, andthe refiners. The main interface to the library is the Nuprl 5 navigator . It enables the user to

1. browse and search through the library

2. create, delete, and rename library objects of various

3. arrange objects in folders and theories

4. edit library objects by invoking a term editor (Chapter 5) or a proof editor (Chapter 6)

5. check the validity of objects and theories

6. export and import theories

7. print library objects and theories to text and LATEX files

The same operations can also be initiated from Nuprl’s ML top loop, which provides an interactiveinterface to the ML system of the editor process. The difference is that the navigator provides avisual interface to the library, while the ML top loop requires a user to enter ML commands thatwill be accepted by the Nuprl 5 editor and communicated to the library.

The ML top loop also provides additional functionality, such as experimenting with Nuprlfunctions, loading ML files, and exploring the Nuprl state. These functions can also be executedfrom the ML top loop that was initially started by the editor process. The difference between thesetwo top loops is that Nuprl’s ML top loop runs in a term editor window and thus supports mostof the editing commands described in Chapter 5 work in it. In contrast to that the process ML toploop runs in a Unix shell that does not support editing Nuprl terms but may support text editingfeatures if run from within emacs. Furthermore, most library functions are not accessible from theprocess top loop.

Nuprl’s ML top loop can also be run as refiner ML top loop or as library ML top loop. Inthese cases the ML top loop interfaces with the refiner process or the library process instead ofthe editor. This means that a different set of functions will be preloaded and that the commandsentered will affect a different process. For instance, all tactics (see Chapter 8) are accessible from therefiner top loop, which enables a user to experiment with new tactics while having access to a termeditor. In the library top loop, functions for modifying the library itself (such as loading patches orstructural rearrangements) become available. The same functionality will also be provided by thecorresponding process ML top loops, yet without term editing support.

Most users will rarely use the ML top loops, because all standard tasks can be performed byusing the navigator. More experienced users will occasionally use the refiner or editor top loops.The refiner top loop is usually only required for maintenance.

31

4.1 The Library

Nuprl’s library is a mathematical and logical database. All library contents are represented by acommon basic data structure called objects. There are objects for theorems, definitions, inferencerules, tactics and other algorithms, comments and articles, objects that control the visual appear-ance of the mathematical notation, and objects that are used to organize other objects in theoriesand directories. A library table binds objects to identifiers that are used when referring to them.

In contrast to previous releases of Nuprl, all library contents are kept in a persistent libraryand are accessible (modulo permission restrictions) as soon as the Nuprl 5 system is started. Thelibrary roughly operates like a data base: modifications to theories, such as creating, deleting, orediting objects are immediately committed to the library. However, all changes may be undone ifnecessary. A backup of all previous versions of an object is kept until is explicitly destroyed in agarbage collection process, which enables a user to recover previous versions if needed.

The navigator shows information on a segment of the library, which is sometimes called theuser’s work space. The format of the navigator window is discussed in Section 4.2.1. Commandsfor for browsing, searching, editing, and structuring library contents as well as for controlling thenavigator window and are discussed in Section 4.3. In the rest of this section we briefly explain theinternal structure of Nuprl’s library and its relation to the externally visible behavior of Nuprl.

4.1.1 Library Objects

Library objects the common representation of all the contents of Nuprl’s library. They are abstractterms that are associated with a kind , a variety of properties, and possibly with extra data.

Abstract terms provide a uniform data structure for representing almost any kind of formalcontent. They consist of an operator identifier, a list of parameters, and a list of bound subterms(see Chapter 5 for a detailed description). The abstract term syntax makes sure that no predefinedstructure is imposed on the contents of the library and makes parsing unnecessary. All visiblestructure and notation is generated by the editor process, which consults display forms that describehow to “read” an abstract term. The separation between internal representation and externalpresentation makes formal notation extremely flexible and expressive, as it supports an almostarbitrary syntax and allows information to be presented differently depending on context and thepreferences of the users of Nuprl.

The kind of an object is a description of the intended role of the abstract term. It allows mak-ing a distinction between theorems, definitions, tactics, comments, etc., and identifying structureinformation when assembling theories. Currently the following kinds are defined

statement objects contain a proposition and (reference to) a proof. If the proof is complete, theproposition is considered a theorem (or a lemma). Otherwise it is a conjecture. A statementobject for a complete theorem also contains the extract term of the theorem

proof objects contain Nuprl proofs, i.e. directed acyclic graphs of (references to) inference steps,where the conclusion of a child inference is a premise of its parent inference. A proof iscomplete if all its leaves are closed by inferences.

inference objects contain records of actual inference steps. These may consists of instances ofprimitive rules, of tactics executions, or more generally of applications of inference enginesthat are connected to the Nuprl library.

abstraction objects introduce the abstract definition of a new term.

32

display objects define display forms for primitive terms and abstractions.

precedence / lattice objects assign precedences for terms. Precedences control the automaticparenthesization of terms.

code objects contain the code of tactics and other ML code.

rule objects define primitive rules of the object logic.

directory objects define Nuprl theories. They contain lists of references to other objects and areused to add structure to the library.

comment objects contain comments. Comments have no logical significance but can be used tolink formal material to informal text.

term objects are used to represent all library objects whose kind is not specified. Inactive (seebelow) directories are considered term objects.

Statement objects, proofs, and inferences are discussed more in Chapter 6, abstractions in Chap-ter 7.1, display forms and precedences in Chapter 7.2, rules and tactics in Chapter 8, and ML codein Appendix B.

The properties contain status information that is helpful for maintaining the object, trackingdependencies, building justifications etc. The most common properties are

• A liveness bit , indicating whether the object is active and may be referenced to by others.

• A sticky bit , indicating whether the object may be removed from the library table duringgarbage collection. Most objects are not sticky.

• A description of clients to which the object shall be made visible.

• A memnonic name which is commonly used for presenting the object identifier.

• The language in which a code object is programmed.

• A reference environment (Section 4.3.3.1) describing the context of the object.

Extra data are used to collect information that accounts for the validity of an object’s content.Statements include a list of (links to) proof objects as extra data, proofs include a tree of inferences,and inferences include primitive inference steps.

4.1.2 The Library Table

In the library table, objects are also associated with abstract identifiers that are bound to thecontents of the object. All references to objects have to use these abstract identifiers, which in turnare linked to names for objects in a user’s work space.

Object contents are viewed as non-destructive. To change the content of an object, the librarycreates a new object content and rebinds the abstract identifier of the object to the new content. Toremove the object from the library, it simply removes the binding between the abstract identifier andthe content. Object contents are usually not removed from the library except by garbage collection.

All library operations are built from a small collection of primitive operations on object contentsand library tables. These operations are performed by the library’s transaction manager , whichensures that the library is always in a consistent state, and provides mechanisms that make itpossible to recover from failures and system crashes. Library transactions also provide a model forcontrolling the outside access to the actual library contents, which enables the library to certify thecorrectness of its formal theorems and proofs. The primitive library operations are

33

• Binding an object identifier to an object and unbinding an object identifier.

• Looking up object contents bound to an abstract identifier.

• Generating new object identifiers.

• (De)activating an object (changing the liveness bit).

• (Dis)allowing garbage collection for the object (changing the sticky bit).

There are also primitives for creating new object contents from existing object contents and newdata. The most basic primitive creates a new abstract term for the object. Other primitives modifyextra data related to building proof structures by changing the list of proofs linked to a statement,modifying the inference tree of a proof, or changing the inference step of an inference object.

4.1.3 User Interaction with the Library

Nuprl users do not directly interact with the library but through an editor process that communi-cates with one of the library’s application interfaces. The application interface generates the user’swork space from the actual library table and communicates the modifications initiated by the userto the transaction manager, which in turn performs the actual modification to the library. Thismakes it possible to restrict access to certain parts of the library, to hide the abstract representationof data, and to present to the user a consistent view of the library to the user.

In the user’s work space, library objects grouped into directories, or theories. Every object has aunique name and belongs to exactly one theory, although they may be linked to from other theoriesor by a different name within the same theory. Theories can be nested like Unix directories and maydepend on each other. The dependencies of theories on one-another forms a partial order. Withineach theory, objects are ordered linearly.

The Nuprl editor enables users to walk through the directory tree in a visual fashion and toinitiate commands for browsing, searching, editing, and structuring library contents through menubuttons. The editor does not execute these commands directly but sends requests to the library’sapplication interface, which in turn will perform the appropriate actions and sends an updated viewof the client’s work space back to the editor.

For most practical purposes, the distinction between the apparent external behavior of Nuprland the internal operations that are performed to realize this effect is irrelevant. The subsequentexpositions will therefore consider the library to be identical to the directory structure of objectsthat is presented on the screen.

4.2 Nuprl Windows

A complete Nuprl session (see Section 3.3) usually starts with five windows, shown in Figure 4.1: anavigator , an ML top loop, and three windows for the library, refiner, and editor processes.1 Amongthese, the navigator window is the most important one, as most user interaction goes through thenavigator. The ML top loop will only be needed for more advanced tasks that have not (yet) beenintegrated into the navigator. The process windows receive all system output and error messagesand are usually only needed for maintenance and debugging purposes.

1Users may also connect to existing library and refiner processes and only see one Lisp process window.

34

Figure 4.1: Initial Nuprl 5 screen

4.2.1 The Navigator Window

The navigator window , shown on the left of the screen in Figure 4.1, is divided into three majorzones, a command zone, a library statistics zone, and a navigation zone.

The command zone can be found in the upper part of the navigator window, as in mostNuprl 5 windows. It contains several buttons, which are are indicated by a * at the end of a pieceof text. Clicking these buttons with the left mouse button will trigger the action described by thetext and occasionally pop up a template that needs to be filled in. The arrows in the window (↑↑↑↑,↓↓↓↓, . . . , ↑, ↓) also operate as buttons that can be clicked for faster scrolling. The commands linkedto the navigator buttons are described in detail Section 4.3 below.

Many commands require interaction with the user, for instance typing in the name of an objectto be created. The interaction takes place through templates and additional command buttons thatwill appear on top of the command zone, as illustrated in Section 4.3.2.1. The additional buttonand slots created depend on the individual command.

It should be noted that the buttons in the command zone may depend on the directory that iscurrently shown by the navigator. Subsequent snapshots will show, for instance, that the buttonsfor the standard theories include a variety of theory specific buttons that are not relevant for theroot directory. Nuprl allows users to customize the command zone by adding new buttons tailoredfor specific modes of operation in certain theories.

The statistics zone immediately above the display of library contents shows directory statistics.

• The line beginning with Navigator describes the current directory path path, beginning withthe actual theory and going backward to the root of the directory tree.

• The Scroll position field shows the position of the navigation pointer within the currentdirectory. When the edit point , which is marked by a thin vertical line, is in this field thearrow keys on the keyboard can be used to move the through the directory tree.

• The List Scroll field shows the total number of objects in objects in the current theory, theposition of the navigation pointer, and the number of visible objects. The latter us usually10, or less if there are less than 10 objects in the directory, but can be modified using the <>or >< buttons (Table 4.1).

35

The navigation zone in the lower part of the navigator window displays a linear segment of thelibrary, one object per line. From left to right each line contains:

The object kind is described by a string of three or four characters.

STM stands for statement objects, PRF for proof objects, INF for inference objects, ABS forabstractions, DISP for display forms, PRC for precedence objects, CODE for ML code, RULE forinference rules, COM for comments, DIR for directories, and TERM for objects of unspecified kind.

Proof and inference objects are usually not listed in the directory but can be accessed onlythrough the proof editor (Chapter 6.2).

The object status is described by three characters, either T or F.

The first character describes whether the object has been activated and is T in most cases.

The second character is reserved for theorem objects and describes if the theorem has acomplete proof and an extract term. For all other objects it is T.

The third character describes the status of the sticky bit. It is F for most objects.

The object’s name can have arbitrarily many characters and may include blanks.

One of the displayed objects in the library is also marked by an arrow (->) to the left of its kind.We call this distinguished object the navigation pointer (or nav point . All navigator commands willbe executed relatively to this object.

4.2.2 The ML Top Loop Window

The ML Top Loop window , shown on the right bottom of the screen in Figure 4.1, offers a commandinterface to the editor, refiner, and library processes. It is divided into two major zones, a commandbutton zone and a command line zone.

The command button zone in the upper part of the ML Top Loop window is similar to thecommand zone of the navigator. The command buttons, however, do not interact with the librarycontents but affect the behavior of the editor itself. Most importantly, the buttons LIB*, EDD*, andRED* switch between the processes that the ML Top Loop interacts with and change the commandprompt of the command line zone accordingly to M[LIB]>, M[EDD]>, or M[REF]>.

The command line zone between the command line prompt and the double semicolon providesa term editor window for entering ML commands that may contain Nuprl terms as arguments.The latter can be inserted by opening a term slot and entering terms as described in Chapter 5.

4.2.3 The Process Top Loop Windows

The Process Top Loop windows are the windows in which the library, refiner, and editor Lispprocesses were started. Usually they run as ML top loops for interacting with the correspondingprocesses. However, it is also possible to switch into Lisp mode, if low-level operations have to beperformed. The process Top Loops support most of the commands of the corresponding NuprlML top loop, but lack the features for editing Nuprl terms and most of the navigator commands.

These windows should only be used for maintenance and debugging purposes. It is recommendedto run them within an emacs shell to have some text editing support.

36

4.3 Library Commands

Most library commands are best executed from the navigator may also be invoked from the ML toploop (see Section 4.4). In this section we will describe the usual navigator operation and mentionthe corresponding commands.

Many commands are initiated by clicking the left mouse button on one of the predefined menubuttons in the navigator’s command zone. Often this will pop up a template containing one orseveral slots into which the user has to enter text or terms. When issuing commands, pressingcertain key sequences will have the following effects.

• The return key | closes a slot and moves to the next empty slot. If all slots have been filled,it highlights the completed command. Pressing | again then executes the command .

• The tabulator key | !| usually cancels a command.• The space key spc moves the cursor back into the navigation zone but leaves the template

open. This is helpful for moving objects or link objects in different theories.• As spc is used for the above action, blanks are inserted into a text slot by pressing 〈S- spc 〉.• 〈C- 〉 is used to undo an operation (on a fairly fine level)〈C-+〉 is used to redo an undone operation.

• Pressing the left mouse button left usually sets the point to that location. Pressing leftwhile over a menu command button executes the corresponding command.

• Pressing the middle mouse button middle usually raises the display form of a term or thecode object containing the definition of an ML function. Within the navigation zone, it opensthe corresponding object.

• Pressing the right mouse button middle raises the abstraction of an object, if there is one.

These bindings are also valid in many other editing contexts.

4.3.1 Browsing the Library

To browse the library , a user may move a navigation pointer through the current directory by usingarrow keys, the mouse, or clicking on one of the arrow buttons ↑↑↑↑, ↓↓↓↓, . . . , ↑, ↓. To move intoa directory or to open an object for editing, one uses the right arrow key (or middle-clicks on itwith the mouse), to move out of a directory, one moves the navigation pointer to the left. Thereare also emacs like key bindings to substitute for the arrow keys and buttons for changing thenumber of visible objects, or screen size. Table 4.1 lists all the key bindings and buttons for movingthrough the navigator window and manipulating its size. Users may customize these bindings intheir mykeys.macro file (see Chapter 3.2.2).

4.3.1.1 Viewing and Editing Objects

In order to view or edit an object, one moves the navigation pointer to it and then opens it usingthe right arrow (or middle ). If the object is not already being viewed, this will pop up a newwindow and open the appropriate editor: a proof editor (Chapter 6.2) is used on theorem objects,while the term editor (Chapter 5) is used for all other objects.

Abstractions and display forms of an abstract term can also be opened when an instance of theterm is visible in a term editor. In this case one may click on the term with middle to view thedisplay form and right to view the abstraction. Alternatively one may position the term cursorat the term and type 〈C-X〉df or 〈C-X〉ab, respectively. Chapter 5.7 gives a detailed description ofthese term editor utilities.

37

Key Button↓ 〈C-n〉 move navigation pointer one step down〈C-↓〉 move navigation pointer 5 steps down〈C-M-↓〉〈C-v〉 move navigation pointer 10 steps down

↓↓↓ move navigation pointer one screen down↓↓↓↓ move navigation pointer to bottom

↑ 〈C-p〉 move navigation pointer one step up〈C-↑〉 move navigation pointer 5 steps up〈C-M-↑〉〈M-v〉 move navigation pointer 10 steps up

↑↑↑ move navigation pointer one screen up↑↑↑↑ move navigation pointer to top

left move navigation pointer to mouse point→ 〈C-f〉 open object at navigation pointermiddle open object at mouse point← 〈C-b〉 move navigation pointer to next higher directory

<> increase screen size by 10>< reduce screen size by 10

Table 4.1: Navigator Motion Commands

Objects can also be viewed by typing the command xview namey into the editor ML top loop,where name is a token indicating the name of the new object. The view command was the standardmethod for viewing objects in the predecessors of Nuprl 5. Its use in Nuprl 5 is discouraged, asthe command is ambiguous if the same name use used for multiple objects.

4.3.1.2 Searching for Objects

The navigator provides a utility for a pattern-based search for object names in the library. Namesearch is initiated by clicking the NameSearch* button in the navigator’s command zone, which willcreate a search command zone on top of the current command zone and place the edit point intoa [pattern] slot.

After entering a text string into the pattern slot, a user types | start the search for the nextobject whose name contains the entered string. By default, the search proceeds forward beginningat root of the library directory tree. Typing | again will search for the next matching name, etc.

The search mechanism can be modified by using the additional buttons of the search commandzone. These buttons have the following effects.

• Hide*: Hide the search command zone by iconifying it to a button Search#.• Backward*: Change the default direction to backward search and search for the next match.• Forward*: Change the default direction to forward search and search for the next match.• Global*: Search within the entire library• Tree*: Restrict search to the subtree beginning in the current directory• List*: Restrict search to the list of objects in the current directory• PreviousPattern*: Replace the current search pattern by the one previously entered. This

pattern may be modified but the modified pattern will not be stored in the list of patterns• NextPattern*: Replace the current search pattern by the one entered immediately after it,

if there is one.• Reset*: Replace the pattern by an empty [pattern] slot.• Cancel*: End the search and remove the search command zone.

38

- TERM: NavigatorHide* Backward* Forward* Global* Tree* List*PreviousPattern* NextPattern* Reset* Cancel*(* jumps to next matching name in library *)

Search Forward : Pattern" [pattern]Searching entire lib.!Void()

----------------------------------------MkTHY* OpenThy* CloseThy* ExportThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*

Mill* ObidCollector* NameSearch* PathStack* RaiseTopLoops*PrintObjTerm* PrintObj* MkThyDocObj* ProofHelp* ProofStats* showRefEnvs* FixRefEnvs*CpObj* reNameObj* EditProperty* SaveObj* RmLink* MkLink* RmGroup*

ShowRefenv* SetRefenvSibling* SetRefenvUsing* SetRefenv* ProveRR* SetInOBJ*MkTHM* MkML* AddDef* AddRecDef* AddRecMod* AddDefDisp* AbReduce* NavAtAp*Act* DeAct* MkThyDir* RmThyObj* MvThyObj*

↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><

Navigator: [num thy 1; standard; theories]

Scroll position : 0

List Scroll : Total 159, Point 0, Visible : 01-----------------------------------------------> CODE TTF RE init num thy 1

COM TTF num thy 1 beginCOM TTF num thy 1 summaryCOM TTF num thy 1 introDISP TTF divides dfABS TTF dividesSTM TTF divides wfSTM TTF comb for divides wfSTM TTF zero divs only zeroSTM TTF one divs any

----------------------------------------------

- TERM: NavigatorHide* Backward* Forward* Global* Tree* List*PreviousPattern* NextPattern* Reset* Cancel*(* jumps to next matching name in library *)

Search Forward : Pattern" divides$Searching entire lib.4218 divides




↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><


Scroll position : 5


CODE TTF RE init num thy 1COM TTF num thy 1 beginCOM TTF num thy 1 summaryCOM TTF num thy 1 introDISP TTF divides df

-> ABS TTF dividesSTM TTF divides wfSTM TTF comb for divides wfSTM TTF zero divs only zeroSTM TTF one divs any

----------------------------------------------

Figure 4.2: Pattern-based name search

Currently, search patterns have to be text strings that can match either a substring of anobject’s name, its beginning, or its end. To search for the beginning of names, one simply adds acaret (^) before string, to search for the end of names one appends a dollar symbol ($) to its end.

For instance, entering xdividesy into the pattern slot on the left side of Figure 4.2 searchesfor the object in the library whose name contains the string divides. This includes divides df,divides, divides wf, comb for divides wf, etc. Entering x dividesy searches only for objects,whose name begins with divides, which excludes comb for divides wf. Entering xdivides$y, asshown on the right side of Figure 4.2, searches only for objects, whose name ends with divides,and entering x divides$y searches for all objects named divides.

4.3.1.3 Advanced Motion: Using Path Stacks

To enable users to jump between commonly used positions in the directory tree, the navigatorprovides a path stack utility. Clicking the PathStack* button will which will create a path stackcommand zone on top of the current command zone and store the current position of the navigationpointer in the path stack. A user may add additional positions to the path stack and jump backto any position stored in it using the additional buttons of the path stack command zone. Thesebuttons have the following effects.

• Hide*: Hide the path stack command zone by iconifying it to a button PathStack# (see theright of Figure 4.3). This is usually a good idea if one works with several directories at thesame time but doesn’t jump very often.

• Yank*: Jump to the position on top of the path stack.• Rot&Yank*: Rotate the positions in the path stack, moving the top position to the bottom,

and jump to the position that is now on top.• Push*: Add the current position of the navigation pointer on top of the path stack.• Pop*: Remove the position on top of the path stack.• Swap&Yank*: Swap the two positions on top of the path stack and jump to the position that

is now on top.

39

- TERM: NavigatorHide* Yank* Rot&Yank* Push* Pop* Swap&Yank* Swap* Rot* RevRot* CpLink* Cancel*

divides; num thy 1; standard; theories

----------------------------------------

MkTHY* OpenThy* CloseThy* ExportThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*



↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><


Scroll position : 5




----------------------------------------------

- TERM: NavigatorPathStack#




↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><


Scroll position : 5




----------------------------------------------

Figure 4.3: Path stack command zone

• Swap*: Swap the two positions on top of the path stack.• Rot*: Rotate the positions in the path stack, moving the top position to the bottom.• RevRot*: Rotate the positions in the path stack, moving the bottom position to the top .• CpLink*: Insert a link (Section 4.3.2.5) to the current position of the navigation pointer

immediately below the object that is currently on top of the path stack. Links cannot beinserted into the same where the object resides.

• Cancel*: Close the path stack and remove the path stack command zone.

4.3.2 Operations on objects

4.3.2.1 Creating Objects

Objects are created by describing their name, their kind, and the position where they shall beinserted into the library. Usually, this is done interactively by clicking the MkObj* command button,which will open two templates on top of the current command zone, into which a user may enterthe name and kind of a new object, and place the edit point in the name slot, as shown on the leftof Figure 4.4.

After the name and the kind has been entered into the corresponding slots, a user has toclick the OK* button (or type | twice), which will close the new object templates and placethe corresponding object into the current directory immediately after the navigation pointer. Theobject will have the status FFF and no content assigned to it yet.

The name of an object is case sensitive and may contain blanks (enter 〈S- spc 〉 to create them)and other special characters. The kind is not case sensitive but is usually displayed in capitals.Typing not over and | stm | | after clicking MkObj* in the above context, for instance, leads tothe result shown on the right of Figure 4.4.

Nuprl also provides commands and buttons for creating objects of a particular kind. They canbe used instead of the more general command, whose button is not shown in most user theories.

Clicking the command button MkTHM* creates a statement object and places it into the currentdirectory immediately after the navigation pointer. In the interactive version, one only has to enter

40

new object : [name] [kind]

(* creates an object in the current directory *)




↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><


Scroll position : 0


----------------------------------------------

- TERM: NavigatorMkTHY* OpenThy* CloseThy* ExportThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*



↑↑↑↑ ↑↑↑ ↑↑ ↑ ← <>

↓↓↓↓ ↓↓↓ ↓↓ ↓ → ><


Scroll position : 0


Figure 4.4: Creating Objects: Initial template and resulting update to the library

the name of the theorem. In a similar way MkML* creates a new code object, MkDir* creates adirectory object, and MkThyDir* creates a directory object within a theory (see Section 4.3.3.2).

The command button MkTHY* creates a new theory within the current directory. Theories aresimilar to directories, but in addition contain code objects for initializing their reference environ-ments. We will discuss them separately in Section 4.3.3.1.

AddDefDisp* creates a display form for a given abstraction. If the navigation pointer is at anabstraction with name absname, then clicking the command button AddDefDisp* will create adisplay form object named absname df and places it immediately after the the abstraction object.No new object will be created if an object named absname df already exists. Clicking AddDefDisp*while the nav point is not at an abstraction will result in an error.

Currently there are no special command buttons for creating comments, inference rules, orprecedence objects. The command for creating abstractions has been subsumed by the mechanismfor creating definitions, which is described in Section 4.3.2.2 below.

Objects can also be created by typing the command xdyn mkobj kind position directory nameyinto the editor ML top loop, where

• kind is a token indicating the object’s kind.

• position is a token indicating the object after which the new object shall be inserted. Theempty token, null token, is used to describe a position in an empty directory.

• directory is an object identifier indicating the directory in which the new object shall beplaced. To create this identifiers, one has to mark the directory object by clicking on it, andyank the corresponding term into the editor top loop by entering 〈C-y〉. The term will usuallybe displayed as Obid: directory-name . To convert this term into an object identifier onehas to apply the ML function ioid.

• name is a token indicating the name of the new object.

Thus, to create the theorem not over and with an editor command instead of using the interactivecommand initiated by MkObj* one could alternatively type

xdyn mkobj ‘stm‘ null token (ioid Obid: kreitz) ‘not over and‘yHowever, it is recommended to use the interactive version of the command.

41

add def : [lhs] ==[rhs]

----------------------------------------




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0





↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 4, Point 0, Visible : 4-----------------------------------------------> STM FFF not over and

DISP TTF exists uni dfABS TTF exists uniSTM TFF exists uni wf

----------------------------------------------

Figure 4.5: Creating Definitions: Initial template and resulting update to the library

4.3.2.2 Creating Definitions

A formal definition adds a new abstract term to the formal language of Nuprl that is defined tobe equal to some already existing term. In Nuprl a formal definition requires the creation of twonew objects: an abstraction, which defines the meaning of the abstract term (see Chapters 7.1),and a display form, which defines its syntactical appearance (see Chapter 7.2). In addition, mostdefinitions are accompanied by a well-formedness theorem, which proves that the newly introducedterm belongs to a certain type and is thus well-formed. The names of these objects follow a certainconvention: if the operator identifier of the abstract term is opid , then the abstraction object isnamed opid , the display form opid df, and the well-formedness theorem opid wf.2

The AddDef* command button provides a convenient way to generate these three objects and apart of their content. Clicking AddDef* button will open a template for defining the abstract term.

To enter the abstract term on the left hand side of the definition, one has to provide its objectidentifier , its parameters, and a list of its subterms together with the variables to be bound inthese subterms. Ways to create new terms with the term-editor are described in Sections 5.4.4 and5.4.5. The term for the right hand side of the definition is entered in the usual structural top-downfashion of the term-editor as explained in Section 5.4.

Closing the add def templates, creates a display form object opid df, an abstraction objectopid , and a statement object opid wf, where opid is the object identifier of the new abstract term.The abstraction object contains exactly the left and right hand sides of the definition as enteredinto the add def templates. The display form object contains a display form for the abstract termthat makes the term look like the left hand side of the definition but can easily be modified. Thestatement object is empty, as there are no defaults for initiating a well-formedness theorem. Allthree objects will be placed immediately after the navigation pointer, which remains at its currentposition, and are already activated.

Entering xexists uni(T; x.P[x])y and x∃x:T. P[x] ∧ (∀y:T. P[y] ⇒ y=x ∈T)y into theadd def templates, for instance, creates the three objects shown on the right of Figure 4.5.

Definitions can also be created with the command xlib thy add def lhs rhs directory positiony,where lhs is the left hand side of the definition, rhs its right hand side, directory the object identifier

2In Nuprl 4 this convention made it easier for tactics to access the well-formedness theorems corresponding to acertain abstraction. Although Nuprl 5 offers a more general method for making objects depend on each other, wepreserve the convention for compatibility reasons.

42

↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 4


STM FFF not over andDISP TTF exists uni dfABS TTF exists uniSTM TFF exists uni wf

-> CODE TTF listsel create----------------------------------------------

- ABS: listsel createlistsel(l;i)==r if i ≤ 0

then hd(l)else listsel(tl(l);i - 1)fi




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 6


STM FFF not over andDISP TTF exists uni dfABS TTF exists uniSTM TFF exists uni wfCODE TTF listsel createDISP TTF listsel df

-> ABS FFF listselCODE FFF listsel RecUnfoldFold convSTM TFF listsel wfTERM FFF .recall listsel

----------------------------------------------

- ABS: listsellistsel(l;i)==Y(λlistsel,l,i.if i ≤ 0then hd(l)else listsel tl(l) (i - 1)fi )

li

Figure 4.6: Creating Recursive Definitions: code object and created definition objects

of the directory in which the new object shall be placed, and position the name of the object afterwhich the definition shall be inserted. Thus, to create the above three objects within the ML toploop one could type

lib thy add def pexists uni(T; x.P[x])q p∃x:T. P[x] ∧ (∀y:T. P[y] ⇒ y=x ∈T)q

(ioid Obid: kreitz) ‘not over and‘

The refiner’s def utility provides a more advanced method for creating definitions and theirwell-formedness theorems. This method, however, is less easy to use.

The AddDef* mechanism is sufficient for creating non-recursive extensions of Nuprl’s objectlanguage. For integers, lists, and recursive data types, Nuprl’s type theory also provides expres-sions that describe primitive recursion over these types (see Appendix ch:app-type-theory). Theterms pind(u,x.fx; s; base ,y.fy)tq, plist ind(s; base ; x,l,fxl.t)

q, and plet∗ f(x)= t in f(e)q,however, are insufficient for describing more general forms of recursion and most users find themsomewhat awkward to use.

The definition for selecting the i-th element of a list l, for instance, would typically be expressedas xl[i] ≡ if i≤0 then hd(l) else tl(l)[i-1] fiy. This definition, however, involves a si-multaneous recursion over both the list l and the index i. Although it is possible to express thisin a primitive recursive fashion,3 a direct representation of the above definition would certainlybe more natural. Nuprl therefore provides a mechanism for a controlled introduction of generalrecursive definitions using the Y combinator. This mechanism proceeds in two separate phases.

In the first phase, clicking the AddRecDef* command button will create a code object thatcontains the ML function add rec def at, which will later build the actual definition. For the sakeof comprehensibility, the function is encapsulated in a formal definition and initially appears astemplate x[lhs] ==r [rhs]y. A user has to provide the left hand side and the right hand side ofthe recursive definition as arguments to this function. A third argument two the function is thelocation, where the definition is to be placed. To make sure that the function does not executeevery time the object is viewed and closed again, this third argument is initially set to inl().

After the user has entered the left hand side and the right hand side of the recursive defi-nition and closed the code object, clicking the NavAtAp* button (Section 4.3.4.3) will create the

3One can bypass the simultaneous recursion by using the listind operator to define a function on indices, which thenis applied to i: l[i] ≡ (list ind(l;λj.0; hd,tl,jth-of-tl.λj.if j≤0 then hd else jth-of-tl(i-1) fi))(i).

43

actual definition by executing the function add rec def at with the third argument substitutedby the location of the code object. This results in 5 additional objects: an abstraction, a displayform, a statement object for the well-formedness theorem, a code object that updates the tac-tics for unfolding and folding definitions, and a recall object, which allows removing all the newlycreated objects with the RmGroup* button (Section 4.3.2.6). For example, entering xlistsel(l;i)yand xif i≤0 then hd(l) else listsel(tl(l);i-1y into the templates of the recursive definitionobject listsel ml creates the objects shown on the right of Figure 4.6.

Recursive definitions can also be created with the commandxadd rec def at lhs rhs (inr(directory, position))y,

where lhs is the left hand side of the definition, rhs its right hand side, directory the object identifierof the directory in which the new object shall be placed, and position the name of the object afterwhich the definition shall be inserted. Thus, to create the above five objects within the ML toploop one could type

add rec def at plistsel(l;i)q pif i≤0 then hd(l) else listsel(tl(l);i-1q

(inr ((ioid Obid: kreitz), ‘exists uni wf‘))

This command has to be run in refiner mode and will not create the initial code object listsel ml.Again, there is a more advanced version of this command.

Besides creating abstractions, display forms, and well-formedness theorems, introducing a defi-nition may also require updating the tactics that rely on folding and unfolding definitions. As onlythe user can decide which abstractions should be unfolded automatically and which ones shouldn’t,Nuprl provides a mechanism for updating the Reduce tactic (see Section 8.6.2) on demand.

Clicking the AbReduce* command button will open two templates on top of the command zone.The first is a token template into which a user may enter the name of a new conversion to be added toReduce. The second is a term describing the left hand side of that conversion. Upon clicking OK* theright hand side of the conversion will be computed by applying xUnfoldsC opid ANDTHENC ReduceCy(see Section 8.9.3) to this term and the resulting macro-conversion will be added to the list ofconversions used by the tactic Reduce.

4.3.2.3 Creating Modules

Nuprl provides support for defining module types, which are useful for defining abstract data typesand algebraic classes. Module types are essentially (dependent) record types, where the type of eachfield can depend on the value of previous fields, and are allowed to have parameters. For instance,an abstract data type for stacks may use the type of stack elements as a parameter. Module typesare currently implemented using Nuprl’s Σ type.4 A predefined mechanism helps with settingup new module type definitions, adding projection functions as module component selectors, andupdating the AbReduce tactic (Section 8.6.2) to recognize applications of these functions. Likeadding recursive definitions it proceeds in two phases.

In the first phase, clicking the AddRecMod* command button will create a code object that con-tains the ML function create rec module at, which will later build the actual module. Currently,the object contains the function call in its raw from, providing a few slots for the user to describethe module.

4A more elegant approach is implementing record types as dependent function types on a type of labels. Thisapproach does not require creating definitions that map field selectors onto projection functions, but is somewhatmore complex theoretically and not yet supported by the existing tactics collection.

44

↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 10


STM FFF not over andDISP TTF exists uni dfABS TTF exists uniSTM TFF exists uni wfCODE TTF listsel createDISP TTF listsel dfABS FFF listselCODE FFF listsel RecUnfoldFold convSTM TFF listsel wfTERM FFF .recall listsel

-> CODE TTF stack createDIR FFF mk stack object directory

----------------------------------------------

- ABS: stack create((create rec module at‘Stacks‘ % Name of the module type %‘mk stack‘ % constructor for module elements %‘st‘ % prefix to disambiguate definition names%[tok to var ‘T‘, U;tok to var ‘default‘, T ] % module parameters %[tok to var ‘STACK‘, U;tok to var ‘empty‘, STACK;tok to var ‘push‘, T → STACK → STACK;tok to var ‘pop‘, STACK → (T × STACK) ] % module fields %U % Universe of the module %·)

inl())·




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><

Navigator: [mk stack object directory; kreitz; user; theories]

Scroll position : 0

List Scroll : Total 27, Point 0, Visible : 27-----------------------------------------------> COM FFF mk stack start

DISP TTF Stacks dfABS TTF StacksDISP TTF st STACK dfABS TTF st STACKDISP TTF st empty dfABS TTF st emptyDISP TTF st push dfABS TTF st pushDISP TTF st pop dfABS TTF st popCODE FFF Stacks FoldUnfold updateCODE FFF mk stack AbReduce conv defsCODE FFF mk stack AbReduce conv updatesSTM TFF Stacks wfSTM TFF st STACK wfSTM TFF st empty wfSTM TFF st push wfSTM TFF st pop wfDISP TTF mk stack dfABS TTF mk stackDISP TTF case mk stack dfABS TTF case mk stackCODE FFF mk stack install patternSTM TFF mk stack wfTERM FFF .recall mk stackCOM FFF mk stack finish

----------------------------------------------

Figure 4.7: Creating Recursive Modules: code object and created directory

• The first token slot contains the name of the module type, e.g. ‘Stacks‘.

• The second token slot contains the name of the constructor that builds modules from theirindividual components.

• The third token slot contains a short name of the module that is prefixed to the namesof the abstractions and display forms defining the module’s field selectors. This prefix wasnecessary in previous releases of Nuprl to disambiguate the names of these definitions buthas become obsolete because of the directory structure introduced in Nuprl 5. It is retainedfor compatibility purposes.

• The fourth slot contains the parameters of the module type and their types, which have tobe given as list of pairs of Nuprl variables and terms.

• The fifth slot contains the fields of the module type, again as a list of pairs of variables andtypes. The type of a field may use the variables declared in the previous fields.

In addition to that, the last two function arguments are already filled in. The type of the moduleis U and the the location, where the module is to be placed, is initially set to inl().

Clicking the NavAtAp* button (Section 4.3.4.3) will create the actual module by executingthe function create rec module at with the last argument substituted by the location of the codeobject. This results in the creation of an object directory for the module that contains definitions forthe module type, projection functions, the module constructor and uniform module decompositionoperator, (unproven) well-formedness theorems, code for updating the AbReduce tactic, a recallobject, and two comment objects that serve as delimiters for the module type definition. Figure 4.7describes a code object for defining an abstract data type of stacks over a type T and the objectdirectory created by it.

45

4.3.2.4 Copying Objects

Copies of existing objects can be created using the the CpObj* command button. This will open atemplate on top of the command zone into which the user may type the name of the object thatwill contain the copy. The current name of the object already occurs in the template, with the editcursor at its beginning. To place a copy into a different directory, a user may leave the commandzone (by pressing spc ), move to the position where the object should be placed, and then click OK*.

Objects may also be copied by typing xcopy object after directory position name obidy intothe editor ML top loop, where directory the object identifier of the directory and position the nameof the object after which the copy shall be placed, name the name of the copy, and obid the objectidentifier of the object to be copied.

4.3.2.5 Links

Links are named references to objects in the library, similar to links or shortcuts in operatingsystems. Unlike copies of objects, different links refer to the same object and changes to the objectwill be visible from wherever it is referenced to. For consistency reasons, a directory may not containduplicate references to the same object.

To create a link, one has to click the MkLink* command button. This will open a templateon top of the command zone into which the user may type the name of the link to the object. Ifthe link is not placed in a different directory (by leaving the command zone and moving into thatdirectory), creating the link will rename the reference to the object but keep its internal name.

Links may also be created by typing xdyn mklink directory position name obid rmdup?y intothe editor ML top loop, where rmdup? is a boolean flag indicating whether or not to removeduplicate links to the same object from the directory. This flag should usually be set to true.

4.3.2.6 Removing Objects and Links

To remove an object in a theory, one simply moves the navigation pointer to it and clicks theRmThyObj* button. This will remove the object from the current directory, but preserve externallinks to it. The same effect can be achieved by typing xlib rm thy obj directory namey into thelibrary ML top loop, where directory object identifier of the directory in which the object to bedeleted resides and name a token describing its name.

Similarly clicking RmLink* will remove a reference to an object from the current directory. Theeffect is almost the same as RmThyObj*, but the command will be executed by the editor insteadof the library and will not immediately affect proof tactics that refer to the object.

Some theories also provide a RmDir* button, which allows to remove a directory and all theobjects contained in it. Since this is a dangerous operation, the user is asked for confirmationto avoid that a directory is wiped out accidentally. Directories can also be removed by typingxdelete tree directory namey into the editor ML top loop. In this case there the command isexecuted without asking for confirmation.

Some editor commands such as AddRecDef* and AddRecMod* create groups of objects related toeach other. Nuprl offers a convenient method for removing all these objects by a single command.For this purpose one has to position the navigation pointer at the recall object of the group (anobject of the form ‘.recall group-name’) and click the RmGroup* button. This will remove theobjects from the library and update the reference environment (see Section 4.3.3.1) accordingly.

46

4.3.2.7 Moving Objects

Objects may be moved to different locations within the same directory or to locations in otherdirectories. Clicking the MvThyObj* command button will open a template on top of the commandzone into which the user may type the name of the object to be moved. The name of the objectat the navigation pointer already occurs in the template, with the edit cursor at its beginning. Tomove the object to a different location one has to leave the command zone, move to the positionwhere the object should be placed, and then click OK*.

The same effect can be achieved by typing xlib mv thy obj src-dir name dest-dir positiony intothe library ML top loop, where src-dir and dest-dir are the object identifier of the source anddestination directories, name the name of the object to be moved, and position the name of theobject after which the definition shall be inserted.

4.3.2.8 Renaming Objects

Renaming an object involves changing both the object’s internal name (see Section 4.1.1) and theexternal reference to the object. Clicking the reNameObj* command button will open a templateon top of the command zone into which the user may type the new name of the object. Leavingthe command zone while renaming an object is not recommended, as renaming will be applied towhatever object the navigation pointer points to at the time the OK* button is clicked.

The same effect can also be achieved by using the EditProperty* button (Section 4.3.2.10) tochange the object’s name and MkLink* (Section 4.3.2.5) to change the external reference to it.

4.3.2.9 Activating and Deactivating Objects

Usually, a library object is active in the sense that it may be referenced by tactics and other objects.Occasionally, users may want to experiment with alternate versions of a definition or theorem andto prevent tactics from using a particular object without having to remove it from the library. Thiscan be done by changing the liveness bit of the object (see Section 4.1.1), indicated by the firstcharacter of the object’s status information.

To deactivate an object, one moves the navigation pointer to it and clicks the DeAct* com-mand button. To activate it again, one clicks the Act* command button. Notice that deactivatingdirectories converts them into TERM objects and makes their contents (temporarily) inaccessible.Activating a code object will execute its content.

The same effects can be achieved by typing the commandsxlib thy deactivate directory objecty and xlib thy activate directory objecty

into the library ML top loop, where directory the object identifier of the directory of the object tobe (de)activated and object the object identifier of the object itself.

4.3.2.10 Editing Object Properties

In advanced applications, users may want to change some of the properties of an object (seeSection 4.1.1). For instance, when using abstraction objects to represent definitions of the PVSsystem, it makes sense to make them visible to PVS clients but not to the Nuprl refiner. Inrare cases it may be necessary to adjust the reference environment (Section 4.3.3.1) of an object.Therefore, Nuprl provides a simple method for editing the properties of an object directly.

Clicking the EditProperty* command button will open a property command zone for the objectat the navigation pointer on top of the current command zone. It contains a token slot for entering

47

reference environment* NAME* tttt* DESCRIPTION*ReferenceEnvironment* ReadFromLib* RemoveProperty*

!edit property argsnot over and:o, [token]:t([term])----------------------------------------




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 0

List Scroll : Total 4, Point 0, Visible : 4-----------------------------------------------> STM TTF not over and

CODE TTF listsel createCODE TTF stack createDIR TTF mk stack object directory

----------------------------------------------

Figure 4.8: Editing Object Properties

the name of the property (e.g. DESCRIPTION, NAME, or reference environment) and a term slotfor entering the value of that property.

It is not recommended to enter the value of a particular property directly. Instead, one shouldmake use of the command buttons for editing the important object properties that are immediatelyabove the two slots. Each of the buttons in the top row represents a particular property of thecurrent object, which will be inserted into the slots upon clicking the button. These buttons varydepending on the kind of the object.

Clicking the NAME* button, for instance, will insert the token NAME into the token slot andthe term xobject-name:ty into the term slot, where object-name is a token describing the object’sname. Clicking reference environment* will insert the token reference environment into thetoken slot and the term xObid: object-identifiery into the term slot, where object-identifier is theidentifier of the object that is immediately before the current object in the ephemeral referenceenvironment chain. A user may now edit these properties by modifying the corresponding terms.

The buttons in the bottom row are the same for all objects. Clicking ReferenceEnvironment*inserts the reference environment property into the two slots, ReadFromLib* inserts the storedvalue of the current property back into the term slot, and RemoveProperty* removes that propertyfrom the object. Properties, once removed, can only be re-inserted explicitly.

Editing object properties should only be done by advanced users. Most users will rarely find itnecessary to edit the properties of an object.

4.3.2.11 Saving Objects

During the development of formal theories, users may occasionally want to save the current versionof an object before modifying it. Clicking the SaveObj* command button will copy the objectat the navigation pointer to a subdirectory .save of the current directory. The internal name ofthe object will be preserved, which makes it easier to move the saved version back into its oldlocation, and the reference to it will include a time stamp in its name. If the subdirectory .savedoesn’t exist yet, it will be created. The same effect can be achieved by typing the commandxcopy to save directory namey into the library ML top loop.

48

4.3.2.12 Printing Objects

Often users like to create print representations of objects in order to document their formal theorieson paper or on the web. Clicking the PrintObj* command button will create a print representationof the object at the navigation pointer and write it into a file ˜/nuprlprint/name obj.prl. Thisfile can be inspected with any 8bit capable editor that has the Nuprl fonts loaded. It will alsocreate a LATEX-version and write it to ˜/nuprlprint/name obj.tex. The directory ˜/nuprlprintmust already exist. Otherwise clicking the PrintObj* button will result in an error. The same effectcan be achieved by typing the command xprint an object objecty into the editor ML top loop.

In the conversion to LATEX PrintObj* is capable of interpreting LATEX syntax that occurs in acomment object and to re-interpret display forms as LATEX macros, which allows for a more eleganttype setting. In contrast to that, clicking the PrintObjTerm* command button will print the objectcontents as a single term without interpreting them further.

4.3.2.13 Commenting Objects

In addition to providing comment objects for an online –COM: not over and commentComments for object not over and:

Prefix Comments :--------

--------

Suffix Comments :--------

--------

Figure 4.9: Commenting an object

documentation of formal material, Nuprl offers users the op-portunity to produce formal articles that blend informal textwith direct quotations of the formal material. For this purposeit allows the user to create comment objects that are linked toa specific object.

Clicking the commentObj* button will create this objectfor the object at the navigation pointer and place it in a sub-directory .comments, which will be created, if it does not existyet. The object contains a template that allows the user to enter comments that will be printedbefore (prefix comments) and after (suffix comments) the object when the theory containing theobject is printed (Section 4.3.3.8).

4.3.2.14 Proof Help

Nuprl offers users a minimal form of online help for the development of proofs. Clicking theProofHelp* button will open a comment object that describes the most important (standard) keybindings for the proof editor. Further online documentation will be added in the future.

Clicking the ProofStats* button while the navigator points to a statement object will pop upa window displaying some statistics about the proof of that statement. This can also be achievedby typing the command xshow stm stats objecty into the editor ML top loop.

4.3.3 Theory Operations

Theories are groups of objects that describe the definitions, theorems, and specific methods of rea-soning of a mathematical or computational discipline. Formally they are organized like directories,but they contain objects describing their dependencies on other theories and they can also be as-sociated with different sets of command buttons. For structuring purposes theories may be brokeninto sub-theories. However, these have to be ordinary directories instead of theory objects, sinceotherwise the dependency tracking mechanism may get confused when sub-theories are moved.

49

4.3.3.1 Object Dependencies and Reference Environments

While the notion of correctness of a formal proof is easy to define (see Chapter 6.1), the correctnessof a formal theory depends on the fact that there is no circular chain of lemma references inits proofs. In principle, this could be guaranteed by requiring that a proof may only depend onlemmata that in some linear ordering of the library occur before the proof that refers to them.While keeping a certain discipline in the development of formal theories certainly helps avoidingcircular references, some dependencies are hidden in various reference variables and proof cachesemployed by some of the tactics. In previous releases of Nuprl this fact often led to major problemswhen theories were replayed. Nuprl now supports a dependency checking mechanism that adds alayer of indirection between references and their values and allows greater control over these valueduring the development of formal proofs.

A reference environment (often abbreviated as RefEnv or RE) is an index into a graph of pos-sible values for a set of reference variables. All refinements are parameterized by a reference envi-ronment. Reference environments are generally associated with statement and proof object via areference environment property (see Sections 4.1.1 and 4.3.2.10). Code objects can also have areference environment property to parameterize reference variables during evaluation of the code.The specification of a reference environment consists of:

• an object identifier describing the index being defined• a list of reference environments to inherit from• a list of abstractions to add• a list of lemmas to add• a list of updates consisting of snippets of code that update the value of a reference variable

for the current index. Update code should not itself lookup values of reference variables.

Currently reference environments also contain a list of additions to the code of a code object, amethod used in previous releases of Nuprl. Additions are preserved for compatibility reasons butthey will be phased out in the future.

To contain updates to a reference environment, Nuprl uses code objects that have a!propertyreference environment additions:t(update:t) property. There are three vari-eties of reference environments.

• Static reference environments are ML code objects placed in theory directories that evaluateto a reference environment specification.

• Ephemeral reference environments are computed at refine time by chaining backwards throughreference environment properties of objects until a static reference environment is located.The reference environment specification is then built in a linear depth-first order: it includesthe objects “above” it and all the objects in directories above it.

• Minimal reference environments are partial specifications of reference environments. Insteadof defining an index, they bind an arbitrary temporary index for the scope of some evaluation.The intent is that only objects necessary for a successful evaluation will be listed. A minimalreference environment may be relative to a static one. Thus there are flavors of minimalreference environments. Currently, the following flavors are recognized.

minimal : minimal relative to the empty environment.theories minimal : minimal relative to a set of theories, most commonly the standard theories.relative minimal : minimal relative to a specific theory. This is commonly used while devel-

oping a set of theories.

50

!mkthy args[token]:t(Obid: kreitz)----------------------------------------




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 7


CODE TTF RE init user-> DIR TTF kreitz----------------------------------------------

- CODE: RE init new-theoryMake Reference Environment [RE init new-theory]

Prerequisites : Obid: kreitzAbstractions : !oid consStatements : !oid consAdditions : !oid consUpdates : !oid cons

Figure 4.10: Creating Theories: initial template and generated static reference environment

The presence of static reference environments puts certain restrictions on the nesting of theories.Although in principle it would be possible to have theories be objects within other theories, thereis no reliable method for moving such a theory within a theory directory without making its staticreference environment inconsistent. Conceptually, most sub-theories are not autonomous theoriesin themselves, but only means for structuring a theory into smaller fragments. Placing them insub-directories is more appropriate than opening a new theory. Therefore Nuprl does not allowtheories to contain other theory objects.

4.3.3.2 Creating Theories and Sub-Theories

Theories are created by clicking the MkTHY* command button. This will open a token slot on top ofthe command zone into which a user may enter the name of the theory. Also visible is a reference tothe object after which the theory will be placed. This object will be used for building the referenceenvironment of the theory.

Upon closing the template (by clicking OK* or typing | ) a new directory will be placed imme-diately after the navigation pointer. This directory contains a code object named RE init theory-name, the specification of the static reference environment of the new theory. An example of sucha static reference environment is shown in Figure 4.3.3.2.

Users should not move theory objects or create objects immediately before them, without fixingthe static reference environment, since otherwise the static reference environment of that theorywould be inconsistent with the visible presentation of the library.

To create sub-theories of a theory, one should use the MkThyDir* button instead of MkTHY*.Like MkDir*, this will create an directory within the theory that does not contain a static referenceenvironment. In addition to that, it adds a theory property to the directory object, which will helpother commands maintain the reference environment chain within the theory.

Theories can also be created by typing xlib mkthy preREs directory position namey into theeditor ML top loop, where preREs is a list of object identifiers describing the reference environ-ments on which the theory depends, directory is an object identifier of the directory in which thetheory shall be placed, position a token describing the object after which it shall be positioned,and name a token describing its name. Theories directories can be created with the commandxlib mkthy dir directory position namey.

51

4.3.3.3 Changing Theory Modes

Depending on the reference environments (Section 4.3.3.1) of its objects, a theory can be in one oftwo modes.

• open & ephemeral , where all theory objects will have ephemeral reference environments, or

• closed & minimal , where all theory objects have some flavor of minimal reference environmentsand ephemeral reference environments are removed. Instead, the theory has a final referenceenvironment object that summarizes the contents of the entire theory.

In addition to that, theories can also be static (or explicit), which means that all theory objectshave static reference environments. This mode, however, is only needed to maintain older theoriesthat have not yet migrated to be minimal or ephemeral. It will be phased out in the future.

When a theory is created with MkTHY*, an initial static reference environment is created andtheory will be open and ephemeral until it is explicitly closed. The following command buttons canbe used to change the mode of a theory.

• CloseThy* closes a theory by creating a finish reference environment named RE final theory-name, which summarizes the contents of the theory.

• OpenThy* opens or re-opens a theory by rebuilding its initial reference environment andresetting its ephemeral reference environment property.

• MinTHY* will make a theory (relative) minimal and modify the available command buttonsfor the theory.

• EphTHY* will make a theory ephemeral by rechaining ephemeral reference environments andmodify buttons for the theory.

• ExTHY* will make a theory explicit and modify the available command buttons for the theory.

The above commands can also be executed by typingxclose theory theoryy,xopen theory theoryy,xset theory relative minimal theoryy,xset theory ephemeral theoryy, orxset theory explicit theoryy

into the library ML top loop, where theory is the object identifier of the current theory.

4.3.3.4 Examining and Modifying Reference Environments

To examine the current set of reference environments, one has to click the showRefEnvs* commandbutton. This will pop up a new window containing a list if all existing static reference environments.Clicking on one of the terms with middle (or moving the cursor to it and pressing the right arrowkey) will open the corresponding object, which shows the reference environment specification as anassociation list of reference variables and indices. Clicking middle on the on a variable/index pairwill pop-up some indication of the data that is bound to that variable by that index.

Reference environments may also be examined by typing xshow ref environments ()y into theeditor ML top loop.

The normal methods for creating and manipulating theory objects will maintain the chain ofephemeral reference environments in a theory. Occasionally this chain may get corrupted whenobjects are moved or deleted. To fix this problem, a user has to click the FixRefEnvs* button. Thiswill rechaining all the objects in a theory and thus update the ephemeral reference environment.

52

Reference environments may also be fixed by typing xreset ephemeral refenvs directoryy intothe library ML top loop, where directory the object identifier of the theory to be rechained.

In an open theory, users may insert static reference environments by clicking the mkRefEnv*command button. This will create an object named RE summary theory-name index that summa-rizes all theory objects up to the current one and places it immediately after the current object.

Static reference environments are inserted into a theory mostly for debugging purposes. Theyenable a user to set the reference environment register (see Section 4.3.3.5 below) to a specificenvironment and to replay proofs in that environment to analyze dependencies in the proof.

Static reference environments may also be inserted by typing the commandxadd refenv summary directory positiony into the library ML top loop, where position is a tokendescribing the object up to which the theory should be summarized.

4.3.3.5 The Reference Environment Register

The reference environment register (briefly RR) is a global variable in the editor containing areference environment index. The it is used as an implicit parameter in the some of the navigatorcommands and also when evaluating refiner top loop commands. The following command buttonscan be used to examine or change the contents of the reference environment register.

• ShowRefEnv* shows the contents of reference environment register. This will be the emptyterm until one of the commands below has been applied.

• SetRefenvSibling* sets the reference environment register to the reference environment usedby the current object.

• SetRefenvUsing* sets the reference environment register to the least reference environmentthat contains the current object. For ephemeral reference environments this command will bephased out, since an object is the least reference environment containing itself.

• SetRefenv* sets the reference environment register to the current object.• ProveRR* attempts to replay the proof of the statement at the navigation pointer using the

reference environment register instead of the object’s reference environment. It allows a userto make a copy of a proof experiment without modifying the original proof. The proof willbe attempted asynchronously, so the command will return immediately. When it finishes itwill pop-up a window containing the object identifier of the proof generated. Clicking on theobject identifier with middle will pop up the proof.

Note that the new proof is not linked to the statement. It will remain unlinked if the proofis closed with 〈C-q〉. If instead one uses 〈C-z〉 to exit, the proof will be prepended to thestatement’s proof list (see Chapter 6).

• SetInObj* sets the reference environment register to the reference environment propertyof the first proof of the statement at the navigation pointer.

The above commands can also be executed by typingxshow refenv register ()y,xset refenv register sibling termy,xset refenv register using termy,xset refenv register termy,xprove using refenv register termy, orxset re in first prf termy

into the editor ML top loop, where term is a term describing the directory and the position of thecurrent object.

53

4.3.3.6 Checking Theories

Although Nuprl proof environment guarantees that - TERM: check kreitz controlStop* Start* Exit* Reset* NumRemaining* Abort*

Status : check kreitz

Active ? FSave status ? FMaxPend 1

Bot Function: check theory bot completion

Figure 4.11: Checking a theory

proofs are correct wrt. the available set of rules, refiners, andlemmata at the time the proof is being constructed, a storedproof may become invalid if the rules and lemmata on whichit depends are removed or modified afterwards. The Nuprllibrary provides a certification mechanism that accounts forthe validity of its contents. However, it would be computa-tionally infeasible to recheck these certificates whenever alibrary object is modified. Instead, the system provides a utility that enables users to explicitlycheck the consistency of their theories by replay the proofs in a controlled fashion.

To do so, one has to move the navigation pointer to the root of the theory and click theChkThy* command button. This will cause the system to accumulate the object identifiers of theproofs of all the statements in the final reference environment of the theory and then pop up acontrol window for initiating the checks (Figure 4.3.3.6). Since ChkThy* has to determine the finalreference environment, it will fail if the theory lacks an initial static reference environment. Thecommand buttons in the control window have the following effects.

• Stop* completes the replay of the current proof and then stops the check.

• Start* starts the replay of the (remaining) proofs in the theory. (Intermediate) results willbe displayed in a separate window.

• Exit* close the command window. As proofs are replayed asynchronously this will not stopthe ongoing checks.

• Reset* resets the list of remaining proofs to be checked to the initial list of proofs.

• NumRemaining* displays the remaining number of proofs to be checked.

• Abort* aborts the ongoing check and resets the list of remaining proofs to be checked.Users may also modify the parameters of the check mechanism. The number after MaxPend

indicates how many should maximally be used for checking proofs. Using more than one refiner ishelpful when checking large theories but it takes these refiners away from other tasks. The Savestatus ? bit determines whether to save the status of the checking mechanism when the commandwindow is saved. The Active ? bit and the check function after Bot Function: should not bechanged by a user.

Instead of clicking the ChkThy* command button, one may also type the commandxbuild check theory bot directoryy into the editor ML top loop. Although the individual checkcommands could be issued from the top loop as well, it is not advisable to do so.

Nuprl provides a few variations of the ChkThy* command.• ChkAllThys* initiates a check for all the theories in the library. This is the same as clickingChkThy* with the navigation pointer at the root of the theories directory.

• ChkOpenThy* accumulates all the proofs in the theory instead of only proofs of statements inthe final reference environment. This command can also be used tom check sub theories, asit does not attempt to build the final reference environment of a theory.

• ChkMinThy* initiates a check with a minimal reference environment. Users have to enter one ofthe flavors reference environment minimal, reference environment theories minimal,or reference environment relative minimal into a token slot that appears above the com-mand zone.

54

4.3.3.7 Exporting and Importing Theories

A capability for exporting and importing theories is important for moving theories between differentlibraries in a controlled fashion. Nuprl exports theories into files containing raw library data andrebuilds objects from these files when importing theories.

To export a theory one has to click the ExportTHY* command button with the navigationpointer at the theory object. This will collect all the objects in the theory and write them into afile ˜/nuprlpatch/theory-name theory.trm.

Alternatively, a user may type the command xdump theory true (directory, theory-object)yinto the editor ML top loop, where directory is the object identifier of the directory where thetheory resides and theory-object the object identifier of the theory itself.

To import a theory from a file, one has to enter the command xreplace objects path-nameyinto the editor ML top loop, where path-name is the complete path name of the theory’s dump file.This will create a directory containing all the objects of the dumped theory and place it at the samelocation in the user’s work space. If the theory already exists, the objects of the dumped theorywill be added to the theory directory. Objects will not be overwritten: in case of name clashes, theexisting theory object will be renamed if its content is different from the new theory object. If thetwo objects are identical, the new object will be ignored.

4.3.3.8 Printing Theories

To print the contents of an entire theory, a user may either click the PrintThyShort* or thePrintThyLong* command buttons. This will create a print representation of the objectsin the theory at the navigation pointer and write it into a file ˜/nuprlprint/name.prl (or˜/nuprlprint/name long.prl). It will also create a LATEX-presentation of the theory and write itto ˜/nuprlprint/name.tex (or ˜/nuprlprint/name long.tex).

PrintThyShort* provides a less detailed presentation of the theory, which omits the proofsof a theorem and only includes the extract term if a theorem is complete. In contrast to thatPrintThyLong* adds the complete proof to the presentation of a theorem. Users who are onlyinterested in a listing of all the object names in a theory may do so by clicking the PrintObj*button (Section 4.3.2.12).

Theories can also be printed by typing the command xshort print theory theory-objecty orxor print theory theory-objecty into the editor ML top loop, where theory-object is the objectidentifier of the theory to be printed.

4.3.3.9 Creating Theory Documentation

The commands for printing theories only create listings of theory contents in linear order, possiblyaugmented by comment objects as described in Section 4.3.2.13. In addition to these, Nuprlprovides a more flexible mechanism for creating formal documentation that enables a user to insert(references to) formal objects into informal text.

Clicking the MkThyDocObj* command button creates a comment object thy doc-timestampthat contains pointers to all the statement and abstraction objects in the current theory. Usersmay then edit the object to write formal articles by adding text and rearranging and duplicatingthe existing pointers. Printing the object with PrintObj* will then create a LATEX article thatdocuments the formal theory. The advantage of this approach is that the formal article is alwaysup to date, even if a user chooses to change the formalization of a theorem or the display form ofan abstraction.

55

- TERM: NavigatorJumpToLocalCollectors* ObidCollector* TempObidCollector* NamedObidCollector* Cancel*

----------------------------------------




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 3


CODE TTF RE init kreitzSTM TTF not over andCODE TTF listsel create

-> CODE TTF stack createDIR TTF mk stack object directory

----------------------------------------------

- TERM: NavigatorHide* ToggleObidList* Collect* FindNames* Reload* Save* View* Finish* Clear*DeleteDirFromCollector* InsertDirIntoCollector*DeleteCollectorFromDir* InsertCollectorIntoDir* Undo*

Collecting into : kreitz Obid Collector 2002 07 17-PM-03 48 20.

!oid cons----------------------------------------MkTHY* OpenThy* CloseThy* ExportThy* ChkThy* ChkAllThys* ChkOpenThy*CheckMinTHY* MinTHY* EphTHY* ExTHY*



↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><


Scroll position : 3


CODE TTF RE init kreitzSTM TTF not over andCODE TTF listsel create

-> CODE TTF stack createDIR TTF mk stack object directory

----------------------------------------------

Figure 4.12: Creating Object Collections

An example of an article automatically generated from such an object can be found athttp://www.cs.cornell.edu/home/kreitz/Abstracts/01cucs-HybridProtocol-nuprl.html.

Theory documentation objects can also be created by typing xmake thy doc object directoryy intothe editor ML top loop, where directory is the object identifier of the directory to be documented.

4.3.4 Miscellaneous Operations

4.3.4.1 Creating Object Collections

An Obid Collector is a method of collecting a list of object identifiers to be used as an argumentto navigator commands. An Obid Collector persists as an object but the navigator also maintainsa cache of the collector’s list of object identifiers.

To build an obid collector, one has to click the ObidCollector* command button. This willcreate a collector command zone on top of the current command zone, which requires the user tochoose between several options, shown on the left of Figure 4.12.

• JumpToLocalCollectors* jump the navigator to a directory containing the list of namedcollectors.

• ObidCollector* use the object at the navigation pointer as obid collector. The object hasto be of kind TERM or COM.

• TempObidCollector* create an ephemeral collector.

• NamedObidCollector* create a new named collector.

Named collectors are stored in the library and will persist from session to session while ephemeralcollectors will be discarded at the end of a session.

After the user has created or re-opened an obid collector the collector command zone containsa variety of buttons that modify the collector, shown on the right of Figure 4.12.

• Hide* Hide the search collector command zone by iconifying it to a button ObidCollector#.

• ToggleObidList* hides or shows the list of object identifiers in the collector.

• Collect* adds the object at the navigation pointer to the collector.

56

http://www.cs.cornell.edu/home/kreitz/Abstracts/01cucs-HybridProtocol-nuprl.html

• FindNames* starts a dialog to search for objects in the library by name. If the string enteredby the user matches the name of an object exactly, then its object identifier will be added tothe collector. This is useful for finding objects not in directory tree and then adding them toa directory with InsertCollectorIntoDir*.

• Reload* loads the stored object identifiers list into the collector’s navigator cache.

• Save* dumps the object identifiers list from the collector’s navigator cache to the collectorobject.

• View* opens the collector object for editing purposes.

• Finish* saves the object identifiers list and then removes the collector from the navigator.

• Clear* clears the collector’s navigator cache.

• DeleteDirFromCollector* subtracts the object identifiers of objects in the current navigatordirectory from the collector.

• InsertDirIntoCollector* adds all object identifiers of objects in the current navigatordirectory from the collector.

• DeleteCollectorFromDir* removes the object identifiers in the collector from the currentnavigator directory.

• InsertCollectorIntoDir* adds the object identifiers in the collector from the current nav-igator directory.

• Undo* undoes last Insert or Delete operation.

Although all obid collector commands could also be issued from the editor ML top loop, it isnot advisable to do so.

Printing Object Collections

Users may print the objects in a collection by clicking the PrintCollection* button when thenavigation pointer is at a collector object. This will create a print representation of the objectslisted in the collector and write it into a file ˜/nuprlprint/collector-name.prl and a LATEX-presentation, which will be written to the file ˜/nuprlprint/collector-name.tex. The objects areprinted in the order in which they were added to the collector, i.e. in the reverse order of the objectidentifier list in the collector object.

Collections may also be printed by typing the command xprint collection objecty into theeditor ML top loop, whereobject is the object identifier of the collector.

4.3.4.2 Milling

Nuprl provides a framework for developing tools for importing and migrating data from externallibraries into Nuprl’s data repository. This utility can be used for a wide variety of tasks such assearching for objects that contain a specified combination of object identifiers or for objects thathave been modified within a given time specification. It is initiated by milling a theory.

Clicking Mill* while the navigation pointer is at a directory will open a tag slot above thecurrent command zone into which the user may enter a tag for the milling directory to be created.The system will then create a sub-directory .tag-name mill at the beginning of the indicateddirectory. This directory comes with a variety of new command buttons and examples of codepieces that can be assembled for the tasks the user wants to perform.

57

- TERM: NavigatorFilterSource* AppendSource* TransformTargets* ViewTargets*FilterTargets* CopyTargets* TargetsAp* Rerun Bot*




↑↑↑↑ ↑↑↑ ↓↓↓↓ ↓↓↓ <> ><

Navigator: [Examples; .TAG mill; kreitz; user; theories]

Scroll position : 4


DIR FTF auxDIR FTF packages

-> DIR FTF FilterSourceDIR FTF Target ApsDIR FTF Target FiltersDIR FTF Transforms

----------------------------------------------

- CODE: FilterSource/By Kind and Name Searchlet kind = ‘STM‘and namestring = "st "in

(oid k oc.( (kind = k)& (string match f false namestring (tok to string (name of oid oid)))), false

)

Figure 4.13: Standard Milling Directory

To perform a particular operation, users should copy the corresponding object from one of thesub-directories of the directory Examples into the main milling directory, modify the “declaration”part of the code and then click the command button that corresponds to the name sub-directoryfrom where the piece of code was copied.

The object By Kind and Name Search in the directory FilterSource shown in Figure 4.13,for instance, contains the code for collecting all the objects of the milled directory that have a givenkind and name. Changing the let-binding of the variables kind and namestring to STM and stwill cause the search to focus on statement object whose name contains the string st . Clicking thebutton FilterSource* will initiate the search and collect all the found objects in a sub-directoryTargets. If that directory already exists the user will be asked to confirm that its previous contentscan be removed. Code pieces are provided in the following categories.

• FilterSource* collects all objects of the milled directory that satisfy a given predicate andplaces them in the sub-directory Targets. The search predicate may involve the kind, name,status, or creation time of the object, strings and object identifiers occurring in it, and similarcriteria. Existing contents of the directory Targets will be overwritten.

• AppendSource* filters the milled directory that satisfy a given predicate and adds the foundobjects to the directory Targets.

• TransformTargets* applies a specific transformation to the contents of all objects in thedirectory Targets.

• ViewTargets* opens a window displaying the object identifiers in the directory Targets.

• FilterTargets* pops up a list of objects in the directory Targets that satisfy a given pred-icate from the directory Target Filters. The directory Targets itself will not be modified.

• CopyTargets* copies the contents of the directory Targets to a directory Copies.

• TargetsAp* applies a specific operation to all objects in the directory Targets. Currentoperations include activating and deactivating, adding properties, and counting.

• Rerun Bot* creates two TERM objects in the milling directory that allow replaying proofs inthe directory Targets on a fine level of detail. The purpose of this operation is to safely rebuildproofs that are imported from different (or older) proof environments and fail during replay.

58

Milling directories can also be built by typing xbuild mill dir directory tag-namey into theeditor ML top loop, where directory is the object identifier of the directory to be milled andtag-name a token describing the the tag for the milling directory.

4.3.4.3 NavAtAp

Clicking the NavAtAp* command button when the navigation pointer is at a code object will replacethe final argument of the code in the object with the term inr(directory, position), where directorythe object identifier of the current directory and position the name of the object at the navigationpointer, and then evaluate the code.

The main purpose of this command is compatibility of the methods for creating recursivedefinitions (Section 4.3.2.2) and modules (Section 4.3.2.3) with the ones used in libraries developedwith Nuprl 4. The command is likely to be removed in the future.

4.3.4.4 Cloning the Navigator

Users who want to use multiple navigators simultaneously may do so by cloning the navigator.Clicking the Clone* command button will open a new navigator window that is a clone of thecurrent one. Alternatively, a user may type the command xdyn navigator clone termy into theeditor ML top loop, where term is the complete term contained in the current navigator window.

Note that navigator windows, like the ML top loop and the evaluator history window cannotbe closed with 〈C-q〉 again.

4.3.4.5 Raising the ML top loop window

If the ML top loop is buried under other windows, clicking the RaiseTopLoops* command buttonwill bring the ML top loop window to the foreground. This feature works currently only in the twmwindow manager.

Table 4.2 summarizes all the navigator command buttons that are described in this manual.The buttons in the upper part of the table occur in all standard user theories, while the otherbuttons are only present in some of the standard theories.

4.4 The ML Top Loop

The ML Top Loop, shown in Figure 4.14 on the left, provides an interactive interface to Nuprl’seditor, refiner, and library ML processes. It can be used to evaluate ML expressions and declarationsand to issue commands that change the state of the three processes. Commands have to be enteredinto the command line zone between the command line prompt and the double semicolon, thetermination characters for ML expressions. Commands that have been evaluated are stored in acommand history , which makes it possible to recall and modify complex commands. The ML TopLoop also contains a command zone with command buttons that affect the behavior of the editoritself.

4.4.1 Top loop command buttons

The buttons in the top line of the Top Loop command zone interact with the contents of thecommand line zone, the ones below have more global effects

59

Button Command SectionAbReduce* Update the Reduce tactic 4.3.2.2Act* Activate an object 4.3.2.9AddDef* Create a definition 4.3.2.2AddDefDisp* Create a display form 4.3.2.1AddRecDef* Create a recursive definition 4.3.2.2AddRecMod* Create a (recursive) module 4.3.2.3CheckMinTHY* Check with theory minimal RefEnv 4.3.3.6ChkAllThys* Check all library theories 4.3.3.6ChkOpenThy* Check all proofs in theory 4.3.3.6ChkThy* Check a theory 4.3.3.6CloseThy* Close/finalize a theory 4.3.3.3CpObj* Copy an object 4.3.2.4DeAct* Deactivate an object 4.3.2.9EditProperty* Edit object properties 4.3.2.10EphTHY* Make theory ephemeral 4.3.3.3ExTHY* Make theory explicit 4.3.3.3ExportThy* Export theory to file 4.3.3.7FixRefEnvs* Update ephemeral RefEnv 4.3.3.4Mill* Mill a theory 4.3.4.2MinTHY* Make theory (relative) minimal 4.3.3.3MkLink* Create a link 4.3.2.5MkML* Create a code object 4.3.2.1MkTHM* Create a statement object 4.3.2.1MkTHY* Create a theory 4.3.3.2MkThyDir* Create sub-theory directory 4.3.3.2MkThyDocObj* Create theory documentation object 4.3.3.9MvThyObj** Move an object 4.3.2.7NameSearch* Search for object names 4.3.1.2NavAtAp* Apply code to current position 4.3.4.3ObidCollector* Build Obid Collector 4.3.4.1OpenThy* (Re-)open a theory 4.3.3.3PathStack* Advanced motion commands 4.3.1.3PrintObj* Print an object 4.3.2.12PrintObjTerm* Print an object as a term 4.3.2.12ProofHelp* Pop up proof help window 4.3.2.14ProofStats* Display proof statistics 4.3.2.14ProveRR* Replay proof using RR 4.3.3.5RaiseTopLoops* Raising ML top loop window 4.3.4.5RmGroup* Remove a group of objects 4.3.2.6RmLink* Remove a link 4.3.2.6RmThyObj* Remove a library object 4.3.2.6SaveObj* Save copy of an object 4.3.2.11SetInOBJ* Set RR to RefEnv of proof 4.3.3.5SetRefenv* Set RR to object 4.3.3.5SetRefenvSibling* Set RR to current RefEnv 4.3.3.5SetRefenvUsing* Set RR to least RefEnv containing object 4.3.3.5ShowRefenv* Show RR 4.3.3.5reNameObj* Rename an object 4.3.2.8showRefEnvs* Display existing RefEnvs 4.3.3.4Clone* Clone the navigator 4.3.4.4MkDir* Create a directory object 4.3.2.1MkObj* Create a library object 4.3.2.1PrintCollection* Print collection of objects 4.3.4.1PrintThyLong* Print theory with proofs 4.3.3.8PrintThyShort* Print theory contents 4.3.3.8RmDir* Completely remove a directory 4.3.2.6commentObj* Create comments for an object 4.3.2.13mkRefEnv** Insert static RefEnv 4.3.3.4

Table 4.2: Navigator command buttons

60

TERM: ML TopLoop

Previous* Next* Eval* Reset* Remove* SaveWOEval*LIB* EDD* REF* ShowRefenv* RaiseHistory* RaiseNavigator*

M[REF]> FwdThruLemma ;;

TERM: EvaluatorHistory

Previous* Next* RaiseEvaluator*

M[REF]> FwdThruLemma ;;

- : (tok -> int list -> tactic)

Figure 4.14: The ML Top Loop and the Evaluator History Window

Previous*: Insert the previous command from the command history into the command line zone.

Next*: Insert the next command from the command history into the command line zone.

Eval*: Evaluate the command that is currently in the command line zone.

Reset*: Reset the command line zone.

Remove*: Remove the current command from the history and reset the command line zone.

SaveWOEval*: Save the current command to the command history without evaluating it.

LIB*: switch to interaction with the library ML process.

EDD*: switch to interaction with the editor ML process.

Ref*: switch to interaction with the refiner ML process.

ShowRefenv*: show the contents of reference environment register (Section refsec:nav-RefEnvReg),i.e. the reference environment of the ML expression in the command line (this makes senseonly in refiner mode).

RaiseHistory*: open an evaluator history window that shows the output from evaluating theML expression in the command line zone.

The window (shown on the right of Figure 4.14) shows the command prompt of the corre-sponding process, the ML expression, its value, its type, and a time stamp. It also providesthree buttons. Previous* and Next* are used for going backward and forward in the evalu-ator history. RaiseEvaluator* inserts the current history command back into the ML toploop, provided the command and the ML top loop interact with the same process.

RaiseNavigator*: bring the navigator window to the foreground (works currently only for twm).

4.4.2 The command line zone editor

The command line zone provides a term editor . The editor is initially in text mode, indicated by thetext cursor , which allows the user to enter ML text. Nuprl terms may be inserted into this textby opening a term slot and entering terms as described in Chapter 5. Most of the editor commandsdescribed in Chapter 5 will work the same way in the command line zone. The only exception isthe return key | , which sends the command to the ML evaluator instead of inserting a new lineas in the term editor. The commands and key bindings of the command line zone editor that differfrom those of the regular term editor are listed in Table 4.3.

| evaluator eval call ML evaluator〈S- | 〉 insert-newline add line-break〈C-R〉 evaluator previous scroll back through history

Table 4.3: Command line zone editor commands and bindings

61

To evaluate an expression, type it in at a text cursor after the command prompt and then useeither the Eval* button or the return key | . You may edit the expression using the term-editorcommands described in Chapter 5. To break an expression into several lines, use 〈S- | 〉. Outputfrom evaluating the ML expression in the command line zone is usually directed to the evaluatorhistory window (although it is possible to have it appear below the command line zone in the MLtop loop window as well).

Nuprl error messages appear in a separate window that describes the nature of the error andsome debugging information. The window can be closed by either clicking it’s Quit* button or bytyping 〈C-Q〉. Errors can come from various sources. In most cases the ML expression you typeddoesn’t parse or type-check properly or has been sent to the wrong process.

Occasionally you can get the ML top loop into an unexpected state. In this case undo theprevious steps using 〈C- 〉 until a stable state has been recovered. If that doesn’t work, the editorprocess itself may have reached an unrecoverable state. It is best to close all other Nuprl windows,saving their contents if needed, to kill the editor process, and to start it again.

4.4.3 Top Loop Commands

Depending on the command prompt at the beginning of the command line zone top loop commandsare sent by the editor to either the library, editor, or refiner processes. Refiner commands usuallyinvolve evaluating existing or newly developed tactics (Chapter 8) and related ML functions, oranalyzing proof details that are not shown by the proof editor (Chapter 6). Library commandsaffect the contents of the library as permitted by the corresponding library application interface.Editor commands change the visible contents of the navigator (which my also affect the library),modify the behavior of the editor itself, or open new windows that invoke specific applications suchas a proof editor or the Nuprl term evaluator.

Most of the editor and library top loop commands have been described in Section 4.3. In thissection we briefly summarize other commands that may be of interest for a user.

4.4.3.1 Invoking the Nuprl term evaluator

The ML top loop provides the means to evaluate expressions of Nuprl’s meta language ML.Nuprl’s object language, however, comes with its own notion of evaluation (see Table A.2 inAppendix A.2.1), which is supported by a separate term evaluator . To invoke this evaluator, a userhas to type the command xview showc name termy into the editor ML top loop, where the tokenname will be a suffix to the name of a new window and term is a Nuprl term to be evaluated.This will open a new window with the name ‘compute name‘ that contains the Nuprl term termand four buttons that initiate the evaluation of the term.

compute addition

Compute1* Compute5* Compute10* ComputeAll*

((3 * 4) - 5) + 6

Clicking Compute1* once will perform one top-level reduction step on the Nuprl term. Clickingit again will perform the next step, and so on. For the term p((3*4)-5)+6q, for instance, this willresult in the reduction sequence p((3*4)-5)+6q −→ p(12-5)+6q −→ p7+6q −→ p13q.

The other three buttons proceed in larger steps. Compute5* and Compute10* perform 5, respec-tively 10 computation steps at once. ComputeAll* continues with the evaluation until no furtherreduction is possible. To undo a computation step, simply use the undo key combination 〈C- 〉.

62

Note that evaluation in Nuprl is lazy: evaluating the term p〈((3*4)-5)+6〉7q will leave itunchanged. Using ComputeAll* on terms like pY (λx.x)q, whose evaluation does not terminatewill cause the library and refiner processes to loop indefinitely. A user will have to interrupt theseprocesses and bring them back into a stable state (see Section 4.6 below).

With a similar command, a user may also invoke the Nuprl term evaluator on the extractterm of a theorem (see Section 6.3.3). Typing xview show co obidy into the editor ML top loopwill open a Nuprl term evaluator window that contains as its term argument the extract term ofthe theorem object denoted by the term obid . This, however, requires that the extract term of thetheorem has been made available to the editor. If this hasn’t been done already, one has to enterthe command xrequire termof (ioid obid)y before invoking the evaluator.

4.4.3.2 Loading and compiling ML code

Nuprl allows users to load files containing ML code into the library, editor, or refiner processes. Todo so, a user has to type the command xloadt system root-dir [path1, files1 ; ...; pathn, filesn]yinto the respective ML top loop. root-dir is a string describing the root directory of the user’s Nuprlfiles. path is a list of strings describing the sub-directory in which the specific files reside, and filesis a list of file names (without the .ml extension) in that directory. The command will compile allthe named files and load the compiled code into the current process. For instance,

loadt system "/home/nuprl/lib/ml"[ ["standard"],["a";"b"]; ["testing";"new"],["d";"e";"f"] ]

will compile and load files in the following order

"/home/nuprl/lib/ml/standard/a.ml""/home/nuprl/lib/ml/standard/b.ml""/home/nuprl/lib/ml/testing/new/d.ml""/home/nuprl/lib/ml/testing/new/e.ml""/home/nuprl/lib/ml/testing/new/f.ml"

Compiled files will be stored in a sub-directory mlbin/os/lisp-version of the directory in whichthe ML files reside, where os is currently either linux or solaris, and lisp-version is the nameof the Lisp dialect that runs the process, e.g. allegro61 or cmucl. If these directories do not yetexists, an error message will be created.

4.4.3.3 Importing Text

One of the advantages of having code reside within the Nuprl library instead of in external files isthat Nuprl links ML functions to the code object in which they are defined. Clicking the middlemouse button middle on a piece of ML text will raise the code object where the correspondingML function is defined, provided its definition is stored within the library.

One way to migrate an ML file into the system is to import its text. Entering the commandximport text filenamey into the editor ML top loop will open a new window containing thecontents of the file described by the string filename. Users may then copy and paste pieces of thetext into any term editor that is in text mode such as the ML top loop or code and commentobjects. This feature also simplifies the on-line documentation of theories, as it allows importingpreviously written text and turning it into comment objects.

63

4.5 Process Top Loops

The Process Top Loops are Nuprl’s interface to the system processes that run the editors, refiners,or the library. They represent the top loops of the corresponding ML interpreters and do not provideany editing features. Their main purpose is to display system output and error messages and toexecute maintenance and debugging commands. Usually, they are run within an emacs shell to havesome text editing support.

Most users will hardly ever use the process top loops except for monitoring the process in caseof long delays (see Section 4.6 below). There are, however, a few useful commands that advancedusers may want to take advantage of.

Most commands have to be entered as conventional ML expressions, which must be terminatedexplicitly by a double semicolon. Users may also switch to Lisp mode and enter low-level systemcommands in Lisp. These commands need to be terminated by a double semicolon as well, but willbe forwarded to the Lisp interpreter. For both ML and Lisp there are also a few dotted commands.These are expressions without arguments that are terminated by a period. Below we list some ofthe most commonly used commands.

• Editor Commands:

– xnuprl oed suspend ();;y closes all Nuprl windows.– xnuprl oed resume ();;y reopens the Nuprl windows.– xnuprl oed reset ();;y : kills all Nuprl windows.– xwin.y opens the navigator and ML top loop windows.– xset xhost "hostname" display index;;y redirects all Nuprl windows to the specified

display after the next suspend/resume cycle. hostname must be a string describing thedisplay host and display index a number (usually 0) specifying the display terminal onthat host.

– xnuprl oed rehash ();;y rehashes the macros and bindings in the user’s mykeys.macrofile (see Section 3.2.2).

• Commands for the Editor or Refiner:

– xsetup connect socket1 socket2 "hostname";;y sets up a connection to the library athost hostname using the indicated socket numbers.

– xdc ();;y try to establish the connection that was set up.– xdd ();;y disconnect the process.– xopen lib ‘lib-memnonic‘;;y opens the connection to the library environment called

lib-memnonic.– xclose lib ‘lib-memnonic‘;;y closes the connection to the library environment lib-

memnonic.

The difference between the commands dc/dd and open lib/close lib is that the formerestablish the low-level TCP/IP connection to the library’s object request broker, while thelatter link to a client work space provided by the library (see Section 4.1).

The above commands are implicitly executed when the editor and refiner processes are started,using the data contained in the user’s .nuprl.config file (see Section 3.2.2).

• Library commands:

– xnosa socket1;;y Opens a connection to a client using the indicated socket number.

64

– xlibrary open ‘‘lib-memnonic‘‘;;y opens the library environments lib-memnonic forexternal connections. Usually, one opens the library environment that was stored thelast time the library was closed, but there may be reasons to re-open older libraryenvironments.

– xlibrary open as ‘‘lib-memnonic‘‘ ‘new memnonic‘;;y opens the library environ-ments lib-memnonic under the alias new memnonic.

– xlibrary close ‘libenv‘;;y closes the library environment libenv .– xlibrary close gc ‘libenv‘;;y closes the library environment libenv , performing garbage

collection first. Unlinked library objects will not be included in the stored environment.However, they will not be removed from the data base and may be recovered by openingan older environment.

– xdb envs print ‘‘memnonic-match‘‘;;y Print a list of all existing library environmentsthat match all the tokens in the list memnonic-match.

Library Lisp commands:

– x(stop-db-buffering);;y stops buffering data base information. This is useful whenone sees buffering messages like xWBI 23y or xLBI 25y building up to high numbers andnever decreasing.

• Commands for all processes:– xenvs ();;y prints a list of the environments currently accessible by the process.– xl.y switches to Lisp mode.– xml.y switches to ML mode.– xstop.y terminates the process.

4.6 Recovering from Errors

Most Nuprl errors relate to commands that were entered into the navigator, the ML top loop, orthe proof editor. Quite often they have to do with misspelled tactics or ML functions, type errors,or unsuccessful executions of the command. In these cases, error messages appear in a separatewindow that describes the nature of the error and some debugging information. Usually, it sufficesto re-enter the command after correcting the mistake.

Many library commands that were executed erroneously, like removing an object or unlinking adirectory, can be undone by entering the key combination 〈C- 〉 (see Section 4.3). Since the librarynever destroys information, it is possible to retrieve the contents of every object that was previouslyaccessible. The undo history is limited, though. Recovering from an error that was made many stepsago is more difficult.

If a user enters text into the navigator while the cursor is at the “scroll position” the navigatorwill show an error after the next operation. Using the undo operation until the entered text isremoved and moving the cursor to where it is supposed to be solves the problem.

Sometimes the contents of a window are not updated after resizing it. Scrolling down and upwith 〈C-v〉 and 〈M-v〉 usually forces the window to be updated.

If a user has messed up the contents of a window and cannot undo the error, closing the windowwith 〈C-q〉 and opening it again will often solve the problem. 〈C-q〉 closes the window withoutsaving the modifications to the object, so reopening the object will show the state after the lastsave operation (usually 〈C-z〉). Note that the navigator, the ML top loop, and the evaluator historycannot be closed without using the editor commands from Section 4.5.

65

If the system appears to be inexplicably stuck, check the ML process loops. It is possible thatone of them is garbage-collecting , which may take up to several minutes depending on processorspeed and available memory.

In rare cases, one of the three Lisp processes crashes and ends up in debug mode, which offersseveral restart actions to the user. Entering the Lisp command x(fooe)y after the prompt usuallybrings the process back to a stable state.

If a user has initiated a non-terminating computation, for instance by entering a recursive MLexpression into the ML top loop or by applying the Nuprl term evaluator to a term containing theY combinator, the corresponding process must be interrupted explicitly. Typing 〈C-c〉 repeatedlywill eventually break the Lisp process, which then can be restarted with (fooe).

If everything else fails, one may have to restart the editor, the refiner, or even all three Nuprlprocesses. Interrupt the Lisp process with 〈C-c〉, type x:exity (or kill the process from Unix), andthen start it again as described in Chapter 3. If all three Nuprl processes have to be shut down, itis best to stop those that are still alive using the xstop.y command, shutting down the library last.

66

Chapter 5

Editing Terms

Terms in Nuprl are a general-purpose, uniform data-structure that serves two different purposes.

• Terms are used to represent Nuprl’s object logic, that is the expressions and types of its typetheory together with user-defined extensions as well as all Nuprl propositions. Sometimeswe refer to terms of this kind as object-language terms.

• Nearly all library objects, that is proofs, abstractions, display forms, and even the descriptionsof the Nuprl editors are represented as terms to which we refer as system-language terms.

Terms are either primitive or abstract . Primitive terms have fixed pre-defined meanings and areused to describe the primitives of Nuprl’s type theory as well as the foundation of the Nuprlsystem. Abstract terms or abstractions (see Chapter 7.1) are defined as being equal to other,more primitive terms. The definitions of abstractions are stored in abstraction objects of Nuprl’slibrary (see Section 4.1.1). The visual appearance of a term is governed by its display forms (seeChapter 7.2), which are defined in the display-form objects of Nuprl’s library.

This chapter describes the internal structure of terms, the interplay between Nuprl’s structurededitor and display forms, and the commands for interactively viewing and editing terms in Nuprl.

5.1 Uniform Term Structure

Nuprl terms have the form opid p1:F 1,..,pk:F

k(x1

1,..,x1m1

.t1; ...; xn1,..,x

nmn

.tn),where opid is the operator identifier . The pi:Fi are parameters and the xi

1,..,ximi.ti are the

bound subterms, expressing that the variables xi1,..,x

imi

become bound in the term ti. The tuple(m1, . . . , mn), where mj≥0 is the arity of the term. Appendix A.1 describes the current parametertypes and the acceptable strings for opids, parameters, and variables. The primitive operators ofNuprl’s type theory are listed in Table A.1 on page 148.

When writing terms, we sometimes omit the brackets around the parameter list if it is empty.Note that parameters are separated by commas while subterms are separated by semicolons.

Terms are implemented as tree data structures in Nuprl’s meta-language ML (see Appen-dices B). Most users will rarely have to work with terms on the ML level but use the term editorto view and edit terms.

5.2 Structured Editing

In mathematics one distinguishes between logical structure of objects, and the notation in whichthey are presented. When we talk of the logical structure of a term, we are thinking of the abstract

67

mathematical object that it represents. Nuprl’s uniform term syntax , described in the previoussection, is meant to reflect the regularity of these objects.

In contrast to that, notation aims at a visual presentation of abstract objects on the printed pageor on the computer screen. Familiar notation for mathematical expressions helps human readersto construct the described abstract object in their minds, but should not be confused with theabstract structure itself.

In mathematics notation is crucial issue. Many mathematical developments depend heavily onthe adoption of some clear notation, which makes mathematics much easier to read. However,mathematical notation can be rather complex and ambiguous if one is not aware of the immediatecontext it is presented in. Juxtaposition of symbols, for instance, can mean function application inone place and multiplication in another.

Notation understandable by machines, on the other hand, is often restricted to source texts inASCII files that can be easily be parsed by a computer. Programming languages allow overloadingof operators and implicit coercions and resolve these ambiguities by type-checking and similarmethods. For interactive theorem proving, however, parseable ASCII notation is far from beingsufficient, as it is not anywhere as easy to read as mathematics in books and papers.

The Nuprl system provides an interactive editing mechanism that presents terms in mathe-matical notation and groups the notation in chunks that correspond to parts of the internal treestructures. Users edit the tree structure directly, so there is no need for a parser.1 Such editors areoften called structured editors. The advantages of structured editors are:

• Structured editors allow using a notation that is ambiguous to a machine but unambiguousto a human who is aware of its full context.

• Formal notation is not limited to ASCII characters. Nuprl uses a single 8-bit font of up to256 characters for displaying formal text on the screen while it is being edited and providesmechanisms for integrating LATEX and Display PostScript-like technology to generate almosttext-book quality displays. Currently the latter is only used for printing formal mathematicaltext but not for editing it.

• Formal notation may become context dependent. Theorems, definitions and proofs may con-tain local abbreviations and implicit information.

• Notation can be freely changed without altering the underlying logical structure of terms.

• Structured editors link abstract terms to notation. Users who find a particular notation con-fusing only need to point and click the mouse on the notation in question in order to receivea formal definition and possibly additional explanations.

The main disadvantage of structured editors is that they are quite different from conventionaltext editors like Emacs. Users have to get used to entering and editing terms in accordance withtheir tree structure instead of their textual appearance. They also have less control over formatting,since all display formatting is done automatically and may only be influenced by display forms (seeChapter 7.2). It may take a while to learn how to use a structured editor and to take advantage ofits capabilities. Suggestions for improvements from users of the Nuprl editor are always welcome.

5.2.1 Term Display

To associate a chunk of notation with a term, Nuprl’s term editor relies on display form definitions.Binary addition, for instance, is represented by the term add(x;y), but conventionally written with

1An alternative approach, taken for instance by Mathematica [Wol88], is to use a rich parseable ASCII syntaxfor input and then to process the input with pretty-printing routines for formatted output like Display PostScript.

68

the symbol + in infix notation. We could write the notation chunk as 2 + 2 , where the 2’s areholes for the two subterms, and the outer box shows the extent of the chunk. We call these holesterm slots, because they can be filled by terms. In a display form definition we usually label termslots with variables to indicate how term slots correspond to the logical structure of a term. Thedisplay form for addition, for instance, can be defined as

x + y ≡df

add(x; y)

where a =dform b means that a is defined as the display form for b. Term slots stretch to accom-modate the terms inserted in them. For instance, the term add(mul(1;2);3) will be shown as

1 * 2 + 3

Nuprl automatically adds parentheses according to display form precedences. When a displayform of lower precedence is inserted into the slot of display form with higher precedence, parenthesesare automatically inserted to delimit the slot. For instance, if we assign the display form for mul(x;ya higher precedence than the one for add(x;y) then the term add(mul(1;2);3) is displayed withoutparentheses, while mul(1;add(2;3)) is displayed as

1 * ( 2 + 3 )

Note that parentheses are inserted merely to disambiguate the notation for a human reader, whocannot see the term slots but only x1 * (2 + 3)y.

In addition to term slots and the fixed components of a notation chunk, some display formscontain text slots. These are slots in a definition that are filled with text strings like values forterm parameters and names of binding variables. A universally quantified formula, for instance,is represented by the term xall(T;x.P)y, meaning that “for all x of type T , the proposition Pis true” (note that free occurrences of the variable x become bound in P ). To generate the usualnotation x∀x:T.P y for this formula, we use the display form definition

∀ pxxqy: T . P ≡df

all(T; x.P)

where pxqy is used to indicate a text slot.

Two display form definitions in Nuprl are rather special: the display form definition for variableterms, and the display form definition for natural numbers. Both display forms have only a singletext slot, and no other printing or whitespace characters.

pxxqy ≡df

variablex:vpxiqy ≡

dfnatural numberi:n

In general, a display form for a term is made up of text and term slots, interspersed with printingand space characters. We can annotate display forms with formatting commands that specify whereline breaks can be inserted, and how to control indentation. The structure and appearance of displayform definitions, which are contained in display objects in Nuprl theories, as well as the effect ofprecedences on parenthesization is described in detail in Chapter 7.2.

Nuprl’s term editor builds the notation for a term from the display forms associated with eachnode of the term tree. Thus the structure of the notation mirrors the tree structure of the term.The display form tree of a term is the tree structure that one actually edits with Nuprl’s term

69

editor. In a display form tree, each display form and each slot is considered a node of the tree. If aslot is not empty, it is identified with the display form tree or the text string filling it. All the slotsof a display form are considered to be the immediate children of the display form and the editorconsiders slots ordered in the order they appear, left to right, in display form definitions.

In this manual, we refer to terms by their display notation rather than their abstract syntax,unless we want to emphasize their logical structure. Also, in our description of the editor, we talkinformally about nodes of terms, when we are actually referring to nodes of the correspondingdisplay-form trees.

5.2.2 Editor Modes

Users can navigate through a term by moving a cursor (sometimes called the point). Depending onthe position of the cursor, the term editor will be in one of three modes, which are indicated bythe shape of the cursor.

In term mode the cursor is positioned at some node of the term tree. The term node is indicatedby highlighting its notation and the notation for all its subtrees. The highlighting is usually achievedby using reverse video; swapping foreground and background colors. For example,

∀i:Z. ∃j:Z. (j = (i + 1))

indicates that a term cursor is at the subterm xj = i + 1y. Occasionally a term has no width,and a term cursor on such a term is displayed as a thin vertical line. In this document, we indicatesuch a cursor by . In term mode, keystrokes corresponding to printing characters form (parts of)editor commands.

In text mode the cursor is positioned within a text slot and displayed as xy. Keystrokes corre-sponding to printing characters cause those characters to be inserted at the position of the cursor.The text cursor is significantly thinner than the term cursor on a no-width term, so it should beeasy to distinguish the two. It may be positioned either between two adjacent characters, beforethe first character of a text slot, or after the last. Valid text cursors for the text string xabcdefy,for instance include

abcdef abcdef abcdef

There is a potential ambiguity as to which text slot a text cursor is at. Consider, for instance, twoadjacent text slots containing the strings xaaay and xzzzy and the following text cursor:

aaazzz

Display forms are designed that this kind of situation should never occur.

Certain cursor motion commands are designed for moving around a term’s display character-by-character as with a conventional text editor. In this case the cursor occupies a single charac-ter position on the screen. If possible, the editor uses a text cursor. Otherwise it uses a screencursor , which is displayed by outlining the character. For instance, if we had the following textcursor in a term:

∀i:Z. ∃j:Z. (j = (i + 1))

then a ‘move-left-one-character’ command would leave a screen cursor over the character x∀y.∀i:Z. ∃j:Z. (j = (i + 1))

In screen mode, keystrokes corresponding to printing characters form parts of editor commands. Inthe rest of this document we will never have to explicitly represent a screen cursor, so all outlinedterms should be interpreted as term cursors.

70

5.2.3 Term and Text Sequences

The term editor has special features for handling certain kinds of sequences of terms, which makesthem appear much like terms with variable numbers of subterms. A term sequence is constructedby iteratively pairing term slots in a right-associative way and displayed as a linear sequence. Asequence containing 4 empty term slots, for instance, might be displayed as:

(2, 2, 2, 2)

Different kinds of term sequences have different pairing terms, a special term to represent the emptysequence, different left and right delimiters, (the x(y and x)y respectively in the example), anddifferent element separators (the x,y in the example). Delimiters and separators in term sequencesalways consist of at least one character.

The editor considers all the term slots of the sequence as siblings in the display form tree, andthe whole sequence as their immediate parent. Often, the editor does not distinguish between aterm and a one-element sequence containing that term but treats a term as a one element sequence.Thus for nearly all purposes the internal structure of sequences can safely be ignored.

A text sequence is a text string in which characters may be replaced by terms. Text sequencesare primarily used for proof tactics and other ML code, for comments, and for the left-hand sidesof display forms. The editor presents a text sequence as a display form with alternating text andterm slots. In contrast to term sequences, text sequences normally have no delimiters or elementseparators. They are however easily identified because they usually occur in well-defined contexts.An example of a text sequence is the ML expression:

With ’n + 1’ (D 0) THENW TypeCheck

This text sequence consists of 3 term slots filled with the terms x’n + 1’y, x y, and x y, and 4text slots filled with the text strings xWith y, x (D 0)y, xTHENW TypeChecky, and xy (the null orempty text string). The x y’s are new-line terms, which are usually kept invisible and only shownwith a printing character for illustration purposes. New-line characters in text should be avoidedas much as possible, as this simplifies the display formatting algorithm.

5.3 Term Editor Windows

Term editor windows are used for viewing and editing terms. Except for the navigator and proofeditor windows, most windows opened by Nuprl are term editor windows. Each window displaysa single display form tree representing a single term. All editing operations can be carried out fromthe keyboard alone, but the editor accepts input from the keypad and the mouse as well.

Input characters typed at the keyboard in multi-character commands are echoed as high-lighted text near the position of the cursor, and can be corrected by using del . Certain keycombinations are bound to editor commands, which also may be invoked explicitly by typingx〈C-M-x〉command-namey. The default key bindings are intended to be reminiscent of Emacs’skey bindings. A summary of all the key bindings that we will describe below can be found in Ta-ble 5.8 at the end of this chapter. Users who wish to use alternative key bindings may customizethe term editor as described in Section 5.8.

The editor adjusts the display of an object in a window to the size of the window. If the windowis too small, not all the object can be displayed at once. In this event, one can resize the window, orscroll the window up and down. Sometimes, if the window is to narrow, some subterms are elided .

71

The display form tree for an elided subterm is replaced by x...y. Currently, the only way to toun-elide a subterm is to widen the window as much as possible. Eventually, one will be able toexamine elided subterms by moving the root display form of an editor window to some term treeposition other than the term root.

Term editor windows are opened when a user access a library object through the navigator.Opening a proof object opens a proof editor window , which in turn opens a term slot for enteringthe goal sequence and text slots for entering refinement rules (see Chapter 6 for details). To closeand change term editor windows, one may use the following commands and key sequences.

〈C-Z〉 exit save, check, and close window〈C-Q〉 quit close window without saving〈C-J〉 jump-next-window jump to next window

exit first saves a copy of the object. It then checks the object before closing the window. Thischecking has the same effect on library objects as using the ML check command. If the checkfails, then the window is left open. If you still want to close the window, use quit instead.Separate save and check commands are described in Section 5.7.

quit is an abort command. It closes the window, abandoning any changes made to the windowsince it was last checked by attempting exit.

jump-next-window allows one to cycle around all the currently open windows, including anyproof editor windows.

5.4 Entering Information

Term editor windows for ML and comment objects initially open in text mode while abstractionsand display forms usually open in term mode.2 Special display forms allow opening text slots interm windows while special key sequences are used to open term slots within text sequences (seeSection 5.4.2 below).

5.4.1 Inserting Text

The following commands are for inserting text whenever the editor is in text mode.

x insert-char-x insert char x〈C-#〉num insert-spec-char-num insert special char x | insert-newline insert newline

Standard ASCII printing characters (including space) self insert in text mode. Non-standardcharacters can be inserted using insert-spec-char-num, where num is the decimal code for thecharacter. Table 5.1 lists the currently available special character codes.3 Alternatively, specialcharacters can be copied from the object FontTest in the library theory core-1.

The insert-newline command is only appropriate in text sequences. Within terms the newlinecharacter is actually a term whose display is controlled by the display layout algorithm.

2Currently, newly created objects contain an empty term slot. Removing this slot in ML and comment objectswith 〈C-C〉 puts the editor into text mode. The term slot in abstractions and display forms cannot be removed.

3The Nuprl fonts may be extended in the future. Executing the Unix command xfd -font nuprl-13 & pops upa display of the actual standard Nuprl font. Clicking left on a character results in its decimal code being displayed.

72

0 1 2 3 4 5 6 7 8 9120 P R130 N C Q Z U ⇐ ⇒ d e

140 ` ∫ · ↓ α β ∧ ¬ ∈ π

150 λ γ δ ↑ ± ⊕ ∞ ∂ ⊂ ⊃160 ∩ ∪ ∀ ∃ ⊗ ↔ ← 6= ¦170 ≤ ≥ ≡ ∨ → Σ ∆ Π180 × ÷ + − 0 ⊆ ⊇

0 1 2

190 3 B ρ a q b d c

200 1 2 3 µ ε θ

210⋂ ⋃

= .= ⇔ 6→ v > ⊥220 7→ a o u ß A O230 U T F ∅ 6∈ 6⊆ 6v240 Γ Λ \ Θ σ i j

250k l m n

Table 5.1: Nuprl special character codes

5.4.2 Adding and Removing Slots

〈C-U〉 open-list-to-left open slot to left of cursor〈M-U〉 open-list-to-right open slot to right of cursor〈C-O〉 open-list-left-and-init open and initialize slot to left〈M-O〉 open-list-right-and-init open and initialize slot to right〈C-C〉 close-list-to-left close slot and move left〈M-C〉 close-list-to-right close slot and move right

Nuprl’s term editor makes it possible to combine informal, semi-formal, and formal knowledgeby inserting terms into text sequences. These terms are displayed according to their display formsand surrounded by ordinary text.

To make this possible, a term slot must be opened and then initialized. The latter inserts aterm holder into the term slot, which initially looks like x’[term]’y. The commands open-list-left-and-init and open-list-right-and-init combine these two commands and position thecursor at the empty slot of the term holder. Terms may now be inserted into the slot as usual (seeSection 5.4.3 below).

The commands for opening, initializing, and removing slots apply both in text and in termmode and thus have a slightly more general meaning than just described.

In term mode, open-list-to-left and open-list-to-right only apply if the term cursor isan element of a (term or text) sequence. They add a new empty slot to the left (or right) of thecursor and move the cursor to the new empty slot. On an empty term sequence, both commandshave the same effect; they simply delete the nil sequence term. In text mode, both commands openup an empty term slot at the text cursor, and leave the cursor at the new slot.

With text or term sequences represented by a single term, these commands infer the kind ofsequence to create from context. Occasionally with term sequences, more than one kind of sequenceis permitted in a given context (for example, in precedence objects) and in such cases you can useexplicit term insertion commands to create the sequence. Such ambiguity should not arise withtext sequences.

73

open-list-left-and-init and open-list-right-and-init are similar, but if there is someobvious term to insert in the opened up slot, then that term is automatically inserted and thecursor is left at an appropriate position in the new term.

If a term cursor is at an empty term slot in a term sequence, the commands close-list-to-leftand close-list-to-right delete the slot, and then (if possible) move the cursor to the element tothe left or right respectively of the slot just deleted. If the term slot is filled with a term, that termis deleted as well. If the term slot is in a text sequence, these commands leave a text cursor at theposition of the deleted slot.

5.4.3 Inserting Terms

In structured editing, one usually enters terms in a top-down fashion, starting with the root of theterm tree and working on down to the leaves. This means that one has to work with incompleteterms. For example, at an intermediate stage of entering the term x∀i:Z. ∃j:Z. j = i + 1yone might be presented with the term:

∀i:Z. ∃[var]:[type]. [prop]

Here [var], [type] and [prop] are place-holders for slots in the display of the existential quantifier.If a slot has a place-holder, we say that the slot is empty , or uninstantiated . Place-holders forsubterms of a term are term slots while others are text slots. The labels that appear in the place-holders (the var, type or prop in the example above) are controlled by the definition of the term’sdisplay form. If a text (term) slot contains a a text string (term) we say that slot is filled orinstantiated . If a display form has no uninstantiated slots, then it is considered complete. Place-holders re-appear when the contents of slots are removed.

name insert-term-name insert name into empty slot〈C-I〉name insert-term-left-name insert name, using existing term as left subterm〈M-I〉name insert-term-right-name insert name, using existing term as right subterm〈C-S〉name substitute-term-name replace existing term with name〈C-M-I〉 init-term initialize term slot〈C-M-S〉 select-dform-option selects display form variations

To insert terms into term slots one may use the editor commands listed above. In these com-mands, name is a string of characters naming a new term to be inserted. The interpreter for namestrings checks each of the following conditions until it finds one which applies.4

1. name is an editor command enabled in a particular context.

2. name is an alias for some display form, defined in in the library object for that display form.

3. name is the name of a display form object. In this case it refers to the first display formdefined in that object.

4. name is of the form ni where n is the name of a display form object and i is a natural number.ni refers to the i-th display form definition in the object named n. Definitions in objects arenumbered starting from 1.

4Note that this order gives display form names and aliases preference over abstraction names. The operatoridentifier of a term can not be used to identify a term, if it is neither of these three. This is particularly importantwhen referring to the elementary terms of type theory. To find out how to refer to a particular term, mark the termand enter 〈C-X〉df to see its display form or 〈C-X〉ab to see the abstraction that defines it, if there is one.

74

5. name is the name of an abstraction object. In this case it refers to the earliest display formin the library for that abstraction.

6. name is all numerals, then the term referred to is the term xnatural-numbername:n()yterm of Nuprl’s object language.

7. If none of the above applies, name is assumed to refer to the term xvariablename:v()y.Since names always have acceptable extensions as variable names, the editor does not interpretname until some explicit terminator such as spc (no-op) or a cursor motion command is typed. | (right-empty-slot, see Section 5.5) is a particularly useful terminator.

insert-term-name is only applicable at empty term slots. It results in the display form referredto by name being inserted into the slot. If name is terminated by a no-op, then a term cursoris left at the new term. If name is terminated by some cursor motion command, then thatcommand is obeyed.

insert-term-left-name is intended for use at a filled term slot. Its behavior is to:1. save the existing term in the slot, leaving the slot empty,2. insert the new display form referred to by name into the slot,3. paste the saved term into the leftmost term slot of the new display form. If the new

display form has no term slots, then the saved term is lost.

insert-term-right-name behaves in a similar way to insert-term-left except that in step 3,the saved term is pasted into the rightmost term slot of the new display form.

substitute-term-name replaces one display form with another that has the same sequence ofchild text and term slots. The children of the old display form become the children of the newone. If the new display form has a different sequence of children substitute-term-nametries something sensible, but in these cases it is safer to explicitly cut and paste the children.

init-term initializes a term slot to some default term. initialize-term is automatically invokedby Nuprl to initialize new windows. To re-initialize a window, place a term cursor at the rootof the term in the window, delete the term and then give the initialize-term command.The default terms for particular contexts are described in various sections of this document.If no default has been designated, initialize-term does nothing.

select-dform-option selects an alternative display form for the term where the term cursoris positioned. For instance, if term cursor is positioned at an independent function type, itselects the more general dependent-function display form.

5.4.4 Adding New Terms

The term editor recognizes certain input sequences as indicating that a new term should be created.A new term structure can be created as follows:

• Position a term cursor at an empty slot and enter the letters of the new term’s opid

• Enter a (possibly empty) list of parameter types for the new term (see Section A.1.2), abbre-viated by single letters. The list has to be delimited by xy and xy characters, and elementsmust be separated by x,y characters. Empty lists of parameter types are optional.

• Enter a list of subterm arities, i.e. numbers designating the number of binding variables foreach subterm. The list must be delimited by x(y and x)y characters, and elements must beseparated by x;y characters. This list has to be entered even when it is empty.

75

Upon receiving the opid, the list of parameter types, and the list of subterm arities the editorcreates a new term in uniform syntax with appropriate place-holders for parameters and subterms.For instance, entering myidn,t(0;1) creates the term

myid[natural]:n, [token]:t([term]; [binding].[term])

5.4.5 Exploded Terms

Exploded terms provide access to the internal structure of a term, allowing users to change its opid,the number and kind of its parameters, or its arity. They are most commonly used for creating newterms in an abstraction or for changing the definition of an abstraction.

A term constructor is exploded by replacing it by a special collection of terms that make itpossible to edit its structure. Exploded terms may be generated from scratch by typing exterm intoan empty term slot, or by positioning the term cursor over a term and typing 〈C-X〉ex. Explodedterms may be imploded again into the term which the exploded term represents by typing 〈C-X〉im.The commands for editing exploded terms are summarized in the table below.

〈C-X〉ex explode-term explode term at cursor〈C-X〉im implode-term implode term at cursorexterm insert-term-exterm insert new exploded termlparm insert-term-lparm insert level expression parametervparm insert-term-vparm insert variable parametertparm insert-term-tparm insert token parametersparm insert-term-sparm insert string parameternparm insert-term-nparm insert natural number parameter〈C-O〉 open-list-to-left open new slot to left〈M-O〉 open-list-to-right open new slot to right

The editor is somewhat intelligent when new slots with open-list-to-left and open-list-to-right. Depending on the context, the new slot will be a placeholder for a bound term ([bterm]),bound variable ([bvar]), or a parameter ([parm]).

To show how exploded terms are used, we walk through the entry of the term xfoobar:s(A;x.B)y.Create an empty term slot and enter xexterm spcy. The highlighted term should look like:

EXPLODED<<[opid] ([bterm])>>Enter the opid xfooy to get:

EXPLODED<<foo ([bterm])>>Click left on the , and you should get a null width term cursor sitting on an empty term sequencefor parameters.

EXPLODED<<foo ([bterm])>>Enter 〈C-O〉 to add a new slot to the parameter sequence:

EXPLODED<<foo [parm]([bterm])>>Insert the string parameter with text bar by typing xsparm | bary:

EXPLODED<<foo bar:s([bterm])>>Click left on the [bterm] and enter 〈C-O〉〈C-O〉 to make a two element sequence for bound terms,leaving the cursor on the left-most element.

76

EXPLODED<<foo bar:s([bindings].[term];[bindings].[term];)>>Enter 〈C-O〉 | to open up a slot in the sequence, and enter a binding variable term:

EXPLODED<<foo bar:s(.[term];[bvar],.[term];)>>You could now go ahead and fill in the binding variable, and subterm slots by typing xA | x | B |y.

EXPLODED<<foo bar:s(.A;x,.B;)>>Finally, click left on any part of EXPLODED and then enter x〈C-X〉imy to implode the exploded

terms. You should now have the term:

foobar:s(.A;x.B)In general, when imploding and exploding terms the parameter values, binding variable names,

and subterms stay the same, so entering and/or editing them when a term is exploded has the sameeffect as when the term is imploded.

5.5 Cursor and Window Motion

Nuprl’s editor supports two basic forms of cursor motion. Screen oriented cursor motion commandsignore the structure of the term in the window and allow one to quickly navigate to parts of thescreen. In contrast to that tree oriented cursor motion commands follow the structure of the termtree. In addition to key sequences mouse commands allow easy jumping around terms and searchcommands allow moving the cursor to a particular substring.

5.5.1 Screen Oriented Motion

〈C-P〉 screen-up move cursor up 1 character〈C-B〉 screen-left move cursor left 1 character〈C-F〉 screen-right move cursor right 1 character〈C-N〉 screen-down move cursor down 1 character〈C-A〉 screen-start move to left side of screen〈C-E〉 screen-end move to right side of screen〈C-L〉 scroll-up scroll window up 1 line〈M-L〉 scroll-down scroll window down 1 line〈C-V〉 page-down move window down 1 page〈M-V〉 page-up move window up 1 page〈C-T〉 switch-to-term switch to term mode

Screen oriented cursor motion commands are listed in the table above. After a screen cursorcommand the cursor is always either in text mode or screen mode. To switch to term mode, onemay use the switch-to-term command if the cursor is over the printing character of a displayform. If the cursor is moved over the top or bottom of the display, the window scrolls appropriately.There are also explicit window scrolling commands.

77

5.5.2 Tree Oriented Motion

〈M-P〉 up move up to parent〈M-B〉 left structured move left〈M-F〉 right structured move right〈M-N〉 down-left move to leftmost child〈M-M〉 down-right move to rightmost child〈M-A〉 leftmost-sibling move to left-most sibling〈M-E〉 rightmost-sibling move to right-most sibling〈M-<〉 up-to-top move up top of term〈C- lfd 〉 right-leaf next leaf to right〈M- lfd 〉 left-leaf next leaf to left | right-empty-slot next empty slot to right〈C- | 〉 right-empty-slot next empty slot to right〈M- | 〉 left-empty-slot next empty slot to left

up, left, right, down-left, down-right are the basic walking commands. These commandsrecognize text and term sequences, and skip over their internal structure. Within text slots, leftand right stop at each word.

right-leaf, left-leaf, right-empty-slot, left-empty-slot are particularly good forrapidly moving around terms, since you can often get where you want to go by just repeatedlyusing one of them. Note that | is not bound to right-empty-slot within text sequences. Inthat case, you need to use 〈C- | 〉.

5.5.3 Mouse Commmands

left mouse-mark-then-set-point set mark then point〈C- left 〉 mouse-mark-then-set-point-to-term set mark then point to term

mouse-mark-then-set-point first sets the mark , an auxiliary cursor for marking regions (seeSection 5.6.2) at the current position of the editor cursor and then sets the editor’s cursor, the point ,to where the mouse is pointing. mouse-set-point results in a text cursor if one is valid betweenthe character pointed to and the character to the immediate left. If there is a null width termto the immediate left of the mouse, it results in a term cursor pointing to that term. Otherwise,the editor cursor is set to the most smallest term that contains the character being pointed to.mouse-mark-then-set-point-to-term is like mouse-mark-then-set-point except that pointis always set to the term immediately surrounding the character being pointed to.

5.5.4 Search for Subterms

〈M-s〉 set-search-mode initialize substring search〈C-s〉 view-search-forwards search forward〈C-r〉 view-search-backwards search backward

set-search-mode initializes the search for a substring. It expects a substring to be be enteredand then sets the cursor to the next text or term slot that contains this substring. Thus a user hasto enter x〈M-s〉substring spcy to search for the first occurrence of substring . Currently, substringcannot contain whitespace.

As long as the editor is in search mode view-search-forwards move the cursor to the nextslot containing substring . view-search-backwards does the same moving backwards.

78

5.6 Cutting and Pasting

Cut-and-paste commands work on terms, segments of text slots, and segments of text and termsequences. In this section we refer to these collectively as items. Items can be saved on a save stack ,in which they are represented as terms. Often it is possible to cut one kind of item and then paste itinto another kind of context. For example, one can cut a term and paste into text sequence, or cuta segment of text from a text slot and paste into a term sequence. Within the context of Nuprl’seditor, cut-and-paste commands have the following meaning:

save: push a copy of an item onto the save stack, leaving the item in place. Similar to copy-as-killin Emacs.

delete: remove an item from a buffer without saving it.

cut: (= save + delete) remove an item from a buffer and push it onto the top of the savestack. Similar to kill in Emacs, although Nuprl does not append together items that werecut immediately one after the other.

paste: insert the item on top of the stack back into a buffer, removing it from the stack. Successivepastes thus retrieve items that were saved earlier.

paste-copy: insert the item on top of the stack back into a buffer without removing it from thestack. This is useful for making several copies of an item. Similar to yank in Emacs.

paste-next: remove the item just pasted from the buffer and paste the item that is now on top ofthe stack. Can only be used immediately after a paste. By repeating paste-next one mayback through the save stack for some desired item. Similar to yank-next in Emacs.

5.6.1 Basic Commands

del delete-char-to-left delete char to left of text cursor〈C-D〉 delete-char-to-right delete char to right of text cursor〈M-D〉 cut-word-to-right cut word to right of text cursor〈C-K〉 cut cut term〈M-K〉 save save term〈C-M-K〉 delete delete term〈C-Y〉 paste paste item〈M-Y〉 paste-next delete item then paste next item〈C-M-Y〉 paste-copy paste copy of item

delete-char-to-left and delete-char-to-right are conventional character deletion com-mands. They only remove the character without saving it on the save stack. They can be used inany text slot of a term or in a text sequence and also work on newline terms in text sequences.

cut-word-to-right cuts the word to the right of a text cursor. If a term is to the immediateright of a text cursor in a text sequence, then that term is cut. cut, save, and delete work ona term underneath a term cursor as described above. These commands work fine on terms in textand term sequences. Note that deleting a term leaves an empty term slot.

When a term cursor is at an empty term slot, the paste and paste-copy commands paste theterm on top of the stack into the slot. paste-next replaces the last term pasted with the term ontop of the paste stack. It should only be used immediately after a paste or a previous paste-next.

79

5.6.2 Cutting and Pasting Regions

A region is a segment of any text slot, or a segment of a text or term sequence. A region is delimitedby the editor’s term or text cursor and an auxiliary text or term cursor position. Following Emacs’sterminology, we call the cursor’s position the point and the auxiliary cursor position the mark . Itdoes not matter whether mark is to the left or the right of point when selecting a region. In whatfollows, we call the left-most of point and mark the left delimiter , and the right-most the rightdelimiter . If a term is used as a region delimiter, the term is included in the region.

Various regions are acceptable. For selecting a text string in a text slot, both delimiters mustbe text cursor positions. For selecting a segment of a term sequence, both delimiters must be termcursor positions. For selecting a segment of a text sequence, text or term cursor positions may beused for each delimiter. The commands for cutting and pasting regions are shown below.

〈C- spc 〉 set-mark set mark at point〈C-X〉〈C-X〉 swap-point-mark swap point and mark〈C-W〉 cut-region cut region〈M-W〉 save-region save of region〈C-M-W〉 delete-region delete region

set-mark sets the mark to the current cursor position while swap-point-mark swaps themark and the editor cursor. This command is often used to check the mark’s position.

save-region saves a region onto the save stack. delete-region deletes the region. If theregion is of a text slot or a text sequence, delete-region leaves a text cursor at the old positionof the region. If the region is of a term sequence, an empty term slot is left in place of the region.cut-region has the same effect as a save-region followed by a delete-region.

The paste commands for regions are the same as the basic paste commands described above.One can paste with a text cursor in a text slot or text sequence, and a term cursor at any emptyterm slot. Pasting a sequence into another sequence of the same kind merges the pasted sequenceinto the sequence being pasted into. In this event, the point is set to be the left-delimiter for thesequence just pasted and the mark is set to be the right-delimiter. This ensures proper functionalityfor the paste-next operation. Otherwise, pasting and item into a sequence always incorporatesthe item as a single sequence element and both the mark and point are set to that element. Notethat it does not make sense to try to paste a term or a text sequence containing a term into a textslot that is not in a text sequence.

5.6.3 Mouse Commands

left mouse-mark-then-set-point set mark then point〈C- left 〉 mouse-mark-then-set-point-to-term set mark then point to term〈C- middle 〉 mouse-paste paste region〈M- middle 〉 mouse-paste-next replace last paste with new paste〈C-M- middle 〉 mouse-paste-copy paste copy of region on stack〈C- right 〉 mouse-cut cut term or region〈M- right 〉 mouse-save save term or region〈C-M- right 〉 mouse-delete delete term or region

mouse-set-point and mouse-set-term-point first set the mark at the current editor cursorposition and then set the point to where the mouse is pointing, as described in Section 5.5.3. These

80

commands are set up so that a region can be selected by using them at both ends; after the secondmouse-set-point the mark will be at one end of the region and point will be at the other.

mouse-paste, mouse-paste-next, and mouse-paste-copy are the same as paste, paste-next, and paste-copy. mouse-cut is the same as cut-region in text sequences and text slotsand the same as cut otherwise. mouse-save and mouse-delete behave similarly. Note all thatthese commands do not move the point before cutting and pasting.

5.7 Utilities

Nuprl’s term editor provides various utility commands that are shown in the table below. Theidentify-term, suppress-dform and unsuppress-dform commands assist in interpreting unfa-miliar or ambiguous display forms. Exploding a term reveals its internal structure. Viewing abstrac-tion and display form definitions of a term help understanding the formalization of a user-definedconcept and its notation. The latter two commands can also issued via mouse commands.

〈C-X〉id identify gives info on term at cursor〈C-X〉su suppress suppress display form at cursor〈C-X〉un unsuppress unsuppress display form at cursor〈C-X〉ns term-insert-null insert empty string in text slot〈C-X〉df view-disp view display form def for term〈C-X〉ab view-abs view abstraction def of termmiddle view-disp view display form of termright view-abs view abstraction definition of term

identify will print out in the ML Top-Loop window information on the term and display form atthe current cursor position.

suppress suppresses use of the display form of all occurrences of the term pointed to by the cursorin the currently viewed object. If multiple display forms are defined for a term, a singlesuppress-dform might result in some other more general display form being selected. Inthis case one can repeat suppress-dform. When all appropriate display forms for a termare suppressed, the term is displayed in uniform syntax.

unsuppress restores a suppressed display form if the editor cursor is at a term to which that sup-pressed display form belongs. Display forms remain suppressed until explicitly unsuppressedor until the editor window is closed.

term-insert-null is useful for inserting empty text strings into text slots. Normally, when all thecharacters in a text slot that is outside of a text sequence are deleted, a text slot placeholderis left to indicate what kind of item should be inserted into the slot. Use this command if anempty string is what is really wanted.

view-dform and mouse-view-disp open the display form object that defines the display form ofthe term pointed to by the editor cursor (or the mouse).

view-abstraction and mouse-view-ab open the abstraction object that defines the type theo-retical meaning of the term pointed to by the editor cursor (or the mouse).

81

(c-U) open term slot del delete char to left of text cursor(cm-I) init term slot with prl term 〈C-D〉 delete char to right of text cursor(c-O) open term slot and init 〈M-D〉 cut word to right of text cursor〈C-Q〉 close window without saving 〈C-K〉 cut term〈C-Z〉 save, check, and close window 〈M-K〉 save term〈C-J〉 jump to next window 〈C-M-K〉 delete term| !| jump to ML top loop 〈C-Y〉 paste itemx insert char x 〈M-Y〉 delete item then paste next item〈C-#〉num insert special char x 〈C-M-Y〉 paste copy of item | insert newline 〈C- spc 〉 set mark at pointname insert name 〈C-X〉〈C-X〉 swap point and mark〈C-I〉name insert name 〈C-W〉 cut region〈M-I〉name insert name 〈M-W〉 save of region〈C-S〉name replace with name 〈C-M-W〉 delete region〈C-M-I〉 initialize term slot 〈C-(Y〉 paste region〈C-M-S〉 selects dform variations 〈M-Y〉 replace last paste with new paste〈C-U〉 open slot to left of cursor 〈C-M-Y〉 paste copy of region on save-stack top〈M-U〉 open slot to right of cursor left set mark then point〈C-O〉 open slot to left and init 〈C- left 〉 set mark then point to term〈M-O〉 open slot to right and init middle view display form of term〈C-C〉 close slot and move left 〈C- middle 〉 as paste〈M-C〉 close slot and move right 〈M- middle 〉 as paste-next〈C-P〉 move cursor up 1 character 〈C-M- middle 〉 as paste-copy〈C-N〉 move cursor down 1 character right view abstraction definition of term〈C-B〉 move cursor left 1 character 〈C- right 〉 cut term or region〈C-F〉 move cursor right 1 character 〈M- right 〉 save term or region〈C-A〉 move to left side of screen 〈C-M- right 〉 delete term or region〈C-E〉 move to right side of screen 〈C-X〉id gives info on term at cursor〈C-L〉 scroll window up 1 line 〈C-X〉su suppress display form at cursor〈M-L〉 scroll window down 1 line 〈C-X〉un unsuppress display form at cursor〈C-V〉 move window down 1 page 〈C-X〉ex explode term at cursor〈M-V〉 move window up 1 page 〈C-X〉im implode term at cursor〈C-T〉 switch to term mode 〈C-X〉ch check object〈M-P〉 move up to parent 〈C-X〉sa save object〈M-B〉 structured move left 〈C-X〉ab view abstraction def of term〈M-F〉 structured move right 〈C-X〉df view display form def for term〈M-N〉 move to leftmost child 〈C-X〉ns insert empty string in text slot〈M-M〉 move to rightmost child exterm insert new exploded term〈M-A〉 move to left-most sibling lparm insert level exp parm〈M-E〉 move to right-most sibling vparm insert variable parm〈M-<〉 move up top of term tparm insert token parm〈C- lfd 〉 next leaf to right sparm insert string parm〈M- lfd 〉 next leaf to left nparm insert natural number parm | next empty slot to right 〈C-O〉 open bterm / parm / bvar slot to left〈C- | 〉 next empty slot to right 〈M-O〉 open bterm / parm / bvar slot to right〈M- | 〉 next empty slot to left

Table 5.2: All key and mouse commands

82

% ---------------------------------------------------------------------% Arrow keys%% Default :%(UP)==(m-p)(LEFT)==(m-b)(RIGHT)==(m-f)(DOWN)==(m-n)%% Text :%(RIGHT)==(-text)(m-X)screen-right(LEFT)==(-text)(m-X)screen-left% ---------------------------------------------------------------------% Mouse keys:%(MouseLeft)==(cm-X)mouse-mark-then-set-point(c-(MouseLeft))==(cm-X)mouse-mark-then-set-point-to-term%(MouseMiddle)==(m-X)view-disp(c-(MouseMiddle))==(cm-X)mouse-paste(m-(MouseMiddle))==(cm-X)mouse-paste-next(cm-(MouseMiddle))==(cm-X)mouse-paste-copy%(MouseRight)==(m-X)view-abs(c-(MouseRight))==(cm-X)mouse-cut(m-(MouseRight))==(cm-X)mouse-save(m-X)blink(cm-(MouseRight))==(cm-X)mouse-delete%% ---------------------------------------------------------------------

Table 5.3: Term-editor fragment of the standard mykeys.macro file

5.8 Customizing the Editor

The current key bindings of Nuprl’s term editor, which are summarized in Table 5.8, are intendedto be reminiscent of Emacs’s key bindings and compatible with previous releases of Nuprl.

Users who wish to change the default bindings may do so by putting a file called mykeys.macrointo their home directory. In this file one may define bindings of keys or key combinations tocommands of Nuprl’s term editor (as well as to navigator and proof editor commands). Bindingscan be made globally or depending on the context of cursor. Table 5.3 lists the term-editor fragmentof a standard mykeys.macro file with the default bindings. Users should exercise caution whenchanging global bindings, as these may have unwanted effects on the navigator and the proof editor.

83

Chapter 6

Interactive Proof Development

Whenever an object of kind STM is opened, Nuprl’s proof editor will be invoked on it. The proofeditor provides an interactive method for constructing and modifying proofs in a highly visualfashion. Users enter a goal statement and develop its proof in a top-down fashion: proof goals willbe refined into “smaller” subgoals until all subgoals represent basic axioms or already proven facts.

In this chapter we will first describe the general structure of Nuprl proofs and then discussthe features and usage of the proof editor.

6.1 Proof Structure

Nuprl’s inference system is based on the notion of sequents. These are objects of the form

H1,...,Hn ` C bext tc

which are read as “under the assumptions Hi we can prove that the type C is inhabited by somemember t”. C is called the conclusion of the sequent and the Hi the hypotheses.1 A hypothesisis either an assumption Ai or a type declaration xi:Ti. A type declaration xi:Ti is considered tobind free occurrences of the variable xi in the terms to the right of it, that is the hypothesesHi+1, . . . , Hn and in the conclusion C. The expression t is called the extract term of the sequent.It will be constructed during the proof and remains unknown up to its completion.

Sometimes we refer collectively to the hypotheses and the conclusion of the sequent as clauses.The word goal is used either to refer to a whole sequent or to just the conclusion. Which should beclear from context.

Nuprl’s inference rules refine sequents, obtaining subgoal sequents whose proofs would sufficeto validate the original goal. Primitive rules (see Section 6.1.3.1 below) are usually characterizedby rule schemata that match placeholders for the hypotheses and conclusion against a goal sequentand instantiate subgoal sequents accordingly. They also describe how to construct the extract termof the goal sequent from extract terms of the subgoal sequents (see Section 8.1 for details). Tacticrules (Section 6.1.3.2) combine several primitive rules into a single inference rule.

Proofs are trees whose nodes contain a goal sequent and a refinement slot. The refinement slotusually contains an inference rule and the goal sequents of the children of the node are the subgoalsresulting from applying this rule to the node’s goal. If the refinement slot is empty, the node hasno children and is considered unrefined .

1The older Nuprl literature uses >> instead of the turnstyle symbol ` to separate hypotheses from the conclusion.

85

A proof is complete if it has no unrefined nodes, which means that the goals of the leaf nodesare completely proven by their inference rules. In this case, the top goal of the proof, i.e. the goal ofthe root node, is called a theorem. The extract term of a theorem can be constructed bottom-up,using the instructions contained in each of the inference rules occurring in the proof.

In Nuprl, sequents, rules, and proofs are abstract data structures that are accessible from ML.Like all system components, they are implemented in the form of abstract terms and in principle,all term editing features described in Chapter 5 can be applied to them. However, all modificationsto a proof have to pass through the proof editor before they are saved to the library, which ensuresthat all the proofs in the library are correct.

In the sections below we will briefly describe the essential aspects of these data structures.

6.1.1 Sequents

The data structure of sequents consists of a list of hypotheses H1, . . . , Hn and a conclusion C. Theconclusion is a proposition of Nuprl’s logic, while each hypothesis may either be an assumption,i.e. a proposition, or a type declaration. For the sake of uniformity, assumptions are consideredtype declarations2 with invisible variables. Furthermore, a sequent may contain hidden hypotheses.These are hypotheses that cannot be used for constructive reasoning but become accessible in partsof the proof that do not contribute to the extract term.

Sequents must be closed . Free variables in the conclusion must be declared in one of the hy-potheses while free variables occurring in hypothesis Hi must be declared in on of the hypothesesH1 . . . , Hi−1. Obviously, all variables declared in the hypotheses have to be distinct.

Sequents do not explicitly contain extract terms, since extract terms are only constructed forcomplete proofs.

In Nuprl, sequents occur only within the nodes of a proof and are therefore considered iden-tical to proof nodes with empty refinement slots. Usually Nuprl displays sequents vertically andexplicitly numbers the hypotheses, so a sequent H1,...,Hn ` C is displayed as:

1. H1...

n. Hn

` C

Variables, whose name starts with a % character are considered invisible and will not be displayed.

The system provides a few ML functions for accessing the components of a sequent.

var of declaration: assumption -> vartype of declaration: assumption -> termis hidden declaration: assumption -> boolmk declaration: (var # term # bool) -> assumption

conclusion: proof -> termhypotheses: proof -> assumption listmk sequent: (var # term # bool) list -> term -> proof

Advanced users may take advantage of these functions when developing proof tactics that analyzethe contents of a sequent in order to determine appropriate inferences.

2Since Nuprl’s type theory incorporates the propositions-as-types principle, which associates logical propositionswith the type of all their proofs, all the clauses of a sequent contain types.

86

6.1.2 Proof Objects

Proof trees are implemented in Nuprl as recursive data structure, consisting of either

• an unrefined goal sequent g, or

• a goal sequent g, an inference rule r, and a list p1, . . . , pn of proofs.

Thus each sub-tree of a proof is considered a proof as well, which makes it possible to reasonlocally. The Nuprl proof editor (see Section 6.2 below) enables users to focus on any node of aproof tree and to view the corresponding sub-proof as a full proof object.

The sequent g in a proof object is referred to as the (root) goal of the proof and the goals ofthe proofs p1; . . . ; pn in a refined proof are referred to as its subgoals. A proof is good if

1. every sequent in the proof is closed,

2. in every sequent all variables declared in the hypotheses are distinct, and

3. at every refined node of the proof tree, the subgoals are the result of applying the rule r tothe root goal g.

A proof is complete if it is good and contains no unrefined nodes. A proof is incomplete if it is goodbut does contain unrefined nodes.

Each statement object in Nuprl’s library is associated with a list of proof objects with thesame root goal, sometimes referred to as the main goal of the statement object. The main goalmust be an initial sequent , i.e. a sequent with an empty hypotheses list. The main goal is a theoremif at least one of its proofs is complete.

If a statement object is linked to more than one proof object, one of them is considered theactual proof. The proof editor enables users to switch between proofs for the same statement, whichallows them to formalize different approaches to solving the same problem or to work on a “better”proof for a theorem while preserving the existing ones.

The system provides a few ML functions for accessing the components of a proof.

var of hyp: int -> proof -> vartype of hyp: int -> proof -> term

conclusion: proof -> termhypotheses: proof -> assumption listrefinement: proof -> rulechildren: proof -> proof list

mk sequent: (var # term # bool) list -> term -> proofrefine: rule -> tactic

The function mk sequent is the only way to build unrefined proofs in Nuprl, while refine is theonly way for constructing functions that modify proofs from scratch. The proof editor implicitlymakes use of these functions when a user initiates and refines a proof.

6.1.3 Refinement Rules

Refinement rules in Nuprl serve two purposes. They decompose a goal sequent into a list of subgoalsequents and they provide a validation, which transforms evidence for the validity of the subgoalsinto evidence for the validity of the original goal. Refinement rules are therefore implemented asfunctions that transform a proof into a list of (unrefined) proofs and a validation v. The validationin turn is a function transforms a list of proofs into a proof.

87

A refinement rule is correct , if the validity of the generated subgoals g1; . . . ; gn implies the valid-ity of the root goal g, and if the validation v transforms complete proofs p1; . . . ; pn for the subgoalsinto a complete proof p for the root goal. Logically, validations only prove for the correctness ofthe rule applications. Computationally, however, they provide evidence for the validity of the maintheorem and can therefore be used for building the extract term of a theorem.

Nuprl distinguishes two kinds of rules. Primitive refinement rules are the basic rules of in-ference that constitute the formal theory on which Nuprl is founded. Tactic rules are the basisfor automating the application of primitive rules. Tactics can only be constructed by combining(converted) primitive rules and other tactics into a new refinement rule. This guarantees that thecorrectness of proofs generated by tactics only depends on the correctness of the primitive inferencerules, which in turn are justified semantically.

6.1.3.1 Primitive Refinement Rules

Nuprl’s primitive refinement rules are all introduced by rule objects (see Section 8.1.1) in thesystem’s library. The current system has primitive rules for a constructive type theory that is closelyrelated to Martin-Lof type-theory (see Appendix A.3 for a complete list of rules). All Nuprl proofsare eventually justified by these primitive rules.3

The correctness of a Nuprl proof depends only on the correctness of these rules and of Nuprl’srefiner. The refiner is a fixed piece of Lisp that applies primitive rules to unrefined leaves of proofs.

In contrast to previous releases of Nuprl, users of Nuprl 5 cannot invoke primitive rulesdirectly. The proof editor expects users to enter tactics when refining a proof, which means thatprimitive rules have to be converted into tactics before they can be applied (see Section 8.1.3).Furthermore, using primitive rules would require users to understand how mathematical conceptsare coded within type-theory. Tactics operate at a higher level of reasoning and are much easier todeal with.

6.1.3.2 Tactic Rules

As explained in detail in Chapter 8, tactics are ML functions that enable one to automate applica-tion of primitive rules. If one applies a tactic to a proof and the tactic does not fail, then the tacticreturns a proof built entirely from primitive rules. The Nuprl proof editor treats a tactic like asingle inference rule and only displays the unrefined leaves of the generated proof tree. Users mayview the generated primitive proof on demand.

More precisely, if a tactic rule is applied to a proof node, the Nuprl proof editor will performthe following steps.

1. The ML text of the tactic is interpreted by the ML system and applied to the current proofnode, resulting in a proof tree p with unrefined leaves p1, . . . , pn. Note that the root goal ofp is always identical to the goal sequent of the current proof node and that p also includesvalidations.

2. Instead of simply replacing the proof node by the proof p, the editor stores p together withthe tactic text in a tactic rule.

3. The tactic rule is inserted as refinement of the proof node and the leaves p1, . . . , pn becomethe new children of the node.

3This may change in the future, as Nuprl may also accept proofs provided by external proof engines withouttransforming them into type-theoretical proofs

88

The display of the tactic rule hides the proof tree p. When one views a tactic rule refinement, oneonly ever sees the text of the tactic. From a logical point of view, it is not strictly necessary tokeep p around at all, after the tactic has executed. However, it is necessary to access the validationcontained in the proof when constructing the extract term of the main theorem.

Running a tactic as a refinement rule makes it appear in a proof as a high level rule of inference,and consequently greatly increases the readability of proofs.

Note that applying a tactic rule to an already refined proof node overwrites the existing prooftree. The editor first discards the existing refinement of the node and then proceeds as describedabove. The previous refinement, however, remains stored in the library and can still be accessedand reinserted into the proof.

6.2 The Proof Editor

The proof editor is designed to support the top-down refinement style generation of proofs. Therefinement style entails repeatedly choosing an unrefined leaf node of a proof and a rule to tryon that node. If the rule applies, the Nuprl system changes the node to a refined node, andautomatically generates appropriate children nodes.

The proof editor generates windows onto sections of proofs. One can have windows open ondifferent proofs at the same time, and even view multiple proofs of the same theorem. In the latterevent, one proof is the main proof while the other ones are backup proofs.

6.2.1 Proof Window Format

Each proof window is associated with a node of a proof. It shows the goal sequent at that node,the refinement rule (if any) at that node, the immediate subgoals, and the proofs (if any) of thesesubgoals, as long as they fit into the window. Figure 6.1 shows an example of a window onto arefined node of a proof and an example of a window onto an unrefined node of a proof.

- PRF: intsqrt

©1 # top 1©2©3 1. x:N

` ∃y:N. y2≤x ∧ x<(y+1)2

©4 BY NatInd 1

©5 # 1 1.....basecase.....` ∃y:N. y2≤0 ∧ 0<(y+1)2

©6 BY exR p0qThere is 1 hidden subgoal

©5 # 1 2.....upcase.....1. x:Z2. 0<x3. ∃y:N. y2≤x-1 ∧ x-1<(y+1)2

` ∃y:N. y2≤x ∧ x<(y+1)2

©5 BY

- PRF: intsqrt

©1 # top 1 2©2 .....upcase.....©3 1. x:Z

2. 0<x3. ∃y:N. y2≤x-1 ∧ x-1<(y+1)2

` ∃y:N. y2≤x ∧ x<(y+1)2

©4 BY

Figure 6.1: Proof window on refined and unrefined proof node

89

The title of each window contains the indicator PRF, denoting the kind of the object beingviewed, and the name of the statement object associated with the proof. The numbered parts ofthese windows are as follows:

©1 The # indicates that this proof node is considered incomplete. Other symbols used here are *for complete, and - for bad proofs.The top 1 and top 1 2 are tree addresses of the nodes being viewed. The left window showsthe first child of the root of the proof and the right window shows the second child of thatproof node.

©2 Some nodes are annotated to indicate the nature of the proof goal. Typical annotations are wffor well-formedness subgoals or upcase and downcase in inductive proofs. These annotationsmay be used by tactics but are mainly intended to assist the users.

©3 This is the goal sequent of the proof node. Hypotheses are numbered and listed vertically.The conclusion is at the bottom after the turnstyle.

©4 This is a tactic which was executed on the goal ©3 above in order to generate the subgoals ©5below. The BY is part of the proof node display, and is not part of the tactic.In an unrefined proof, there is an empty text slot after the BY.

©5 These are the subgoals of the proof node. Each subgoal comes with a status (*, #, or -), anaddress, and the subgoal sequent. For brevity, only hypotheses that have changed or beenadded are displayed in the subgoal sequents.

©6 If a subgoal has a proof, it is being displayed immediately below the subgoal as long as it fitsinto the window. If a proof is too large to be shown, the editor will only display its top-leveltactic and indicate that its subgoals are hidden. In this case users have to move into thecorresponding node to see further details or to continue editing the proof.

Sometimes the proof window is too short to display all the goal, rule, and subgoals. In this casethe cursor motion commands described in Section 5.5 will automatically scroll the window. Onecan of course also resize the window.

6.2.2 Proof Motion Commands

← move to sibling to immediate left→ move to sibling to immediate right〈M-a〉 move to left-most sibling〈M-e〉 move to right-most sibling↑ move up to parent node↓ move down to selected subgoal〈M-z〉 zoom in on current node〈C-↑〉 move up to top of proof〈C-M-j〉 jump to next unrefined node

The keyboard commands for navigating through a proof tree are summarized in the table below.In addition to these, most of the motion commands for terms described in Section 5.5 can be usedfor navigating through (the term-tree of) a proof window.4

4In contrast to previous releases, Nuprl 5 only uses arrow keys for proof-tree navigation. The emacs-like keyboardand mouse commands used in Nuprl 4 are now captured by the term editor, which has priority over the proof editor,and are thus reserved for navigating through the term tree of the proof window as described in Section 5.5.2.

90

The left-, right-, up-, and down-arrow keys move one node left, right, down, or up in the prooftree. If a node has many siblings, users may also use the key combinations 〈M-a〉 and 〈M-e〉 forlarger jumps. In each case the proof window will focus on the new node, i.e. make it the root of thecurrently displayed proof tree. The cursor will be positioned in the refinement slot of that node.The proof window on the right of Figure 6.1, for instance, results from the window on the left bypressing ↓ first and then →. Pressing the ↑ key in the right window will again produce the windowon the left.

Proof tree motion is relative to the node where the cursor is positioned. If the cursor is at thecurrent root node, then pressing ←, →, or up ↑ will move the focus to a sibling or parent node thatis currently not visible, while ↓ will focus on the first visible subgoal. If the cursor is at a subgoalof the current root node, then pressing an arrow key will move the focus relatively to that node,while pressing 〈M-z〉 will cause the proof window to focus on that node.

〈C-↑〉 causes the editor to jump to the root of the proof tree that is currently being edited, while〈C-M-j〉 causes it to jump to the next unproven subgoal in that tree, using a preorder traversal ofthe proof tree. If there are none, 〈C-M-j〉 shifts the focus to the root of the proof tree.

6.3 Stating and Proving Theorems

The proof editor is invoked whenever a statement object is opened for viewing. Usually, this isdone through the navigator by using either the right arrow key or the middle mouse button (Sec-tion 4.3.1.1). As proofs associated with statement objects are not copied when they are viewedwith the proof editor, all changes made to proofs are immediately committed to the library. This isin contrast to editing objects of other kinds (abstractions, display forms, code objects, . . . ) wherechanges are only committed when one exits the object or explicitly asks for changes to be saved.Users who want to make tentative changes to a section of a proof should first create a backup proof(see Section 6.4.3) and then work on either of the two versions.

6.3.1 Editing The Main Goal

PRF not over and

# top[goal]

BY

PRF not over and

# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

When a new proof window is opened, the window appears as depicted on the left above. A termcursor is positioned on an empty [goal] slot immediately below the root address. A user may nowenter the main goal using the structured term editor (Chapter 5).5 The window on the right, forinstance, is the result of enteringxall | A | prop | i | all | B | prop | i | implies | or | not | A | not | B | not | and | A | B |y

into the initial proof window. Pressing ↓ then moves the cursor into the text slot for proof tactics.It should be noted that the proof goal is not committed to the library until the first refinement

step has been executed. If a user closes the proof window after entering the main goal, the inputwill be discarded and the statement object remains empty. To commit a proof goal explicitly tothe library, one may use the key combination 〈C-M-g〉. This will save the main goal into a proofobject, which will be linked to the statement object that is currently being viewed.

5Currently, all input until the first | will be ignored. This is an interface bug that will be corrected in the future.

91

Using 〈C-M-g〉 is required if one wants to change an already existing main goal. Simply editingthe goal is not sufficient and an error message will be produced if a user tries to refine a modifiedproof goal that has not yet been committed.

Changing a proof by modifying either its main goal or one of the refinement steps will removeit from the proof window but not from the library. Previous versions of a proof may be recoveredby walking through the proof editor history (see Section 6.4.2 for details).

6.3.2 Refining Proof Goals

To refine a proof goal, one uses the arrow keys or the mouse to move the cursor into the text slot forentering proof tactics and then types the name of the tactic to be applied. Tactics are ML functionsthat may have Nuprl terms and other parameters as arguments (see Chapter 8). The structureand special editing commands for tactics are the same as for CODE objects. Nuprl terms may beentered using the term editor after opening a term slot with 〈C-o〉 (Section 5.4.2). Other tacticarguments have to follow the syntax of the corresponding ML data types. Tactics may include MLcomments (using % both as left and right delimiter) and newline characters, which will be insertedwhen a user types the | key.

There are two possible modes for executing a tactic. In synchronous mode, initiated by pressing〈C- | 〉, the tactic is sent to the refiner and the editor waits for the refinement process to be completebefore allowing the user to continue. Pressing 〈C- | 〉 instead initiates asynchronous refinement ,which allows the user to work on other proof goals while the proof goal is being refined. This isuseful when executing complex tactics that may take a long time to complete.

Once a (synchronous or asynchronous) refinement is successfully completed, the proof is com-mitted to the library and the proof window gets updated, showing the subgoals that were generatedby applying the tactic. If the refinement fails, an error message describing the nature of the errorand some debugging information will be inserted after the tactic and the proof goal will be markedas bad . The proof itself will not be changed.

Entering xD 0 〈C-M- | 〉y, for instance, surrounds the tactic D 0 by markers to indicate that itis currently being processed (see the window on the left below). Upon completion of the refinement,the editor removes the markers and inserts the resulting subgoals as shown in the window on theright below. The latter is also the result of entering xD 0 〈C- | 〉y.

PRF not over and# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY << D 0 >>

PRF not over and# top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY D 0

# 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY

# 2

.....wf.....P ∈ U’BY

A refinement is always initiated for the proof goal at the current location of the cursor. Usersare free to refine subgoals in any order and to modify already existing refinements. The latter willerase the proof tree at the current proof node and insert the result of the modified refinementinto the proof window (see Section 6.4.1 for details). The old proof may, however, be recovered bywalking through the proof editor history (see Section 6.4.2).

92

6.3.3 Generating Extract Terms

Proof steps are committed to the library as soon as a refinement step has been executed successfully.Users may therefore simply close the proof editor once a proof is complete. Like all other windows,the proof editor window will be closed by 〈C-q〉.

Pressing 〈C-z〉 instead will cause the proof editor to build the extract term of the proof beforeclosing the proof window. As the extract term is constructed by assembling the validations containedin the refinements of each proof node, it can only be built if the proof is complete. Using 〈C-z〉 onan incomplete proof will close the proof window but pop up a window with an error message.

Term extraction is Nuprl’s mechanism for supporting the proofs-as-programs principle. Ex-tract terms describe the computational content of a proof and the algorithms that are synthesizedwhile formally solving a program specification problem. These algorithms are proven to satisfy thespecification and can be executed by the Nuprl term evaluator as described in Section 4.4.3.1.

Once created, extract terms and the corresponding proof extract tree can also be viewed fromwithin the proof editor. Typing 〈C-M-v〉pex pops up the extract term of the saved proof, while〈C-M-v〉pet shows the proof extract tree. The windows below, for instance, show a complete proofof the statement x∀A,B:P. (¬A ∨ ¬B) ⇒ ¬(A ∧ B)y and the term extracted from that proof.

PRF not over and* top∀A,B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY D 0

* 1

1. A:P` ∀B:P. (((¬A) ∨ (¬B)) ⇒ (¬(A ∧ B)))

BY Auto

* 1 1

2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)


* 2

.....wf.....P ∈ U’BY Auto

extract: not over andRefresh* Quit*(get prf extract Obid: not over and)@ 2:15PM 9/10/2002

λA,B,%,%1.case % of inl(%2) => Ax | inr(%3) => Ax

6.4 Advanced Editing Features

6.4.1 Modifying existing refinements

In previous releases of Nuprl, modifications to an existing refinement of a proof node caused theentire proof tree below that node to be lost. Often however, some of the subgoals generated bythe new refinement could be solved by replaying certain parts of that proof tree. Since Nuprl 5immediately commits all successful refinement steps to the library, it is possible to reuse these stepswhen a proof is modified.

The default refinement, initiated by pressing 〈C- | 〉 (or 〈C-M- | 〉) refines the goal at thecurrent proof node and reuses the proofs of subgoals that were already refined in the previousproof. This is useful, when some of the newly created subgoals are identical to subgoals of theprevious refinement of that node. In the example below, for instance, replacing the tactic xD 0y byxD 0 THENW Autoy generates the same “main” subgoal and initiating the refinement with 〈C- | 〉preserves the proof of that subgoal (center window). In previous releases, that proof would havebeen lost and the whole proof would have become incomplete (right window).

93

PRF not over and* top 1

1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0

* 1 1

4. A ∧ B` false

BY D 3 THEN Auto

* 1 2.....wf.....A ∧ B ∈ PBY Auto


1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0 THENW Auto

* 1 1

4. A ∧ B` false

BY D 3 THEN Auto

PRF not over and# top 1

1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0 THENW Auto

# 1 1

4. A ∧ B` false

BY

Instead of reusing the proof of a specific subgoal, users may also want to reuse the tactics thathad been applied to the subgoals of the previous refinements. Using 〈M- | 〉 instead of 〈C- | 〉causes Nuprl 5 to reuse the tactic tree of the previous proof for subsequent refinements. This isuseful when the new refinement generates subgoals that are different from the previous ones butthat can be solved in the same way.

If users want to discard the original proof and just execute a single new refinement step, theymay enter the keyboard macro 〈C-M-r〉st. “step” refinement emulates the behavior of previousNuprl releases, which is meaningful if reusing the previous proof would be time-consuming and oflittle use for the new proof.

Often, users want to rearrange a proof in a way that each refinement step corresponds to anargument a human would make. Usually this means assembling several refinements steps into oneand adding a comment that describes the logical meaning of that step. Nuprl offers some supportfor this technique.6 Pressing 〈C-M-r〉kr will collect all the inference steps of the proof tree startingat the current node into a single refinement step. This step consists of a tactic that combines theindividual steps using the tacticals THEN and THENL. The window on the right below shows the resultof applying this command to the proof on the left. Extensions of this command (like accumulatingonly a certain amount of steps or inserting comments) will be added in the future.


1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0

* 1 1

4. A ∧ B` false

BY D 3 THEN Auto

* 1 2.....wf.....A ∧ B ∈ PBY Auto


1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0 THENL [D 3 THEN Auto; Auto]

Pressing 〈C-M-r〉dk turns a “kreitzed” proof back into its original form. It has no effect onrefinements that were not previously generated by 〈C-M-r〉kr.

6At some time in the past, the name kreitzing was introduced for this technique. For lack of a better name, it isstill called that way.

94

Similarly to the path stack of the navigator (Section 4.3.1.3) the proof editor enable users tojump between commonly used positions in the proof tree. Pressing 〈C-h〉 marks the current proofaddress and stores it in an address stack. Pressing 〈M-h〉 jumps back to that position and removesthe address from the stack.

Nuprl also enables users to copy a pattern of reasoning used in one proof to another proof.Pressing 〈M-k〉 copies the proof at the current node to a proof stack. 〈C-y〉 pastes the proof ontop of the proof stack into the current proof node and removes it from the stack. Pasting a proofmeans re-executing the tactics of its tactic tree until one of the tactics fails or the complete tactictree has been reused.

6.4.2 Proof History

In the course of proof development, Nuprl’s proof editor stores each refinement as a separateobject in the library. As a consequence, users may walk backward and forward through the proofhistory and continue the refinement of previous versions of the proof.

Pressing 〈C-←〉 reverts the proof window to the previous proof in the proof history while 〈C-→〉moves to the next proof, if there is one. If a user refines one of the previous proofs in the history,all subsequent proofs in that history will be discarded the new proof will be the last proof in thenew history. Users who want to save an older version of a proof to the library without modifyingit, can do so by pressing 〈C-x〉〈C-s〉 (just moving through the history does not change the storedproof). Pressing 〈C-M-e〉 reverts the proof window to the proof that was last stored in the library.

The proof history is only preserved through a proof editing session. Once the proof window isclosed the history is discarded.

6.4.3 Backup Proofs

In addition to using a temporary proof history Nuprl 5 allows users to create and edit backupproofs that are linked permanently to a statement object. This makes it possible to elaborate andkeep different proofs of the same statement and to preserve several interim versions of a proofattempt until they are not needed anymore.

Pressing 〈C-M-c〉 will create a backup copy of current proof and save it to the library. Thisproof will usually remain invisible. Pressing 〈M-→〉 pops up a proof editor window for each backupproof of the current statement.

Users may create multiple backup copies, including backups of backup proofs. The proof fromwhich all these backups were created will remain to be the main proof unless the user explicitlychanges that by pressing 〈C-M-f〉. This will declare the current proof to be the main proof fromnow on. To remove a specific proof, users may type 〈C-M-d〉 into the proof window of that proof.Typing 〈C-x〉〈C-b〉 deletes all backup proofs.

It should be noted that deleted backup proofs and the temporary proof history are still containedin the library but not linked to the statement object anymore. Expert users may still be able toretrieve them if that should be necessary.

6.4.4 Views of Proofs and Refinements

Nuprl enables users to look at proof trees in different ways. In the default view, the proof windowdisplays the addresses, goals, and refinements of each visible node. Pressing 〈C-M-t〉 will show thetactic tree instead, 〈C-M-a〉a the proof structure (i.e. the address tree), and 〈C-M-v〉v the goal

95

tree. 〈C-M-d〉 will revert to the default view. Examples of these four views are displayed in thewindows below.


1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

BY D 0 THENW Auto

* 1 1

4. A ∧ B` false

BY D 3 THEN Auto

PRF not over and* top 1BY D 0 THENW Auto

1 1BY D 3 THEN Auto


* 1 1


1. A:P2. B:P3. (¬A) ∨ (¬B)` ¬(A ∧ B)

* 1 1

4. A ∧ B` false

Users may also want to create views on specific proof parts. Pressing 〈C-M-p〉 pops up a newproof window whose main proof is the current node. This window is considered a scratch window.Users may execute refinements in this window but these refinements will not affect the originalproof. If a statement has several proofs, pressing 〈C-M-i〉 will pop up a window that containspointers to other proofs of this same statement.

PRF not over and# top 1 1

1. A:P2. B:P3. (¬A) ∨ (¬B)4. A ∧ B` false

BY D 3

# 1 1 1

3. ¬A4. A ∧ B` false

# 1 1 2

3. ¬B4. A ∧ B` false

PRF not over and# top

1. A : P2. B : P3. (¬A) ∨ (¬B)4. A ∧ B` False

BY !rule instancedirect computation hypothesis:o(#3 [1:(¬A) ∨ (¬B)] ())

# 1

3. ¬A + (¬B)4. A ∧ B` False

BY !rule instanceunionElimination:o(#3 %2 %3 ())

# 1 1

4. ¬A5. A ∧ B` False

BY !rule instancethin:o(#3 ())

# 1 1 1

3. ¬A4. A ∧ B` False

BY

# 1 24. ¬B5. A ∧ B` False

BY !rule instancethin:o(#3 ())

# 1 2 1

3. ¬B4. A ∧ B` False

BY

The keyboard macros 〈C-M-h〉 and 〈C-M-l〉 are used to show internal details of a refinementstep. 〈C-M-h〉 pops up a window that shows the the actual steps performed by the refinement tactic,while 〈C-M-p〉 shows the proof on the level of primitive inferences. An example of a primitive prooftree corresponding to simple refinement step is shown above.

96

6.4.5 Miscellaneous Features

Users may print proofs by typing 〈C-M-m〉 into the editor window. This will print a snapshot ofthe current proof to a file nuprlprint/stm-name in the user’s home directory, where stm-name isthe name of the corresponding statement object. The directory nuprlprint must already exist.

The generic commands for closing and saving editor windows have a slightly different meaningin the context of proof editing. As usual, 〈C-q〉 closes a proof window without initiating anymodifications. However, since proofs are saved after each refinement step, all editing steps thatwere performed after opening the proof editor are already committed to the library and will notbe discarded. Saving a proof window with 〈C-z〉 therefore has a somewhat stronger meaning thanjust saving its visible contents. In addition, an extract term will be created and saved, provided theproof is complete.

6.5 Customizing the Proof Editor

Table 6.5 summarizes the current commands of Nuprl’s proof editor. Users may change the key-board macros that initiate these commands by editing the file mykeys.macro, which is also used formodifying the key bindings of the term editor (Section 5.8). Modifications should be done carefullyto avoid that they affect the navigator and term editor as well.

6.6 Troubleshooting

Most proof editing mistakes can easily be corrected by typing the undo command 〈C- 〉 or bywalking backwards through the proof history with 〈C-←〉.

A common problem occurs when users try to delete a refinement rule as a whole with 〈C-k〉 or〈C-c〉. This will delete the text slot for entering refinement tactics and leave a term slot, displayedas [left]. Usually the undo command 〈C- 〉 will bring back the original rule, which can then bemodified using text editing commands. If the rule cannot be removed by text editing, for instanceif it was created by 〈C-M-r〉kr, users should instead enter xitext dfy into the [left] slot to getan empty text slot.

97

Movement← move to sibling to immediate left→ move to sibling to immediate right〈M-a〉 move to left-most sibling〈M-e〉 move to right-most sibling↑ move up to parent node↓ move down to selected subgoal〈M-z〉 zoom in on current node〈C-↑〉 move up to top of proof〈C-M-j〉 jump to next unrefined node

Inference〈C- | 〉 refine goal at current node〈M- | 〉 refine goal reusing the tactic tree below〈C-M- | 〉 asynchronously refine goal〈C-M-r〉st “step” refine〈C-M-r〉kr kreitz this subtree〈C-M-r〉dk de-kreitz this node

Copy/Paste:〈C-h〉 mark proof address〈M-h〉 goto proof at address on stack〈M-k〉 copy proof when selected〈C-y〉 paste proof on stack into current proof node

Proof Editor History〈C-←〉 reverts window to previous proof in history walk〈C-→〉 reverts window to next proof in history walk〈C-x〉〈C-s〉 save proof in window to library〈C-M-e〉 update the proof window with the current proof in the library

Saving and Deleting Proofs〈C-M-g〉 save goal to library〈C-M-c〉 make backup copy of current proof〈C-M-f〉 set current proof to be the main proof〈M-→〉 bring up backup proofs〈C-M-d〉 delete current proof〈C-x〉〈C-b〉 delete all backup proofs

Alternative Views〈C-M-p〉 create scratch window containing the current sub-proof〈C-M-i〉 pop up pointers to other proofs of the current statement〈C-M-d〉 select default view mode〈C-M-t〉 view the tactic tree〈C-M-a〉a view the address tree〈C-M-a〉v view the goal tree

Proofs Details〈C-M-h〉 show interior proof〈C-M-l〉 show primitive proof〈C-M-v〉pet show extract tree〈C-M-v〉pex show extract term

Miscellaneous〈C-M-m〉 print current proof〈C-q〉 close proof window〈C-z〉 generate extract term and close proof window

Table 6.1: Proof Editor Keyboard Macros

98

Chapter 7

Definition and Presentation of Terms

Nuprl offers users an opportunity to extend the basic language of type theory by introducing new,abstract terms whose meaning is defined in terms of existing language constructs. In addition tothat users may also modify the visual appearance of abstract terms1 and adjust the presentation offormal material without changing the formal content itself, which makes it possible to use familiarnotation or to present the same material differently to different target groups.

Users can create several kinds of library objects for this purpose. Abstractions are used to intro-duce the abstract definition of a new term, display forms define the textual presentation of abstractterms, and precedence objects assign precedences for terms to control automatic parenthesization.In Section 4.3.2.2 we briefly described how to create abstractions and display forms using the nav-igator’s AddDef* button. In this chapter we will describe the contents and features of abstractions,display forms, and precendences as well as editor support for defining them.

7.1 Abstractions

Abstractions are terms that are definitionally equal to other terms. In Nuprl they may be definedin terms of language primitives and other abstractions, but the dependency graph for abstractionsshould be acyclic. In particular, an abstraction not depend on itself. Recursive definitions can beintroduced using the AddRecDef button as described in Section 4.3.2.2.

Abstraction definitions have formlhs == rhs

where lhs and rhs are pattern terms that may contain free variables. The latter are implicitlyuniversally quantified. When Nuprl unfolds some lhs-inst instance of lhs, it first matches thisinstance against the pattern lhs and generates bindings for the free variables of lhs accordingly. Itthen applies these bindings to the free variables in rhs to calculate the term rhs-inst into whichlhs-inst unfolds. Therefore, all free variables of rhs must also occur free in since otherwise unfoldinga definition would yield a term with unbound variables. An example of an abstraction object isgiven below.

- ABS: int seg

i..j− == k:Z | i ≤ k < j

1This includes user defined terms, primitive terms of Nuprl’s type theory, and even the terms used for describingNuprl editing features such as the navigator, proof terms, or the appearance of abstractions and display forms.

99

The abstraction defines a type of segments of integers. The abstraction object int seg alreadyconsults a display form in the presentation of the left hand side of the definition. The structureof the left hand side becomes more readily apparent if we write it in uniform syntax (which canbe made visible by exploding the term as described in Section 5.4.5). xi..j−y is xint seg(i;j)y,a term with opid int seg, no parameters, and two subterms. An instance of the left hand side isx0..10−y, which would unfold to x k:Z | 0 ≤ k < 10 y.

Just as abstractions can be unfolded by applying their definition left-to-right, so instances oftheir right hand sides can be folded up to be instances of their left hand sides. Folding, however doesnot always work, as information can be lost in the unfolding process. For instance, an abstractioncan have variables and parameters that are not used in its definition but are only used for “book-keeping purposes”. In this case the variables and parameters only occur on the left hand side of thedefinition and would have to be inferred when folding up a specific instance of the right hand side.

7.1.1 Bindings in Abstractions

In additions to ordinary variables, abstractions can have binding structure. Consider, for instance,the definition of the unique existence quantifier below.

- ABS: exists uni

∃!x:T. P[x] == ∃x:T. P[x] ∧ (∀y:T. P[y] ⇒ y=x ∈T)

Here x represents a variable that becomes bound in the term P[x] and this binding structuremust be mapped from the abstract term xexists uni(T; x.P[x])y to its definition

First-order matching and substitution are inadequate for handling terms with binding struc-ture, since they consider variables to be independent from each other and thus cannot express thedependency between x and P[x]. Nuprl’s therefore uses second-order matching and substitutionfunctions to handle abstractions with binding variables in a systematic way.

A second-order binding is a binding v 7→ x1, . . . , xan .t of a second-order variable v to asecond-order term x1, . . . , xan .t. A second-order variable is essentially an identifier as with normalvariables, but it also has an associated arity n≥0. Second-order terms are a generalization of termsthat can be thought of as ‘terms with holes’, i.e. as terms with missing subtrees.2 They can berepresented by bound-terms such as x1, . . . , xan .t, where the binding variables are place-holders forthe missing subtrees. In a second-order binding v 7→ x1, . . . , xan .t, the arity of v must be equal to n.

An instance of a second-order variable v with arity n is a term v[a1; . . . ; an], where a1, . . . , an

are terms, also called the arguments of v. A second-order substitution is a list of second-orderbindings. The result of applying the binding [v 7→ w1, . . . , wn.tw1,...,wn ] to the variable instancev[a1; . . . ; an], is the term ta1,...,an – the arguments of the instance of the second-order variable fillthe holes of the second-order term.

In our above example, P is a second order variable with arity 1, and the terms P[x] and P[y] aresecond-order-variable instances. Consider unfolding an instance of the left-hand side, say the termx∃!i:Z. i=0 ∈Zy. The substitution generated by matching this against x∃!x:T. P[x]y would be

[ P 7→ i. i=0 ∈Z ; T 7→ Z ]

and the result of applying this to the right hand side of the definition would be

∃x:T. x=0 ∈Z ∧ (∀y:Z. y=0 ∈Z ⇒ y=x ∈Z)2Roughly, second-order terms are like functions on terms but there are subtle differences between the two concepts.

100

Actually, the matching and substitution functions used by Nuprl are a little smarter thanshown above, as they try to maintain names of binding variables. The result one would get inNuprl would be x∃i:T. i=0 ∈Z ∧ (∀y:Z. y=0 ∈Z ⇒ y=i ∈Z)y.

Nuprl does not allow nested bindings on the left-hand side of abstraction definitions. Allvariables must either be first-order or second-order variables with first-order variable arguments.

7.1.2 Parameters in Abstractions

Abstractions can also contain meta-parameters, i.e. placeholders for parameters that matching andsubstitution treat as variables. We usually indicate that a parameter is meta by prefixing it with a$ sign. For example, we might define an abstraction labelx:t,i:n as shown below

- ABS: label

label$tok:t,$nat:n() == <"$tok",$nat>

Meta-parameters make it possible to map parameters in newly defined abstractions onto pa-rameters of existing terms. In the above example labels are defined as pairs of tokens and naturalnumbers and the parameter $tok is mapped onto the parameter of the term token while the pa-rameter $nat is mapped onto the parameter of the term natural number, which is revealed whenthe right hand side of the definition is exploded into xpair(token$tok:t;natural$nat:n)y.

Level-expression variables occurring in level-expression parameters of abstraction definitionsare always considered meta-parameters, so there is no need to designate them explicitly. However,indicating meta-parameters explicitly makes it easier to identify them as such.

In general, the term on the left-hand side of an abstraction can have a mixture of normal andmeta-parameters. You can define a family of abstractions which differ only in the constant valueof some parameter. However, it is an error to make two abstraction definitions with left-hand sidesthat have some common instance.

7.1.3 Attributed Abstractions

A recently added feature of abstraction definitions is an optional list of attributes or conditions. Anattribute is simply an alpha-numeric label associated with the abstraction and the general form ofan abstraction with conditions c1, . . . , cn is:

(c1,. . .,cn)::lhs == rhs

Abstraction conditions can be used to hold information about abstractions that may be usefulto tactics and other parts of the Nuprl system. They could, for instance, be used to group ab-stractions into categories, and when doing a proof, one could ask for all abstractions in a givencategory to be treated in a particular way, e.g. to unfold all abstractions of a category “notationalabbreviations”.

7.1.4 Editor Support

In this section, we describe the editor support for abstraction objects. An abstraction can be viewedby opening it with the navigator (Section 4.3.1.1) or by using the view-abstraction command(〈C-X〉ab) on a term containing an instance of it (Section 5.7). The following commands and keysequences may be used for editing abstractions.

101

〈C-M-I〉 initialize initialize object / conditionso varn insert-termso varn insert second order var with n args〈C-M〉 cycle-meta-status make parameter meta / normal〈C-M-S〉 select-term-option open condition sequence〈C-O〉 open-seq-to-left open slot in cond seq to left〈M-O〉 open-seq-to-right open slot in cond seq to right

Since most abstraction objects are created using the AddDef* mechanism described in Sec-tion 4.3.2.2, the left and right hand side of the abstraction is already present when the object isopened. In the rare case that the abstraction object was created with the MkObj* command button(Section 4.3.2.1) it will contain an empty term slot when it is first visited, which must be initializedbefore a definition can be entered.

The initialize command will create an uninstantiated abstraction definition term, which looks like:

[ab lhs] == [ab rhs]

To enter the abstract term on the left hand side of the definition, one has to provide its objectidentifier , its parameters, and a list of its subterms together with the variables to be boundin these subterms. Ways to create new terms with the term-editor are described in Sections5.4.4 and 5.4.5. The term for the right hand side of the definition is entered in the usualstructural top-down fashion of the term-editor as explained in Section 5.4.

so varn has to be used to enter second order variable instances on the left and right hand sidesof the definition. This will insert a term of the form xvariablex:v(a1;. . .;an)y where x isthe variable’s name, and n > 0 is a natural number. The library display form object for thisterm is named so varn so this family of names can be used to reference them.

Note that abstraction objects are the only places where these second-order variable instancesare used. When writing propositions, second-order variable instances are simulated using theso applyn abstraction.

cycle-meta-status converts a parameter into a meta-parameter if the text cursor is in the pa-rameter’s text slot. If the parameter is already meta, using this twice will cycle its status backto being a normal parameter.

select-term-option enables a user to add conditions to an abstraction. By default, an abstrac-tion definition term has an empty condition sequence as a subterm, which is hidden by thedisplay form for abstractions. Moving the term cursor over the whole abstraction term andusing select-term-option will add an empty term slot for a condition. The condition termis much like the term for variables; it has a single text slot, and otherwise no other dis-play characters. To get additional slots for condition terms one may use open-seq-to-leftor open-seq-to-right.

7.2 Term Display

Display form objects are used to control the visual presentation of formal mathematical concepts.They define how a term shall appear when it is being displayed on the screen or printed on paper.This enables users to present formal content within a variety of notations without having to changethe internal logical representation of these terms. Display forms are commonly created whenevera definition is introduced using the AddDef* mechanisms (Section 4.3.2.2), but they may also beadded for existing abstractions as well as for the primitive terms of the library.

102

def-seq ::= definition ;;| definition ;; def-seq

definition ::= format-seq == term| attr-seq :: format-seq== term

format-seq ::= format| format format-seq

attr-seq ::= attribute| attribute :: attr-seq

Figure 7.1: Display Object Structure

In Nuprl the presentation of all formal content, including the appearance of the navigator, theeditor, sequents, and proofs is controlled by display forms and may be adjusted according to thepreferences of a user. Even the mechanisms for editing and presenting display forms themselves maybe modified. The display forms for the quantifiers (all df, exists df) and the logical connectives(and df, or df, . . . ), for instance, appear as “display form generators”.

The top level structure of a display form object is summarized by the grammar shown inFigure 7.1. An object contains one or more display form definitions. Each definition has a right-hand-side term to which the display form applies, and a sequence of formats that specify howto display the term. A definition also has an optional sequence of attributes that specify extrainformation about the definition.

Usually, all the definitions in one object refer to a closely related set of terms. When choosinga display form to use for a term, the layout algorithm tries definitions in a backward order, sodefinitions are usually ordered from more general to more specific.

7.2.1 Editing Display Form Objects

Since most display forms are created using the AddDef* mechanism described in Section 4.3.2.2,a right-hand-side term, a standard sequence of formats, and an alias attribute (see Section 7.2.4below) are already present when the object is opened. If the object was created with the MkObj*command (Section 4.3.2.1) it will contain an empty term slot, which must be initialized before adisplay form definition can be entered.The command 〈C-M-I〉 will create an initial display form definition, which looks like:

== [rhs]

To get additional slots for display form definitions one may use the commands 〈C-O〉 and 〈M-O〉.An initial display form definition has an empty attribute sequence as a subterm, which is hidden

by the display form for display form definitions. Moving the term cursor over the whole term andusing 〈C-M-S〉 will add an empty term slot for an attribute.

7.2.2 Right-hand-side Terms

The right-hand-side term is a pattern. A definition applies to some term t if t is an instance ofthe right-hand-side term. The display definition matcher has a notion of meta-variable differentfrom that of Nuprl’s usual matching routines; it has 3 kinds of meta-variable: meta-parameters,meta-bound-variables, and meta-terms.3 Meta-parameters and meta-bound-variables correspond totext slots on the left-hand side of a definition, and meta-terms correspond to term slots.

3The meta-parameters are different from those used in abstraction definitions. To be clear, we sometimes call thoseones abstraction-meta-variables and the ones in display definitions, display-meta-variables.

103

The right-hand-side term is restricted to being a term whose subterms are either constant terms,i.e. terms with no meta-variables, or meta-terms. To enter a meta-term into a term slot one hasto use the name mterm. To turn parameters and variable into meta-parameters or meta-bound-variables, position a text cursor in the appropriate parameter or bound variable slot and givethe cycle-meta-status command 〈C-M〉 (twice). Display-meta-variables are readily recognizedbecause they have <> as delimiters.

The rhs right-hand-side term may also contain normal parameters, bound variables and variableterms. These are treated like constants: for a definition to be applicable, they must match exactly.

7.2.3 Format Sequences

Format sequences are text sequences that may contain slots for meta-variables and commands forcontrolling the layout of formal material through insertion of optional spaces, line breaking, andindentation. Except for text strings, all formats must be entered into term slots, which may becreated as described in Section 5.4.2.

The various kinds of formats are summarized in the table below. The Name column gives thename that has to be entered into a term slot to create the format, while the Display columndescribes how the format will be presented within a display form definition.

Name Display Descriptionslot <id:ph> text slot formatlslot <id:ph:L> term slot formateslot <id:ph:E> term slot formatsslot <id:ph:*> term slot formatpushm →i push marginpopm ← pop marginbreak \\a breaksbreak \\?a soft breakhzone [HARD start hard break zoneszone [SOFT start soft break zonelzone [LIN start linear break zoneezone ] end break zonespace Space optional space

7.2.3.1 Slot Formats

Slot formats are placeholders for the children of a display form instance. Text slots are generallyused for meta-parameters and meta-bound-variables, while term slot formats contain meta-terms.

The id in a slot format is the name of the slot. The slot corresponds to the meta-variable ofthe right-hand-side term with the same name. ph is place-holder text, which will appear (enclosedwithin []’s) in the slot whenever it is uninstantiated in some instance of the display form. The L,Eand * options on the term slot formats control parenthesization of the slot and are discussed inSection 7.2.4.2.

7.2.3.2 Margins

The margin control format →i, where i ≥ 0, pushes a new left margin i characters to the right ofthe format position onto the margin stack. The layout algorithm uses the top of the margin stack

104

to decide the column to start laying out at after a line break. To create the format, enter pushminto a term slot and edit the number 0 in the format →0 accordingly.

The margin control format ← (popm) pops the current margin off the top of the margin stackand restores the left margin to a previous margin. Usually display forms should have matchingpushm’s and popm‘s.

7.2.3.3 Line Breaking

Line-breaking formats divide the display into nested break zones. There are 3 kinds of break zone:hard , linear , and soft . The effect of the break format \\a depends on the break zone kind:

• In a hard zone, \\a always causes a line break.

• In a soft zone, either none or all of the \\a are taken.

• In a linear zone, \\a never causes a line break. Instead, its position is filled by the textstring a, which usually is a sequence of blank characters.

Break zones are started and ended by zone delimiters. Display form format sequences should usuallyinclude matching start and end zone formats. There is one end delimiter ] (ezone) for all kindsof zones. Each kind of zone has its own start delimiter:

• [HARD (hzone) starts a hard zone.

• [SOFT (szone) starts a soft zone.

• [LIN (lzone) starts a linear zone.

A linear zone is special in that all zones nested inside are also forced to be linear. Therefore a linearzone contains no line-breaks and always is laid out on a single line. If a linear zone doesn’t fit on asingle line, the layout algorithm chooses subterms to elide (see Section 5.3) to try and make it fit.

When laying out a soft zone, the layout algorithm first tries treating it as a linear zone. If thatwould result in any elision, then it treats the zone as a hard zone.

The soft break format \\?a (sbreak) is similar to the break format but is not as sensitiveto the zone kind. Soft breaks in linear zones are never taken, but otherwise, the layout algorithmuses a separate procedure to choose which soft breaks to take and which not. This procedure usesvarious heuristics to try and layout a term sensibly in a given size window with at little elision ofsubterms as possible.

7.2.3.4 Optional Spaces

The space format Space inserts a single blank character if the character before it isn’t alreadya space. Otherwise it has no effect.

7.2.4 Attributes

Attributes specify extra information about display form definitions. By default, display form defi-nitions are created with a right-hand-side term, a standard sequence of formats, and a single aliasattribute. Moving the cursor over the whole attribute term and using 〈C-O〉 or 〈M-O〉 will createadditional attribute slots to the left or right of this attribute.

Possible display form attributes are summarized in the table below. The Name column givesthe name that has to be entered into a term slot to create the attribute, while the Display columndescribes how it will be presented within a display form definition.

105

Name Display Descriptionalias EdAlias a alias for definition inputithd #Hd a head of iteration familyittl #Tl a tail of iteration familyparens Parens parenthesis controlprec Prec a precedenceindex Index a definition nameconds (c1,. . .,cn) conditions

The alias attribute provides an alternate name which the input editor recognizes as referring tothe definition. Alternate names are often convenient abbreviations for the full names of definitions.The iteration attributes ithd and ittl control selection of a definition by the display layoutalgorithm. They are used to come up with convenient notations for iterated structures, which arediscussed in Section 7.2.4.1. The parens and prec attributes affect automatic parenthesization,described in Section 7.2.4.2. The index attribute together with the name of the object containinga definition give a unique name for the definition. Conditions specify requirements for using adisplay form definition. Each condition c1,. . .,cn in the conds term is a term with a alpha-numericlabel associated with the display form definition.

7.2.4.1 Iteration

The iteration attributes control choice of display form definition based on immediately-nestedoccurrences of the same term. The idea is to group occurrences into iteration families. An iterationfamily has a head display form definition and one or more tail definitions. A tail definition can onlybe used as an immediate subterm of a head in the same family or another tail in the same family.Choice of display form is also affected by the use of the iterate variable # as the id of a term slotformat (Section 7.2.3.1). If # is used in some term slot of a definition, then the definition is onlyusable if the same term occurs in the subterm slot that uses the #.

The following set of display forms for λ abstraction terms, for instance, makes sure that the λcharacter is suppressed on nested occurrences:

λ<x:var>.<t:term:E>== lambda(<x>.<t>)#Hd A ::λ<x:var>,<#:term:E>== lambda(<x>.<#>)#Tl A ::<x:var>.<t:term:E>== lambda(<x>.<t>)#Tl A ::<x:var>,<#:term:E>== lambda(<x>.<#>)

Using these, the term lambda(x.lambda(y.lambda(z.x))) will be displayed as xλx,y,z.xy insteadof xλx.λy.λz.xy.

7.2.4.2 Parenthesization

Automatic parenthesization is controlled by certain display definition attributes, term slot options,and by definition precedences. A precedence is an element in the precedence order , which is de-termined by the precedence objects in the Nuprl library. A display form definition is assigned aprecedence by giving it a prec attribute which names some precedence element.

Precedence Objects collectively introduce a set of precedence elements, and define a partialorder on them. The components of a precedence object and the names used to enter them by aresummarized in the table below. The prser, preq, and prpar terms are sequence constructors that

106

may be nested. The standard editor commands described in Section 5.4.2 work on the sequencesbuilt with these terms.

Name Display Descriptionprser (p1>. . .>pn) serial precedence termpreq p1=. . .=pn equal precedence termprpar [p1|. . .|pn] parallel precedence termprel obname element of precedence orderprptr *obname* precedence object pointer

Object names and object pointers are the primitive elements in a precedence order. Serialprecedence terms impose a linear order on a set of precedences p1 . . . pn. Equal precedence termdeclare all precedences pi to be equal in the precedence order. Parallel precedence terms declare allprecedences pi to have the same “rank” in the precedence order while being unrelated to each other.

Each display form not explicitly associated with any precedence element is implicitly associatedwith a unique precedence element unrelated to all other precedence elements. The uniquenessimplies that two such display forms have unrelated precedence.

Examples of a base set of precedences set up for the current Nuprl theories can be found inthe standard theory core 1.

Automatic Parenthesis Selection. The parenthesization of a term slot of a display form iscontrolled by the parenthesis slot-option, i.e. the third field of the term slot in the display formdefinition (see Section 7.2.3.1), by the parens attribute of the display form filling that term slot,and by the relative precedences of the term slot and the term filling it. The precedence of a termslot is usually that of the display form containing it, although it is possible to assign precedencesto individual slots. The parenthesis control works as follows:

• Term slots are parenthesized only if the filling display form has a parens attribute. If thisattribute is absent, the slot is never parenthesized. The parens attribute must be explicitlyadded to a display form definition for that definition to ever be parenthesized.

• Term slots are parenthesized unless parenthesization is suppressed by the parenthesis slot-options. These options have the following meanings:

L : Suppress parentheses if the display-form precedence is less than the display-form prece-dence of the term filling the slot.

E : Suppress parentheses if the display-form precedence is less than or equal to the display-form precedence of the term filling the slot.

* : Always suppress parentheses.

The L and E options make it possible to represent the conventional precedences and associativitylaws of standard infix operators. If they are used in the definitions of display forms for the arithmeticterms plus(a;b), and times(a;b), then the term plus(a;times(b;c)) is displayed as xa + b ∗ cy,but times(a;plus(b;c)) is displayed as xa ∗ (b + c)y. Similarly, function(A;function(B;C)) isdisplayed as xA→B→Cy, but function(function(A;B);C) is displayed as x(A→B)→Cy

The L, E and * characters in the display of term slot formats are display forms for parenthe-sization control terms. To change the parenthesis slot-options, one may delete the term and enterthe new option using the names shown in the table below.

107

Name Display Descriptionlparens L L optioneparens E E optionsparens * * option

The parenthesization control terms also allow the specification of the delimiter characters usedfor parenthesization, and a precedence for the individual slot. No specific editor support has yetbeen provided for these features.

7.2.5 Examples

As an example, we walk through the entry of a display form definition from scratch. We start bycreating a new display form object and viewing it. Click the MkObj* button, enter xtst dfy as nameand xdispy as kind, and click the OK* button.4

Open the object by pressing the right arrow or clicking on it with the mouse. This will pop up awindow, containing a highlighted empty term slot. Initialize the display form definition by entering〈C-M-I〉. The window now looks like:

- DISP:: tst df

== [rhs]

We begin by entering the right-hand side of the display form. Click left on the [rhs] placeholder,and enter xexists unique(0;1)y to create a new term (see Section 5.4.4). Do not fill in the variableslot or either of the subterm slots. The definition should now look like:

- DISP:: tst df

== exists unique([term];[binding].[term])

Enter | or click left on the left-most term slot and enter <T>, <x>, and as meta-terms andmeta-variable, respectively, by typing xmterm | T | x〈C-M〉 | mterm | Py. As a result you get:

- DISP:: tst df

== exists unique((<T>;<x>.)

To create a display form for the term on the right hand side, click left on the first = toget a text cursor in the empty format sequence on the left-hand side of the definition. Typex〈C-#〉163!〈C-O〉slot | x | var〈C-F〉y to generate an ∃ symbol and an exclamation mark as initialtext and a slot for the variable x. The definition should now look like:

- DISP:: tst df

∃!<x:var>== exists unique((<T>;<x>.)

Enter a colon, the type slot, a period, a space, and the second term slot:

x:〈C-O〉sslot | T | type〈C-F〉〈C-F〉〈C-F〉. 〈C-O〉eslot | P | propyThe definition should now look like:

4Note that the MkObj* button is not present in user theories. The only way to create display forms is through theAddDef* and AddDefDisp* buttons, which already generate a right-hand-side term, a standard sequence of formats,and an alias attribute.

108

- DISP:: tst df

∃!<x:var>:<T:type:*>. <P:proP:E>== exists unique((<T>;<x>.)

The display form definition is now complete and may be saved by closing the display form ob-ject with 〈C-Z〉. However, the definition does not yet include line breaking or parenthesizationinformation. In particular, it does not contain any visible delimiter for the end of the prop slot.

We therefore want the layout algorithm to automatically parenthesize the display form. To addparenthesizing attributes, click left on the second = character to get a term cursor over the wholedefinition, and then enter x〈C-M-S〉 | 〈C-O〉y to get two empty attribute slots, with a term cursorover the first:

- DISP:: tst df

[attr]::[attr]::∃!<x:var>:<T:type:*>. <P:prop:E>== exists unique((<T>;<x>.)

To instantiate the attribute slots enter xparens | prec | existsy To get:

- DISP:: tst df

Parens::Prec(exists)::∃!<x:var>:<T:type:*>. <P:prop:E>== exists unique((<T>;<x>.)

This means that we assign the same precedence to the term ∃!x:T.Px as is assigned to the term∃x:T.Px in the standard libraries.

We may also add a soft-break format such that the period separating the type slot from the propslot does not appear if a break is taken. Click left on the x.y character and delete it using 〈C-D〉.Enter x〈C-O〉sbreak spcy, click left on the after the ? character in the soft break display form,and enter x.y.

- DISP:: tst df

Parens::Prec(exists)::∃!<x:var>:<T:type:*>\?. <P:prop:E>== exists unique((<T>;<x>.)

Finally, we add a second display form for the term ∃!x:T.Px, which drops the type information fromthe display whenever the type is N.

Click left on the second = character to get a term cursor over the whole definition, and thenenter x〈M-O〉y to get a second initial display form definition after it.

- DISP:: tst df


== [rhs]

Copy the first definition into the second as follows: enter 〈C-K〉 to replace the initial display formby an empty term slot, move the term cursor over the whole first definition, copy it with 〈M-K〉,move the term cursor back over the empty term slot, and paste the first definition with 〈C-Y〉.

109

- DISP:: tst df



On the right hand side of the definition, replace the meta-term <T> by the type constant N.Click left on the < character, enter 〈C-K〉 and then type xnat |y to enter the type N.

On the left hand side, remove the term slot for T by clicking left on the > character (!) andentering 〈C-K〉. Remove the colon with backspace .

- DISP:: tst df


Parens::Prec(exists)::∃!<x:var>\?. <P:prop:E>== exists unique((N;<x>.)

In a similar way, one may add further display form definitions with iteration families to suppress the∃! string and duplicate type information in nested occurrences of the term ∃!x:T.Px. The displayform object exists df in the standard theory core 1 can be used as an example for doing that.

110

Chapter 8

Rules and Tactics

Logically, all formal reasoning in Nuprl is based on the basic inference rules of intuitionistic typetheory [ML84, CAB+86]. In practice, however, reasoning with basic inference rules can becomevery tedious. Therefore Nuprl provides the concepts of proof tactics, i.e. programmed applicationsof inference rules. Proof tactics range from straightforward applications of inference rules to fullyautomated proof search mechanisms for certain domains. Most tactics are deal with intellectuallytrivial, but formally lengthy proof details, enabling the user to concentrate on the more interestingaspects of a proof. Others mimic the particular style of reasoning in a certain application domainand can only be applied in this context. Technically, all refinement steps in Nuprl are executionsof tactics. Basic inference rules, although explicitly present in the Nuprl library, cannot be invokeddirectly but only through conversion into tactics.

In the rest of this chapter we will describe the structure of basic inference rules and tactics aswell as the most important groups of tactics that are currently implemented. Nuprl’s type theory,its semantics, and the guiding principles for its development is explained in [CAB+86]. It shouldbe noted, however, that Nuprl’s type theory is open-ended and that fundamentally new conceptsand their inference rules are added whenever this is turns out to be necessary.

A complete list of the current set of inference rules can be found in Appendix A.3.

8.1 Rules

Inference rules characterize the semantics of all formal expressions in Nuprl. For each type con-struct they describe how to form types and the conditions for two types to be equal, how to formmembers of types and the prerequisites for two members of a type to be equal in that type.

Nuprl’s proof calculus is based on the notion of sequents. These are objects of the formx1:T 1,...,xn:T n ` C, which should be read as “Under the hypotheses that the xi are variablesof type Ti a member of the conclusion C can be constructed” (see Section 6.1.1 for details).

In Nuprl a proof for such a sequent is developed in a top-down fashion. Proof rules refine a goalsequent obtaining subgoal sequents whose proofs would suffice to validate the original goal. Theyare described by rule schemata with placeholders for lists of hypotheses and conclusions. A rule

Γ ` C bext mcby rule-name (& optional arguments)

Γ1 ` C1 bext m1c...

Γn ` Cn bext mnc

111

expresses the fact that the goal sequent Γ ` C is provable if all the subgoals Γi ` Ci are. Fur-thermore, it also describes how to construct an (implicitly present) member m of C from membersmi of the subgoal conclusions Ci.

Rules may operate both on the conclusion or the hypotheses of a proof goal. In most casesthey simply decompose a type or a member of a type into smaller components. The rule for theformation of pairs, for instance, states that in order to form a member 〈s,t〉 of a product type S×Tit suffices to form a member s of the type S and a member t of T .

Γ ` S×T bext 〈s,t〉cby independent pairFormation

Γ ` S bext scΓ ` T bext tc

This rule can be applied to any goal whose conclusion is a product type. In this case S ismatched against the left, and T against the right component of that product, while Γ is matchedagainst the complete list of hypotheses. As a result, Nuprl generates two new proof goals, the firstwith the left component as proof goal and the second one with the right component. The list ofhypotheses remains unchanged in both cases.

8.1.1 Representation of Inference Rules

Nuprl’s inference rules are not hard-wired into the code of the system but explicitly represented inthe library as objects of kind rule. Rule definitions are ‘terms’ in the sense described in Chapter 5and they can be edited like any other term. The rule for the formation of pairs, for instance, isrepresented by an object called independent pairFormation.

- RULE: independent pairFormation

H ` A × B ext <a, b>BY independent pairFormation ()

H ` A ext aH ` B ext b

The fact that the rule object is almost identical to the rule described on paper, makes it veryeasy to verify the implementation of intuitionistic type theory in Nuprl. The explicit representationof inference rules in Nuprl also allows a user to modify the logic represented in system by addingnew rules or deactivating existing ones. Thus Nuprl supports any logic that can be represented asa top-down sequent calculus.

Nuprl provides the basic mechanisms for applying rule objects to proofs. In most cases thismeans matching the rule’s top goal against the current proof goal and extending the proof tree bythe instantiated sub-goals of the rule. Some rules, such as the decision procedure arith provideexplicit calls to special purpose algorithms that will be executed when Nuprl applies the rules.

- RULE: arith

H ` C ext tBY arith U

Let SubGoals t = CallLisp(ARITH)SubGoals

8.1.2 Rule Arguments

In most cases, the application of an inference rule to a proof goal requires more information thanjust the name of the rule. For instance, if a rule shall be applied to one of the hypotheses, it is

112

necessary to identify this hypothesis; or if a rule creates new variables in the subgoals, it is necessaryto give names to these variables. Because inference rules are supposed to be applied schematically,this information will not be determined automatically but has to provided as additional arguments.Inference rules may require the following arguments.

Hypothesis index. If a rule shall be applied to a particular hypothesis of the proof goal, thecorresponding index i of that hypothesis in the hypotheses list of the goal must be provided. Therule hypothesis, for instance, can be used to prove a goal if the conclusion is identical (α-equal)to one of the assumptions, but the index of that assumption must be given.

Γ, x:T,∆ ` T bext xcby hypothesis i

- RULE: hypothesis

H x:A, J ` A ext xBY hypothesis #$i

No Subgoals

Variable names. Many inferences require the creation of new variables when refining a proofgoal. The corresponding proof rules do not choose the names for these variables automaticallybut expect them to be provided explicitly. The rule functionEquality, for instance, is used toprove two dependent function types x1:S1→T 1 and x2:S2→T 2 equal. It creates two subgoals: the twodomains S1 and S2 must be equal, and the two ranges T 1[x/x1] and T 2[x/x2] must be equal for eachargument x ∈S1. The second subgoal contains a new variable, whose name must be given.

Γ ` x1:S1→T 1= x2:S2→T 2∈ Uj bAxc

by functionEquality x

Γ ` S1=S2∈ Uj bAxc

Γ, x:S1 ` T 1[x/x1] =T 2[x/x2] ∈ Uj bAxc

- RULE: functionEquality

H ` (x1:a1 → b1) = (x2:a2 → b2)BY functionEquality y

H ` a1 = a2H y:a1 ` !subst(b1; x1.y) = !subst(b2; x2.y)

Universe level. Because of the expressiveness of type theory, the well-formedness of a typeexpression cannot be decided automatically, but must be established in the course of a proof devel-opment. Whenever a rule creates a new declaration in one of the its subgoals, the well-formednessof the corresponding type must be established. If this cannot not guaranteed by the proof of theother subgoals (as in the case of functionEquality it must be proven as a separate subgoal. Therule lambdaEquality, for instance, proves the equality of two λ-terms in a function type x:S→T .For this purpose, it declares a new variable X ′ of type S and adds a subgoal stating that S belongsto some universe Uj . The level j of that universe must be given.

Γ ` λx1.t1=λx2.t2 ∈ x:S→T bAxc

by lambdaEquality j x′

Γ, x′:S ` t1[x′/x1] = t2[x

′/x2] ∈ T [x′/x] bAxc

Γ ` S ∈ Uj bAxc

- RULE: lambdaEquality

H ` (λx1.b1) = (λx2.b2)BY lambdaEquality !parameteri:l z ()

H z:A ` !subst(b1; x1.z) = !subst(b2; x2.z)H ` A = A

Values for variables. Some proof goals can only be decomposed if it is known how to instantiatea certain variable. To prove ∃x:S.T [x] – which is the same as the dependent product x:S×T [x]),for instance, one has to provide a value s for the existentially quantified variable x and can thengo on to prove T [s]. The corresponding rule dependent pairFormation requires this term as oneof its arguments.

Γ ` x:S×T bext 〈s,t〉cby dependent pairFormation j s x′

Γ ` s ∈S bAxc

Γ ` T [s/x] bext tcΓ, x′:S ` T [x′/x] ∈ Uj bAxc

- RULE: dependent pairFormation

H ` x:A × B ext <a, b>BY dependent pairFormation !parameteri:l a y ()

H ` a = aH ` !subst(B; x.a) ext bH y:A ` !subst(B; x.y) = !subst(B; x.y)

113

Type of a subterm. Sometimes decomposing a proof goal into smaller components involvesproving that certain subterms belong to a type that cannot immediately constructed from thetypes mentioned in the goal. Proving the equality of two function applications f 1t1 and f 2t2 in atype T , for instance, requires proving f 1 and f 2 equal in some type x:S→T . As this type cannotbe derived from T it must be given explicitly.Γ ` f 1 t1= f 2 t2 ∈ T [t1/x] bAxc

by applyEquality x:S→T

Γ ` f 1= f 2∈ x:S→T bAxc

Γ ` t1= t2 ∈ S bAxc

- RULE: applyEquality

H ` (f1 a1) = (f2 a2)BY applyEquality x:A → B

H ` f1 = f2H ` a1 = a2

Term dependency. Applying a proof rule may sometimes involve replacing an sub-expressione in the goal by some other expression. If e occurs several times in the goal, one must indicatewhich of the occurrences of e shall be replaced and which one shall not. Technically, this is doneby providing a term substitution: all occurrences of e in the term C that shall be affect by therule application are replaced by a new variable z. The rule will then substitute every occurrence ofz by the new expression. Both z and the modified term C[z] must be given as arguments. As anexample, consider the rule decideEquality for proving two case analyses equal.

Γ ` case e1 of inl(x1) 7→ u1 | inr(y1) 7→ v1 = case e2 of inl(x2) 7→ u2 | inr(y2) 7→ v2∈ C[e1/z] bAxc

by decideEquality z C S+T s t y

Γ ` e1= e2∈ S+T bAxc

Γ, s:S, y: e1=inl(s) ∈ S+T ` u1[s/x1] = u2[s/x2] ∈ C[inl(s)/z] bAxc

Γ, t:T, y: e1=inr(t) ∈ S+T ` v1[t/y1] = v2[t/y2] ∈ C[inr(t)/z] bAxc

- RULE: decideEquality

H ` case e1 of inl(x1) => l1 | inr(y1) => r1 = case e2 of inl(x2) => l2 | inr(y2) => r2BY decideEquality z T (A + B) u v w

H ` e1 = e2H u:A, w:(e1 = (inl u )) ` !subst(l1; x1.u) = !subst(l2; x2.u)H v:B, w:(e1 = (inr v )) ` !subst(r1; y1.v) = !subst(r2; y2.v)

In most cases, the arguments of an inference rule can easily be determined from the proof goal.Nuprl’s tactic collection therefore provides a set of single-step inference tactics that try to computethe arguments required by the corresponding inference rule from the actual proof context beforeexecuting the rule (see Section 8.1.3 below). In some situations, however, the relation between theproof goal and the arguments of inference rule is not so obvious and it is necessary that the userprovides the rule arguments explicitly in order to be able to complete the proof.

8.1.3 Converting rules into tactics

Nuprl’s basic mechanism for creating and modifying proofs is the application of proof tactics.These are functions that take a sequent (i.e. the goal) and generate a list of sequents (i.e. thesubgoals) as well as a validation, which shows that a proof for the main goal can be constructedfrom proofs for all the subgoals.

Basic inference rules cannot be applied directly to a proof goal, but first have to be convertedinto a tactic. Technically, this is done by calling a meta-level function refine that takes a primitiverule, that is the name of a rule object and the corresponding rule arguments, and generates a tacticthat executes the rule. The function refine encodes Nuprl’s mechanism for applying rule objectsto proofs (c.f. Section 8.1.1 above) and is the only method for creating proof tactics from scratch.

114

This guarantees that all proof steps are eventually based on primitive inference rules and thuscorrect with respect to the implemented proof calculus.

In most cases, the applicable inference rule and its arguments can easily be determined from theproof context. Nuprl’s library therefore contains a small collection of single-step inference tacticsthat subsumes the complete set of elementary inference rules. Almost all primitive inferences can beexpressed the single-step decomposition tactics D, MemCD, EqCD, MemHD, EqHD, MemTypeCD, EqTypeCD,MemTypeHD, EqTypeHD, and NthHyp. These tactics, which are described in detail in Section 8.3.1,uniformly apply to both the hypotheses and the conclusion of a proof goal. Often a user only hasto give the index of the goal clause to which they shall be applied. The tactic then analyzes thesyntactical structure of the indicated clause, identifies the applicable rule, and tries to determineits arguments from the proof context.

For the sake of efficient interaction, the heuristics built into these tactics only determine variablenames, universe levels, types of subterms, and term dependencies, while the user always has toprovide the clause index and values to be substituted for variables.1 A user may also want tooverride the choices made by the single-step decomposition tactics. For this purpose Nuprl providesa collection of tacticals (i.e. functions that take tactics as arguments and generate tactics) thatenable a user to supply rule arguments explicitly (see Section 8.2.2 for details). Arguments may besupplied to tactics as follows.

Clause index. Most single-step tactics require a clause index to be given as explicit argument.By convention (see Section 8.2.1.1 for a discussion) the index 0 stands for the conclusion of theproof goal, while positive numbers indicate hypotheses. As a convenience, negative indices can beused to count backwards from the end of the hypothesis list. The index (-1) indicates the lasthypothesis in the goal, (-2) the second to last, etc.

The rule independent pairFormation, for instance, operates on the conclusion and is repre-sented by the single-step tactic D 0. The rule hypothesis i is represented by NthHyp i.

Variable names. All tactics in Nuprl’s library automatically assign names to new variables.In rare cases a user may want to select different names. The tactical New takes as an input a listof variables and a tactic and generates a tactic that uses the provided variables instead of theautomatically chosen ones.

The the tactic D 0, which usually suffices to represent the rule functionEquality x, can beforced to choose the name x for the new variable by writing New [x] (D 0).

Universe level. Universe levels can usually be determined from the immediate proof contextand the well-formedness theorems of user-defined concepts. In some cases, the heuristics choose arather arbitrary, high universe level. To enforce a particular level, one may use the tactical At.

The the tactic D 0, which usually suffices to represent the rule lambdaEquality j x′, can beforced to choose the universe level j by writing At Uj (D 0). In addition, one could also enforcethe use of x′ as new variable name as in At Uj (New [x′](D 0))

Values for variables. The With tactical can be used to supply terms that are needed for theinstantiation of variables. The rule dependent pairFormation j s x′, for instance, requires theterm s to be provided explicitly. It is represented by the tactic With s (D 0). A universe level anda variable name may also be provided by writing At Uj (With s (New [x′] (D 0))).

1Nuprl’s library contains proof tactics that attempt to determine clause index and values for variables automat-ically. But since the underlying heuristics are often time consuming and sometimes choose values leading to subgoalsthat cannot be proven, they are not suited for representing single-step inferences.

115

Type of a subterm Although type checking in general is undecidable for intuitionistic type the-ory, the types of subterms occurring in a proof goal can almost always be determined automatically.A user may override the heuristically chosen type if it is too coarse for completing the proof orprovide a type explicitly to improve the efficiency of proof checking. The tactical With can be usedfor this purpose as well.

The tactic MemCD, which usually suffices to represent the rule applyEquality x:S→T , canbe forced to use a particular function type x:S→T by writing With x:S→T MemCD.

Term dependency. Term dependencies can be supplied to a tactic with the Using tactical. Thetactic D 0, which usually suffices to represent the rule decideEquality z C S+T s t y, canbe forced to use a particular dependency C[z] with a new variable z by writing Using [z,C](D 0). Note that a disjunctive type and up to three new variables could be provided as well, as inUsing [z,C] (With S+T (New [s;t;y] (D 0))).

Rule selection. In some rare cases it is impossible to determine the exact rule that shall beapplied to a particular proof clause. For instance, there are two different rules can be applied to adisjoint union S+T in the conclusion of a goal.

Γ ` S+T bext inl(s)cby inlFormation j

Γ ` S bext scΓ ` T ∈ Uj bAxc

Γ ` S+T bext inr(t)cby inrFormation j

Γ ` T bext tcΓ ` S ∈ Uj bAxc

There is no simple heuristic for determining from the proof context which of the two mustbe applied (although this is possible in limited application domains). Instead, a user has to selectbetween the two rules, using the tactical Sel. The rule inlFormation j will be executed by writingSel 1 (D 0), while Sel 2 (D 0) leads to the execution of inrFormation j. In both cases auniverse level can also be supplied.

A complete description of all the inference rules currently present in the Nuprl system as well asthe corresponding single-step tactics can be found in Appendix A.3.

8.2 Introduction to Tactics

The creation and modification of proofs in Nuprl is based on the concept of tactics. Logically,tactics are functions that represent valid refinements. They convert a proof goal into a list ofsubgoals such that the validity of all the subgoals implies the validity of the initial proof goal.They range from elementary inference steps to sophisticated proof strategies that can solve majorproof problems automatically.

Technically, tactics are functional programs written in the ML programming language (seeAppendix B). They take as input a proof goal and return a list of proof goals and a validation. Thevalidation is a function that constructs a proof for the initial goal from proofs for the subgoals andthus validates the refinement step performed by the tactic.

Tactics are usually initiated from within the proof editor. After the user types in the tactic theproof editor applies it to the current proof goal. The proof goals generated by the tactic will beadded to the proof tree as children of the current proof node and displayed as subgoal sequentsstill to be proven. The validation is stored in the proof node as well but remains invisible. Uponcompletion of the proof the validations of all proof nodes are composed into a proof for the initialproof goal, which provides computational evidence for the validity of the initial theorem.

116

Tactics can either be built from elementary inference rules using the function refine (seeSection 8.1.3), or by composing existing tactics into new ones using tacticals (see Section 8.8)or more sophisticated ML programs that analyze the proof context before initiating a refinementstep. This makes sure that all refinements performed by tactics are eventually based on elementaryinference rules and thus correct with respect to the underlying logic.2 Applying a tactic to a proofgoal may produce incomplete proofs or not terminate, but it always results in a valid proof .

Nuprl’s standard library contains a large collection of useful tactics that have been developedover the past 15 years. Users may extend that collection by adding their own tactics as code-objects to their personal directories. But in most cases it is sufficient to use the existing tactics andto combine them through tacticals.

In the rest of this chapter we will describe the most important standard tactics contained inthe library. Further tactics may be found by inspecting Nuprl’s library of standard theories.

8.2.1 Tactic Arguments

Invoking a tactic often requires certain arguments to be supplied. These may be indices of hypothe-ses to which the tactic shall be applied (type int), Nuprl terms that instantiate variables (typeterm), new variables to be generated (type var), universes to be used in well-formedness goals(type term), names of library objects to be consulted (type token), substitutions to be applied(type (var # term) list), sub-tactics to be used during refinement (type tactic), and others.

The proof goal (type proof) to which the tactic shall be applied is always the last argument ofa tactic. If the tactic is invoked in the proof editor, the user does not have to supply this argument,as the proof editor will automatically insert it.

Unless otherwise stated, we assume that arguments to tactics have the following types and uses:

T∗ : tacticc∗ : int clause index.i∗ : int hypothesis index.t∗ : term term of Nuprl’s type theoryn∗ : tok name of lemma object in Nuprl’s librarya∗ : tok name of abstraction object in Nuprl’s libraryv∗ : var variables in terms of Nuprl’s object languagel∗ : tok subgoal labelp∗ : proof current proof goal

A suffix s on the name of an argument indicates that it is a list. For example vs is considered tohave type var list.

8.2.1.1 Referring to hypotheses in a sequent

Hypotheses are conventionally numbered from left to right, starting from 1. These hypothesis num-bers are displayed by the proof editor, and tactics usually refer to hypotheses by these numbers.Sometimes, it is convenient to consider the hypotheses numbered from right to left, and for this rea-son tactics consider a hypotheses list H1, . . . ,Hn to also be numbered H−n, . . . ,H−1. Occasionally,the index n+1 or 0 is used to refer to the position to the right of the last hypothesis.

2An experienced Nuprl hacker will, of course, find ways to bypass these mechanisms and modify proofs withoutusing elementary inference rules. However, the dependency tracking mechanisms of Nuprl’s library are able to detecttheorems whose proofs were constructed that way and to identify all library objects that depend on such theorems.Thus it is possible to account for the validity of theorems even in the presence of hacks.

117

There are tactics which work in similar ways on both hypotheses and the conclusion. In thiscase, we call the hypothesis and conclusion collectively clauses, refer to the conclusion as clause 0 ,and to hypothesis i (i 6=0) as clause i.

As a convention in this manual, we prefix a hypothesis with a number followed by a period ifwe want to indicate explicitly the number of a hypothesis in a schematic sequent. For example, ifhypothesis i is proposition P , we write the hypothesis as i. P .

8.2.1.2 Universes and Level Expressions

In Nuprl’s type theory, types are grouped together into universes. Types built from the base typessuch as Z or Atom using the various type constructors are in universe U1. The subscript 1 is thelevel of the universe. Types built from universe terms with level at most i are in universe Ui+1.Universe membership is cumulative; each universe also includes all the types in lower universes.

Since propositions are encoded as types, propositions reside in universes too. In keeping withthe propositions-as-types encoding, we define a family of propositional universe abstractions P1, P2,. . . , which unfold to the corresponding primitive type universe terms U1, U2, . . . .

If one is only allowed to use constant levels for universes, one often has to choose arbitrarilylevels for theorems. One would then find that one needed theorems that were stated at a higherlevel, and would have to reprove those theorems. This was the case in Nuprl 3 and earlier releases.

Nuprl now allows one to prove theorems that are implicitly quantified over universe levels.Quantification is achieved by parameterizing universe terms by level expressions rather than naturalnumber constants. The syntax of level expressions is given by the grammar:

L :: = v | k | L i | L′ | [L | · · · |L]

The v are level-expression variables, which can be arbitrary alphanumeric strings. They are implic-itly quantified over all positive integer levels. The k are level expression constants, which can bearbitrary positive integers. The i are level expression increments and must be non-negative integers.The expression L i is interpreted as standing for levels L+i. L′ is an abbreviation for L 1. Theexpression [L1 | · · · |Ln] is interpreted as being the maximum of the expressions L1 · · ·Ln.

Usually when stating theorems, only level expressions of the form v and v′ need be used.Other expressions get automatically created by tactics. Further, it is sufficient to use a single level-expression variable throughout a theorem statement, as two occurrences of the same level-expressionvariable will not be related. For example, we normally prove the theorem ∀A,B:Pi. A⇒ (B⇒A)rather than ∀A:Pi.∀B:Pj . A⇒ (B⇒A).

8.2.2 Optional Arguments

Unlike Lisp functions, ML functions cannot take optional arguments, although it is natural to wantto write tactics which do take optional arguments. One approach is to provide a set of variants ofeach tactic for the most common combinations of arguments. This can be confusing, and places anextra burden on the user who has to keep track of these variants.

Nuprl allows optional arguments to be passed to tactics by providing tacticals (see Section8.8 below) that attach these arguments to the proof argument (i.e. the last argument) of a tactic(c.f. Section 8.2.1). Currently, this is supported for arguments of type int, tactic, term, tok, varand (var#term) list. Each argument is also given a token label, and arguments are looked up bythese labels. Sets of arguments are maintained on a stack, which enables nesting of tactics that useoptional arguments. Tacticals for manipulating these arguments are:

New ([v1;...;vn] : var list) T

118

Runs tactic T with variables v1 to vn as optional arguments, Typically, New is used to supply atactic with names for newly created variables. The argument labels of the vi are ‘v1‘ to ‘vn‘.

With (t : term) T

Runs tactic T with term t as optional argument, which may, for instance, be a term to beinstantiated for a variable or the type of some subgoal. The argument label of t will be ‘t1‘.

At (U : term) T

Runs tactic T with term U as a optional ‘universe‘ argument. U should either be either atype universe or a propositional universe term.

Using (sub : (var#term) list) T

Runs tactic T with the substitution sub as optional ‘sub‘ argument. The substitution sub maybe applied to instantiate variables or to indicate dependencies in some term.

Sel (k : int) T

Runs tactic T with the integer k as optional argument. Sel is used for selecting a simplecomponent of a formula or a subterm of a term. The argument label of k will be ‘n‘

Thinning T

Runs tactic T with the token ‘yes‘ as optional ‘thinning‘ argument. Some tactics mayoptionally remove (or thin) hypotheses that are considered superfluous after a refinement step.Thinning causes T ’s default behavior to be to thin.

NotThinning T

Runs tactic T with the token ‘no‘ as optional ‘thinning‘ argument. This causes T ’s defaultbehavior to be to not thin.

WithArgs (args : (tok#arg) list) T

Run tactic T with the arguments in args on the top of the stack. arg is an ML abstract datatype, defined as the disjoint union of the types int, tactic, term, tok, var and (var#term)list. There are injection and projection functions for each of these types, such as int to argand arg to int. All the above tacticals are special cases of WithArgs

Each tactic description in this chapter includes information on the optional arguments (if any) thatit takes. Note that some tactics do useful preprocessing on some of their arguments. In these casesthere would be a performance penalty if such arguments were supplied.

8.2.3 Proof Annotations

Nuprl proof terms can be annotated with extra information that is not relevant to the logicalcorrectness of a proof but may assist in structuring proofs and identifying applicable tactics.

Goal Labels. Nuprl tactics generate various kinds of subgoals. Some express the main proofidea, while others are only auxiliary or well-formedness goals. In inductive proofs one distinguishesthe base case from the step cases. Usually, different kinds of goals have to be treated differently, soone would like subsequent tactics to discriminate on subgoal kind. Sometimes a subgoal’s kind can

119

be deduced directly from its structure, but this can be a error-prone process. Thus the tactics that generate the subgoalsoften attach explicit labels to them indicating their kind.Labels consist of an ML token and an optional number. Typ-ical examples of labels are main, upcase, aux, and wf. Some-times tactics generate a set of subgoals of the same kind,where the order of the subgoals is important. The optionalnumbers are used to discriminate between these subgoals.Most descriptions of tactics include information on subgoallabeling. It is also a simple matter to find out what labels aregenerated by experimentation.

- PRF: int mul# top∀x:Z. x * x ≥ 0

BY D 0

# 1

1. x:Z` x * x ≥ 0

BY

# 2.....wf.....Z ∈ U1

BY

For historical reasons, goal labels are sometimes known as hidden labels.3 Labels may be addedexplicitly using the following tactics.

AddHiddenLabel lab

Add label lab to the current goal.AddHiddenLabelAndNumber lab i

Add label lab to the current goal along with the integer label i.RemoveHiddenLabel

Remove the label from the current goal.Note that the goal label created by AddHiddenLabelAndNumber ‘x‘ 1 is xxy and not xx 1y, althoughit will be displayed as the latter. The number is considered as strictly separate from the label andwill only be considered by tactics that discriminate on the number as well. Removing a label isequivalent to adding the label main. This label will not be displayed, since unlabeled goals areusually considered main goals.

To make subsequent tactics discriminate on labels one usually applies the tacticals describedin Section 8.8.2 below. For convenience, labels are divided into the classes main and aux . Thediscriminating tacticals allow one to select either subgoals with a particular label, or subgoals ofone of these two classes.

8.2.4 Soft Abstractions

In most proofs tactics do not deal with basic expressions of Nuprl’s logic but with user-defined con-cepts. Before applying generic tactics to these, the corresponding abstractions need to be unfoldedfirst. To prevent unwanted unfolding of abstractions, tactics usually do not unfold abstractionsunless they are designated as soft .

Some tactics treat soft abstractions as being transparent, that is they behave as if all softabstractions had first been unfolded. In practice, those tactics only unfold soft abstractions whenthey need to and for the most part are careful not to leave unfolded soft abstractions in the subgoalsthat they generate.

Specific tactics that unfold soft abstractions are MemCD, EqCD, NthHyp, NthDecl (Section 8.3.1),Eq (Section 8.3.3), Inclusion. (Section 8.7), the forward and backward chaining tactics (Sec-tion 8.4), and the atomic rewrite conversions based on lemmata and hypotheses (Section 8.9.2).

Table 8.1 lists the most important soft abstractions in Nuprl’s standard libraries. The logicabstractions (and, or, implies, exists, all) are made soft because the well formedness rule forthe underlying primitive term is simpler and more efficient than the well formedness lemma would

3In Nuprl 3 labels used not to be visible when editing proofs with the proof editor.

120

member t ∈T ≡ t = t ∈Tnequal x6=y ∈T ≡ ¬(x = y ∈T )ge i≥j ≡ j≤igt i>j ≡ j<ilelt i≤j<k ≡ (i≤j) ∧ (j<k)lele i≤j≤k ≡ (i≤j) ∧ (j≤k)prop Pi ≡ Ui

and A ∨B ≡ A×Bor A ∧B ≡ A + Bimplies A⇒B ≡ A→Brev implies A⇐B ≡ B⇒Aiff A⇔B ≡ (A⇒B) ∧ (A⇐B)exists ∃x:A. Bx ≡ x:A×Bx

all ∀x:A. Bx ≡ x:A⇒Bx

Table 8.1: Soft abstractions in Nuprl’s basic libraries

be. The softness is also useful when one wishes to blur the distinction between propositions andtypes, for example when reasoning explicitly about the inhabitants of propositions. member, nequal,rev implies, ge and gt are soft principally because it can simplify matching.

Abstractions are not soft by default. They can be declared soft or hard by supplying their opidsto the functions

add soft abs abs

Declare the abstractions in the token list abs as soft.

remove soft abs abs

Declare the abstractions in the token list abs as hard.

Instances of these functions are usually kept in ML objects in close proximity to the abstrac-tion definitions that they are declaring soft. For an example use of add soft abs, see the objectsoft ab decls in the core 2 theory.

8.2.5 Universal Formulas

Many of Nuprl’s tactics work on a specific subclass of logical formulas generated by the grammar

P :: = ∀x:T. P | Pa⇒P | P ⇐Pa | P ∧P | P ⇔P | C

where T is a type, and C is a propositional term not of the above form. We call these universalformulas, positive definite formulas, or Horn clauses. Formulas generates without the ∧ and ⇔connectives are also called simple universal formulas. We call the proposition C a consequent andeach Pa an antecedent. Occasionally we refer to the types T as type antecedents.

We view a universal formula as being composed of several simple formulas, one for each conse-quent. The simple components are numbered from 1 up, starting with the leftmost consequent.

Such formulas are the standard way of describing derived rules of inference, and are used assuch by the forward and backward chaining tactics (see Section 8.4). Often, a consequent C of aformula will be an equivalence relation, in which case the formula can be used as a rewrite rule bythe rewrite package (see Section 8.6).

Occasionally, one has a universal formula where the outermost constructor of C is also one ofthe constructors that make up the universal formula. In this case, one can surround C by a guardabstraction to designate it as consequent of the formula. A guard abstraction takes a single subtermas argument and unfolds to this subterm. The tactics that take apart universal formulas recognizeand automatically remove guard abstractions, so the user rarely has to explicitly unfold them.

121

8.3 Basic Tactics

8.3.1 Single-Step Decomposition

Single-step decomposition tactics invoke the primitive formation, equality , and elimination rules ofNuprl’s logic described in Appendix A.3. These rules describe how types and their members canbe formed and when two types or members are equal by decomposing the corresponding terms inthe hypotheses or the conclusion of a goal into smaller fragments. Structurally the effect is alwaysthe same, as the top-level terms are analyzed and their sub-terms will occur in the subgoals.

Each single-step decomposition tactic covers a large collection of primitive inference rules using asingle name. The tactic name indicates which part of a hypothesis or conclusion will be decomposed.

D c

Decompose the outermost connective of clause c. D can take several optional arguments:• A ‘universe‘ argument, usually supplied using the At tactical.• A ‘t1‘ argument for a term (using With). This argument is necessary when decomposing

a hypothesis with an outermost universal quantifier, or a conclusion with an outermostexistential quantifier.

• ‘v1‘ and ‘v2‘ arguments for new variable names (using New. These are useful if one isnot satisfied with the system supplied variable names.

• An ‘n‘ argument to select a subterm (using Sel). This is necessary when applying D to adisjunct in the conclusion.

Usually D unfolds all top level abstractions and applies the appropriate primitive (formation orelimination) rule. It is somewhat intelligent with instances of set and squash terms.

ID c

Intuitionistically decompose clause c. This behaves as D does, except that when decomposinga function, a universal quantifier, or an implication, in a hypothesis, the original hypothesis isleft intact rather than thinned.

MemCDDecompose the immediate subterm of a membership term in the conclusion.For primitive terms MemCD uses the appropriate primitiveequality rule. For abstractions, it tries to use an appropri-ate well-formedness lemma. Soft abstractions will be unfoldedif there is no appropriate well-formedness lemma. A subgoalcorresponding to the n-th subterm will be labeled with labelsubterm and number n. Other subgoals are labeled wf.An example application of MemCD is shown on the right.Well-formedness lemmata for a term t with operator iden-tifier opid should have the name opid wf and consist of asimple universal formula with consequent xt ∈Ty. Usually, the

- PRF: pairtest

# top<3, 4> ∈ N × ZBY MemCD

# 1.....subterm..... T:t` 3 ∈ NBY

# 2.....subterm..... T:t` 4 ∈ ZBY

subterms of t should be all variables, but constants are acceptable too. If more than one lemmais needed, the lemma names should be distinguished by suffices to the opid wf root.

Usually MemCD attempts to use lemmata in reverse dependency order (i.e. the later ones do notrefer to the former and are often more general) but different orders may be specified if needed.If the conclusion is a ∈A where a is an instance of t and A does not match any of the T of thelemmata, then MemCD tries matching a against the term t of the last lemma. If this succeeds and

122

Tactic In the hypotheses In the conclusionUnivCD ∀ ⇒ →GenUnivCD ∀ ⇒ ∧ ⇔ → ×RepD ∧ ∀ ⇒ →GenRepD ∧ ∀ ⇒ ∧ ⇔ → ×ExRepD ∃ ∧ ∀ ⇒ →GenExRepD ∃ ∧ ∨ ∀ ⇒ ∧ ⇔ → ×

Table 8.2: Iterated decomposition tactics and the connectives they decompose

generates some substitution σ, MemCD produces a subgoal σT⊆A and tries to use the Inclusiontactic (Section 8.7) to prove it.

MemHD i

Decompose the immediate subterm of a membership term in hypothesis i.

Since there are no primitive rules for decomposing equalities in hypotheses, MemHD only works onhypotheses when the type of the membership term is a product or function type. For products,the decomposition generates the first and second projection of the term. For functions, it createsa function application. A ‘t1‘ argument is required in this case.

MemberEqD c

Decompose the immediate subterm of a membership term in clause c. Works like MemCD on theconclusion and like MemHD on a hypothesis.4

EqD c

Decomposes terms which are the immediate subterms of an equality term in clause c.

EqD is like MemberEqD, except that it expects and generates equality terms rather than member-ship terms. It is good for congruence reasoning and is used extensively by the rewrite package(see Section 8.6).Commonly used variants are the tactics EqCD and EqHD i, which work identical to EqD on theconclusion and a hypothesis, respectively.

EqTypeD c

Decompose just the type subterm of an equality term in clause c. Only works when the type isa set type or is an abstraction that eventually unfolds to a set type.Commonly used variants are EqTypeCD and EqTypeHD i

MemTypeD c

Decompose just the type subterm of a membership term in clause c. Only works when the typeis a set type or is an abstraction that eventually unfolds to a set type.Commonly used variants are MemTypeCD and MemTypeHD i

The above tactics cover almost all of the primitive inference rules of Nuprl’s logic. Appendix A.3gives a complete description of all the inference rules and the corresponding tactics.

Several tactics perform iterated decomposition of clauses. Table 8.2 lists the most commonlyused ones, together with the logical connectives they decompose. These tactics do not decomposeguarded terms. If a guard is encountered in the process of decomposing the conclusion, the guardis removed and decomposition of the conclusion stops.

4A better name would have been MemD

123

8.3.2 Structural

Structural tactics invoke inferences that depend only on the syntactical structure of the proof goalbut are independent of a particular logic.

HypothesisProve goals of form . . . A . . .À′ where the conclusion A′ is α-equal to A.

NthHyp i

Prove goals of form . . . A . . .À′ where A is the i-th hypothesis and A′ is α-equal to A.Declaration

Prove goals of form . . . x:T . . .`x ∈T ′ or . . . x:T . . .`x=x ∈T ′ where T ′ is α-equal to T .NthDecl i

Prove goals of form . . . x:T . . .`x ∈T ′ or . . . x:T . . .`x=x ∈T ′ where x:T is the i-th declarationand T ′ is α-equal to T .

ContradictionProve goals where both P and ¬P occur in the hypotheses list.

Assert t

Assert term t as last hypothesis. Generates a main subgoal with t asserted, and an assertionsubgoal to prove t. Logically this inference is often called a cut .A more general variant is AssertAt i t, which asserts t before hypothesis i.

Thin i

Delete hypothesis i.MoveToHyp i j

Move hypothesis i to before hypothesis j.MoveToConcl i

Move hypothesis i into the conclusion. If the goal has the form . . . A . . .`C, where A is the i-thhypothesis, then MoveToConcl generates the main subgoal . . .À⇒C. If the i-th hypothesisis a declaration x:T , it generates the main subgoal . . .`∀x:T.C.MoveToConcl first invokes itself recursively on any hypothesis that might depend on hypothesis i.

MoveDepHypsToConcl i

Use MoveToConcl to move all hypotheses that use the variable declared by hyp i into theconclusion. Hypothesis i itself will not be moved.

RenameVar v i

Rename the variable declared in hypothesis i to v.RenameBVars (σ: (var#var) list) c

Rename all occurrences of bound variables in clause c using the substitution σ.

The following two tactics are usually used inside other tactics.

IdThe identity tactic, which does not change the proof goal

FailThe tactic that always fails.

8.3.3 Decision procedures

Decision procedures use special-purpose reasoning to decide problems within a specific limitedapplication domain. In many cases, they analyze the problem by translating it into a different

124

problem domain (e.g. the problem of finding cycles in a directed graph) for which there are well-known decision algorithms. To ensure consistency with type theory, some of these procedures haveto generate proof tactics that validate the result of the analysis and create appropriate subgoals ifnecessary. For Arith and Eq, the consistency of the decision procedure has been proven externallyand the procedures are implemented as elementary inference rules.

Decision procedures require the well-formedness of the components used during the analysis tobe proven as separate subgoals, as this is a purely type-theoretical issue that cannot be addressedby the decision algorithm.

8.3.3.1 Logical reasoning

ProvePropProve a goal that involves only simple propositional reasoning.The proof strategy is basically a classical tableau prover for propositional logic, which exhaus-tively decomposes propositions and seeks for applications of the Hypothesis tactic. BecauseNuprl sequents only allow one conclusion (rather than many as in tableau calculi) the tac-tic has to do ‘or’ branching and backtracking when it tackles an ∨ conclusion or an ⇒ or ¬hypothesis. It fails if not all main goals can be solved.

The tactic is not complete for intuitionistic propositional logic, because it always thins ⇒ and¬ hypotheses that are decomposed. Common variants of ProveProp are

• ProvePropWith T , which tries running the tactic T before abandoning a search path inan ‘or’ branch and continues the search on any main subgoal that T creates.

• ProveProp1, which leaves main subgoals at ‘or’ branching points of the search for a solutionwhen the search down every branch fails.

JProverProve a goal that involves only first-order reasoning.JProver [SLKN01] is a complete theorem prover for first-order intuitionistic logic that is basedon a strategy called the connection method [KO99]. Upon success it generates a sequent proof forthe proof goal [KS00] that may be inspected by the user. Since first-order logic is undecidable,JProver will not terminate if the goal cannot be proven and must be interrupted.JProver is run as an external prover, which means that the MetaPRL proof engine must beconnected to Nuprl before invoking JProver.

8.3.3.2 Exploiting properties of relations

EqProve goals of form H`s=t ∈T using hypotheses that are equalities over T and the laws ofreflexivity, commutativity and transitivity.Eq also uses hypotheses that are equalities over a type T ′ when T = T ′ can be deduced fromother hypotheses using reflexivity, commutativity and transitivity.

RelRSTProve goals by exploiting common properties of binary relations, including reflexivity, symmetry,transitivity, irreflexivity, antisymmetry, and linearity.The heart of RelRST is a routine that builds a directed graph based on the binary relations ina sequent and finds shortest paths in the graph. It can also handle strict order relations andrelations with differing strengths.

125

RelRST uses the the same database on relations and some of the same lemmata as the rewritepackage (see Section 8.6). In addition, it relies on library lemmata of the following forms.

• Irreflexivity lemmata, which should be named opid-lt irreflexivity and have form∀x1:T 1 . . . xm:T m.∀y:S.A1⇒ . . . ⇒An⇒¬(y < y)

• Antisymmetry lemmata, which should be named opid-le antisymmetry and have form∀x1:T 1 . . . xm:T m.∀y, y′:S.A1⇒ . . . ⇒An⇒ y≤y′⇒ y′≤y⇒ y = y′ ∈S

• Complementing lemmata, which should be named opid-le complement and have form∀x1:T 1 . . . xm:T m.∀y, y′:S.A1⇒ . . . ⇒An⇒ ⇒¬(y≤y′)⇒ y′ < y

or be named opid-lt complement and have form∀x1:T 1 . . . xm:T m.∀y, y′:S.A1⇒ . . . ⇒An⇒ ⇒¬(y < y′)⇒ y′≤y

where opid-lt and opid-le are the operator identifiers of the relations < and ≤.

RelRST generalizes the equality decision procedure used in previous versions of Nuprl thatcould only handle such reasoning with the equality relation. Examples of its use can be foundin the theory of integer divisibility within the theory num thy 1.

8.3.3.3 Integer arithmetic

ArithProve goals of the form H`C1∨ . . . ∨Cm by a restricted form of arithmetic reasoning. Each Ci

must be an arithmetic relation over the integers built from <, ≤, >, ≥, =, 6=, and negation.Arith knows about the ring axioms for integer multiplication and addition, the total orderaxioms of <, the reflexivity, symmetry and transitivity of equality, and a limited form of sub-stitutivity of equality. As a convenience Arith will attempt to prove goals in which not all ofthe Ci are arithmetic relations; it simply ignores such disjuncts.The heart of Arith is a procedure that translates the sequent into a directed graph whose egdesare labelled with natural numbers and finds positive cycles in that graph [Cha82].

RepeatEqCDForArithApply arithmetic equality reasoning if the conclusion is a=b ∈T and a and b arithmeticallysimplify to same expression.5 RepeatEqCDForArith first decomposes a and b using EqCD andthen applies Arith to subgoals containing integer equalities.

SupInfSolve linear inequalities over integers and subtypes of integers.The algorithm used in Arith cannot solve general sets of linear inequalities over the integers,though such problems are abundant. SupInf uses an adaptation of Bledsoe’s Sup-Inf method[Ble75] for solving integer inequalities. While this method is only complete for the rationals, itis sound for the integers and does work well in practice.SupInf converts the sequent into a conjunction of terms of the form 0≤ei where each ei is alinear expression over the rationals in variables x1 . . . xn and determines whether or not thereexists an assignment of values to the xj that satisfies the conjunction. The algorithm works bydetermining upper and lower bounds for each of the variables in turn.

SupInf identifies counter-examples if it fails. These can be viewed by looking at value of the MLvariable supinf info. The value gives a list of bindings of variables in the goal for the counter-

5Arithmetic simplification applies only subterms that involve the basic arithmetic operators +, -, *, / and rem.Currently simplification involving / and rem does not work and has been disabled.

126

example. If SupInf finds an integer counterexample, then the goal is definitely unprovable. If arational counter-example is given, then SupInf is unsure whether the goal is true or not.

SupInf’

Like SupInf, but tries inferring additional arithmetic information about the non-linear termsin arithmetic expressions. The information on a non-linear term t is gathered in two ways:

1. If standard type-inference returns a subtype of Z for t, then the predicate information fromthe subtype is added.

2. Information may be gathered from arithmetic property lemmata, i.e. lemmata of the form∀x1:T 1 . . . xm:T m.A1⇒ . . . ⇒An⇒C

where C is constructed from ∧ , ∨ , and standard arithmetic relations over integer subtypesbuilt from <, ≤, >, ≥, =, 6=, and their negations. To apply the lemma, match handlesare selected from C, i.e. terms occuring in arithmetic relations in C that contain all thefree variables contained in C and the Ai. If, after matching a match handle with t, all theinstantiated Ai are equal to hypotheses of the sequent, then the instantiated clause C willbe added as information.6

Arithmetic property lemmata are identified by invoking the ML functionadd arith lemma lemma-name.

SupInf’ is still under development and should be used with caution when combined with type-checking tactics: it may get invoked unendingly on subgoals derived from ones that it created.

8.3.4 Autotactics

Autotactics are used primarily for typechecking and well-formedness goals. They should not beused for other non-trivial proof goals, as their behavior on such goals is somewhat unpredictable.

Trivial

Completely prove a goal by applying various steps of trivial reasoning.Trivial reasoning includes Hypothesis, Declaration, Contradiction, and Eq. Trivial alsoproves goals of the form H ` True, H1 . . . False . . . Hn ` C, and H1 . . . Void . . .Hn ` C.

Auto

Repeatedly apply the following tactics until no further progress is made.

• Trivial• GenExRepD• MemCD for (non-recursive) member conclusions and EqCD on reflexive equality conclusions.• Arith• RepeatEqCDForArith• EqTypeCD if the conclusion is a ∈T or a=b ∈T and T is a subset of Z.

Auto and its variants frequently encounter the same goals over and over again, so solved proofgoals will be cached. Common variants of Auto are

• StrongAuto, which also tries MemCD and EqCD on recursive primitive terms;• SIAuto, which also tries using the SupInf tactic; and• Auto’, which uses SupInf’ instead of Arith.

6The condition that Ai must be equal to some hypothesis is too strict and may be relaxed in the future.

127

8.4 Forward and Backward Chaining

Forward and backward chaining means treating a component of a universal formula (see Sec-tion 8.2.5) as derived inference rule. Backward chaining involves matching the conclusion of thegoal against the consequent of a universal formula, which leaves the instantiated antecedents ofthe universal formula as new subgoals. Forward chaining involves matching hypotheses of the goalagainst antecedents of a universal formula and asserting the instantiated consequent of the universalformula as a new hypothesis. A simplified version of forward chaining is instantiating the universalformula by explicitly providing a list of terms to be substituted for the quantified variables.

Chaining tactics consult universal formulas can either be found in the hypotheses of the currentproof goal or as lemma in the library. Therefore each tactic comes in two versions.

InstHyp [t1;..;tn] iInstLemma name [t1;..;tn]

Instantiate hypothesis i (or lemma name) with terms t1. . . tn. If the lemma has m distinct levelexpressions, the first m terms should be level expressions to substitute for these.7

InstConcl [t1;..;tn]

Instantiate existential quantifiers in the conclusion with terms t1. . . tn.

FHyp i [h1;..;hn]FLemma name [h1;..;hn]

Forward chain through hypothesis i (or lemma name) matching its antecedents against any ofthe hypotheses h1. . . hn. The order of the hj is immaterial: the tactics try all possible pairingsof hypotheses with antecedents. If there are more antecedents that hypotheses listed, the an-tecedents not matched will manifest themselves as new subgoals to be proved.The main subgoal with the consequent asserted is labelled main. Unmatched antecedents arelabelled antecedent and the rest are labelled wf. Aliases are FwdThruLemma and FwdThruHyp.

Forward chaining can take an optional argument (c.f. Section 8.2.2), supplied by using the Seltactical, to select a specific component of a conjunction or equivalence in a universal formula.An argument of -1 forces the tactic to treat the whole subformula as simple.

BHyp iBLemma name

Backward chain through hypothesis i (or lemma name) matching its consequent against theconclusion of the goal. Subgoals corresponding to antecents of the lemma (hyp) are labelledwith antecedent. The rest are labelled wf. Aliases are BackThruLemma and BackThruHyp.

An explicit list of variable bindings can be supplied to backward chaining as optional argumentby using the Using tactical. This argument is necessary if some of the variable bindings cannotbe inferred by matching. For instance

Using [‘n‘.’3’] (BackThruLemma ‘int upper induction‘)

would bind the variable n in the lemma int upper induction to the value 3.BHypWithUnfolds i asBLemmaWithUnfolds name as

Backward chain through hypothesis i (or lemma name) while unfolding the abstractions in as.

7To inject a level expression L into a term list one has to invoke the special term parameter in the term editor.

128

Backchain bc namesCompleteBackchain bc names

Repeatedly try backchaining using lemmata named in bc names in the order given.Backchain leaves alone any subgoals which do not match the consequent of any of the lemmatawhile CompleteBackchain backtracks in the event of any such subgoal coming up.

In addition to lemma names, bc names may contain a few special names:

• An positive integer i, indicating that hypothesis i shall be consulted.• ‘hyps‘, indicating that all hypothesis should be consulted in the order in which they occur.

Hypotheses that declare variables will be ignored.• ‘rev hyps‘, indicating that all hypothesis should be consulted in reverse order.• ‘new hyps‘, indicating that all new hypotheses introduced by backchaining should be

consulted, beginning with the least recent.• ‘rev new hyps‘, indicating that all new hypotheses introduced by backchaining should be

consulted, beginning with the most recent.

Common variants of backchaining are HypBackchain and CompleteHypBackchain which per-form backchaining with the arguments [‘rev new hyps‘; ‘rev hyps‘].

8.5 Case Splits and Induction

Case split and induction tactics analyze conclusions that depend on finite or enumerable alter-natives. The general way to do this is to backchain through an appropriate lemma (see e.g. thelemmata int upper ind and int seg ind at the end of the int 2 theory). To use these lemmata,one must ensure that the outermost universal quantifier in the conclusion corresponds to the typeof the induction.

The following tactics are good for a few common cases. They expect the variable the induction/ case-split is being done over to be declared in some hypothesis.

BoolCases iDo a case split over a boolean variable declared in hypothesis i . Generates two subgoals, labelledtruecase and falsecase, where the boolean variable is replaced by tt or ff.

Cases [t1;..;tn]Perform an n-way case split over the terms ti as follows:

H ` Cby Cases [t1;..;tn]

...assertion... H ` t1∨.. ∨ tn

H, t1 ` C...

H, tn ` C

Decide PPerform a case split over a decidable proposition P and its negation.Like Cases [P;¬P], but immediately runs the tactic ProveDecidable tactic on the first sub-goal ` P ∨¬P , which may generate wellformedness subgoals with labels in the aux class. IfProveDecidable fails then Decide fails too.

Because of the constructive nature of Nuprl’s type theory P ∨¬P is not true for every propo-sition P .

129

IntInd iPerform integer induction on hypothesis i , generating three subgoals labelled upcase, basecaseand downcase. IntInd is a little smarter than the primitive rule intElimination (see AppendixA.3.8) in that it first moves any hypotheses that depend on the induction variable to theconclusion and maintains the name of the induction variable.

NatInd iPerform natural-number induction on hypothesis i , which must contain a declaration of typeN, generating two subgoals labelled upcase and basecase. NatInd first moves any dependinghypotheses to the conclusion and maintains the name of the induction variable.

NSubsetInd iPerform induction on a subrange of the natural numbers. Hypothesis i must contain a decla-ration of type N, N+, i..., or i...j−. NSubsetInd generates two main subgoals labelledupcase and basecase an many aux subgoals which should always be easily solvable by Auto.

CompNatInd iPerform complete induction on hypothesis i , which must contain a declaration of type N.

ListInd iPerform list induction on hypothesis i , which must contain a declaration of type T list,generating two subgoals labelled upcase and basecase. ListInd is a little smarter than theprimitive rule listElimination (see Appendix A.3.10) in that it first moves any dependinghypotheses to the conclusion and maintains the name of the induction variable.

The theory well fnd has some definitions for well-founded induction. In particular it definesthe tactic Ranknd. This is useful when you know how to do induction over some type A and youwant to perform induction over a type B using some rank function which maps elements of B toelements of A. The tactic is described in the objects inv image ind tac and rank ind.

The theory bool 1 defines various tactics for case splitting on the value of boolean expressionsin the conclusion such as BoolCasesOnCExp and SplitOnConclITE. View the theory for details.

8.6 Simple Rewriting

Rewriting is the process of transforming goals and hypotheses into equivalent ones. In Nuprl,rewrite tactics are based on unfolding and folding abstractions, applying primitive reductions, andusing equivalences in lemmata and hypotheses of the form ∀x1:T 1 . . . xi:Ti. a = b.

Nuprl’s rewrite package (see Section 8.9) provides a collection of ML functions for creatingrewrite rules and applying them in various fashions. The rewriting tactics in this section are sufficientin many situations while hiding the complex conversion language of the rewrite package.

8.6.1 Folding and Unfolding Abstractions

Unfolds as cUnfold a c ≡ Unfolds [a] c

Unfold all visible occurrences of abstractions listed in the token list as in clause c. Unfolds failsif clause c contains none of the abstractions listed in as.

RepUnfolds as cRepeatedly try unfolding any occurrences of abstractions listed in the token list as in clause c.

RecUnfold a cUnfold all visible occurrences of the recursive definition of a in clause c.

130

Folds as cFold a c ≡ Folds [a] c

Fold all visible occurrences of abstractions listed in the token list as in clause c. Folds failsnone of the subterms of clause c matches the right hand side of an abstraction listed in as.

RecFold a cTry to fold an instance of the recursively defined term a in clause c.

8.6.2 Evaluating Subexpressions

Reduce c ≡ AbReduce cRepeatedly contract all primitive and abstract redices in clause c.

The Reduce tactic can take an optional force argument:

With force (Reduce c)

only reduces those redices with strength less than or equal to force. Details about definingabstract redices and setting the strength of redices can be found in Section 34.

To reduce a specific subterm of a clause, one may apply the tactic ReduceAtAddr address c,where address is a list of integers describing the exact address of the subterm in the term treeof clause c. Applying this rule is only recommended for advanced users who are very familiarwith the term structure of Nuprl expressions.

ArithSimp cArithmetically simplify clause c.This creates a main subgoal with clause c rewritten in arithmetical canonical form and an auxsubgoal stating the equivalence between the original clause and the rewritten one.

8.6.3 Substitution

Nuprl’s logic contains a few rules for carrying out simple kinds of substitutions. These rules oftengenerate fewer and easier-to-solve well-formedness goals than the rewrite package and are accessiblethrough the tactics described here.

Subst eq cIf the term eq has the form t1 = t2 ∈ T then replace all occurrences of t1 in clause c by t2.Three subgoals are generated: an equality subgoal to prove that t1 = t2 ∈ T , a main subgoalwith the substitution carried out, and a wf subgoal to prove functionality of the clause (see therule substitution in Section A.3.5).

HypSubst i cRevHypSubst i c

Run the Subst tactic using the equality proposition in hypothesis i (in reversed order). Thisgenerates only a main and a wf subgoal.

SubstClause t cReplace clause c with term t . This generates a main subgoal and an equality subgoal (see therule hyp replacement in Section A.3.16).

131

Token Rulei Use hypothesis i as an left-to-right rulei< Use hypothesis i as an right-to-left rulename Use lemma name as an left-to-right rulename< Use lemma name as an right-to-left ruler:id Reduce redex with operator identifier idr* Reduce any redexr*force Reduce any redex with force forceu:id Unfold abstraction with operator identifier idf:id Fold abstraction with operator identifier id

Table 8.3: Format of Tokens in Rewrite Control Strings

8.6.4 Generic Rewrite Tactics

The tactics RWW and RWO subsume the above tactics by providing uniform access to all kinds ofrewrite rules. They take a control string to specify the rewrite rules to use. The control stringshould be a whitespace-separated list of tokens as specified in Table 8.3.RWW "ctl-str" c

Repeatedly apply rewrite rules specified by ctl-str to all subterms of clause c until no furtherprogress is made.

RWO "ctl-str" cApply rewrite rules specified by ctl-str in one top-down pass over clause c. RWO does not go intosubterms of terms that result from rewriting a subterm of c.

In some cases, RWW and RWO generate more subgoals than the more specific tactics, as they areimplemented in a different fashion.

8.7 Miscellaneous Tactics

Type Inclusion

Inclusion iProve goals of the form . . . , i . x:T, . . .`x ∈T ′ or . . . , i . t ∈T, . . .`t ∈T ′,where either types T and T ′ are equivalent or T is a proper subtype of T ′. Inclusion also solvessimilar goals where one or both of the membership terms are replaced by equality terms.

The specific kinds of relations between T and T ′ that Inclusion currently handles are roughly:

• T and T ′ are the same once all soft abstractions are unfolded.• T and T ′ are both universe or prop terms and the level of T is no greater than the level of

T ′ for any instantiation of level variables.• T and T ′ are each formed by using subset types, and both have some common superset

type. In this case Inclusion tries to show that the subset predicates of T ′ are implied bythe subset predicates of T together with other hypotheses.

• T and T ′ have the same outermost type constructor. In this case, the inclusion goal isreduced to one or more inclusion goals involving the immediate subterms of T and T ′.Currently works for function, product, union and list types.

• T is a subtype of T ′ according to a lemma in the library.

132

For the inclusion reasoning involving subset types to work, one has to supply information aboutabstractions involving subset types using the function add set inclusion info. The theoryint 1 contains several examples of the use of this function.

Squash Stability and Hidden Hypotheses

The constructivity of Nuprl’s logic manifests itself in the fact that the decomposition of sets inhypotheses (rule setElimination in Section A.3.12) results in a subgoal containing the predicatepart of the set term as a hidden hypothesis (the rule quotient equalityElimination in SectionA.3.14 has a similar effect). A hidden hypothesis does not contribute to the computational contentof a proof (i.e. the term inhabiting its conclusion) and is therefore not immediately usable. However,there are ways in which it might become usable later.

A hidden hypothesis P in a proof goal can be unhidden if either P or the conclusion of the goalis squash stable, which roughly means that it is possible to determine the computational content ifone knows that there is one (in the classical sense). Squash stability is defined in the theory core 2as ↓P ⇒ P , where the proposition ↓P ≡ x:Unit|P (read ‘squash P ’) is true exactly when P istrue, but has no computational content.

Squash stability can be inferred for many predicates using the tactic ProveSqStable, which isnot called by the D tactic because it can be rather slow. Instead, hypothesis can be unhidden byapplying one of the following tactics.

UnhideTry to unhide hidden hypotheses, first by checking whether the conclusion is squash stable andthen, if this fails, by checking each hidden hypothesis separately for squash stability.

Unhide applies the tactics UnhideAllHypsSinceSqStableConcl, which tries to prove the con-clusion squash stable using ProveSqStable and unhides all hidden hypotheses if this succeeds,and UnhideSqStableHyp i , which tries to prove the hidden hypothesis i squash stable.

AddProperties iAdd the predicate part of the set type underlying an abstraction A in hypothesis i as a newhypothesis immediately after i .Hypothesis i should be declaration of form A or a proposition of form t ∈A or t = t′ ∈A, whereA is an abstraction with an associated property lemma of the form ` ∀x:T. ∀y:A.P [x, y].

GenConcl xt=v ∈TyGeneralize occurrences of t as subterms of the conclusion to the variable v . This adds newhypotheses declaring v to be of type T and stating t=v ∈T .

FiatIf you about to give up hope on a theorem, this tactic is guaranteed to provide satisfaction.Fiat uses Nuprl’s because rule, which should be used for experimental purposes only. Nuprl’slibrary has a mechanism to detect uses of this rule while checking a theory for consistency.

8.8 Tacticals

Tacticals are functions for converting tactics into new one. Apart from injecting optional argumentsas described in Section 8.2.2, they are most commonly used for composing tactics. 2-ary tacticalsare often written in infix form and distinguished from others by having the first part of their namein all capitals. Infix tacticals always associate to the left.

133

8.8.1 Basic Tacticals

T1 THEN T2

Apply T1 and then run T2 on all the subgoals generated by T1.T THENL [T1;...;Tn]

Apply T and then run Ti on the i-th subgoal generated by T . T must create exactly n subgoals.T1 ORELSE T2

Apply T1. If it fails, run T2 instead.Try T ≡ T ORELSE Id

Apply T . If it fails, leave the proof unchanged.Complete T

Apply T but fail if T generates subgoals (i.e. does not complete the proof).Progress T

Apply T but fail if T does not change the goal (i.e. makes no progress).Repeat T

Repeat running T on subgoals created by previous applications until no further progress is made.RepeatFor n T

Repeat the application of T exactly n times.If e T1 T2

Apply T1 if e pf evaluates to true, where pf is the current proof goal. Otherwise, run T2.

8.8.2 Label Sensitive Tacticals

Label sensitive tacticals tacticals allow one to apply a tactic only to goals with a particular label,or to goals of one of the classes main, aux , and predicate (c.f. Section 8.2.3). For the former, thelabel associated with the tactic has to match exactly the label of the goal. For the latter, one mayuse the class names main, aux, and predicate as wild cards.8

IfLab lab T1 T2

If lab matches the label of pf, run T1. Otherwise, run T2.IfLabL [l1,T1; l2,T2; ...; ln,Tn]

Run the first tactic Ti for which li matches the label of pf. If none of the labels match, leavethe proof unchanged.

T1 THENM T2 ≡ T1 THEN IfLab ‘main‘ T2 Id

T1 THENA T2 ≡ T1 THEN IfLab ‘aux‘ T2 Id

T1 THENW T2 ≡ T1 THEN IfLab ‘wf‘ T2 Id

Apply T1 and then run T2 on all main/aux/wf subgoals.T THENLL [l1,Ts1; l2,Ts2;...; ln,Tsn]

Apply T and then do the following on each subgoal. Select the first list of tactics Tsi for whichli matches the label of the subgoal. If the subgoal also has a number label j, run the jth tacticfrom Tsi on it. If it has no number label, run the first tactic listed in Tsi.THENLL fails if there are not sufficiently many tactics in Tsi. It runs the Id tactic if a subgoallabel does not match any of the li.

SeqOnM [T1;...;Tn]Run the tactics T1 to Tn on successive main subgoals.

8Unfortunately main is currently used as both a class name and a particular label name, which means there is noway to select only subgoals in with the particular label main.

134

RepeatM TRepeatMFor n T

Repeat the tactic T on main subgoals (exactly n times).

8.8.3 Multiple Clause Tacticals

Multiple clause tacticals allow to apply a tactic T : int -> tactic to several clauses of a goalwith n hypotheses.

On [c1;...;cn] T ≡ T c1 THENM ... THENM T cn

Run T on the clauses c1. . . cn. If T succeeds on some clause, then On only continues on subgoalscreated by T that are labelled main.

AllHyps T ≡ On [n;n-1;...;1] (ı. Try (T i))

Try running T on all hypotheses starting with the end of the hypothesis list and workingbackwards. If T succeeds on some hypothesis, then AllHyps only continues on subgoals createdby T that are labelled main.

All T ≡ On [n;n-1;...;1;0] (ı. Try (T i))

Try running T on all hypotheses and then on the conclusion.

OnSomeHyp T ≡ T n ORELSE ... ORELSE T 1

Try running T on one of the hypotheses of the goal, starting with the end of the hypothesis listand working backwards.

The library contains a few abstractions that provide a more elegant notation for the most commoncombinations of tactics and tacticals.

auto T ... ≡ T THEN Autoaux auto T ...a ≡ T THENA Autosiauto T ... ≡ T THEN SIAutoautop T ...’ ≡ T THEN Auto’aux autop T ...a’ ≡ T THENA Auto’aux siauto T ...as ≡ T THENA SIAuto

8.9 The Rewrite Package

Nuprl’s rewrite package is a collection of ML functions for creating rules for rewriting termsinto equivalent ones and applying them in various fashions to clauses of a sequent. The packagesupports rewrite rules involving various equivalence relations – such as the 3-place equality-in-a-typerelation, logical bi-implication, the permutation relation on lists, abstractions, and computationalequivalence – and takes care of automating proofs that these equivalence relations are respectedby rewriting. It also supports rewriting rules involving arbitrary transitive relations such as logicalimplication and takes care of checking that relevant terms are appropriately monotonic.

The package is based around ML objects called conversions, similar to those found in othertactic-based theorem provers such as LCF, HOL, and Isabelle, provide a language for systematicallybuilding up rewrite rules in a fashion similar to the way tactics are assembled using tacticals.

135

8.9.1 Introduction to Conversions

A conversion is a function that transforms a term t into a new term t′ that is equivalent to twith respect to some relation r. The conversion also produces a justification j that describes howto prove that t r t′ holds. The transformation takes place in an environment e, which specifiesamongst other things the types of the variables that might be free in t. Conversions fail if they arenot appropriate for the term they are applied to.

In Nuprl, the type convn of conversions is an ML concrete type abbreviation for the typeenv -> term -> (term # reln # just),

where env, reln and just are abstract types for environments (Section 8.9.1.1), relations (Sec-tion 8.9.1.2), and justifications (Section 8.9.1.3). The language of conversions provides a small setof atomic conversions that may be assembled into more advanced conversions using higher orderfunctions called conversionals.

Atomic conversions (Section 8.9.2) are either based on direct computation rules (which includesfolding and unfolding abstractions) or can be created from lemmata and hypotheses that containuniversally quantified formulas with consequent of the form a r b, where the free variables of b area subset of those in a. Applying a conversion to a term t means either executing the correspondingcomputation or matching the term t against a and replacing it by an appropriate instance of b.That is, if σ is a substitution of the free variables in a such that σa = t, then t will be replacedby t′ =σb. For instance, rewriting the term (2×3) + 0 with the relation x + 0 = x means matching(2×3) + 0 against x + 0, which yields a substitution σ that binds x to 2×3. The result of rewritingis the term σx = 2×3.

Atomic conversions cannot by themselves rewrite subterms of a given term. For instance, ap-plying an atomic conversion to rewrite (1 + 0)×3 with the relation x + 0 = x fails. Conversionals(Section 8.9.4) provide the means for applying conversions to subterms of a term and help control-ling the sequence in which atomic conversions are applied to these subterms.

An example of a conversional is SweepUpC, which attempts to apply a conversion c to eachsubterm of a term t, working from the leaves of term t up to its root. Another example is ORELSEC,which first tries to apply a conversion c1 to a term and, if that fails, applies a conversion c2.

Conversionals rely on a variety of lemmata, which we will describe in Section 8.9.1.4. These lem-mata have to state reflexivity, transitivity and symmetry properties of the relation r and congruenceproperties of the terms making up the clauses that are being rewritten.

A tactic Rewrite : convn -> int -> tactic is used for making a conversion applicable tosome clause of a proof goal. It takes care of executing the justifications generated by conversions.Section 8.9.1.5 lists common variations on this tactic.

8.9.1.1 Environments

An environment is a list of propositions and declarations of variable types that are being assumed.The environment of the conclusion of a sequent is the list of all the hypotheses. The environment ofa hypothesis is the list of hypotheses to the left of it. We can also talk about local environments ofsubterms of sequent clauses. For example, in the sequent x1:H1, . . . , xn:Hn ` ∀y:T. B⇒C the localenvironment for the subterm C in the conclusion is x1:H1, . . . , xn:Hn, y:T, B. The rewrite conver-sionals keep track of the local environment each conversion is being applied in, and every conversiontakes as its first argument an expression e of type env which supplies this local information. Theenvironment information is used by lemma and hypothesis conversions in three ways.

136

• Declarations of variables in the environment are used to infer types that help to completematches.

• Propositions in the environment state the assumptions that are necessary for conditionalrewrites to go through. For example, if the subterm C in x1:H1, . . . , xn:Hn ` ∀y:T. B⇒C isrewritten by a rewrite rule based on the lemma ∀z:T. A[z]⇒ t[z] = t′[z] and matching theterm C against t results in binding the variable z to a term s, then the subgoal that has tobe proven for the rewrite rule to be valid is x1:H1, . . . , xn:Hn, y:T, B,`A[s].

• The hypothesis conversions access the hypothesis list via environment terms.

Currently, Nuprl only knows how to extend the environment when descending to the subterms ofa ∀-, ∃-, and ⇒ -term. For other terms, it does not modify the environment, unless explicitly toldso by the user, who may extend the list of environment update functions by applying the functionadd env update fun. Further details can be found in the system file env.ml.

8.9.1.2 Relations

The rewrite package supports rewriting with respect to both primitive and user-defined equivalencerelations. Some examples are:

• t ∼ t′, the computational equality relation,• t = t′ ∈T , the primitive equality relation of Nuprl’s type theory,• P ⇔Q, the logical bi-implication,• i = j mod n, the equality on the integers modulo a positive natural,• t =q t′, equality of rationals (represented as pairs of integers),• l≡ l′, the permutation relation on lists.

The package also supports ‘rewriting’ with respect to any relation that is transitive but notnecessarily symmetric or reflexive, such as logical implication9 ⇒ and order relations, becauseproofs involving transitive relations and monotonicity properties of terms can be made very similarin structure to those involving equivalence relations and congruence properties.

For each user-defined relation, the user has to provide the rewrite package with lemmata abouttransitivity, symmetry, reflexivity and strength, where a binary relation r over a type T is strongerthan a relation r′ a r b implies a r′ b for all a, b ∈T . These lemmata are used by the package for thejustification of rewrites (see Section 8.9.1.4). The user may also provide a declaration that identifiesrelation families and extra properties of relations.

Rewrite relations should be defined as first-order terms with two principal arguments suppliedas subterms. Additional parameters should always be positioned before the principal argumentsubterms. For example, the equality relation t = t′ ∈T has the type T as additional parameterand the internal structure equal(T;t;t′). Relations are most commonly represented as logicalpropositions (i.e. are of type P). Boolean-valued relations are also accepted, but they have to bewrapped in the assert abstraction if used in a context where a logical proposition is expected.

Equivalence relations should be declared by an invocation ofdeclare equiv rel rnam stronger-rnam

This declares the term with operator identifier rnam to be an equivalence relation, and the term withoperator identifier stronger-rnam to be an immediately stronger equivalence relation. Commonly,there will be only one such declaration for each rnam and stronger-rnam will be ‘equal‘. However,multiple declarations for a single equivalence relation are sometimes needed.

9 Note that treating implication as a rewrite relation leads to a generalization of forward and backward chaining.

137

Order relations are grouped into relation families, i.e. lattices of order and equivalence relations ofthe form:

< = >

≤ ≥©©©© HHHH ©©©© HHHH

where weaker relations are higher in the lattice, and relations within a family satisfy

aa a=b ⇔ a≤b ∧ b≤aa≤b ⇔ b≥a a<b ⇔ a≤b ∧ ¬(b≤a)

The converse of an order relation r should always be defined directly in terms of r. For example,the definition of the abstraction rev implies is P ⇐Q ≡ Q⇒P . The rewrite package assumesthat order relations can be inverted by folding and unfolding such definitions. A relation familyshould be declared using an invocation of

declare rel family lt le eq ge gtwhere dummy terms (i.e. the abstraction dummy(), which displays as ?) should be used as place-holders when a member of a family is missing. To simplify such invocations, a user may enter thename relfam into a term slot, which will display the template:

Relation Family< : [lt]≤ : [le]≡ : [eq]≥ : [ge]> : [gt]

Relation Family< : i < j≤ : i ≤ j≡ : i = j≥ : i ≥ j> : i > j

As an example, the invocation to the right shows the declaration of the standard order relations onthe integers as relation family. Frequently several order relation families share the same equivalencerelation, but there may also be equivalence relations that are not be associated with any orderrelation family.

The partial order of strengths of relations is the reflexive transitive closure of the strengthrelation for each family and the equivalence relation declarations. Additional relations betweenorder relations can be declared using

declare order rel pair stronger-rtm weaker-rtmFor the sake of clarity, all relation declarations should be inserted in ML objects that are

positioned after the referred-to relations but before any lemmata that might be accessed by therewrite package.

8.9.1.3 Justifications

The justification produced by a rewrite rule describes how to prove that the origin and the resultof rewriting stand in the relation r. This information is used by the rewrite tactic to generate thecorresponding Nuprl proof. There are two types of justifications.

Computational Justifications are lists of precise applications of the forward and reverse directcomputation rules. As these are comparatively very fast and generate no well-formednesssubgoals, the rewrite package uses these whenever possible.

Tactic Justifications are more generally applicable, but make extensive use of lemmata (seeSection 8.9.1.4 below) and often generate many well-formedness subgoals.

Conversions generating both types of justification can be freely intermixed; the system takescare of converting computational justifications to tactic justifications when necessary.

138

8.9.1.4 Lemma Support

The rewrite package must have access to several kinds of lemmata in order to construct justificationsfor rewrites. This section describes those lemmata.

Functionality Lemmata give congruence and monotonicity properties of terms. They are re-quired by conversionals like SubC to construct justifications for rewriting terms based on thejustifications for rewriting the immediate subterms of those terms. A functionality lemma fora term with operator op should have the form

∀z1:S1..zk:S

k.∀x1, y1:T 1..xn, yn:T n. A1⇒ . . . ⇒Am

⇒x1r1y1⇒ . . . ⇒xnrnyn⇒ op(x1; ..;xn) r op(y1; ..; yn)

where k, m≥0. The universal quantifiers and A’s can be intermixed, but the antecedentscontaining the ri must come afterward and be in the same order as the subterms of op.

If op binds variables in its subterms, then these variables should be bound by universal quanti-fiers wrapped around the appropriate ri antecedents. For example, the lemma for functionalityof ∃ with respect to the ⇔ relation is:

∀A1, A2:Ui.∀P 1:A1⇒Pi.∀P 2:A2⇒Pi.A1 = A2∈Ui

⇒ (∀x:A1. P 1[x]⇔P 2[x]) ⇒ ∃x:A1.P 1[x] ⇔ ∃x:A2.P 2[x]

To allow conversionals to find functionality lemmata in the library, they should be namedopid functionality[ index ] where opid is the operator identifier of op and index is anoptional suffix. When more than one functionality lemma is created for a given operator, theymust be ordered with the most specific r1 . . . rn first, as conversionals search for functionalitylemmata in the order in which they appear.

Functionality lemmata are not needed when all the ri and r are primitive equalities. In thiscase functionality information can be derived from the well-formedness lemma for op.

Transitivity Lemmata give transitivity information for rewrite relations. They are used to con-struct the justification in sequencing conversionals like ANDTHENC and should have the form:

∀z1:S1..zk:S

k.∀x1, x2, x3:T. A1⇒ . . . ⇒Am ⇒x1 ra x2⇒x2 rb x3⇒x1 rc x3

where k, m≥0 and rc should be the weaker of ra and rb. Transitivity lemmata should benamed opid-of-rc transitivity[ index ]. Transitivity lemmata are not needed for primi-tive equality relations.

Weakening Lemmata extend the usefulness of the transitivity and functionality lemmata. Theyshould have the form

∀z1:S1..zk:S

k.∀x1, x2:T. A1⇒ . . . ⇒Am ⇒x1 ra x2⇒x1 rb x2,

where k, m≥0 and rb is weaker than ra, and be named opid-of-rb weakening[ index ].Weakening lemmata are required for all reflexive relations rb with ra being equality.

Inversion Lemmata are used by the Rev* atomic conversions and in conjunction with weaken-ing, transitivity, and functionality lemmata when these mix order and equivalence relations.They are required for equivalence relations, but not for equality or order relations. Inversionlemmata should have the form

∀z1:S1..zk:S

k.∀x1, x2:T. A1⇒ . . . ⇒Am ⇒x1 r x2⇒x2 r x1

where k, m≥0 and should be named opid-of-r inversion.

139

Note that for order relations one only needs lemmata for one direction as the other can bederived from them. For example, one does not require both the lemma ∀a, b, c. a≤b⇒ b≤c⇒ a≤cand ∀a, b, c. a≥b⇒ b≥c⇒ a≥c.

If Nuprl finds a lemma missing in the course of constructing a rewrite justification it prints outan error message suggesting the kind and structure of the missing lemma. After adding an appro-priate lemma to the library, you need to evaluate the function initialize rw lemma caches ()to make it accessible to the rewrite package.

8.9.1.5 Applying Conversions

The following tactics can be used to make conversions applicable to some clause of a proof goal.Rewrite c i

Apply conversion c to clause i . The subgoal with the result of the conversion is labelled mainwhile the labels of the other subgoals fall into the aux class.

A shorthand notation for Rewrite is RW. The following variants of Rewrite provide a con-trolled application of the conversion c to the subterms of clause i by combining Rewrite withconversionals (see Section 8.9.4) in various fashions.RWH c i ≡ RW (HigherC c) i :

Apply c to the first possible subterm of clause i , starting from the root.RWU c i ≡ RW (SweepUpC c) i :

Apply c to all subterms of clause i , starting from the leaves.RWD c i ≡ RW (SweepDnC c) i :

Apply c to all subterms of clause i , starting from the root.RWN n c i ≡ RW (NthC n c) i :

Apply c to the n-th immediate subterm of clause i .RWAddr addr c i ≡ RW (AddrC addr c) i :

Apply c to the subterm of clause i whose address in addr

RewriteType c iApply conversion c to the type of a member or equality term in clause i .The advantage of this tactic over Rewrite is that this generates simpler well-formedness goals.In particular, it generates no well-formedness goals involving the equands of the equality or theelement of the member term. A shorthand notation for RewriteType is RWT

For testing the effect of a conversion c on a term t with an empty environment one may evaluatethe expression apply conv c t in the refiner top loop.

8.9.1.6 Conversion Arguments

The descriptions of conversions in the sections below assume that the conversions have been appliedto an environment e and a term t. Types of arguments to conversions are:

c∗ : convn type of conversionse∗ : env environmenti j : int hypothesis or clause indicesaddr : int list subterm addressa : tok name of abstractionname : tok name of lemma or cached conversiont∗ : term

A suffix s on the name of an argument indicates that it is a list. For example cs is considered tohave type conv list.

140

8.9.2 Atomic Conversions

Atomic conversions are the basic building blocks for constructing conversions. They may rewriteterms according to given lemmata and hypotheses, fold and unfold abstractions, or evaluate prim-itive and abstract redices. For the sake of completeness, there are also two trivial conversions.

IdCThe identity conversion, which does not change a term

FailCThe conversion that always fails

8.9.2.1 Lemma and Hypothesis Conversions

Lemma and hypothesis conversions derive rewrite rules from lemmata and hypotheses that containeither simple or general universal formulae (see Section 8.2.5). The consequents of these formulaemust be of form a r b, where r is a relation as described in Section 8.9.1.2.

Usually we describe these conversions as rewriting in a left-to-right direction: they replaceinstances of a’s by instances of b’s. Each conversion also has a twin conversion that works right-to-left, which is indicated by a prefix Rev to their names.

LemmaC nameRevLemmaC name

If lemma name contains a simple universal formula with consequent a r b, rewrite instances ofa to instances of b (or instances of b to instances of a, respectively).

HypC iRevHypC i

If hypothesis i contains a simple universal formula with consequent a r b, rewrite instances ofa to instances of b (or instances of b to instances of a, respectively).

The above conversions are instances of two more general conversions

GenLemmaWithThenLC (n:int) (hints:(var#term) list) (Tacs:tactic list) (name:tok)GenHypWithThenLC (n:int) (hints:(var#term) list) (Tacs:tactic list) (i:int)

which rewrite according to general universal formulae in lemmata and hypotheses. The meaning oftheir arguments is as follows:

n indicates the n-th consequent of a general universal formula. If -1 is used then the formulais always treated as simple. In particular a ⇔ relation will be considered the relation in theconsequent rather than a part of the structure of the general universal formula.

hints supply bindings for variables in the formula that Nuprl’s matching routines cannot guess.

Tacs is used for conditional rewriting, i.e. when the antecedents of a formula have to be checkedfor validity before the rewrite rule is used.The tactics in Tacs are paired up with the subgoals formed from instantiated antecedents.The rewrite goes through only if each tactic completely proves its corresponding subgoal. Ifthere are fewer tactics than antecedents, an appropriate number of copies of the head of Tacswill be added to left of Tacs. If Tacs is empty, then rewriting must go through unconditionally.

name is the name of the lemma.

i is the number of a hypothesis. Negative numbers are allowed (c.f. Section 8.2.1.1).

141

Other useful specializations of GenLemmaWithThenLC and GenHypWithThenLC are:

GenLemmaC n name ≡ GenLemmaWithThenLC n [] [] nameLemmaWithC hints name ≡ GenLemmaWithThenLC (-1) hints [] nameLemmaThenLC Tacs name ≡ GenLemmaWithThenLC (-1) [] Tacs name

GenHypC n i ≡ GenHypWithThenLC n [] [] iHypWithC hints i ≡ GenHypWithThenLC (-1) hints [] iHypThenLC Tacs i ≡ GenHypWithThenLC (-1) [] Tacs i

The hypothesis conversions described here derive their rewrite rules from local environments (Sec-tion 8.9.1.1) that they are presented with on their first applications. If the conversions are appliedwith conversionals such as HigherC or NthC that start applying a conversion at the top of a term,then the environment is always the same as the environment of the clause being rewritten.

8.9.2.2 Atomic Direct-Computation Conversions

Low level direct-computation conversions are not usually invoked directly by the user, but useful forcontrolling the evaluation of redices and the folding/unfolding of abstractions in advanced rewritestrategies. Computation conversions for interactive invocation are described in Section 8.9.3.

UnfoldTopAbCUnfoldsTopC asUnfoldTopC a ≡ UnfoldsTopC [a]

Unfold t if it is an abstraction (with operator identifier listed in as).AUnfoldsTopC attrs

Unfold t if it is an abstraction that has any of the attributes in attrs (see Section 7.1.3).RecUnfoldTopC a

Unfold the recursive definition of a if it occurs on the top level of t.FoldsTopC asFoldTopC a ≡ FoldsTopC [a]

Try to fold an instance of an abstraction whose operator identifier is listed in asRecFoldTopC a

Try to fold an instance of the recursively defined term a on the top level of t.

RecUnfoldTopC and RecFoldTopC work only with recursive definitions that have been introducedwith the AddRecDef* button (see Section 4.3.2.2).

TagC taggerDo forward computations on the term t as indicated by the tags in (tagger t).

RedexC

Contract t if it is a primitive redex.AbRedexCForceRedexC force

Contract t if it is a primitive or abstract redex (of strength less or equal to force).AnyExtractCExtractC names

Expand t if it is an extract term (of a theorem listed in names).

142

Abstract redices. Primitive redices that are buried under abstractions are called abstract redices.For example, the first and second projection functions for pairs are abstractions:

*A pi1 t.1 ≡ let <x,y> = t in x*A pi2 t.2 ≡ let <x,y> = t in y

and the term x<a,b>.1y is an abstract redex, which contracts to the term xay.To contract abstract redices, the conversion AbRedexC consults an abstract redex table, whose

entries are created using the functionadd AbReduce conv opid c

where opid is the operator identifier of the outermost term of the redex10 and c is a conversionfor contracting instances of the redex. Instances of add AbReduce conv are usually included in MLobjects positioned immediately after the definitions of non-canonical abstractions.

An alternative method for indicating an abstract redex is to associate a ‘reducible’ attribute(see Section 7.1.3) with a non-canonical abstraction using the function

add reducible ab opidThe AbRedexC conversion first unfolds all reducible abstractions at the top level of the term beforefurther analyzing it to see if it is a redex. When this method is applicable, it is more concise thanusing add AbReduce conv.

Reduction Strengths and Forces. In some situations it is desirable to have some redicescontracted but not others. To this end, one may specify the strength of a redex and provide anoptional force argument to tactics invoking direct computation conversions. Strengths and forcesare arranged in a partial order on ML tokens. A redex is contracted only if the reduction forceapplied to it is greater or equal to its strength. A strength is associated with a redex in two ways.

• The strength is directly associated with the reduction rule for the redex.

• The strength is associated with the canonical term that is the principal argument of the redex.Strengths can be associated with canonical terms using the function

note reduction strength opid strength

The currently supported strengths, in increasing order, are

‘1‘ beta redices‘2‘ other primitive redices‘3‘ abstract redices recursive‘4‘ abstract redices non-recursive‘6‘ module projection functions with coercion arguments‘7‘ functions creating module elements from concrete parts.‘8‘ quasi-canonical redices.‘9‘ irreducible terms.

Contraction conversions that should be sensitive to the force of reduction can be added to theabstract redex table using the function

add ForceReduce conv opid cwhere opid is the operator identifier of the outermost term of the redex and c is a conversion thattakes a token argument for the force with which contraction of the redex is being attempted.

10If the outermost term is an (iterated) apply term, then opid refers to the operator identifier of the term at thehead of the application.

143

8.9.3 Composite Direct Computation Conversions

The following conversions are commonly used for folding and unfolding abstractions and for theevaluation of primitive and abstract redices in a term.UnfoldsC asUnfoldC a

Unfold all occurrences of abstractions listed in as, starting at the leaves of t.RecUnfoldC a

Unfold all occurrences of the recursive definition of a in t.FoldsC asFoldC a

Fold all instances of abstractions whose operator identifiers are listed in as.RecFoldC a

Fold all instances of the recursively defined term a in t.

ReduceC ≡ AbReduceC ≡ PrimReduceC

ForceReduceC forceRepeatedly contract all redices in t (with maximal strength force) starting from the root.

EvalC asRepeatedly unfold abstractions listed in as starting at the leaves, and then contract all redices.

NormalizeCSemiNormC as

Repeatedly unfold abstractions (listed in as), starting at the root, and then contract redices.

IntSimpCRewrite t into arithmetical canonical form.

8.9.4 Conversionals

Conversionals provide the means for sequencing conversions in a way similar to the basic tacticalsdescribed in Section 8.8.1 and to apply them to subterms in a controlled fashion.c1 ANDTHENC c2

Apply c2 to the result of c1. Fail if either c1 or c2 fails.c1 ORTHENC c2

Apply c2 to the result of c1, or to t if c1 failsc1 ORELSEC c2

Apply c1. If this fails, apply c2.RepeatC cRepeatForC n c

Repeat c until it fails (exactly n times).ProgressC c

Apply c, but fail if c does not change the term.TryC c

Apply c. If this fails, leave the term unchanged.AllC cs

Iteratively apply all conversions from cs. Fail if one of them fails.SomeC cs

Iteratively apply all applicable conversions from cs.

144

FirstC csApply the first applicable conversion from cs.

SubC cApply c to all immediate subterms of t (in left-to-right order).

SubIfC p cApply c to all immediate subterms of t that satisfy the proposition p

NthSubC n cApply c to the n-th immediate subterm of t.

AddrC addr cApply c to the subterm of t with term address addr .

HigherC cLowerC c

Apply c the first applicable subterm of t, starting from the root (leaves).NthC n c

Execute the n-th successful application of c to the subterms of t, starting from the root.SweepDnC cSweepUpC c

Apply c to all subterms of t, starting from the root (leaves).TopC cDepthC c

Repeatedly apply c to the first applicable subterm of t, starting from the root (leaves).

8.9.5 Macro Conversions

Macro conversions allow to express rewrite rules via pattern terms that describe the left and theright hand side of a transformation.

MacroC name c1 t1 c2 t2Rewrite an instance of t1 to the corresponding instance of t2 using forward and reverse compu-tation steps.c1 and c2 must be direct computation conversions that rewrite the pattern terms t1 and t2 tothe same term. MacroC uses second-order matching when matching instance terms against t1.name is a failure token, which will be returned if rewriting fails.

SimpleMacroC name t1 t2 asRewrite an instance of t1 to an instance of t2 by unfolding abstractions from as and contractingredices.

FwdMacroC name c tRewrite an instance of t to an instance of the term resulting from applying c to t .

Using macro conversions enables a user to express rewrite steps in a user-defined theory in a waythat does not reveal the underlying type theory. An example for the use of MacroC is the conversionfor unrolling the Y combinator, defined in the theory core 2:

*A ycomb Y == λf.(λx.f (x x)) (λx.f (x x))*M ycomb unroll let YUnrollC =

MacroC ‘YUnrollC‘(AllC [UnfoldC ‘ycomb‘; RedexC; RedexC]) dY Fe(AllC [UnfoldC ‘ycomb‘; AddrC [2] RedexC]) dF (Y F)e

;;

145

For another example, look at the length unroll object in the list 1 theory. SimpleMacroCcan be used if the rewrite steps involved in justifying the equivalence of t1 and t2 are simpler, as inthe case of the abstract redex for the projection functions on products

let pi1 evalC =SimpleMacroC ‘pi1 evalC‘ d<a, b>.1e dae [‘pi1‘]

;;

146

Appendix A

The Basic Nuprl Type Theory

A.1 Syntax

Nuprl terms have the form opid p1:F 1,..,pk:F

k(x1

1,..,x1m1

.t1; ...; xn1,..,x

nmn

.tn). Wename the parts of a term as follows:

• opid p1:F 1,..,pk:F

k is the operator .

The parts of the operator are:

– opid is the operator identifier.

– pj:F j is the j-th parameter . pj is the parameter value and F j is the parameter type.

• The tuple (m1, . . . , mn), where mj≥0 is the arity of the term.

• si = xi1,..,x

imi.ti is the i-th bound-term of the term, which binds free occurrences of the

variables xi1,. . . ,x

imi

in ti.

When writing terms, we sometimes omit the brackets around the parameter list if it is empty.Note that parameters are separated by commas while subterms are separated by semicolons.

A.1.1 Operator Identifiers

Operator identifiers are character strings drawn from the alphabet1 a−z A−Z 0−9 - !. An ! atthe start of a character string indicates that the term does not belong to Nuprl’s object language.Operator identifiers are implemented using ML type tok. Valid operators are listed in Nuprl’soperator table, which contains the basic operators2 given in Table A.1 as well as conservativelanguage extensions defined by abstractions in the library.

1We distinguish between the ASCII character - and the character range x−y, indicating the characters from x to y.2Note that the operator identifier of a term is not always identical to the name a user has to type into Nuprl’s

term editor in order to generate the corresponding display template. The latter depends only on the informationprovided in the display form while the abstract name can only be used to enter terms in the abstract (expanded)mode. Different names are, for instance, used for the simple inductive types (simplerec instead of rec) and the less thanpredicate (lt instead of less than). A complete list of display forms for the basic terms can be found in the system’score 1 theory.

147

Canonical noncanonical(Types) (Members)

varx:v()x

function(S; x.T) lambda(x.t) apply( f ;t)

x:S→T, S→T λx.t f t

product(S; x.T) pair(s;t) spread( e ; x,y.u)x:S×T, S×T 〈s,t〉 let 〈x,y〉= e in u

union(S;T) inl(s), inr(t) decide( e ; x.u; y.v)S+T inl(s), inr(t) case e of inl(x) 7→ u | inr(y) 7→ v

universej:l() – All types of level j –

Ujequal(s;t;T) Axiom()s = t ∈ T Ax

void() – No canonical elements – any(e)void any(e)Atom() tokentoken :t() atom eq( u ; v ; s; t)Atom ¨token ¨ if u = v then s else t

int() natural numbern:n() ind( u ,x.fx; s; base ,y.fy)tZ n ind( u ,x.fx; s; base ,y.fy)t

minus(natural numbern:n()) minus( u ), add( u ; v ), sub( u ; v )−n - u , u + v , u - v

mul( u ; v ), div( u ; v ), rem( u ; v )u * v , u ÷ v , u rem vint eq( u ; v ; s; t), less( u ; v ; s; t)if u = v then s else t, if u < v then s else t

less than(u;v) Axiom()u<v Ax

list(T) nil(), cons(t;l) list ind( s ; base ; x,l,fxl.t)T list [], t::l list ind( s ; base ; x,l,fxl.t)rec(X.TX) – members defined by unrolling TX – rec ind( e ; f,x.t)rectype X = TX let∗ f(x)= t in f( e )set(S; x.T) – members of S that satisfy P –

x:S |T , S |T isect(S; x.T) – Terms that belong to all T [x] –

∩x:S.Tquotient(T; x,y.E) – members of T , new equality –

x,y :T//E

Table A.1: Basic operators of Nuprl’s Type Theory. Terms are divided into canonical and noncanoni-cal terms. Principal arguments in noncanonical terms are marked by a box . Standard display formsof terms are written below the abstract representation. The distinction between types and membersis not a part of Nuprl’s syntax.

148

A.1.2 Parameters

Parameters p:F consist of a parameter name p and a parameter family F . The current parameterfamilies and associated values are:

variable : Names of variables, implemented using the ML data type var.Acceptable names are generated by the regular expression [a−z A−Z 0−9 - %]+. The% character has a special use.

natural : Natural numbers (including 0), implemented using the ML data type int.Acceptable numbers are generated by the regular expression 0 + [1− 9][0− 9]∗.

token : Character strings, implemented using the ML data type tok.Acceptable strings can draw from any non-control characters in Nuprl’s font.

string : Character strings, implemented using the ML data type string.Acceptable strings can draw from any non-control characters in Nuprl’s font.

level-expression : Universe level expressions, implemented using the ML data type level exp.Universe level expressions are used to index universe levels in Nuprl’s type theory. Theirsyntax is described by the grammar L:: = v | k | L i | L′ | [L| · · · |L] where v denotes a level-expression variable (alphanumeric string), k a level expression constant (positive integer), andi a level expression increment (non-negative integer).

Level-expression variables are implicitly quantified over all positive integer levels. The ex-pression L i is interpreted as standing for levels L + i. L′ is an abbreviation for L 1. Theexpression [L1| · · · |Ln] is interpreted as being the maximum of expressions L1 · · ·Ln.

The names of parameter types are usually abbreviated to their first letters.

A.1.3 Binding Variables

Binding variables are character strings drawn from the same alphabet as variable parameters. Toexpress terms without bindings, the empty string can be used as null variable. Null variables neverbind. Binding variables are implemented using ML type var.

A.1.4 Injection of Variables and Numbers

In Nuprl, we consider variables and terms to be distinct. We have a special term kind, variablevfor injecting variables into the term type. When we talk of the variable x as a term, we really meanthe term variablex:v. In a similar way, when we talk of the number n as a term, we reallymean the term natural numbern:n.

The injection is often made implicitly when it is clear from the context. Nuprl’s editor atomat-ically converts variables and numbers into terms when they are typed into templates for terms.

A.1.5 Term Display

The display of Nuprl terms is not necessarily identical to their abstract form. Usually, they arepresented in a more conventional notation, which is created by the display forms described inChapter 7.2. In Table A.1 we present the standard display of Nuprl terms immediately belowtheir abstract form.

149

Redex Contractum

( λx.u ) tβ−→ u[t/x]

let 〈x,y〉= 〈s,t〉 in uβ−→ u[s, t/x, y]

case inl(s) of inl(x) 7→ u | inr(y) 7→ vβ−→ u[s/x]

case inr(t) of inl(x) 7→ u | inr(y) 7→ vβ−→ v[t/y]

if a = b then s else tβ−→ s, if a = b; t, otherwise

ind( 0 ,x.fx; s; base ,y.fy)tβ−→ base

ind( i ,x.fx; s; base ,y.fy)tβ−→ t[i,ind( i-1 ,x.fx; s; base ,y.fy)t /y, fy], (i>0)

ind( -i ,x.fx; s; base ,y.fy)tβ−→ s[−i,ind( -i+1 ,x.fx; s; base ,y.fy)t /x, fx], (i>0)

- iβ−→ The negation of i (as number)

i + jβ−→ The sum of i and j

i - jβ−→ The difference of i and j

i * jβ−→ The product of i and j

i ÷ jβ−→ 0, if j=0; the integer division of i and j, otherwise

i rem jβ−→ 0, if j=0; the division rest of i and j, otherwise

if i = j then s else tβ−→ s, if i = j; t, otherwise

if i < j then s else tβ−→ s, if i < j; t, otherwise

list ind( [] ; base; x,l,fxl.t)β−→ base

list ind( s::u ; base; x,l,fxl.t)β−→ t[s, u,list ind(u; base; x,l,fxl.t)/x, l, fxl]

let∗ f(x)= t in f( e )β−→ t[λy.let∗ f(x)= t in f(y), e / f, x]

Table A.2: Redex–Contracta Table for Nuprl’s Type Theory: the principal arguments must be inthe corresponding canonical form

A.2 Semantics

A.2.1 Evaluation

Nuprl’s semantics is based on a notion of values. Terms are divided into canonical forms, i.e. values,and noncanonical forms, i.e. terms that need to be evaluated. Evaluation in Nuprl is lazy : whethera term is canonical or not depends solely on its operator identifier but not on its subterms. Innoncanonical forms, certain subterms are marked as principal arguments. If a principal argumentis instantiated with a matching canonical form, the expression becomes reducible (i.e. a redex ) andcan be evaluated to its contractum, defined in a redex–contracta table.

Nuprl’s evaluation mechanism first computes the values of all principal arguments of a non-canonical expression. If an argument does not have a value or if the resulting expression is notreducible, evaluation stops: the expression has no value. Otherwise the expression will be reducedaccording to redex–contracta table and the resulting term will be evaluated.

Canonical forms and noncanonical forms together with their principal arguments are given inTable A.1. The corresponding redex–contracta table is given in Table A.2.

150

x1:S1→T 1 = x2:S2→T 2 if S1=S2 and T1[s1/x1]=T2[s2/x2] for all s1, s2 with s1=s2 ∈S1.T = S2→T 2 if T = x2:S2→T 2 for some x2

∈V.S1→T 1 = T if x1:S1→T 1 = T for some x1

∈V.x1:S1×T 1 = x2:S2×T 2 if S1=S2 and T1[s1/x1]=T2[s2/x2] for all s1, s2 with s1=s2 ∈S1.T = S2×T 2 if T = x2:S2×T 2 for some variable x2.S1×T 1 = T if x1:S1×T 1 = T for some variable x1.S1+T 1 = S2+T 2 if S1=S2 and T 1=T 2.Uj1

= Uj2if j1=j2 (as natural number)

s1= t1 ∈ T 1 = s2= t2 ∈ T 2 if T 1=T 2, s1=s2∈T 1, and t1=t2∈T 1.

void = voidAtom = AtomZ = Zi1<j1 = i2<j2 if i1 = i2 ∈ Z and j1 = j2

∈ ZT 1 list = T 2 list if T 1 = T 2

rectype X1= T 1 = rectype X2= T 2 if T 1[X/X1] = T 2[X/X2] for all types Xx1:S1|T 1 = x2:S2| T 2 if S1=S2 and there are terms p1, p2 and a variable x, which occurs

neither in T 1 nor in T 2, such thatp1

∈ ∀x:S1. T1[x/x1]⇒T2[x/x2] andp2

∈ ∀x:S1. T2[x/x2]⇒T1[x/x1].T = S2 | T 2 if T = x2:S2| T 2 for some variable x2.S1 | T 1 = T if x1:S1| T 1 = T for some variable x1.∩x1:S1.T 1 = ∩x2:S2.T 2 if S1=S2 and T1[s1/x1]=T2[s2/x2] for all s1, s2 with s1=s2 ∈S1.x1,y1:T 1//E1

= x2,y2: T 2//E2if T 1 = T 2 and there are terms p1,p2,r,s,t and variables x, y, z,

which occur neither in E1 nor in E2, such thatp1

∈ ∀x:T 1.∀y:T 1.E1[x, y/x1, y1]⇒E2[x, y/x2, y2],p2

∈ ∀x:T 1.∀y:T 1.E2[x, y/x2, y2]⇒E1[x, y/x1, y1],r ∈ ∀x:T 1.E1[x, x/x1, y1],s ∈ ∀x:T 1.∀y:T 1.E1[x, y/x1, y1]⇒E1[y, x/x1, y1], andt ∈ ∀x:T 1.∀y:T 1.∀z:T 1.

E1[x, y/x1, y1]⇒E1[y, z/x1, y1]⇒E1[x, z/x1, y1]

Table A.3: Type semantics table for Nuprl

A.2.2 Judgments

The meaning of type theoretical expressions is given in the form of judgments about essentialproperties of the terms. Judgments are assertions of certain truths that form the foundation oftype theory. We distinguish 4 types of judgments: Typehood (T Type), Type Equality (S=T ),Membership (t ∈T ), and Member Equality (s=t ∈T ). The precise meaning of these judgments isdefined as follows.

T Type if T=T .

S=T if there are canonical terms S′ and T ′ such that S∗−→S′, T

∗−→T ′

and S′=T ′ follows from the type semantics table.

t 2T if t=t ∈T .

s=t 2T if there are canonical terms s′, t′ and T ′ such that s∗−→ s′, t

∗−→ t′, T=T ′,and s′=t′ ∈T ′ follows from the member semantics table.

Nuprl’s type semantics table is given in Table A.3 and its member semantics table in Table A.4.

151

λx1.t1 = λx2.t2 ∈ x:S→T if x:S→T Type and t1[s1/x1] = t2[s2/x2] ∈ T [s1/x]for all s1,s2 with s1=s2

∈S.〈s1,t1〉 = 〈s2,t2〉 ∈ x:S×T if x:S×T Type, s1=s2

∈S, and t1=t2∈T [s1/x].inl(s1) = inl(s2) ∈ S+T if S+T Type and s1=s2

∈S.inr(t1) = inr(t2) ∈ S+T if S+T Type and t1=t2∈TAx = Ax ∈ s = t ∈ T if s = t ∈ Ts = t ∈ void never holds !¨token¨ = ¨token¨ ∈ Atomi = i ∈ ZAx = Ax ∈ s<t if s

∗−→ i and t∗−→ j for some integers i, j with i < j

[] = [] ∈ T list if T Typet1::l1 = t2::l2 ∈ T list if T Type, t1=t2∈T , and l1=l2∈T lists = t ∈ rectype X = TX if rectype X = TX Type and s = t ∈ TX [rectype X = TX/X]s = t ∈ x:S |T if x:S |T Type, s=t ∈S, and there is some term p ∈T [s/x]t1 = t2 ∈ ∩x:S.T if ∩x:S.T Type and t1=t2 ∈T [s/x] for all s ∈S.s = t ∈ x,y : T//E if x,y :T//E Type, s ∈T , t ∈T ,

and there is some term p ∈ E[s, t/x, y]x1:S1→T1 = x2:S2→T2 ∈ Uj if S1=S2 ∈Uj and T1[s1/x1]=T2[s2/x2] ∈Uj

for all s1, s2 with s1=s2 ∈S1

T = S2→T2 ∈ Uj if T = x2:S2→T2 ∈ Uj for some variable x2

S1→T1 = T ∈ Uj if x1:S1→T1 = T ∈ Uj for some variable x1

x1:S1×T1 = x2:S2×T2 ∈ Uj if S1=S2 ∈Uj and T1[s1/x1]=T2[s2/x2] ∈Ujfor all s1,s2 with s1=s2 ∈S1

T = S2×T2 ∈ Uj if T = x2:S2×T2 ∈ Uj for some variable x2

S1×T1 = T ∈ Uj if x1:S1×T1 = T ∈ Uj for some variable x1

S1+T1 = S2+T2 ∈ Uj if S1=S2 ∈Uj and T1=T2 ∈Ujs1= t1 ∈ T 1 = s2= t2 ∈ T 2

∈ Uj if T 1=T 2∈Uj , s1=s2

∈T 1, and t1=t2∈T 1.Uj1 = Uj2

∈ Uj if j1=j2<j (as natural number)

void = void ∈ UjAtom = Atom ∈ UjZ = Z ∈ Uji1<j1 = i2<j2

∈ Uj if i1 = i2 ∈ Z und j1 = j2∈ Z

T 1 list = T 2 list ∈ Uj if T 1 = T 2∈ Uj

rectype X1= T 1 = rectype X2= T 2∈ Uj if T 1[X/X1] = T 2[X/X2] ∈ Uj for all X ∈ Uj

x1:S1|T 1 = x2:S2|T 2 ∈ Uj if S1=S2∈Uj and there are terms p1, p2 and a variable x,

which occurs neither in T 1 nor in T 2, such thatp1

∈ ∀x:S1.T1[x/x1]⇒T2[x/x2] andp2

∈ ∀x:S1.T2[x/x2]⇒T1[x/x1].T = S2 | T 2 ∈ Uj if T = x2:S2|T 2 ∈ Uj for some variable x2.S1 | T 1 = T ∈ Uj if x1:S1|T 1 = T ∈ Uj for some variable x1.∩x1:S1.T 1 = ∩x2:S2.T 2

∈ Uj if S1=S2 ∈Uj and T1[s1/x1]=T2[s2/x2] ∈Ujfor all s1, s2 with s1=s2 ∈S1.

x1,y1:T 1//E1= x2,y2:T 2//E2

∈ Uj if T 1 = T 2∈ Uj and there are terms p1,p2,r,s,t and variables

x, y, z, which occur neither in E1 nor in E2, such thatp1

∈ ∀x:T 1.∀y:T 1.E1[x, y/x1, y1]⇒E2[x, y/x2, y2],p2

∈ ∀x:T 1.∀y:T 1.E2[x, y/x2, y2]⇒E1[x, y/x1, y1],r ∈ ∀x:T 1.E1[x, x/x1, y1],s ∈ ∀x:T 1.∀y:T 1.E1[x, y/x1, y1]⇒E1[y, x/x1, y1], andt ∈ ∀x:T 1.∀y:T 1.∀z:T 1.

E1[x, y/x1, y1]⇒E1[y, z/x1, y1]⇒E1[x, z/x1, y1]

Table A.4: Member semantics table for Nuprl

152

A.3 Inference rules

Nuprl’s inference rules describe the top-down refinement of proof sequents (see Chapter 6) and thebottom-up construction of extract terms. Rules are written in a top-down fashion, showing the goalsequent above the rule name and the subgoal sequents below it.

For each type there are rules for type formation and type equality, formation and equality ofcanonical members, equality of noncanonical forms, type decomposition in hypotheses (elimination),computation rules, and possibly additional rules. In addition to the rule name, a rule may needcertain arguments (see Section 8.1.2) such as

• The position of a hypothesis to be used as in hypothesis i

• Names for newly created variables as in functionEquality x

• The universe level of a type as in lambdaEquality j x′

• A term that instantiates a variable as in dependent pairFormation j s x′

• The type of some subterm in the goal as in applyEquality x:S→T

• The dependency of a term C[z] from a variable z as in decideEquality z C S+T s t y

Most of the elementary inference rules are subsumed by the one-step decomposition tacticsD, MemCD, EqCD, MemHD, EqHD, MemTypeCD, EqTypeCD, MemTypeHD, EqTypeHD. These tactics try todetermine the parameters of the corresponding rules from the context unless they are explicitlyprovided with the tacticals New, At, With, or Using (see Section 8.2.2). A user may choose touse these tacticals to support the tactics in situations where appropriate parameters cannot befound automatically or in order to enforce the use of, for instance, particular names for newlycreated variables.

In the following we present the basic inference rules of Nuprl’s type theory as well as thetactics that can be used to perform the same one-step decomposition of proof goals. For the latterwe describe both the minimal form, which only lists tactics that are needed for injecting requiredarguments, and a maximal form with all tacticals that may have an effect on the execution ofthe tactic. Some rules that are now considered obsolete are not covered by tactics and have to beconverted explicitly into tactics using the function refine (see Section 8.1.3).

For integer and list induction we use the abstract terms instead of the lengthy display forms.Goals of the form a ∈T always abbreviate a=a ∈T . ¬P stands for P→void, s6=t for ¬(s=t ∈Z), ands≤t for ¬(t<s).

153

A.3.1 Functions

Γ ` Uj bext x:S→Tcby dependent functionFormation x S

Γ ` S ∈ Uj bAxc

Γ, x:S ` Uj bext Tc

Γ ` Uj bext S→Tcby independent functionFormation

Γ ` Uj bext ScΓ ` Uj bext Tc

Γ ` x1:S1→T 1 = x2:S2→T 2∈ Uj bAxc

by functionEquality x

Γ ` S1 = S2∈Uj bAxc

Γ, x:S1 ` T1[x/x1] = T2[x/x2] ∈ Uj bAxc

Γ ` S1→T 1 = S2→T 2∈ Uj bAxc

by independent functionEquality

Γ ` S1 = S2∈ Uj bAxc

Γ ` T 1 = T 2∈ Uj bAxc

Γ ` λx1.t1 = λx2.t2 ∈ x:S→T bAxc

by lambdaEquality j x′

Γ, x′:S ` t1[x′/x1] = t2[x′/x2] ∈T [x′/x] bAxc

Γ ` S ∈Uj bAxc

Γ ` x:S→T bext λx′.tcby lambdaFormation j x′

Γ, x′:S ` T [x′/x] bext tcΓ ` S ∈ Uj bAxc

Γ ` f 1 t1 = f 2 t2 ∈ T [t1/x] bAxc

by applyEquality x:S→T

Γ ` f 1 = f 2∈ x:S→T bAxc

Γ ` t1 = t2 ∈ S bAxc

Γ, f:S→T, ∆ ` C bext t[f s, /y]cby independent functionElimination i y

Γ, f:S→T, ∆ ` S bext scΓ, f:S→T, y:T, ∆ ` C bext tc

Γ, f: x:S→T, ∆ ` C bext t[fs, Ax/y, z]cby dependent functionElimination i s y z

Γ, f: x:S→T, ∆ ` s ∈S bAxc

Γ, f: x:S→T, y:T [s/x], z: y=f s ∈T [s/x], ∆ ` C bext tc

Γ ` (λx.t) s = t2 ∈ T bAxc

by applyReduce

Γ ` t[s/x] = t2 ∈ T bAxc

Γ ` f 1 = f 2∈ x:S→T bext tc

by functionExtensionality j x1:S1→T 1 x2:S2→T 2 x′

Γ, x′:S ` f 1x′ = f 2x

′ ∈T [x′/x] bext tcΓ ` S ∈ Uj bAxc

Γ ` f 1∈ x1:S1→T 1 bAxc

Γ ` f 2∈ x2:S2→T 2 bAxc

Basic Inference Rule Corresponding Tacticwith required arguments with optional tacticals

dependent functionFormation x S ---independent functionFormation ---functionEquality x EqCD New [x] EqCDindependent functionEquality ---lambdaEquality j x′ EqCD At Uj EqCD

lambdaFormation j x′ D 0applyEquality x:S→T EqCD With x:S→T EqCDindependent functionElimination i y D idependent functionElimination i s y z D iapplyReduce ReduceEquands 0 ReduceAtAddr [2] 0functionExtensionality j x1:S1→T 1 x2:S2→T 2 x′ EqExtWith Ext

154

A.3.2 Products

Γ ` Uj bext x:S×Tcby dependent productFormation x S

Γ ` S ∈ Uj bAxc


Γ ` Uj bext S×Tcby independent productFormation


Γ ` x1:S1×T 1 = x2:S2×T 2∈ Uj bAxc

by productEquality x′


Γ, x′:S1 ` T1[x′/x1] = T2[x′/x2] ∈ Uj bAxc

Γ ` S1×T 1 = S2×T 2∈Uj bAxc

by independent productEquality



Γ ` 〈s1,t1〉 = 〈s2,t2〉 ∈ x:S×T bAxc

by dependent pairEquality j x′

Γ ` s1 = s2∈ S bAxc

Γ ` t1 = t2 ∈ T [s1/x] bAxc

Γ, x′:S ` T [x′/x] ∈ Uj bAxc

Γ ` x:S×T bext 〈s,t〉cby dependent pairFormation j s x′

Γ ` s ∈ S bAxc

Γ ` T [s/x] bext tcΓ, x′:S ` T [x′/x] ∈ Uj bAxc

Γ ` 〈s1,t1〉 = 〈s1,t1〉 ∈ S×T bAxc

by independent pairEquality


Γ ` t1 = t2 ∈ T bAxc

Γ ` S×T bext 〈s,t〉cby independent pairFormation

Γ ` S bext scΓ ` T bext tc

Γ ` let 〈x1,y1〉= e1 in t1 = let 〈x2,y2

〉= e2 in t2 ∈ C[e1/z] bAxc

by spreadEquality z C x:S×T s t y

Γ ` e1 = e2∈ x:S×T bAxc

Γ, s:S, t:T [s/x], y: e1=〈s,t〉 ∈x:S×T ` t1[s, t/x1, y1] = t2[s, t/x2, y2] ∈ C[〈s,t〉/z] bAxc

Γ, z: x:S×T, ∆ ` C bext let 〈s,t〉= z in ucby productElimination i s t

Γ, z: x:S×T, s:S, t:T [s/x] ∆[〈s,t〉/z] ` C[〈s,t〉/z] bext uc

Γ ` let 〈x,y〉= 〈s,t〉 in u = t2 ∈ T bAxc

by spreadReduce

Γ ` u[s, t/x, y] = t2 ∈ T bAxc


dependent productFormation x S ---independent productFormation ---productEquality x′ EqCDindependent productEquality ---dependent pairEquality j x′ EqCDdependent pairEquality2 j x′ EqCDdependent pairFormation j s x′ With s (D 0) At Uj (With s (New [x′] (D 0)))

independent pairEquality EqCDindependent pairFormation D 0spreadEquality z C x:S×T s t y EqCDproductElimination i s t D ispreadReduce ReduceEquands 0 ReduceAtAddr [2] 0

155

A.3.3 Disjoint Union

Γ ` Uj bext S+Tcby unionFormation


Γ ` S1+T 1 = S2+T 2∈Uj bAxc

by unionEquality



Γ ` inl(s1) = inl(s2) ∈ S+T bAxc

by inlEquality j


Γ ` T ∈ Uj bAxc

Γ ` S+T bext inl(s)cby inlFormation j

Γ ` S bext scΓ ` T ∈ Uj bAxc

Γ ` inr(t1) = inr(t2) ∈ S+T bAxc

by inrEquality j

Γ ` t1 = t2∈T bAxc

Γ ` S ∈ Uj bAxc

Γ ` S+T bext inr(t)cby inrFormation j

Γ ` T bext tcΓ ` S ∈ Uj bAxc

Γ ` case e1 of inl(x1) 7→ u1 | inr(y1) 7→ v1 = case e2 of inl(x2) 7→ u2 | inr(y2) 7→ v2∈ C[e1/z] bAxc

by decideEquality z C S+T s t y

Γ ` e1 = e2∈ S+T bAxc

Γ, s:S, y: e1=inl(s) ∈S+T ` u1[s/x1] = u2[s/x2] ∈ C[inl(s)/z] bAxc

Γ, t:T, y: e1=inr(t) ∈S+T ` v1[t/y1] = v2[t/y2] ∈ C[inr(t)/z] bAxc

Γ, z:S+T, ∆ ` C bext case z of inl(x) 7→u | inr(y) 7→ vcby unionElimination i x y

Γ, z:S+T, x:S, ∆[inl(x)/z] ` C[inl(x)/z] bext ucΓ, z:S+T, y:T, ∆[inr(y)/z] ` C[inr(y)/z] bext vc

Γ ` case inl(s) of inl(x) 7→ u | inr(y) 7→ v = t2 ∈ T bAxc

by decideReduceLeft

Γ ` u[s/x] = t2 ∈ T bAxc

Γ ` case inr(t) of inl(x) 7→ u | inr(y) 7→ v = t2 ∈ T bAxc

by decideReduceRight

Γ ` v[t/y] = t2 ∈ T bAxc


unionFormation ---unionEquality EqCDinlEquality j EqCDinlFormation j Sel 1 D 0inrEquality j EqCDinrFormation j Sel 2 D 0decideEquality z C S+T s t y EqCD Using [z,C] (With S+T (New s t y EqCD)))unionElimination i x y D idecideReduceLeft ReduceEquands 0 ReduceAtAddr [2] 0decideReduceRight ReduceEquands 0 ReduceAtAddr [2] 0

156

A.3.4 Universes

Γ ` Uk bext Ujcby universeFormation j ∗

Γ ` Uj = Uj ∈ Uk bAxc

by universeEquality ∗

Γ ` T ∈Uk bAxc

by cumulativity j ∗

Γ ` T ∈Uj bAxc

∗: proviso j < k


universeFormation j D 0universeEquality EqCDcumulativity j Cumulativity j

157

A.3.5 Equality

Γ ` Uj bext s = t ∈ T cby equalityFormation T

Γ ` T ∈ Uj bAxc

Γ ` T bext scΓ ` T bext tc

Γ ` s1= t1 ∈ T 1 = s2= t2 ∈ T 2∈ Uj bAxc

by equalityEquality


Γ ` s1 = s2∈ T 1 bAxc

Γ ` t1 = t2 ∈ T 1 bAxc

Γ ` Ax = Ax ∈ s = t ∈ T bAxc

by axiomEquality

Γ ` s = t ∈ T bAxc

Γ, z: s = t ∈ T , ∆ ` C bext ucby equalityElimination i

Γ, z: s = t ∈ T , ∆[Ax/z] ` C[Ax/z] bext uc

Γ, x:T, ∆ ` x = x ∈ T bAxc

by hypothesisEquality i

Γ ` C[s/x] bext ucby substitution j s=t ∈T x C

Γ ` s=t ∈T bAxc

Γ ` C[t/x] bext ucΓ, x:T ` C ∈ Uj bAxc


by equalityDecision procedure for elementary equalities


equalityFormation T ---equalityEquality EqCDaxiomEquality EqCDequalityElimination i D ihypothesisEquality i Declaration NthDecl isubstitution j s=t ∈T x C Subst s=t ∈T 0 At j (BasicSubst s=t ∈T x C)equality Eq Eq

158

A.3.6 Void

Γ ` Uj bext voidcby voidFormation

Γ ` void = void ∈ Uj bAxc

by voidEquality

Γ ` any(s) = any(t) ∈ T bAxc

by anyEquality

Γ ` s = t ∈ void bAxc

Γ, z: void, ∆ ` C bext any(z)cby voidElimination i


voidFormation ---voidEquality EqCDanyEquality EqCDvoidElimination i D i

159

A.3.7 Atom

Γ ` Uj bext Atomcby atomFormation

Γ ` Atom = Atom ∈ Uj bAxc

by atomEquality

Γ ` ¨token¨ = ¨token¨ ∈ Atom bAxc

by tokenEqualityΓ ` Atom bext ¨token c

by tokenFormation ¨token¨

Γ ` if u1=v1 then s1 else t1 = if u2=v2 then s2 else t2 ∈ T bAxc

by atom eqEquality v

Γ ` u1 = u2∈ Atom bAxc

Γ ` v1 = v2∈ Atom bAxc

Γ, v: u1=v1∈Atom ` s1 = s2

∈ T bAxc

Γ, v:¬(u1=v1∈Atom) ` t1 = t2 ∈ T bAxc

Γ ` if u=v then s else t = t2 ∈ T bAxc

by atom eqReduceTrue

Γ ` s = t2 ∈ T bAxc

Γ ` u = v ∈ Atom bAxc


by atom eqReduceFalse

Γ ` t = t2 ∈ T bAxc

Γ ` ¬(u = v ∈ Atom) bAxc


atomFormation ---atomEquality EqCDtokenEquality EqCDtokenFormation ¨token¨ D 0atom eqEquality v EqCDatom eqReduceTrue PrimReduceFirstEquand ‘true‘ PrimReduceEquands ‘true‘ [1]atom eqReduceFalse PrimReduceFirstEquand ‘false‘ PrimReduceEquands ‘false‘ [1]

160

A.3.8 Integers

Γ ` Uj bext Zcby intFormation

Γ ` Z ∈ Uj bAxc

by intEquality

Γ ` n = n ∈ Z bAxc

by natural numberEqualityΓ ` Z bext nc

by natural numberFormation n

Γ ` -s1 = -s2∈ Z bAxc

by minusEquality

Γ ` s1 = s2∈ Z bAxc

Γ ` s1+t1 = s2+t2 ∈ Z bAxc

by addEquality


Γ ` t1 = t2 ∈ Z bAxc

Γ ` Z bext s+tcby addFormation

Γ ` Z bext scΓ ` Z bext tc

Γ ` s1-t1 = s2-t2 ∈ Z bAxc

by subtractEquality



Γ ` Z bext s-tcby subtractFormation


Γ ` s1*t1 = s2*t2 ∈ Z bAxc

by multiplyEquality



Γ ` Z bext s*tcby multiplyFormation


Γ ` s1÷t1 = s2÷t2 ∈ Z bAxc

by divideEquality



Γ ` t1 6= 0 bAxc

Γ ` Z bext s÷tcby divideFormation


Γ ` s1rem t1 = s2rem t2 ∈ Z bAxc

by remainderEquality



Γ ` t1 6= 0 bAxc

Γ ` Z bext s rem tcby remainderFormation


Γ ` 0 ≤ s rem t ∧ s rem t < t bAxc

by remainderBounds1

Γ ` 0 ≤ s bAxc

Γ ` 0 < t bAxc

Γ ` 0 ≤ s rem t ∧ s rem t < -t bAxc

by remainderBounds2

Γ ` 0 ≤ s bAxc

Γ ` t < 0 bAxc

Γ ` s rem t ≤ 0 ∧ s rem t > t bAxc

by remainderBounds3

Γ ` s ≤ 0 bAxc

Γ ` t < 0 bAxc

Γ ` s rem t ≤ 0 ∧ s rem t > -t bAxc

by remainderBounds4

Γ ` s ≤ 0 bAxc

Γ ` 0 < t bAxc

Γ ` s = (s÷t)*t + (s rem t) bAxc

by divideRemainderSum

Γ ` s = s ∈Z bAxc

Γ ` t 6= 0 bAxc

161

Γ ` ind(u1; x1,fx1.s1; base1; y1,fy1.t1) = ind(u2; x2,fx2.s2; base2; y2,fy2.t2) ∈ T [u1/z] bAxc

by indEquality z T x fx v

Γ ` u1 = u2∈ Z bAxc

Γ, x:Z, v: x<0, fx:T [(x+1)/z] ` s1[x, fx/x1, fx1] = s2[x, fx/x2, fx2] ∈ T [x/z] bAxc

Γ ` base1 = base2∈ T [0/z] bAxc

Γ, x:Z, v: 0<x, fx:T [(x-1)/z] ` t1[x, fx/y1, fy1] = t2[x, fx/y2, fy2] ∈ T [x/z] bAxc

Γ, z:Z, ∆ ` C bext ind(z; x,fx.s[Ax/v]; base; x,fx.t[Ax/v])cby intElimination i x fx v

Γ, z:Z, ∆, x:Z, v: x<0, fx:C[(x+1)/z] ` C[x/z] bext scΓ, z:Z, ∆ ` C[0/z] bext basecΓ, z:Z, ∆, x:Z, v: 0<x, fx:C[(x-1)/z] ` C[x/z] bext tc

Γ ` ind(i; x,fx.s; base; y,fy.t) = t2 ∈ T bAxc

by indReduceDown

Γ ` t[i,ind(i+1; x,fx.s; base; y,fy.t)/x, fx] = t2 ∈ T bAxc

Γ ` i < 0 bAxc


by indReduceUp

Γ ` t[i,ind(i-1; x,fx.s; base;y,fy.t)/y, fy] = t2 ∈ T bAxc

Γ ` 0 < i bAxc


by indReduceBase

Γ ` base = t2 ∈ T bAxc

Γ ` i = 0 ∈ Z bAxc

Γ ` if u1=v1 then s1 else t1 = if u2=v2 then s2 else t2 ∈ T bAxc

by int eqEquality


Γ ` v1 = v2∈ Z bAxc

Γ, v: u1=v1 ` s1 = s2∈ T bAxc

Γ, v: u16=v1 ` t1 = t2 ∈ T bAxc


by int eqReduceTrue


Γ ` u = v ∈ Z bAxc


by int eqReduceFalse


Γ ` u 6= v bAxc

Γ ` if u1<v1 then s else t = if u2<v2 then s2 else t2 ∈ T bAxc

by lessEquality


Γ ` v1 = v2∈ Z bAxc

Γ, v: u1<v1 ` s1 = s2∈ T bAxc

Γ, v: u1≥v1 ` t1 = t2 ∈ T bAxc

Γ ` if u<v then s else t = t2 ∈ T bAxc

by lessReduceTrue


Γ ` u < v bAxc

Γ ` if u<v then s else t = t2 ∈ T bAxc

by lessReduceFalse


Γ ` u ≥ v bAxc

162

Γ ` C bext tcby arith j

Γ ` si ∈ Z bAxc

Decision procedure for elementary arithmetic

– subgoals for all non-arithmetical expressions si in C –


intFormation ---intEquality EqCDnatural numberEquality EqCDnatural numberFormation n With n (D 0)minusEquality EqCDaddEquality EqCDaddFormation ---subtractEquality EqCDsubtractFormation ---multiplyEquality EqCDmultiplyFormation ---divideEquality EqCDdivideFormation ---remainderEquality EqCDremainderFormation ---remainderBounds1remainderBounds2remainderBounds3remainderBounds4divideRemainderSumindEquality z T x fx v StrongEqCDintElimination i x fx v D iindReduceDown PrimReduceFirstEquand ‘down‘ PrimReduceEquands ‘down‘ [1]indReduceUp PrimReduceFirstEquand ‘up‘ PrimReduceEquands ‘up‘ [1]indReduceBase PrimReduceFirstEquand ‘base‘ PrimReduceEquands ‘base‘ [1]int eqEquality EqCDint eqReduceTrue PrimReduceFirstEquand ‘true‘ PrimReduceEquands ‘true‘ [1]int eqReduceFalse PrimReduceFirstEquand ‘false‘ PrimReduceEquands ‘false‘ [1]lessEquality EqCDlessReduceTrue PrimReduceFirstEquand ‘true‘ PrimReduceEquands ‘true‘ [1]lessReduceFalse PrimReduceFirstEquand ‘false‘ PrimReduceEquands ‘false‘ [1]arith j Arith

163

A.3.9 Less Than Proposition

Γ ` s1<t1 = s2<t2 ∈ Uj bAxc

by less thanEquality



Γ ` Uj bext s<tcby less thanFormation


Γ ` Ax ∈ s<t bAxc

by less thanMember

Γ ` s < t bAxc


less thanEquality EqCDless thanFormation ---less thanMember EqCD

164

A.3.10 Lists

Γ ` Uj bext T listcby listFormation

Γ ` Uj bext Tc

Γ ` T 1 list = T 2 list ∈ Uj bAxc

by listEquality


Γ ` [] = [] ∈ T list bAxc

by nilEquality j

Γ ` T ∈ Uj bAxc

Γ ` T list bext []cby nilFormation j

Γ ` T ∈ Uj bAxc

Γ ` t1::l1 = t2::l2 ∈ T list bAxc

by consEquality

Γ ` t1 = t2 ∈ T bAxc

Γ ` l1 = l2 ∈ T list bAxc

Γ ` T list bext t::lcby consFormation

Γ ` T bext tcΓ ` T list bext lc

Γ ` list ind(s1; base1; x1,l1,fxl1.t1) = list ind(s2; base2; x2,l2,fxl2.t2) ∈ T [s1/z] bAxc

by list indEquality z T S list x l fxl

Γ ` s1 = s2∈ S list bAxc

Γ ` base1 = base2∈ T [[]/z] bAxc

Γ, x:S, l:S list , fxl:T [l/z] ` t1[x, l, fxl/x1, l1, fxl1] = t2[x, l, fxl/x2, l2, fxl2] ∈ T [x::l/z] bAxc

Γ, z:T list , ∆ ` C bext list ind(z; base; x,l,fxl.t)cby listElimination i fxl x l

Γ, z: T list , ∆ ` C[[]/z] bext basecΓ, z: T list , ∆, x:T, l:T list , fxl:C[l/z] ` C[x::l/z] bext tc

Γ ` list ind([]; base; x,l,fxl.t) = t2 ∈ T bAxc

by list indReduceBase

Γ ` base = t2 ∈ T bAxc

Γ ` list ind(s::u; base; x,l,fxl.t) = t2 ∈ T bAxc

by list indReduceUp

Γ ` t[s, u,list ind(u; base; x,l,fxl.t)/x, l, fxl] = t2 ∈ T bAxc


listFormation ---listEquality EqCDnilEquality j EqCDnilFormation j D 0consEquality EqCDconsFormation ---list indEquality z T S list x l fxl EqCDlistElimination i fxl x l D ilist indReduceBase ReduceEquands 0 ReduceAtAddr [2] 0list indReduceUp ReduceEquands 0 ReduceAtAddr [2] 0

165

A.3.11 Inductive Types

Γ ` rectype X1= TX1 = rectype X2= TX2 ∈ Uj bAxc

by recEquality X

Γ, X:Uj ` TX1[X/X1] = TX2[X/X2] ∈ Uj bAxc

Γ ` s = t ∈ rectype X = TX bAxc

by rec memberEquality j

Γ ` s = t ∈ TX [rectype X = TX/X] bAxc

Γ ` rectype X = TX ∈ Uj bAxc

Γ ` rectype X = TX bext tcby rec memberFormation j

Γ ` TX [rectype X = TX/X] bext tcΓ ` rectype X = TX ∈ Uj bAxc

Γ ` let∗ f 1(x1)= t1 in f 1(e1) = let∗ f 2(x2)= t2 in f 2(e2) ∈ T [e1/z] bAxc

by rec indEquality z T rectype X = TX j P f x

Γ ` e1 = e2∈ rectype X = TX bAxc

Γ ` rectype X = TX ∈ Uj bAxc

Γ, P: (rectype X = TX)→Pj, f: (x:x:rectype X = TX |P(x) → T [y/z]),x:TX [x:rectype X = TX |P(x) /X] ` t1[f, x/f1, x1] = t2[f, x/f2, x2] ∈T [x/z] bAxc

Γ, z: rectype X = TX, ∆ ` C bext let∗ f(x)= t[λy.Λ/P ] in f(z)cby recElimination i j P y f x

Γ, z: rectype X = TX, ∆ ` rectype X = TX ∈ Uj bAxc

Γ, z: rectype X = TX, ∆, P: (rectype X = TX)→Pj, f: (y:x:rectype X = TX |P(x) →C[y/z]),

x:TX [x:rectype X = TX |P(x) /X] ` C[x/z] bext tc

Γ, z: rectype X = TX, ∆ ` C bext t[z/x]cby recUnrollElimination i x v

Γ, z: rectype X = TX, ∆, x:TX [rectype X = TX/X], v: z=x ∈TX [rectype X = TX/X] ` C[x/z]bext tc


recEquality X ---rec memberEquality j EqTypeCDrec memberFormation j ---rec indEquality z T rectype X = TX j P f x ---recElimination i j P y f x RecTypeInduction irecUnrollElimination i x v D i

166

A.3.12 Subset

Γ ` Uj bext x:S |T cby dependent setFormation S x

Γ ` S ∈ Uj bAxc


Γ ` Uj bext S |Tcby independent setFormation


Γ ` x1:S1|T 1 = x2:S2|T 2 ∈ Uj bAxc

by setEquality x



Γ ` s = t ∈ x:S |T bAxc

by dependent set memberEquality j x′

Γ ` s = t ∈ S bAxc

Γ ` T [s/x] bAxc


Γ ` x:S |T bext scby dependent set memberFormation j s x′

Γ ` s ∈ S bAxc

Γ ` T [s/x] bAxc


Γ ` s = t ∈ S |T bAxc

by independent set memberEquality

Γ ` s = t ∈ S bAxc

Γ ` T bAxc

Γ ` S |T bext scby independent set memberFormation

Γ ` S bext scΓ ` T bAxc

Γ, z: x:S |T , ∆ ` C bext (λy.t) zcby setElimination i y v

Γ, z: x:S |T , y:S, [bvc]:T [y/x], ∆[y/z] ` C[y/z] bext tc


dependent setFormation S x ---independent setFormation ---setEquality x EqCDdependent set memberEquality j x′ EqTypeCDdependent set memberFormation j s x′ D 0independent set memberEquality EqTypeCDindependent set memberFormation D 0setElimination i y v D i

167

A.3.13 Intersection

Γ ` Uj bext ∩x:S.Tcby isectFormation x S

Γ ` S ∈ Uj bAxc


Γ ` ∩x1:S1.T 1 = ∩x2:S2.T 2∈ Uj bAxc

by isectEquality x

Γ ` S1 = S2∈Uj bAxc


Γ ` t1 = t2 ∈ ∩x:S.T bAxc

by isect memberEquality j x′

Γ, x′:S ` t1 = t2 ∈ T [x′/x] bAxc

Γ ` S ∈ Uj bAxc

Γ ` ∩x:S.T bext tcby isect memberFormation j x′

Γ, x′:S ` T [x′/x] bext tcΓ ` S ∈ Uj bAxc

Γ ` f 1 = f 2∈ T [t/x] bAxc

by isect member caseEquality ∩x:S.T t

Γ ` f 1 = f 2∈ ∩x:S.T bAxc

Γ ` t ∈ S bAxc

Γ, f:∩x:S.T, ∆ ` C bext t[f, Ax/y, z]cby isectElimination i s y z

Γ, f:∩x:S.T, ∆ ` s ∈S bAxc

Γ, f:∩x:S.T, y:T [s/x], z: y=f ∈T [s/x], ∆ ` C bext tc


isectFormation x S ---isectEquality x EqCDisect memberEquality j x′ EqTypeCDisect memberFormation j x′ D 0isect member caseEquality ∩x:S.T t GenTypeCD t = x ∈ SisectElimination i s y z With s (D i)

168

A.3.14 Quotient Type

Γ ` Uj bext x,y :T//Ecby quotientFormation T E x y z v v′

Γ ` T ∈ Uj bAxc

Γ, x:T, y:T ` E ∈ Uj bAxc

Γ, x:T, ` E[x, x/x, y] bAxc

Γ, x:T, y:T, v:E[x, y/x, y] ` E[y, x/x, y] bAxc

Γ, x:T, y:T, z:T, v:E[x, y/x, y], v′:E[y, z/x, y] ` E[x, z/x, y] bAxc

Γ ` x1,y1:T 1//E1= x2,y2:T 2//E2

∈ Uj bAxc

by quotientWeakEquality x y z v v′


Γ, x:T 1, y:T 1 ` E1[x, y/x1, y1] = E2[x, y/x2, y2] ∈ Uj bAxc

Γ, x:T 1 ` E1[x, x/x1, y1] bAxc

Γ, x:T 1, y:T 1, v:E1[x, y/x1, y1] ` E1[y, x/x1, y1] bAxc

Γ, x:T 1, y:T 1, z:T 1, v:E1[x, y/x1, y1], v′:E1[y, z/x1, y1] ` E1[x, z/x1, y1] bAxc

Γ ` x1,y1:T 1//E1= x2,y2:T 2//E2

∈ Uj bAxc

by quotientEquality

Γ ` x1,y1:T 1//E1∈ Uj bAxc

Γ ` x2,y2:T 2//E2∈ Uj bAxc


Γ, v:T 1=T 2∈Uj, x:T 1, y:T 1 ` E1[x, y/x1, y1] ⇒ E2[x, y/x2, y2] bAxc

Γ, v:T 1=T 2∈Uj, x:T 1, y:T 1 ` E2[x, y/x2, y2] ⇒ E1[x, y/x1, y1] bAxc

Γ ` s = t ∈ x,y :T//E bAxc

by quotient memberWeakEquality j

Γ ` x,y :T//E ∈ Uj bAxc


Γ ` x,y :T//E bext tcby quotient memberFormation j


Γ ` T bext tc

Γ ` s = t ∈ x,y :T//E bAxc

by quotient memberEquality j


Γ ` s ∈ T bAxc

Γ ` t ∈ T bAxc

Γ ` E[s, t/x, y] bAxc

Γ, v: s=t ∈x,y :T//E , ∆ ` C bext ucby quotient equalityElimination i j v′

Γ, v: s=t ∈x,y :T//E , [bv′c]:E[s, t/x, y], ∆ ` C bext ucΓ, v: s = t ∈x,y :T//E , ∆ ` E[s, t/x, y] ∈ Uj bAxc

Γ, z: x,y :T//E , ∆ ` s = t ∈ S bAxc

by quotientElimination i j x′ y′ v

Γ, z: x,y :T//E , ∆, x′:T, y′:T ` E[x′, y′/x, y] ∈ Uj bAxc

Γ, z: x,y :T//E , ∆ ` S ∈ Uj bAxc

Γ, z: x,y :T//E , ∆, x′:T, y′:T, v:E[x′, y′/x, y] ` s[x′/z] = t[y′/z] ∈ S[x′/z] bAxc

169

Γ, z: x,y :T//E , ∆ ` s = t ∈ S bAxc

by quotientElimination 2 i j x′ y′ v

Γ, z: x,y :T//E , ∆, x′:T, y′:T ` E[x′, y′/x, y] ∈ Uj bAxc

Γ, z: x,y :T//E , ∆ ` S ∈ Uj bAxc

Γ, z: x,y :T//E , x′:T, y′:T, v:E[x′, y′/x, y], ∆[x′/z] ` s[x′/z] = t[y′/z] ∈ S[x′/z] bAxc


quotientFormation T E x y z v v′ ---quotientWeakEquality x y z v v′ EqCDquotientEquality QuotEqCDquotient memberWeakEquality j WeakEqTypeCDquotient memberFormation j D 0quotient memberEquality j EqTypeCDquotient equalityElimination i j v′ EqTypeD iquotientElimination i j x′ y′ v D iquotientElimination 2 i j x′ y′ v QuotD i QuotientHD’ [x′;y′] i

170

A.3.15 Direct Computation

Γ ` C bext tcby direct computation tagCΓ ` C↓tagC bext tc

Γ ` C bext tcby reverse direct computation tagCΓ, ` C↑tagC bext tc

Γ, z:T, ∆ ` C bext tcby direct computation hypothesis i tagTΓ, z: T↓tagT, ∆ ` C bext tc

Γ, z:T, ∆ ` C bext tcby reverse direct computation hypothesis i tagTΓ, z: T↑tagT, ∆ ` C bext tc


direct computation tagC ComputeWithTaggedTerm tagC 0reverse direct computation tagC RevComputeWithTaggedTerm tagC 0direct computation hypothesis i tagT ComputeWithTaggedTerm tagT ireverse direct computation hypothesis i tagT RevComputeWithTaggedTerm tagT i

171

A.3.16 Miscellaneous

Γ, x:T, ∆ ` T bext xcby hypothesis i

Γ, x:T, ∆ ` C bext tcby thin i

Γ, ∆ ` C bext tc

Γ, ∆ ` C bext (λx.t) scby cut i T x

Γ, ∆ ` T bext scΓ, x:T, ∆ ` C bext tc

Γ ` T bext tcby introduction t

Γ ` t ∈ T bAxc

Γ, z:T, ∆ ` C bext tcby hyp replacement i S j

Γ, z:S, ∆ ` C bext tcΓ, z:T, ∆ ` T = S ∈ Uj bAxc

Γ ` C bext tcby lemma "theorem-name"

Γ ` t ∈ T bAxc

by extract "theorem-name"

Γ ` C bext t[σ]cby instantiate Γ′ C ′ σ

Γ’ ` C ′ bext tc

Γ ` C bext t[y/x]cby rename y x

Γ[x/y] ` C[x/y] bext tc

Γ ` C bAxc

by because


hypothesis i Hypothesis NthHyp ithin i Thin icut i T x Assert T AssertDeclAtHyp i T xintroduction t UseWitness t UseWitness thyp replacement i S j SubstClause S ilemma "theorem-name" Lemma "theorem-name" Lemma "theorem-name"extract "theorem-name"instantiate Γ′ C ′ σrename y x RenameVar x i ∗

because Fiat Fiat∗: y is the variable declared in hypothesis i.

172

Appendix B

Introduction to Nuprl ML

Whenever Nuprl is fired up, several ML top loops are created. Running in these windows is anML interpreter that is embedded into the library, editor, or refiner process. Whenever one has theML> prompt one can type an ML expression, terminate it with ;; and press | . ML will evaluatethe expression, and print its value and type.1

One’s primary interaction with Nuprl 5 is through the navigator and the windows opened by it.However, advanced users will find it necessary to interact with the Nuprl 5 processes for examiningparts of Nuprl objects or customizing the behavior of Nuprl 5. In particular, all Nuprl tacticsare written in ML, as are a variety of utility functions. The tactics are documented in Chapter 8.The utility functions are described throughout this Chapter.

B.1 The History of ML

Several versions of the programming language ML have appeared over the years, between thetime it was first designed and implemented by Milner, Morris and Wadsworth at the University ofEdinburgh in the early 1970’s, and the time it was settled and standardized in the mid-1980’s. Theoriginal ML, the meta-language of the Edinburgh LCF system, is defined in [GMW79].

The ML used in the Nuprl system is fairly close to the original. It is derived from a early versionthat Huet at INRIA and Paulson at the University of Cambridge were working on in 1981. ToddKnoblock at Cornell made most of the Nuprl specific modifications in the mid-1980’s. Nuprl’s MLhasn’t changed since then and is not compatible with the ML versions that are widely used today.

The ML of Huet and Paulson is described in the preface to ‘The ML Handbook ’ [CHP84].Huet used this version in the Formel project; and it subsequently evolved into a version of MLcalled CAML. Paulson also used it, as part of the first version of Cambridge LCF, but switched toStandard ML in the later versions of Cambridge LCF [Pau87].

The CAML language [CH90, WAL+90] is now rarely used. But there is a scaled down versioncalled CAML-Light which is actively used in teaching programming to over 10,000 engineers a year inFrance. Its object-oriented version OCaml [Ler00] have become quite popular in recent years and hasbeen used in the implementation of the group communication toolkit Ensemble [Hay98, BCH+00].The Standard ML language has also become increasingly popular for implementing theorem proverssuch as HOL [GM93] or Isabelle [Pau90].

1Note that the ML prompt is different in each window. It is ML[(ORB)]> in the Nuprl process windows for thelibrary, editor, or refiner and may later change into ML[(lib)]>, ML[(edd)]>, and ML[(ref)]>. In the Nuprl 5 toploop it is ML[EDD]>, ML[LIB]>, or ML[REF]>. The latter already provide the double semicolon for terminating an MLexpression, so the user does not have to enter ;; in these windows.

173

The description of ML that appears in Sections B.3 to B.6 is based very closely on ‘The MLHandbook’ [CHP84]. It was adapted for Nuprl purposes from LATEX sources provided by the HOLtheorem proving group in Cambridge. For completeness (and historical interest), the preface to‘The ML Handbook ’ and the preface to ‘Edinburgh LCF: a Mechanised Logic of Computation’ arereproduced below.

B.1.1 Preface to ‘The ML Handbook’

This handbook is a revised edition of Section 2 of ‘Edinburgh LCF’, by M. Gordon, R. Milner, andC. Wadsworth, published in 1979 as Springer Verlag Lecture Notes in Computer Science no 78.ML was originally the meta-language of the LCF system. The ML system was adapted to Maclispon Multics by Gerard Huet at INRIA in 1981, and a compiler was added. Larry Paulson from theUniversity of Cambridge completely redesigned the LCF proving system, which stabilized in 1984as Cambridge LCF. Guy Cousineau from the University Paris VII added concrete types in thesummer of 1984. Philippe Le Chenadec from INRIA implemented an interface with the Yacc parsergenerator system, for the versions of ML running under Unix. This permits the user to associate aconcrete syntax with a concrete type.

The ML language is still under design. An extended language was implemented on the VAXby Luca Cardelli in 1981. It was then decided to completely re-design the language, in order toaccommodate in particular the call by pattern feature of the language HOPE designed by RodBurstall and David MacQueen. A committee of researchers from the Universities of Edinburgh andCambridge, the Bell Laboratories and INRIA, headed by Robin Milner, is currently working onthe new extended language, called Standard ML. Progress reports appear in the PolymorphismNewsletter, edited by Luca Cardelli and David MacQueen from Bell Laboratories. The design of acore language is now frozen, and its description will appear in a forthcoming report of the Universityof Edinburgh, as ‘The Standard ML Core Language’ by Robin Milner.

This handbook is a manual for ML version 6.1, released in December 1984. The language issomewhere in between the original ML from LCF and standard ML, since Guy Cousineau addedthe constructors and call by patterns. This is a LISP based implementation, compatible for Maclispon Multics, Franzlisp on VAX under Unix, Zetalisp on Symbolics 3600, and Le Lisp on 68000, VAX,Multics, Perkin-Elmer, etc... Video interfaces have been implemented by Philippe Le Chenadec onMultics, and by Maurice Migeon on Symbolics 3600. The ML system is maintained and distributedjointly by INRIA and the University of Cambridge.

B.1.2 Preface to ‘Edinburgh LCF’

ML is a general purpose programming language. It is derived in different aspects from ISWIM,POP2 and GEDANKEN, and contains perhaps two new features. First, it has an escape and escapetrapping mechanism, well-adapted to programming strategies which may be (in fact usually are)inapplicable to certain goals. Second, it has a polymorphic type discipline which combines theflexibility of programming in a typeless language with the security of compile-time type checking(as in other languages, you may also define your own types, which may be abstract and/or recursive).

For those primarily interested in the design of programming languages, a few remarks here maybe helpful both about ML as a candidate for comparison with other recently designed languages,and about the description of ML which we provide. On the first point, although we did not set outwith programming language design as a primary aim, we believe that ML does contain featuresworthy of serious consideration; these are the escape mechanism and the polymorphic type disciplinementioned above, and also the attempt to make programming with functions—including those of

174

higher type—as easy and natural as possible. We are less happy about the imperative aspects of thelanguage, and would wish to give them further thought if we were mainly concerned with languagedesign. In particular, the constructs for controlling iteration both by boolean conditions and byescape-trapping (which we included partly for experiment) are perhaps too complex taken together,and we are sensitive to the criticism that escape (or failure, as we call it) reports information onlyin the form of a string. This latter constraint results mainly from our type discipline; we do notknow how best to relax the constraint while maintaining the discipline.

Concerning the description of ML, we have tried both to initiate users by examples of program-ming and to give a precise definition.

B.2 Introduction and Examples

ML is an interactive language. At top-level one can:

• evaluate expressions

• perform declarations

To give a first impression of the system, we reproduce below a session at a terminal in whichsimple uses of various ML constructs are illustrated. To make the session easier to follow, it is splitinto a sequence of sub-sessions. A complete description of the syntax and semantics of ML is givenin Section B.3 and Section B.4 respectively.

B.2.1 Expressions

In this tutorial, the ML prompt is # so lines beginning with this contain the user’s contribution;all other lines are output by the system. The Nuprl ML prompt is different; usually ML> is usedfor the first line of user input, and > is used for continuation lines.

1# 2+3;;5 : int

# it;;5 : int

ML prompted with #, the user then typed x2+3;;y followed by a carriage return | ; ML thenresponded with x5 : inty , a new line, and then prompted again. The user then typed xit;; |y andthe system responded by typing x5 : inty again. In general to evaluate an expression e one typese followed by a carriage return; the system then prints e’s value and type (the type prefaced by acolon). The value of the last expression evaluated at top level is remembered in the identifier it.

B.2.2 Declarations

The declaration let x = e evaluates e and binds the resulting value to x.

2# let x=2*3;;x = 6 : int

# it=x;;false : bool

175

Notice that declarations do not affect the identifier it. To bind the variables x1, . . . , xn si-multaneously to the values of the expressions e1, . . . , en one can perform either the declarationlet x1=e1 and x2=e2 ...and xn=en or let x1,x2,...,xn = e1,e2...,en. These two declara-tions are equivalent.

3# let y=10 and z=x;;y = 10 : intz = 6 : int

# let x,y = y,x;;x = 10 : inty = 6 : int

A declaration d can be made local to the evaluation of an expression e by evaluating theexpression d in e. The expression e where b (where b is a binding such as x=2) is equivalent tolet b in e.

4# let x=2 in x*y;;12 : int

# x;;10 : int

# x*y where x=2;;12 : int

B.2.3 Assignment

Identifiers can be declared assignable using letref instead of let. Values bound to such identifierscan be changed with the assignment expression x:=e, which changes the value bound to x to bethe value of e. Attempts to assign to non-assignable variables are detected by the type checker.

5# x:=1;;

unbound or non-assignable variable x1 error in typingtypecheck failed

# letref x=1 and y=2;;x = 1 : inty = 2 : int

# x:=6;;6 : int

# x;;6 : int

The value of an assignment x:=e is the value of e (hence the value of y:=6 is 6). Simultaneousassignments can also be done:

6# x,y := y,x;;(2,6) : (int # int)

# x,y;;(2,6) : (int # int)

The type (int # int) is the type of pairs of integers.

176

B.2.4 Functions

To define a function f with formal parameter x and body e one performs the declarationlet f x = e. To apply the function f to an actual parameter e one evaluates the expression f e.

7# let f x = 2*x;;f = - : (int -> int)

# f 4;;8 : int

Functions are printed as a dash, -, followed by their type, since a function as such is notprintable. Application binds more tightly than anything else in the language; thus, for example,f 3 + 4 means (f 3) + 4 not f (3 + 4). Functions of several arguments can be defined:

8# let add x y = x+y;;add = - : (int -> int -> int)

# add 3 4;;7 : int

# let f = add 3;;f = - : (int -> int)

# f 4;;7 : int

Application associates to the left so add 3 4 means (add 3) 4. In the expression add 3, thefunction add is partially applied to 3; the resulting value is the function of type int -> int whichadds 3 to its argument. Thus add takes its arguments one at a time. We could have made add takea single argument of the cartesian product type (int # int):

9# let add(x,y) = x+y;;add = - : ((int # int) -> int)

# add(3,4);;7 : int

# let z = (3,4) in add z;;7 : int

# add 3;;

ill-typed phrase: 3has an instance of type intwhich should match type (int # int)1 error in typingtypecheck failed

As well as taking structured arguments (e.g. (3,4)) functions may also return structured results.

10# let sumdiff(x,y) = (x+y,x-y);;sumdiff = - : ((int # int) -> (int # int))

# sumdiff(3,4);;(7, -1) : (int # int)

177

B.2.5 Recursion

The following is an attempt to define the factorial function:

11# let fact n = if n=0 then 1 else n*fact(n-1);;

unbound or non-assignable variable fact1 error in typingtypecheck failed

The problem is that any free variables in the body of a function have the bindings they had justbefore the function was declared; fact is such a free variable in the body of the declaration above,and since it is not defined before its own declaration, an error results. To make things clear consider:

12# let f n = n+1;;f = - : (int -> int)

# let f n = if n=0 then 1 else n*f(n-1);;f = - : (int -> int)

# f 3;;9 : int

Here f 3 results in the evaluation of 3*f(2), but now the first f is used so f(2) evaluates to2+1=3, hence the expression f 3 results in 3*3=9. To make a function declaration hold within itsown body, letrec instead of let must be used. The correct recursive definition of the factorialfunction is thus:

13# letrec fact n = if n=0 then 1 else n*fact(n-1);;fact = - : (int -> int)

# fact 3;;6 : int

B.2.6 Iteration

The construct if e1 then e2 loop e3 is the same as if e1 then e2 else e3 in the true case;when e1 evaluates to false, e3 is evaluated and control loops back to the front of the constructagain. As an illustration, here is an iterative definition of fact using two local assignable variables:count and result.

14# let fact n =# letref count=n and result=1# in if count=0# then result# loop count,result := count-1,count*result;;fact = - : (int -> int)

# fact 4;;24 : int

Replacing the then in if e1 then e2 else e3 by loop causes iteration when e1 evaluatesto true: e.g., if e1 loop e2 else e3 is equivalent to if not(e1) then e3 loop e2. The con-ditional/loop construct can have a number of conditions, each preceded by if. The expressionguarded by each condition may be preceded by then, or by loop when the whole construct is tobe re-evaluated after evaluating the guarded expression:

178

15# let gcd(x,y) =# letref x,y = x,y# in if x>y loop x:=x-y# if x<y loop y:=y-x# else x;;gcd = - : ((int # int) -> int)

# gcd(12,20);;4 : int

B.2.7 Lists

If e1, . . . , en all have type ty then the ML expression [e1;. . .;en] has type (ty list). The standardfunctions on lists are hd (head), ]tl (tail), null (which tests whether a list is empty – i.e. is equalto []), and the infixed operators . (cons) and @ (append, or concatenation).

16# let m = [1;2;(2+1);4];;m = [1; 2; 3; 4] : int list

# hd m , tl m;;(1, [2; 3; 4]) : (int # int list)

# null m , null [];;(false, true) : (bool # bool)

# 0.m;;[0; 1; 2; 3; 4] : int list

# [1; 2] @ [3; 4; 5; 6];;[1; 2; 3; 4; 5; 6] : int list

# [1;true;2];;

ill-typed phrase: truehas an instance of type boolwhich should match type int1 error in typingtypecheck failed

All the members of a list must have the same type (although this type could be a sum, ordisjoint union type—see Section B.5).

B.2.8 Tokens

A sequence of characters enclosed between token quotes (‘ – i.e. ascii 96) is a token.

17# ‘this is a token‘;;‘this is a token‘ : tok

# ‘‘this is a token list‘‘;;[‘this‘; ‘is‘; ‘a‘; ‘token‘; ‘list‘] : tok list

# it = ‘‘this is a‘‘ @ [‘token‘;‘list‘];;true : bool

The expression ‘‘tok1tok2...tokn‘‘ is an alternative syntax for [‘tok1‘;‘tok2‘;...;‘tokn‘].

179

B.2.9 Strings

A sequence of characters enclosed between string quotes (" – i.e. ascii 34) is a string .

18# "this is a string";;"this is a string" : string

# "";;"" : string

Although similar, strings and tokens are implemented differently in Lisp; strings are imple-mented as character arrays, and tokens as symbols. The implementation affects the efficiency ofsuch operations as comparison and concatenation; Tokens are much slower to concatenate, butfaster to compare.

B.2.10 Polymorphism

The list processing functions hd, tl etc. can be used on all types of lists.

19# hd [1;2;3];;1 : int

# hd [true;false;true];;true : bool

# hd [1,2;3,4];;(1, 2) : (int # int)

Thus hd has several types; for example, it is used above with types (int list) -> int,(bool list) -> bool, and (int # int) list -> (int # int). In fact if ty is any type thenhd has the type (ty list) -> ty. Functions, like hd, with many types are called polymorphic, andML uses type variables *, **, *** etc. to represent their types.

20# hd;;- : (* list -> *)

# letrec map f l = if null l then []# else f(hd l).map f (tl l);;map = - : ((* -> **) -> * list -> ** list)

# map fact [1;2;3;4];;[1; 2; 6; 24] : int list

The ML function map takes a function f (with argument type * and result type **), and a listl (of elements of type *), and returns the list obtained by applying f to each element of l (whichis a list of elements of type **). map can be used at any instance of its type: above, both * and **were instantiated to int; below, * is instantiated to (int list) and ** to bool. Notice that theinstance need not be specified; it is determined by the type checker.

21# map null [[1;2]; []; [3]; []];;[false; true; false; true] : bool list

180

B.2.11 Lambda-expressions

The expression \x.e evaluates to a function with formal parameter x and body e. Thus the decla-ration let f x = e is equivalent to let f = \x.e. Similarly let f(x,y) z = e is equivalent tolet f = \(x,y).\z.e. Repeated \’s, as in \(x,y).\z.e may be abbreviated by \(x,y) z.e. Thecharacter \ is our \x.e and \(x,y) z.e are called lambda-expressions.

22# \x.x+1;;- : (int -> int)

# it 3;;4 : int

# map (\x.x*x) [1;2;3;4];;[1; 4; 9; 16] : int list

# let doubleup = map (\x.x@x);;doubleup = - : (* list list -> * list list)

# doubleup [ [1;2]; [3;4;5] ];;[[1; 2; 1; 2]; [3; 4; 5; 3; 4; 5]] : int list list

# doubleup [];;[] : * list list

B.2.12 Failure

Some standard functions fail at run-time on certain arguments, yielding a string (which is usuallythe function name) to identify the sort of failure. A failure with token ‘t‘ may also be generatedexplicitly by evaluating the expression failwith ‘t‘ (or more generally failwith e where e hastype tok).

23# hd(tl[2]);;evaluation failed hd

# 1/0;;evaluation failed div

# (1/0)+1000;;evaluation failed div

# failwith (hd [‘a‘;‘b‘]);;evaluation failed a

A failure can be trapped by ?; the value of the expression e1 ? e2 is that of e1, unless e1 causesa failure, in which case it is the value of e2.

24# hd(tl[2]) ? 0;;0 : int

# (1/0)?1000;;1000 : int

# let half n =# if n=0 then failwith ‘zero‘# else let m=n/2# in if n=2*m then m else failwith‘odd‘;;half = - : (int -> int)

181

The function half only succeeds on non-zero even numbers; on 0 it fails with ‘zero‘, and onodd numbers it fails with ‘odd‘.

25# half 4;;2 : int

# half 0;;evaluation failed zero

# half 3;;evaluation failed odd

# half 3 ? 1000;;1000 : int

Failures may betrapped selectively (on string) by ??; if e1 fails with token t, then the value ofe1 ?? [t1;...;tn] e2 is the value of e2 if t is one of t1,. . . ,tn; otherwise the expression fails withthe value of t.

26# half(0) ?? [‘zero‘;‘plonk‘] 1000;;1000 : int

# half(1) ?? [‘zero‘;‘plonk‘] 1000;;evaluation failed odd

One may add several ?? traps to an expression, and one may add a ? trap at the end as a catch-all.

27# half(1)# ??[‘zero‘] 1000# ??[‘odd‘] 2000;;2000 : int

# hd(tl[half(4)])# ??[‘zero‘] 1000# ??[‘odd‘] 2000# ? 3000;;3000 : int

One may use ! or !! in place of ? or ?? to cause re-iteration of the whole construct, analogouslyto using loop in place of then.

28# let same(x,y) =# if x>y then failwith ‘greater‘# if x<y then failwith ‘less‘# else x;;same = - : ((int # int) -> int)

# let gcd(x,y) =# letref x,y = x,y# in same(x,y)# !![‘greater‘] x:=x-y# !![‘less‘] y:=y-x;;gcd = - : ((int # int) -> int)

# gcd(12,20);;4 : int

182

B.2.13 Type abbreviations

Types can be given names:

29# lettype intpair = int # int;;type intpair defined

# let p = 12,20;;p = (12, 20) : intpair

The new name is simply an abbreviation; for example, intpair and int # int are completelyequivalent. The system always uses the most recently defined name when printing types.

30# gcd;;- : (intpair -> int)

# gcd p;;4 : int

B.2.14 Abstract types

New types can also be defined by abstraction. For example, to define a type time we could use theconstruct abstype:

31# abstype time = int # int# with maketime(hrs,mins) = if hrs<0 or 23<hrs or# mins<0 or 59<mins# then fail# else abs_time(hrs,mins)# and hours t = fst(rep_time t)# and minutes t = snd(rep_time t);;maketime = - : (intpair -> time)hours = - : (time -> int)minutes = - : (time -> int)

This defines an abstract type time and three primitive functions: maketime, hours and minutes.In general, an abstract type declaration has the form abstype ty = ty′ with b where b is a binding,i.e. the kind of phrase that can follow let or letrec. Such a declaration introduces a new typety which is represented by ty′. Only within b can one use the (automatically declared) functionsabs ty (of type ty′ -> ty) and rep ty (of type ty -> ty′), which map between a type and itsrepresentation. In the example above abs time and rep time are only available in the definitionsof maketime, hours and minutes; these latter three functions, on the other hand, are definedthroughout the scope of the declaration. Thus an abstract type declaration simultaneously declaresa new type together with primitive functions for the type. The representation of the type (i.e. ty′),and of the primitives (i.e. the right hand sides of the definitions in b), is not accessible outside thewith-part of the declaration.

32# let t = maketime(8,30);;t = - : time

# hours t , minutes t;;(8, 30) : intpair

Notice that values of an abstract type are printed as -, like functions.

183

B.2.15 Type constructors

Both list and # are examples of type constructors; list has one argument (hence * list) whereas# has two (hence * # **). Each type constructor has various primitive operations associated withit, for example list has null, hd, tl, . . . etc, and # has fst, snd and the infix ,.

33# let z = it;;z = (8, 30) : intpair

# fst z;;8 : int

# snd z;;30 : int

Another standard constructor of two arguments is +; * + ** is the disjoint union of types *and **, and associated with it are the following primitives:

isl : (* + **) -> bool tests membership of left summandinl : * -> (* + **) injects into left summandinr : * -> (** + *) injects into right summandoutl : (* + **) -> * projects out of left summandoutr : (* + **) -> ** projects out of right summand

These are illustrated by:

34# let x = inl 1# and y = inr 2;;x = inl 1 : (int + *)y = inr 2 : (* + int)

# isl x;;true : bool

# isl y;;false : bool

# outl x;;1 : int

# outl y;;evaluation failed outl

# outr x;;evaluation failed outr

# outr y;;2 : int

Abstract types such as time defined above can be thought of as type constructors with noarguments (i.e. nullary constructors). The abstype...with... construct may also be used to definenon-nullary type constructors (with absrectype in place of abstype if these are recursive). Forexample, trees analogous to LISP S-expressions could be defined by:

184

35# absrectype * sexp = * + (* sexp) # (* sexp)# with cons(s1,s2) = abs_sexp (inr (s1,s2))# and car s = fst (outr(rep_sexp s))# and cdr s = snd (outr(rep_sexp s))# and atom s = isl(rep_sexp s)# and makeatom a = abs_sexp(inl a);;cons = - : ((* sexp # * sexp) -> * sexp)car = - : (* sexp -> * sexp)cdr = - : (* sexp -> * sexp)atom = - : (* sexp -> bool)makeatom = - : (* -> * sexp)

B.3 Syntax of ML

We shall use variables to range over the various constructs of ML as follows:

Variable Ranges overvar variablescon constructorsce constant expressionsty typestab type abbreviation bindings (see B.5.4)ab abstract type bindings (see B.5.5)d declarationsb bindingsp patternse expressions

Variables and constructors are both represented by identifiers but they are different syntaxclasses. Identifiers and constant expressions are described in Section B.3.2 below. Types and type-bindings are explained in Section B.5. Declarations, bindings, patterns and expressions are definedby the following BNF-like syntax equations in which:

1. Each variable ranges over constructs as above.

2. The numbers following the various variables are there merely to distinguish between differentoccurrences—this will be convenient when we describe the semantics in Section B.4.

3. C denotes an optional occurrence of C, and for n>1 C1|C2...|Cn denotes a choice ofexactly one of C1,C2,. . . ,Cn.

4. The constructs are listed in order of decreasing binding power.

5. ‘L’ or ‘R’ following a construct means that it associates to the left (L) or right (R) whenjuxtaposed with itself (where this is syntactically admissible).

6. Certain constructs are equivalent to others and this is indicated by ‘equiv.’ followed by theequivalent construct.

185

B.3.1 Syntax equations for ML

Table B.1 describes ML declarations, Table B.2 bindings, Table B.3 patterns, and Table B.4 onpage 187 describes expressions.

d ::= let b ordinary variables| letref b assignable variables| letrec b recursive functions| lettype tab concrete types| rectype cb recursive concrete types| abstype ab abstract types| absrectype ab recursive abstract types

Table B.1: Declarations

b ::= p=e simple binding| id p1 p2 . . . pn :ty = e function definition| b1 and b2 . . . and bn multiple binding

Table B.2: Bindings

p ::= () empty pattern| id variable| p:ty type constraint| p1.p2 R list cons| p1,p2 R pairing| [] empty list| [p1;p2 . . . ;pn] list of n elements| (p) equivalent to p

Table B.3: Patterns

In the syntax equations constructs are listed in order of decreasing binding power. For example,since e1e2 is listed before e1;e2 function application binds more tightly than sequencing and thuse1e2; e3 parses as (e1e2); e3. This convention determines only the relative binding power of differ-ent constructs. The left or right association of a construct is indicated explicitly by ‘L’ for left and ‘R’for right. For example, as application associates to the left, the expression e1e2e3 parses as (e1e2) e3,and since e1 => e2 | e3 associates to the right, the expression e1 => e2 | e3 => e4 | e5 parsesas e1 => e2 | (e3 => e4 | e5).

Only functions can be defined with letrec. For example, letrec x = 2-x would cause a syntaxerror.

All the variables occurring in a pattern must be distinct. On the other hand, a pattern cancontain multiple occurrences of the wildcard ().

Spaces (ASCII 32), carriage returns (ASCII 13), line feeds (ASCII 10) form feeds (^L, ASCII 12)and tabs (^I, ASCII 9) can be inserted and deleted arbitrarily without affecting the meaning (aslong as obvious ambiguities are not introduced). For example, the space in - x but not in not xcan be omitted. Comments, which are arbitrary sequences of characters surrounded by %’s, can beinserted anywhere a space is allowed.

186

B.3.2 Identifiers and other lexical matters

In this section the lexical structure of ML is defined.

B.3.2.1 Identifiers

A variable (var) or identifier is a sequence of alphanumerics starting with a letter, where analphanumeric is either a letter, a digit, a prime (’) or an underbar ( ). ML is case-sensitive: upperand lower case letters are considered to be different.

B.3.2.2 Constant expressions

The ML constant expressions (ce’s) used in Table B.4 are:

1. Integers, i.e. sequences of digits 0,1...,9.

2. Truth values true and false.

3. Tokens and token-lists:

(a) Tokens consist of any sequence of characters surrounded by token quotes (‘), e.g.‘This is a single token‘.

(b) Token-lists consist of any sequence of tokens (separated by spaces, returns, line-feed ortabs) surrounded by token-list quotes (‘‘). e.g.‘‘this is a token-list containing 7 members‘‘. ‘‘ tok1 tok2 ... tokn‘‘ is equiv-alent to [‘tok1‘; ‘tok2‘; ...; ‘tokn‘].

In any token or token-list, the occurrence of \x has the following meanings for different x’s:

\0 = ten spaces\n = n spaces (0<n<10)\S = one space\R = return\L = line-feed\T = tab\x = x taken literally otherwise (e.g. \‘ to include token quotes in a token or token-list)

4. Strings, consisting of any sequence of characters surrounded by string quotes ("), e.g."This is a single string". Any " characters within a string must be preceded by \. Theescape sequence \x for any other character means always to insert the character x.

5. The expression (), called thing , which evaluates to the unique object of ML type unit.

B.3.2.3 Prefixes and infixes

The ML prefixes px and infixes ix are given by:

px ::= not | - | doix ::= * | / | + | - | . | @ | = | < | > | & | or | ,

In addition, any identifier (and certain single characters) can be made into an infix. Such user-defined infixes bind more tightly than ...=>...|... but more weakly than or. All of them havethe same power binding and associate to the left.

188

Except for & and or, each infix ix (or prefix px) has correlated with it a special identifier$ix (or $px) which is bound to the associated function. For example, the identifier $+ is boundto the addition function, and $@ to the list-append function (see Section B.6 for the meaning ofdollared infixes). This is useful for passing functions as arguments; for example, f$@ applies f tothe append function.

See the descriptions of the functions ml paired infix and ml curried infix in Section B.6.1for details of how to give an identifier infix status.

B.4 Semantics of ML

The evaluation of all ML constructs takes place in the context of an environment and a store. Theenvironment specifies what the variables and constructors in use denote. Variables may be boundeither to values or to locations. The contents of locations—which must be values—are specified inthe store. If a variable is bound to a location then (and only then) is it assignable. Thus bindingsare held in the environment, whereas location contents are held in the store. Constructors may onlybe bound to values (constructor constants or constructor functions) and this binding occurs whenthey are declared in a concrete type definition.

The evaluation of ML constructs may either succeed or fail . In the case of success:

1. The evaluation of a declaration, d say, changes the bindings in the environment of the identi-fiers declared in d. If d is at top-level, then the scope of the binding is everything following d.In d in e the scope of d is the evaluation of e, and so when this is finished the environmentreverts to its original state (see Section B.4.1).

2. The evaluation of an expression yields a value: the value of the expression (see Section B.4.2).

If an assignment is done during an evaluation, then the store will be changed — we shall refer tothese changes as side effects of the evaluation.

If the evaluation of a construct fails, then failure is signalled, and a string is passed to the contextwhich invoked the evaluation. This string is called the failure string , and it normally indicates thecause of the failure. During evaluation, failures may be generated either implicitly by certain errorconditions, or explicitly by the construct failwith e (which fails with e’s value as failure string).For example, the evaluation of the expression 1/0 fails implicitly with failure string ‘div‘, whilethat of failwith ‘str‘ fails explicitly with failure string ‘str‘. We shall say two evaluations failsimilarly if they both fail with the same failure string. For example, the evaluation of 1/0 andfailwith ‘div‘ fail similarly. Side effects are not undone by failures.

If during the evaluation of a construct a failure is generated, then unless the construct is a failuretrap (i.e. an expression built from ? and/or !) the evaluation of the construct itself fails similarly.Thus failures propagate up until trapped, or reaching top level. For example, when evaluating(1/0)+1000, the expression 1/0 is first evaluated, and the failure which this evaluation generatescauses the evaluation of the whole expression (viz. (1/0)+1000) to fail with ‘div‘. On the otherhand, the evaluation of (1/0)?1000 traps the failure generated by the evaluation of 1/0, andsucceeds with value 1000. (In general, the evaluation of e1?e2 proceeds by first evaluating e1, andif this succeeds with value E, then E is returned as the value of e1?e2; however, if e1 fails, then theresult of evaluating e1?e2 is determined by evaluating e2).

In describing evaluations, when we say that we pass control to a construct, we mean that theoutcome of the evaluation is to be the outcome of evaluating the construct. For example, if whenevaluating e1?e2 the evaluation of e1 fails, then we pass control to e2.

189

Expressions and patterns can be optionally decorated with types by writing :ty after them (e.g.[]:int list). The effect of this is to force the type checker to assign an instance of the assertedtype to the construct; this is useful as a way of constraining types more than the type checkerwould otherwise (i.e. more than context demands), and it can also serve as helpful documentation.Details of types and type checking are given in Section B.5, and will be ignored in describing theevaluation of ML constructs in the rest of this section.

If we omit types, precedence information and those constructs which are equivalent to others,then the syntax of ML can be summarized by:

d ::= let b | letref b | letrec b

b ::= p=e | var pl p2 . . . pn = e | bl and b2 . . . and bn

p ::= () |var | pl.p2 | pl, p2 | [] | [pl;p2 . . . ;pn]

e ::= ce | var | e1 e2

| px e | e1 ix e2 | v:=e | failwith e

| if e1 then|loop e′1 if e2 then|loop e′2...if en then|loop e′n

else|loop e′′n | e ??|!! e1 e′1 ??|!! e2 e′2...??|!! en e′n

?|!|?\id|!\id e′′n | el;e2 . . .;en | [] | [el;e2 . . .;en] | d in e

| \p1p2 . . . pn.e

B.4.1 Declarations

Any declaration must be one of the three kinds: let b, letref b or letrec b, where b is a binding.Each such declaration is evaluated by first evaluating the binding b to produce a (possibly empty)set of variable-value pairs, and then extending the environment (in a manner determined by thekind of declaration) so that each variable in this set of pairs denotes its corresponding value. Theevaluation of bindings is described below in Section B.4.1.1.

1. Evaluating let b declares the variables specified in b to be an ordinary (i.e. non assignable)variable, and binds (in the environment) each one to the corresponding value produced byevaluating b. To understand what are the variables defined in a declaration may require someknowledge about the environment. For example, a declaration let f x = e declares x if f isa constructor and declares f as the function \x.e otherwise.

2. Evaluating letref b declares the variables specified in b to be assignable and thus binds(in the environment) each one to a new location, whose contents (in the store) is set to thecorresponding value. The effect of subsequent assignments to the variables will be to changethe contents of the locations they are bound to. Bindings (in the environment) of variables tolocations can only be changed by evaluating another declaration to supersede the original one.

3. Evaluating letrec b is similar to evaluating let b except that:

(a) The binding b in letrec b must consist only of function definitions.

190

(b) These functions are made mutually recursive.

For example, consider:

(a) let f n = if n=0 then 1 else n*f(n-1)

(b) letrec f n = if n=0 then 1 else n*f(n-1)

The meaning of f defined by the first case depends on whatever f is bound before the decla-ration is evaluated, while the meaning of f defined by the second case is independent of this(and is the factorial function).

B.4.1.1 The evaluation of bindings

There are three kinds of variable binding each of which, when evaluated, produces a set of variable-value pairs (or fails):

1. Simple bindings, which have the form p=e where p is a pattern and e an expression.

2. Function definitions, which have the form id p1 . . . pn = e. This is just an abbreviation forthe simple binding id = \p1 . . . pn.e.

3. Multiple bindings, which have the form b1 and b2 . . . and bn where b1, b2 . . . , bn are simplebindings or function definitions. As a function definition is just an abbreviation for a cer-tain simple binding, each bi (0<i<n+1) either is, or is an abbreviation for, some simplebinding pi=ei. The multiple binding b1and b2 . . . and bn then abbreviates p1,p2 . . .,pn = e1,e2 . . . en, which is a simple binding.

As function definitions and multiple bindings are abbreviations for simple bindings we needonly describe the evaluation of the latter.

A simple binding p=e is evaluated by first evaluating e to obtain a value E (if the evaluationfails then the evaluation of p=e fails similarly). Next the pattern p is matched with E to see ifthey have the same form (precise details are given in Section B.4.1.2). If so, then to each identifierin p there is a corresponding component of E. The evaluation of p=e then returns the set of eachidentifier paired with its corresponding component. If p and E do not match then the evaluationof p=e fails with failure token ‘MATCH‘.

B.4.1.2 Matching patterns and expression values

When a pattern p is matched with a value E, either the match succeeds and a set of identifier-value pairs is returned (each identifier in p being paired with the corresponding component of E),or the match fails. We describe, by cases on p, the conditions for p to match E and the sets ofpairs returned:

(): Always matches E. The empty set of pairs is returned.

var: Always matches E. The set consisting of var paired with E is returned.

p1.p2: E must be a non-empty list E1.E2 such that p1 matches E1 and p2 matches E2. The unionof the sets of pairs returned from matching p1 with E1 and p2 with E2 is returned.

p1,p2: E must be a pair E1,E2 such that p1 matches E1 and p2 matches E2. The union of thesets of pairs returned from matching p1 with E1 and p2 with E2 is returned.

[p1;p2 . . .;pn]: E must be a list [E1;E2 . . .;En] of length n such that for each i pi matches Ei.The union of the sets of pairs returned by matching pi with Ei is produced.

191

Thus if p matches E, then p and E have a similar ‘shape’, and each identifier in p correspondsto some component of E (namely that component paired with the identifier in the set returned bythe match). Here are some examples:

1. [x;y;z] matches [1;2;3] with x, y and z corresponding to 1, 2, and 3 respectively.

2. [x;y;z] does not match [1;2] or [1;2;3;4].

3. x.y matches [1;2;3] with x and y corresponding to 1 and [2;3] respectively, becauseE1.[E2;E3...;En] = [E1;E2;E3...;En].

4. x.y does not match [] or 1,2.

5. x,y matches 1,2 with x and y corresponding to 1 and 2 respectively.

6. x,y does not match [1;2] .

7. (x,y),[(z.w);()] matches (1,2),[[3;4;5];[6;7]] with x, y, z and w corresponding to1, 2, 3, and [4;5] respectively.

B.4.2 Expressions

If the evaluation of an expression terminates, then either it succeeds with some value, or it fails; ineither case assignments performed during the evaluation may cause side effects. If the evaluationsucceeds with some value we shall say that value is returned .

We shall describe the evaluation of expressions by considering the various cases, in the order inwhich they are listed in the syntax equations.

ce: The appropriate constant value is returned.

var: The value associated with var is returned. If var is ordinary, then the value returned is thevalue bound to var in the environment. If var is assignable, then the value returned is thecontents of the location to which var is bound.

e1 e2: e1 and e2 are evaluated and the result of applying the value of e1 (which must be a function)to that of e2 is returned. Due to optimizations in the ML compiler, the order of evaluationmay vary.

px e: e is evaluated and then the result of applying px to the value of e is returned. -e and not ehave the obvious meanings; do e evaluates e for its side effects and then returns ().

e1 ix e2: e1 & e2 is equivalent to if e1 then e2 else false, so sometimes only e1 needs beevaluated to evaluate e1 & e2. e1 or e2 is equivalent to if e1 then true else e2, sosometimes only e1 needs to be evaluated to evaluate e1 or e2.

In all other cases e1 and e2 are evaluated (in that order) and the result of applying ix totheir two values is returned. e1,e2 returns a pair whose first component is the value of e1,and whose second component is the value of e2. The meaning of the other infixes are givenin Section B.6.

p:=e: Every variable in p must be assignable and bound to some location in the environment.The effect of the assignment is to update the contents of these locations (in the store) withthe values corresponding to the variables produced by evaluating the binding p=e (see Sec-tion B.4.1.1). If the evaluation of e fails, then no updating of locations occurs, and the as-signment fails similarly. If the matching to p fails, then the assignment fails with ‘MATCH‘.The value of p:=e is the value of e.

failwith e: e is evaluated and then a failure with e’s value (which must be a token) is generated.

192

if e1 then|loop e′1if e2 then|loop e′2...if en then|loop e′n

else|loop e′

:

e1, e2,. . . ,en are evaluated in turn until one of them, say em, returnstrue (each ei must be a boolean expression). When the phrase fol-lowing em is then e′m control is passed to e′m. However, when thephrase is loop e′m then e′m is evaluated for its side effects, and thencontrol is passed back to the beginning of the whole expression again(i.e. to the beginning of if e1 . . .).

In the case that all of e1,e2 . . .,en return false and there is a phrase following e′n, then if thisis else e′ control is passed to e′, while if it is loop e′ then e′ is evaluated for its side effectsand control is then passed back to the beginning of the whole expression again.

In the case that all of e1,e2 . . .,en return false, but no phrase follows e′n then (), the uniquevalue of type void is returned.

e ??|!! e1e′1

??|!! e2e′2...

??|!! ene′n ?|!|?\id|\id e′

:

e is evaluated and if this succeeds its value is returned. If e fails withfailure token tok, then each of e1,e2 . . .,en are evaluated in turn until oneof them, say em, returns a token list containing tok (each ei must be atoken). If ?? immediately precedes em, then control is passed to e′m. If!! precedes it, then e′m is evaluated and control is passed back to thebeginning of the whole expression e ??|!! ....

If none of e1,e2 . . . , en produces a token list containing tok, and ?\e′ follows e′n, then controlis passed to e′. But if !\e′ follows e′n, then e′ is evaluated, and control is passed back to thebeginning of the whole expression.

If ?\id e′ or ?\id e′ follows e′n, then e′ is evaluated in an environment in which id is boundto the failure string tok (i.e. an evaluation equivalent to let id=tok in e′ is done), and thendepending on whether a ? of a ! occurred, the value of e′ is returned or control is passed backto the beginning of the whole expression respectively.

If none of e1,e2 . . .,en returns a token list containing tok and nothing follows e′n, then thewhole expressions fails with tok.

e1;e2 . . .;en: e1,e2 . . .,en are evaluated in that order, and the value of en is returned.

[e1;e2 . . .;en]: e1, e2, . . . , en are evaluated in that order and the list of their values returned. []evaluates to the empty list.

d in e: d is evaluated and then e is evaluated in the extended environment and its value returned.The declaration d is local to e, so that after the evaluation of e, the former environment isrestored.

\p1p2 . . . pn.e: The evaluation of lambda-expressions always succeeds and yields a function value.The environment in which the evaluation occurs (i.e. in which the function value is created)is called the definition environment .

1. Simple lambda-expressions: \p.e evaluates to that function which, when applied to someargument yields the result of evaluating e in the current (i.e. application time) store, andin the environment obtained from the definition environment by binding any variablesin p to the corresponding components of the argument (see Section B.4.1.1).

2. Compound lambda-expressions: A lambda-expression with more than one parameter iscurried, i.e. \p1p2 . . . pn.e is equivalent to \p1. (\p2....\pn.e)....

Thus the free variables in a function keep the same binding they had in the definition envi-ronment. So if a free variable is non-assignable in that environment, then its value is fixed

193

to the value it has there. On the other hand, if a free variable is assignable in the definitionenvironment, then it will be bound to a location. Although that binding is fixed, the contentsof the location in the store is not, and can be subsequently changed with assignments.

B.5 ML Types

So far, little mention has been made of types. For ML in its original role as the meta-language forproof in LCF, the importance of strict type checking was principally to ensure that every computedvalue of the type representing theorems was indeed a theorem.2

The same effect could probably have been achieved by run-time type checking, but compile-time type checking was adopted instead, in the design of ML. This was partly for the considerabledebugging aid that it provides; partly for efficient execution; and partly to explore the possibilityof combining polymorphism with type checking. This last reason is of general interest in program-ming languages and has nothing to do specifically with proof; the problem is that there are manyoperations (list mapping functions, functional composition, etc.) which work at an infinity of types,and therefore their types should somehow be parameterized – but it is rather inconvenient to haveto mention the particular type intended at each of their uses.

The ML type checking system is implemented in such a way that, although the user mayoccasionally (either for documentation or as a constraint) ascribe a type to an ML expression orpattern, it is hardly ever necessary to do so. The user of ML will almost always be content with thetypes ascribed and presented by the type checker, which checks every top-level phrase before it isevaluated. (The type checker may sometimes find a more general type assignment than expected.)

B.5.1 Types and objects

Every data object in ML possesses a type. Such an object may possess many types, in which caseit is said to be polymorphic and possesses a polytype – i.e. a type containing type variables (forwhich we use a sequence of asterisks possibly followed by an identifier or integer) – and moreoverit possesses all types which are instances of its polytype, formed by substituting types for zero ormore type variables in the polytype. A type containing no type variables is a monotype.

We saw several examples of types in Section B.2. To understand the following syntax, notethat list is a postfixed unary (one-argument) type constructor (thereafter abbreviated to tycon).The user may introduce new n-argument type constructors. A binary type operator directory, forexample, can be introduced. The following type expressions will then be types of different kinds ofdirectory:

• (tok, int) directory

• (int, int -> int) directory

The user may even deal with lists of directories, with the type (int, bool) directory list

B.5.1.1 The syntax of types

The syntax of ML types is summarized in Table B.5. Type abbreviations are introduced by alettype declaration (see Section B.5.4 below) which allows an identifier to abbreviate an arbi-trary monotype. An abstract type likewise consists of an identifier (introduced by an abstype or

2The Nuprl system also relies on strict type checking to ensure that objects of type proof can only be constructedby reference to a fixed set of inference rules.

194

Types ty ::= sty Standard (non-infix) type| ty # ty R Cartesian product| ty + ty R Disjoint sum| ty -> ty R Function type

Standard Types sty ::= unit | int| bool| tok | string Basic types| vty Type variable| tycon Type abbreviation (see Section B.5.4)| tycon Nullary abstract type| tyarg tycon L Abstract type (see Section B.5.5)| (ty)

Type arguments tyarg ::= sty Single type argument| (ty,...,ty) One or more type arguments

Type variables vty ::= * | ** | ...| *id | **id | ...| *0 | **0 | ...| *1 | **1 | ...|

... |... | ...

Table B.5: ML Type Syntax

absrectype declaration; see Section B.5.5) postfixed to zero or more type arguments. Two or morearguments must be separated by commas and enclosed by parentheses. The type operator listis a predeclared unary type operator; and #, + and -> may be regarded as infix forms of threepredeclared binary type operators.

For an object to possess3 a type means the following: For basic types, all integers possess int,both booleans possess bool , all strings possess string, etc. The only object possessing void (orunit) is that denoted by () in ML. For a type abbreviation tycon, an object possesses tycon (duringexecution of phrases in the scope of the declaration of tycon) if and only if it possesses the typewhich tycon abbreviates. For compound monotypes ,

1. The type ty list is possessed by any list of objects, all of which possess type ty (so that theempty list possesses type ty list for every ty).

2. The type ty1 # ty2 is possessed by any pair of objects possessing the types ty1 and ty2,respectively.

3. The type ty1 + ty2 is possessed by the left-injection of any object possessing ty1, and by theright-injection of any object possessing ty2. These injections are denoted by the ML functionidentifiers inl : * -> * + ** and inr : ** -> * + ** (see Section B.6).

4. A function possesses type ty1 -> ty2 if, whenever its argument possesses type ty1, its result (ifdefined) possesses type ty2. (This is not an exact description; for example, a function definedin ML with non-local variables may possess this type even though some assumption aboutthe types of the values of these non-local variables is necessary for the above condition tohold. The constraints on programs listed below ensure that the non-locals will always havethe right types).

3We shall talk of objects possessing types and phrases having types, to emphasize the distinction.

195

5. An object possesses the abstract type tyarg id if and only if it is represented (via the abstracttype representation) by an object possessing the tyarg instance of the right-hand side of thedeclaration of id.

Finally, an object possesses a polytype ty if and only if it possesses all monotypes which aresubstitution instances of ty.

B.5.2 Typing of ML phrases

We now explain the constraints used by the type checker in ascribing types to ML expressions,patterns and declarations.

The significance of expression e having type ty is that the value of e (if evaluation terminatessuccessfully) possesses type ty. As consequences of the well-typing constraints listed below, it isimpossible for example to apply a non-function to an argument, or to form a list of objects ofdifferent types, or (as mentioned earlier) to compute an object of the type corresponding to theoremswhich is not a theorem.

The type ascribed to a phrase depends in general on the entire surrounding ML program. Inthe case of top-level expressions and declarations, however, the type ascribed depends only onpreceding top-level phrases. Thus you know that types ascribed at top-level are not subject tofurther constraint.

Before each top-level phrase is executed, types are ascribed to all its sub-expressions, sub-declarations and sub-patterns according to the following rules. Most of the rules are fairly natural;those which are less so are discussed later. You are only presented with the types of top-levelphrases; the types of sub-phrases will hardly ever concern you.

Before giving the list of constraints, let us discuss an example which illustrates some importantpoints. To map a function over a list we may define the polymorphic function map recursively asfollows (where we have used an explicit abstraction, rather than letrec map f l = ..., to makethe typing clearer):

letrec map = \f.\l. null l => [] | f(hd l).map f(tl l) ;;

From this declaration the type checker will infer a generic type for map. By ‘generic’ we mean thateach later occurrence of map will be ascribed a type which is a substitution instance of the generictype.

Now the free identifiers in this declaration are null, hd and $., which are ML primitives whosegeneric (poly)types are * list -> bool, * list -> *, and * # * list -> * list respectively.The first constraint used by the type checker is that the occurrences of these identifiers in thedeclaration are ascribed instances of their generic types. Other constraints which the type checkerwill use to determine the type of map are:

• All occurrences of a lambda-bound variable receive the same type.

• Each arm of a conditional receives the same type, and the condition receives type bool.

• In each application e = (e1e2), if e2 receives ty and e receives ty′ then e1 receives ty -> ty′.

• In each abstraction e = \v.e1, if v receives ty and e1 receives ty′ then e receives ty -> ty′.

• In a letrec declaration, all free occurrences of the declared variable receive the same type.

Now the type checker will ascribe the type (*->**)->* list->** list to map. This is in factthe most general type consistent with the constraints mentioned. Moreover, it can be shown that

196

any instance of this type also allows the constraints to be satisfied; this is what allows us to claimthat the declaration is indeed polymorphic.

In the following constraint list, we say p has ty to indicate that the phrase p is ascribed a type tywhich satisfies the stated conditions. We use x, p, e, d to stand for variables, patterns, expressionsand declarations respectively.

Constants:

1. () has type unit

2. 0 has type int , 1 has type int, ...

3. true has type bool, false has type bool

4. ‘...‘ has type tok

5. "..." has type string

Variables and constructors: The constraints described here are discussed in Section B.5.3 below.

1. If x is a variable bound by \, fun or letref, then x is ascribed the same type asits binding occurrence. In the case of letref, this must be monotype if the letref istop-level or an assignment to x occurs within a lambda-expression within its scope.

2. If x is bound by let or letrec, then x has ty, where ty is an instance of the type of thebinding occurrence of x (i.e. the generic type of x), in which type variables occurring inthe types of current lambda-bound or letref-bound identifiers are not instantiated.

3. If x is not bound in the program (in which case it must be an ML primitive), then xhas ty, where ty is an instance of the type of x given in Section B.6.

Patterns: Cases for a pattern p:

• (): p has ty, where ty is any type.

• p1:ty:p1 and p have an instance of ty.

• p1,p2: If p1 has ty1 and p2 has ty2, then p has ty1 # ty2.

• p1.p2: If p1 has ty then p2 and p have ty list.

• [p1;...;pn]: For some ty, each pi has ty and p has ty list.

Expressions: Cases for an expression e (not a constant or identifier):

• e1e2: If e2 has ty and e has ty′ then e1 has ty -> ty′.

• e1:ty: e1 and e have an instance of ty.

• px e1: Treated as $px(e1) when px is a prefix. If e is -e1, then e and e1 have int.

• e1 ix e2: Treated as $ix(e1,e2) if ix is introduced with ml paired infix, and as($ix e1 e2) if ix is introduced by ml curried infix. If e is (e1 & e2) or (e1 or e2)then e, e1 and e2 have bool.

• e1,e2: If e1 has ty1 and e2 has ty2 then e has ty1#ty2.

• p:=e1: For some ty, p, e1 and e all have ty.

• failwith e1: e1 has tok, and e has any type.

197

• if e1 then e′1 . . . if en then e′n else e′: Each ei has bool, and e, each e′i, and e′ allhave ty for some ty. However, this constraint does not apply to an e′i preceded by loopin place of then, nor to e′ preceded by loop in place of else. If e′ is absent, then ty =void.

• e′0 ?? e1 e′1 . . . ?? en e′n ?\xe′: Each ei has tok list, and e, e′0, each e′i and e′ allhave ty for some ty. However, this constraint does not apply to an e′i preceded by !! inplace of ?? nor to e′ preceded by ! in place of ?. If \x is present, x has tok.

• e1;...;en: If en has ty then e has ty.

• [e1;...;en]: For some ty, each ei has ty and e has ty list.

• d in e1: If e1 has ty then e has ty. If d is a type definition (see Sections B.5.4 and B.5.5)then ty must contain no type defined in d.

• \p.e1: If p has ty and e1 has ty′ then e has ty ->ty′.

Declarations:

1. Each bindingx p1 . . . pn = e is treated as x = \p1. ...\pn.e.

2. let p1 = e1 and ...and pn = en is treated as let p1,...,pn = e1,...,en (similarlyfor letrec and letref).

3. If d is let p=e, then d, p and e all have ty for some ty (similarly for letref). Note thate is not in the scope of the declaration.

4. If d is letrec x1,...,xn = e1,...,en, then xi and ei have tyi, and d has ty1#...#tyn

for some tyi. In addition, each free occurrence of xi in e1,. . . ,en has tyi, so that the typeof recursive calls of xi is the same as the declaring type.

B.5.3 Discussion of type constraints

We give here reasons for our constraints on the types ascribed to occurrences of identifiers. Thereader may like to skip this section at first reading.

1. Consider constraint (1) for lambda-bound identifiers. This constraint implies that the ex-pression let x = e in e′ may be well-typed even if the semantically-equivalent expressionlet f x = e′ in f e is not, since in the former expression x may occur in e′ with two in-compatible types which are both instances of the declaring type. The greater constraint on fis associated with the fact that f may be applied to many different arguments during evalua-tion. To show the need for the constraint, suppose that it is replaced by the weaker constraintfor let-bound identifiers, so that for example let f x = if x then 1+x else x(1) is awell-typed declaration of type *->int, in which the occurrences of x receive types *, bool,int, int->int respectively. In the absence of an explicit argument for the abstraction, noconstraint exists for the type of the binding occurrence of x. But, because f is let-bound,expressions such as f true and f ‘dog‘ are admissible in the scope of f, although theirevaluation should result in either nonsense or run-time type-errors; one of our purposes is topreclude these.

The only exception to this rule is for expressions of the form (\x.e′)e, which is treated exactlyas let x=e in e′. Here we know the unique instance of type of the argument x, namely thetype of e.

198

2. The analogous restriction for letref-bound identifiers is also due to the possibility that theidentifier-value binding may change during evaluation (this time because of assignments).Consider the following:

letref x = [] in(if e then do(x := 1.x) else do(x := [true]) ; hd x) ;;

If letref were treated like let, this phrase would be well-typed and indeed have type *,despite the fact that the value returned is either 1 or true. So, calling the whole expressione, all manner of larger expressions involving e would be well-typed, even including e(e)!

3. Top level letrefs must be monomorphic to avoid retrospective type constraints at top-level.If this restriction were removed the following would be allowed:

letref x = [] ;;...

2.x ;;

But on type checking the last phrase, it would appear that the type of x at declaration shouldhave been int list, not * list, and the types of intervening phrases may likewise needconstraining.

4. To see the need for the exclusion of polymorphic non-local assignments, consider this examplein the HOL system (this example is originally due to Lockwood Morris). (The type thm isthe type of theorems.)

let store,fetch =letref x = [] in (\y. x:=[y]) , (\(). hd x ) ;;

store "T = F" ;;let eureka :thm = fetch() ;;

Now suppose we lift our constraint. Then in the declaration, x has type * list throughoutits (textual) scope, and store, fetch receive types *->* list, **->* respectively. In thetwo ensuing phrases they get respective types term->term list, void->thm (instances oftheir declaring types), and the value of eureka is a contradictory formula masquerading as atheorem!

The problem is that the type checker has no simple way of discovering the types of all valuesassigned to the polymorphic x, since these assignments may be invoked by calls of the functionstore outside the (textual) scope of x. This is not possible under our constraint.However, polymorphic assignable identifiers are still useful: consider

let rev l =letref l,l’ = l,[] inif null l then l’ loop (l,l’:= tl l, hd l.l’) ;;

Such uses of assignable identifiers for iteration may be avoided given a suitable syntax foriteration, but assignable identifiers are useful for a totally different purpose, namely as ‘ownvariables’ shared between one or more functions (as in the store-fetch example). Our constraintof course requires them to be monomorphic; this is one of the few cases where the useroccasionally needs to add an explicit type to a program.

199

B.5.4 Type abbreviations

The syntax of type abbreviation bindings tab is

tab ::= id1 = ty1 and . . . and idn = tyn

Then the declaration

lettype tab

in which each tyi must be a monotype, built from basic types and previously defined types, allowsyou to introduce new names idi for the types tyi. Within the scope of the declaration the expressione:idi behaves exactly like e:tyi, and the type tyi will always be printed as idi.

One aspect of such type abbreviations should be emphasized. Suppose for the rational numbersyou declare lettype rat = int # int;; and set up the standard operations on rationals. Withinthe scope of this declaration any expression of type int # int will be treated as though it hadtype rat, and this could be not only confusing but also incorrect (in which case it ought to causea type failure). If you wish to introduce the type rat, isomorphic to int # int but not matchingit for type checking purposes, then you should use abstract types.

B.5.5 Abstract types

As with concrete types, abstract type constructors may be introduced by a declaration in whichtype variables are used as dummy arguments (or formal parameters) of the operators. The syntaxof abstract type bindings ab is

ab ::= vtyarg1 tycon1 = ty1 and ...and vtyargn tyconn = tyn with b

where each vtyargi must contain no type variable more than once, and all the type variables intyi must occur in vtyargi. An abstract type declaration takes the form

abstype|absrectype ab

The declaration introduces a set of type operators, and also incorporates a normal binding b(treated like let) of ML identifiers. Throughout the scope of the abstract type declaration thetype operators and ML identifiers are both available, but it is only within b that the representationof the type operators (as declared in terms of other operators) is available. In an abstract typedeclaration

absrectype vtyarg1 id1 = ty1 and ...and vtyargn idn = tyn with b

the sense in which the representation of each idi is available only within b is as follows: the isomor-phism between objects of types tyi and vtyargi idi is available (only in b) via a pair of implicitlydeclared polymorphic functions

abs idi : tyi -> vtyargi idi

rep idi : vtyargi idi -> tyi

which are to be used as coercions between the abstract types and their representations. Thus inthe simple case abstype a= ty with x=e′ in e the scope of a is e′ and e, the scope of abs a andrep a is e′, and the scope of x is e.

As an illustration, consider the definition of the type rat of rational numbers, represented bypairs of integers, together with operations plus and times and the conversion functions

inttorat : int->ratrattoint : rat->int

200

Since rat is a nullary type operation, no type variables are involved, and rat can be defined by:

abstype rat = int# intwith plus(x,y) = (abs_rat(x1*y2+x2*y1, x2*y2)

where x1,x2 = rep_rat xand y1,y2 = rep_rat y )

and times(x,y) = (abs_rat(x1*y1, x2*y2)where x1,x2 = rep_rat x

and y1,y2 = rep_rat y )and inttorat n = abs_rat(n,1)and rattoint x = ((x1/x2)*x2=x1 => x1/x2 | failwith ‘rattoint‘

where x1,x2 = rep_rat x ) ;;

Most abstract type declarations are probably used at top-level, so that their scope is the re-mainder of the top-level program. But for non-top-level declarations, a simple constraint ensuresthat a value of abstract type cannot exist except during the execution of phrases within the scopeof the type declaration. In the expression

absrectype vtyarg1 id1 = ty1 and ...and vtyargn idn = tyn with b in e

the type of e, and the types of any non-local assignments within b and e, must not involve any ofthe idi.

Finally, in keeping with the abstract nature of objects of abstract type, the value of a top-levelexpression of abstract type is printed as a dash, - , as functional values are. Users who wish to‘see’ such an object should declare a coercion function in the ‘with’ part of the type declaration, toyield a suitable concrete representation of the abstract objects.

B.6 Primitive ML Identifier Bindings

The primitive ML identifier bindings are described in this Section. Some useful derived functionsare in Section B.7. The primitive bindings are of two kinds:

• ordinary bindings;

• dollared bindings (which are preceded by $) having prefix or infix status.

The description of the ML value to which an identifier is bound is omitted if the semantics isclear from the identifier name and type given. For those functions whose application may fail, thefailure string is the function identifier.

Predeclared identifiers are not regarded as constants of the language. As with all other MLidentifiers, the user is free to rebind them, by let, letref, etc., but note that in the case of infix orprefix operators rebinding the dollared operator will affect even its non-dollared uses. Predeclaredbindings are to be understood as if they had been bound by let, rather than by letref. Inparticular, therefore, none of them can be changed by assignment (except, of course, within thescope of a rebinding of the identifier by a letref-declaration).

201

B.6.1 Predeclared ordinary identifiers

fst : * # ** -> *snd : * # ** -> ** inl : * -> * + **

inr : ** -> * + **null : * list -> bool outl : * + ** -> *hd : * list -> * outr : * + ** -> **tl : * list -> * list isl : * + ** -> bool

The functions hd and tl fail if their argument is an empty list. The functions outl and outr fail iftheir arguments are not in the left or right summand, respectively. A function isr is not providedbecause it is just the complement of isl.

explode : tok -> tok listimplode : tok list -> tok

The function explode maps a token into the list of its single character tokens in order. Thefunction implode maps a list of single character tokens (fails if any token is not of length one) intothe token obtained by concatenating these characters. For example:

1# explode ‘whosit‘;;[‘w‘; ‘h‘; ‘o‘; ‘s‘; ‘i‘; ‘t‘] : tok list

# implode [‘c‘;‘a‘;‘t‘];;‘cat‘ : tok

# implode [‘cd‘;‘ab‘;‘tu‘];;evaluation failed implode

int_to_char : int -> charchar_to_int : char -> int

The function int to char on argument i returns the ith character in Nuprl’s font. The integeri must be non-negative and less than 256. For arguments less than 128 the integer-character corre-spondence is the same as in ASCII. The function char to int returns integer code of its argument,which must be a one-character token.

string_to_toks : string -> tok listtoks_to_string : tok list -> string

These functions are similar to explode and implode except that they work on strings ratherthan tokens.

int_to_tok : int -> toktok_to_int : tok -> int

These are bound to the obvious type coercion functions, with tok to int failing if its argumentis not a non-negative integer token.

ml_curried_infix : tok -> unitml_paired_infix : tok -> unit

The functions ml curried infix and ml paired infix declare their argument tokens to theML parser as having infix status. Infixed functions can either be curried or take a pair as anargument. For example, after executing

202

ml paired infix ‘plus‘;; let x plus y = x+y;;

1 plus 2 is synonymous with $plus(1,2) and after executing

ml curried infix ‘plus‘ ;; let x plus y = x+y ;;

1 plus 2 is synonymous with $plus 1 2.4

B.6.2 Predeclared dollared identifiers

The following prefix and infix operators are provided as primitives (where the dollar symbol isomitted from the table; the constants are $do, and so on):

do : * -> voidnot : bool -> bool*, /, +, - : int # int -> int>, < : int # int -> bool= : * # * -> bool@ : * list # * list -> * list. : * # * list -> * list

Clarifying remarks:

• $do is equivalent to \x.(). do e evaluates e for its side effects.

• / returns the integer part of the result of a division, for example

$/(7,3) = 7/3 = 2

$/(-7,3) = -7/3 = -2

The failure token for division by zero is ‘div‘.

• - is the binary subtraction function. Negation (unary minus) is not available as a predeclaredfunction of ML, only as a prefix operator. Of course, the user can define negation if he or shewishes, e.g. by

let minus x = -x

• Not all dollared infix operators are included above: $, is not provided since it would beequivalent (as a function) to the identity on pairs, nor is & as it has no corresponding call-by-value function (because e & e′ evaluates to false when e does even if evaluation of e′ wouldfail to terminate), nor is or analogously.

• The period symbol . is an infixed Lisp cons:

x.[x1;...;xn] = [x;x1;...;xn]

• = is bound to the expected predicate for an equality test at non-function types, but is nec-essarily rather weak, and may give surprising results, at function types. You can be surethat semantically (i.e. extensionally) different functions are not equal, and that semanticallyequivalent functions are equal when they originate from the same evaluation of the sametextual occurrence of a function-denoting expression; for other cases the equality of functionsis unreliable (i.e. implementation dependent). For example, after the top-level declarations

4Only ordinary identifiers should be used as infixes; infixing other tokens may have unpredictable effectson the parser.

203

let f x = x+1 and g x = x+2;;

let f’ = f and h x = f x and h’ x = x+1;;

f=f’ evaluates to true and f=g evaluates to false, but the truth values of f=h, f=h’, andh=h’ are unreliable. Furthermore, after declaring

let plus = \x.\y.x+y;;let f = plus 1 and g = plus 1;;

the truth value of f=g is also unreliable.

• @ is a predeclared list concatenation operator; the symbol @ has a special parser status andcannot be redeclared as a curried infix.

B.7 General Purpose and List Processing Functions

This Section describes a selection of commonly useful ML functions applicable to pairs, lists andother ML values. All the functions are definable in ML. Each function is documented by:

1. Its name and type.

2. A brief description.

3. An ML declaration defining the function (note that this is not necessarily the definition used:some of the functions are coded directly in Lisp).

Functions preceded by $ may be used as infix operators (without the $), or in normal prefix formor as arguments to other functions (with the $).

The functions usually fail with failure string equal to their name; sometimes, however, the failurestring is the one generated by the subfunction that caused the failure.

B.7.1 General purpose functions and combinators

The standard primitive combinators are: I, K, and S.

I : * -> *K : * -> ** -> *S : (* -> ** -> ***) -> (* -> **) -> * -> ***

Description: I x = x K x y = x S f g x = f x (g x)

Definition:let I x = x

let K x y = x

let S f g x = f x (g x)

The derived combinators KI (the dual of K), C (the permutator), W (the duplicator), B (the compos-itor) and CB (which is declared to be infix) have types:

KI : * -> ** -> **C : (* -> ** -> ***) -> ** -> * -> ***W : (* -> * -> **) -> * -> **B : (* -> **) -> (*** -> *) -> *** -> **CB : (* -> **) -> (** -> ***) -> * -> ***

204

Description:KI x y = y C f x y = f y x B f g x = f(g x) W f x = f x x CB f g x = g(f x)

Definition:let KI = K I

let C f x y = f y x

let W f x = f x x

let B f g x = f(g x)

let (f CB g) x = g(f x)

The next group of functions are various useful infixed function-composition operators:

$o : ((* -> **) # (*** -> *)) -> *** -> **$# : ((* -> **) # (*** -> ****)) -> (* # ***) -> (** # ****)$Co : ((* -> ** -> ***) # (**** -> *)) -> ** -> **** -> ***

Description: (f o g) x = f(g x)

(f # g)(x, y) = (f x, g y)

(f Co g) x y = C(f o g) x y = f (g y) x

Definition:ml paired infix ‘o‘let (f o g) x = f(g x)

ml paired infix ‘#‘let (f # g)(x,y) = (f x, g y)

ml paired infix ‘Co‘let (f Co g) x y = f (g y) x

The following two functions convert between curried and uncurried versions of a binary function.

curry : ((* # **) -> ***) -> (* -> ** -> ***)uncurry : (* -> ** -> ***) -> ((* # **) -> ***)

Description: curry f x y = f(x, y) uncurry f (x, y) = f x y

Definition:let curry f x y = f (x,y)

let uncurry f (x,y) = f x y

The next function tests for failure.

can : (* -> **) -> * -> bool

Description: can f x evaluates to true if the application of f to x succeeds; it evaluates tofalse if the evaluation fails.

205

Definition:let can f x = (f x; true) ? false

The next function iterates a function a fixed number of times.

funpow : int -> (* -> *) -> * -> *

Description: funpow n f x applies f to x n-times: funpow n f = fn

Definition:letrec funpow n f x = if n=0 then x else funpow (n-1) f (f x)

B.7.2 Miscellaneous list processing functions

The function length computes the length of a list.

length : * list -> int

Description: length [x1;...;xn] = n

Definition:letrec length = fun [] . 0 | ( .l) . 1+(length l)

The function append concatenates lists; @ is an uncurried and infixed version of append.

append : * list -> * list -> * list

Description: append [x1;...;xn] [y1;...;ym] = x1;...;xn;y1;...;ym]

Definition:letrec append l1 l2 = if null l1 then l2 else hd l1.append (tl l1) l2

The function el extracts a specified element from a list. It fails if the integer argument is less than1 or greater than the length of the list.

el : int -> * list -> *

Description: el i [x1;...;xn] = xi

Definition:

letrec el i l =if null l or i < 1 then failwith ‘el‘

else if i = 1 then hd lelse el (i-1) (tl l)

The functions last and butlast compute the last element of a list and all but the last element ofa list. Both fail if the argument list is empty.

last : * list -> *butlast : * list -> * list

206

Description: last [x1;...;xn] = xn butlast [x1;...;xn] = [x1;...;xn−1]

Definition:letrec last l = last (tl l) ? hd l ? failwith ‘last‘

letrec butlast l =if null (tl l) then [] else (hd l).(butlast(tl l)) ? failwith ‘butlast‘

The next function makes a list consisting of a value replicated a specified number of times. It failsif the specified number is less than zero.

replicate : * -> int -> * list

Description: replicate x n evaluates to [x;...;x], a list of length n.

Definition:

letrec replicate x n =if n < 0 then failwith ‘replicate‘

else if n = 0 then []else x . (replicate x (n-1))

B.7.3 List mapping and iterating functions

map : (* -> **) -> * list -> ** list

Description: map f l returns the list obtained by applying f to the elements of l in turn.

Definition:letrec map f l = if null l then [] else f(hd l). map f (tl l)

The following three functions are versions of ‘reduce’.

itlist : (* -> ** -> **) -> * list -> ** -> **rev_itlist : (* -> ** -> **) -> * list -> ** -> **end_itlist : (* -> * -> *) -> * list -> *

Description: itlist f [x1;x2;...;xn] x = f x1 (f x2 ( . . . (f xn x) . . . ))= ((f x1) o (f x2) o . . . o (f xn)) x

rev itlist f [x1;...;xn−1;xn] x = f xn (f xn−1 ( . . . (f x1 x) . . . ))= ((f xn) o (f xn−1) o . . . o (f x1)) x

end itlist f [x1;x2;...;xn−1;xn] = f x1 (f x2 ( . . . (f xn−1 xn) . . . ))= ((f x1) o (f x2) o . . . o (f xn−1)) xn

Definition:letrec itlist f l x =

if null l then x else f (hd l) (itlist f (tl l) x)

letrec rev itlist f l x =if null l then x else rev itlist f (tl l) (f (hd l) x)

let end itlist ff l =if null l then failwith ‘end itlist‘

else (let last.rest = rev l in rev itlist ff rest last)

207

or, equivalently:letrec itlist f = fun [] . I | (y.l) . \x. f y (itlist f l x)

letrec rev itlist f = fun [] . I | (y.l) . \x. rev itlist f l (f y x)

B.7.4 List searching functions

The functions described in this section search lists for elements with various properties. Thosefunctions that return elements fail if no such element is found; those that return booleans neverfail (false is returned if the element is not found).

find : (* -> bool) -> * list -> *tryfind : (* -> **) -> * list -> **

Description: find p l returns the first element of l that satisfies the predicate p. tryfind f lreturns the result of applying f to the first member of l for which the application of f succeeds.

Definition:letrec find p = fun [] . failwith ‘find‘

| (x.l) . if p x then x else find p l

letrec tryfind f = fun [] . failwith ‘tryfind‘| (x.l) . (f x ? tryfind f l)

The next two functions are analogous to the quantifiers ∃ and ∀.

exists : (* -> bool) -> * list -> boolforall : (* -> bool) -> * list -> bool

Description: exists p l applies p to the elements of l in order until one is found which satisfiesp, or until the list is exhausted, returning true or false accordingly; forall is the dual.

Definition:let exists p l = can (find p) l

let forall p l = not(exists ($not o p) l)

The next function tests for membership of a list.

mem : * -> * list -> bool

Description: mem x l returns true if some element of l is equal to x, otherwise it returns false.

Definition:let mem = exists o (curry $=)

The following two functions are ML versions of Lisp’s assoc.

assoc : * -> (* # **) list -> (* # **)rev_assoc : * -> (** # *) list -> (** # *)

208

Description: assoc x l searches a list l of pairs for one whose first component is equal to x,returning the first pair found as result; similarly, rev assoc y l searches for a pair whose secondcomponent is equal to y. For example:

1# assoc 2 [(1,4);(3,2);(2,5);(2,6)];;(2, 5) : (int # int)

# rev_assoc 2 [(1,4);(3,2);(2,5);(2,6)];;(3, 2) : (int # int)

Definition:let assoc x = find (\(x’,y). x=x’)

let rev assoc y = find (\(x,y’). y=y’)

B.7.5 List transforming functions

The next function reverses a list:

rev : * list -> * list

Description: rev [x1;...;xn] = [xn;...;x1]

Definition:

let rev = rev1 []whererec rev1 l = fun [] . l | (x.l’) . rev1 (x.l) l’

The following two functions filter a list to the sublist of elements satisfying a predicate.

filter : (* -> bool) -> * list -> * listmapfilter : (* -> **) -> * list -> * list

Description: filter p l applies p to every element of l, returning a list of those that satisfyp; evaluating mapfilter f l applies f to every element of l, returning a list of results for thoseelements for which application of f succeeds.

Definition:letrec filter p = fun [] . []

| (x.l) . if p x then (x.filter p l) else filter p l

letrec mapfilter f = fun [] . []| (x.l) . let l’ = mapfilter f l in (f x).l’ ? l’

The following three functions break-up lists.

remove : (* -> bool) -> * list -> (* # * list)partition : (* -> bool) -> * list -> (* list # * list)chop_list : int -> * list -> (* list # * list)

209

Description: remove p l separates from the rest of l the first element that satisfies the predicatep; it fails if no element satisfies the predicate. partition p l returns a pair of lists. The first listcontains the elements of l which satisfy p. The second list contains all the other elements of l.

chop list i [x1;...;xn] = [x1;...;xi],[xi+1;...;xn]

chop list fails if i is negative or greater than n.

Definition:letrec remove p l =

if p (hd l) then (hd l, tl l)else (I # (. ((hd l) . r))) (remove p (tl l))

let partition p l =itlist (\a (yes,no). if p a then ((a.yes),no) else (yes,(a.no))) l ([],[])

letrec chop list i l =if i = 0 then ([],l)else (let l1,l2 = chop list (i-1) (tl l) in hd l . l1 , l2)? failwith ‘chop list‘

The next function flattens a list of lists:

flat : * list list -> * list

Description: flat [[l11;...;l1m1]; [l21;...;l2m2]; ...[ln1;...;lnmn]]= [l11;...;l1m1; l21;...;l2m2; ...ln1;...;lnmn]

Definition:letrec flat = fun [] . [] | (x.l) . x@(flat l)

The next two functions ‘zip’ and ‘unzip’ between lists of pairs and pairs of lists.

combine : (* list # ** list) -> (* # **) listsplit : (* # **) list -> (* list # ** list)

Description: combine [x1;...;xn] [y1;...;yn] = [(x1,y1);...;(xn,yn)]split [(x1,y1);...;(xn,yn)] = [x1;...;xn],[y1;...;yn]

Definition:letrec combine = fun ([],[]) . []

| ((x.lx),(y.ly)) . ((x,y).combine(lx,ly))| . failwith ‘combine‘

letrec split = fun [] . ([],[])| ((x,y).l) . let lx,ly = split l in (x.lx,y.ly)

B.7.6 Functions for lists representing sets

The following functions behave like the corresponding set-theoretic operations on sets (representedas lists without repetitions).

intersect : * list -> * list -> * listsubtract : * list -> * list -> * listunion : * list -> * list -> * list

210

Description: intersect l1 l2 = l1 ∩ l2 subtract l1 l2 = l1 − l2 union l1 l2 = l1 ∪ l2

Definition:let intersect l1 l2 = filter (\x. mem x l2) l1

let subtract l1 l2 = filter (\x. not(mem x l2)) l1

let union l1 l2 = l1 @ subtract l2 l1

There are also functions to test if a list is a set, remove duplicates from a list and test two lists forset equality.

distinct : * list -> boolsetify : * list -> * listset_equal : * list -> * list -> bool

Description: distinct l returns true if all the elements of l are distinct; otherwise it returnsfalse. setify l removes repeated elements from l, leaving the last occurrence of each duplicate inthe list. set equal l1 l2 returns true if every element of l1 appears in l2 and every element of l2appears in l1; otherwise it returns false.

Definition:letrec distinct l =(null l) or (not (mem (hd l) (tl l)) & distinct (tl l))

let setify l = itlist (\a s. if mem a s then s else a.s) l []

let set equal l1 l2 = (subtract l1 l2 = []) & (subtract l2 l1 = [])

B.7.7 Miscellaneous string processing functions

The following functions split strings into ‘words’; words2 uses a user supplied separator, whilewords uses space and carriage-return as separators.

words2 : string -> string -> string listwords : string -> string list

Description: words2 ‘c‘ ‘s1cs2c . . . csn‘ = [‘s1‘;‘s2‘; ...;‘sn‘]

words ‘s1 s2 . . . sn‘ = [‘s1‘;‘s2‘; ...;‘sn‘]

Definition:let words2 sep string =snd (itlist (\ch (chs,tokl).

if ch = sep thenif null chs then [],toklelse [], (implode chs . tokl)

else (ch.chs), tokl)(sep . explode string)([],[]))

let word separators = [‘ ‘;‘\L‘]

211

let words string =snd (itlist (\ch (chs,tokl).

if mem ch word separators thenif null chs then [],toklelse [], (implode chs . tokl)

else (ch.chs), tokl)(‘ ‘ . explode string)([],[]))

The next three functions (the second of which is an infixed version of the first) are string concate-nation operators.

concat : string -> string -> string$^ : string -> string -> stringconcatl : string list -> string

Description: concat concatenates two strings, $^ is an infixed version of concat, andconcatl concatenates all the strings in a list of strings.

Definition:let concat s1 s2 = implode(explode s1 @ explode s2)

ml curried infix ‘^‘let s1 ^ s2 = concat s1 s2

let concatl sl = implode(itlist append (map explode sl) [])

B.7.8 Failure handling functions

The failure handling functions described here are useful for writing code that fails with a backtrace.

set_fail_prefix : string -> (* -> **) -> * -> **set_fail : string -> (* -> **) -> * -> **

Description: set fail prefix s f x applies f to x and returns the result of the application ifit is successful; if the application fails then the string s is concatenated to the failure string andthe resulting string propagated as the new failure string.set fail s f x applies f to x and returns the result of the application if it is successful; if theapplication fails then the string s is propagated as the new failure string.

Definition:let set fail prefix s f x = f x ?\s’ failwith(concatl[s;‘--‘;s’])

let set fail s f x = f x ? failwith s

212

Bibliography

[ACE+00] Stuart Allen, Robert Constable, Richard Eaton, Christoph Kreitz, and Lori Lorigo.The Nuprl open logical environment. In D. McAllester, editor, 17th Conference onAutomated Deduction, volume 1831 of Lecture Notes in Artificial Intelligence, pages170–176. Springer Verlag, 2000.

[BBS+98] Holger Benl, Ulrich Berger, Helmut Schwichtenberg, Monika Seisenberger, and Wolf-gang Zuber. Proof theory at work: Program development in the minlog system. InW. Bibel and P. Schmitt, editors, Automated Deduction – A Basis for Applications,volume II, chapter II.1.2, pages 41–71. Kluwer, 1998.

[BCH+00] Ken Birman, Robert Constable, Mark Hayden, Jason Hickey, Christoph Kreitz, Rob-bert van Renesse, Ohad Rodeh, and Werner Vogels. The Horus and Ensemble projects:Accomplishments and limitations. In DARPA Information Survivability Conferenceand Exposition (DISCEX 2000), pages 149–160. IEEE Computer Society Press, 2000.

[Ble75] W. W. Bledsoe. A new method for proving certain Presburger formulas. In Patrick H.Winston and Carl Hewitt, editors, IJCAI-75 – 4th International Joint Conference onArtificial Intelligence, Tbilisi, Georgia, USSR, September 1975. Morgan Kaufmann,1975.

[CAB+86] Robert L. Constable, Stuart F. Allen, H. Mark Bromley, W. Rance Cleaveland, J. F.Cremer, Robert W. Harper, Douglas J. Howe, Todd B. Knoblock, Nax Paul Mendler,Prakash Panangaden, Jim T. Sasaki, and Scott F. Smith. Implementing Mathematicswith the Nuprl proof development system. Prentice Hall, 1986.

[CDE+99a] Manuel Clavel, Francisco Duran, Steven Eker, P. Lincoln, N. Marti-Oliet, JoseMeseguer, and J.F.Quesada. The Maude system. In P.Narendran and M. Rusinow-itch, editors, 10th International Conference on Rewriting Techniques and Applica-tions (RTA’99), number 1631 in Lecture Notes in Computer Science, pages 240–243.Springer Verlag, 1999.

[CDE+99b] Manuel Clavel, Francisco Duran, Steven Eker, Jose Meseguer, and Mark-Oliver Stehr.Maude as a formal meta-tool. In J. Wing, J. Woodcook, and J. Davies, editors, FM’99,The World Congress On Formal Methods In The Development Of Computing Systems,number 1709 in Lecture Notes in Computer Science, pages 1684–1703. Springer Verlag,1999.

[CH90] Guy Cousineau and Gerard Huet. The CAML primer. Rapports Techniques 122,Institut National de Recherche en Informatique et en Automatique, September 1990.

213

[Cha82] T. Chan. A decision procedure for checking PL/CV arithmetic inferences. In Intro-duction to the PL/CV2 Programming Logic, volume 135 of Lecture Notes in ComputerScience, pages 227–264. Springer Verlag, 1982.

[CHP84] Guy Cousineau, Gerard Huet, and Larry Paulson. The ML handbook, 1984.

[Dil96] David Dill. The Murphi verification system. In R. Alur and T. Henzinger, editors,Computer Aided Verification (CAV’96), volume 1102 of Lecture Notes in ComputerScience, pages 390–393. Springer Verlag, 1996.

[GM93] Michael Gordon and T. Melham. Introduction to HOL: a theorem proving environmentfor higher-order logic. Cambridge University Press, 1993.

[GMW79] Michael J. Gordon, Robin Milner, and Christopher P. Wadsworth. Edinburgh LCF: Amechanized Logic of Computation. Number 78 in Lecture Notes in Computer Science.Springer Verlag, 1979.

[Hay98] Mark Hayden. The Ensemble System. PhD thesis, Cornell University. Department ofComputer Science, 1998. Technical Report TR98-1662.

[Hol97] G. J. Holzmann. The model checker SPIN. IEEE Transactions on Software Engineer-ing, 23(5):279–295, 1997.

[Jac93a] Paul Jackson. Nuprl ML Manual. Cornell University. Department of Computer Sci-ence, 1993.

[Jac93b] Paul Jackson. The Nuprl Proof Development System, Version 4.1: Reference Manualand User’s Guide. Cornell University. Department of Computer Science, 1993.

[Jac94] Paul Jackson. The Nuprl Proof Development System, Version 4.2: Reference Manualand User’s Guide. Cornell University. Department of Computer Science, 1994.

[KHH98] Christoph Kreitz, Mark Hayden, and Jason Hickey. A proof environment for the de-velopment of group communication systems. In C. Kirchner and H. Kirchner, editors,15th Conference on Automated Deduction, volume 1421 of Lecture Notes in ArtificialIntelligence, pages 317–331. Springer Verlag, 1998.

[KO99] Christoph Kreitz and Jens Otten. Connection-based theorem proving in classical andnon-classical logics. Journal of Universal Computer Science, 5(3):88–112, 1999.

[KOSP00] Christoph Kreitz, Jens Otten, Stephan Schmitt, and Brigitte Pientka. Matrix-basedconstructive theorem proving. In Steffen Holldobler, editor, Intellectics and Compu-tational Logic. Papers in honor of Wolfgang Bibel, number 19 in Applied Logic Series,pages 289–205. Kluwer, 2000.

[Kre97] Christoph Kreitz. Formal reasoning about communication systems I: Embedding MLinto type theory. Technical Report TR97-1637, Cornell University. Department ofComputer Science, June 1997.

[Kre03] Christoph Kreitz. Building reliable, high-performance networks with the Nuprl proofdevelopment system. Journal of Functional Programming, 2003.

214

[KS00] Christoph Kreitz and Stephan Schmitt. A uniform procedure for converting matrixproofs into sequent-style systems. Journal of Information and Computation, 162(1–2):226–254, 2000.

[Ler00] Xavier Leroy. The Objective Caml system release 3.00. Institut National de Rechercheen Informatique et en Automatique, 2000.

[LSBB92] Reinhold Letz, Johann Schumann, Stephan Bayerl, and Wolfgang Bibel. Setheo: Ahigh-performance theorem prover. Journal of Automated Reasoning, 8:183–212, 1992.

[Map] Maple home page. http://www.maplesoft.com/.

[Mat] The MathBus Term Structure. www.nuprl.org/mathbus/mathbusTOC.htm.

[McC97] W. McCune. Solution of the Robbins problem. Journal of Automated Reasoning,19:263–276, 1997.

[McM93] K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993.

[Met] Metaprl home page. http://metaprl.org.

[ML84] Per Martin-Lof. Intuitionistic Type Theory, volume 1 of Studies in Proof TheoryLecture Notes. Bibliopolis, Napoli, 1984.

[Nau98] Pavel Naumov. Publishing formal mathematics on the web. Technical Report TR98-1689, Cornell University. Department of Computer Science, 1998.

[Nau99] Pavel Naumov. Importing Isabelle formal mathematics into Nuprl. Technical ReportTR99-1734, Cornell University. Department of Computer Science, 1999.

[NO79] Greg Nelson and Derek. C. Oppen. Simplification by cooperating decision procedures.ACM Transactions on Programming Languages and Systems, 1(2):245–257, October1979.

[ORR+96] S. Owre, S. Rajan, J. M. Rushby, N. Shankar, and M. K. Srivas. PVS: Combiningspecification, proof checking and model checking. In Rajeev Alur and Thomas A.Henzinger, editors, Computer-Aided Verification, volume 1102 of Lecture Notes inComputer Science, pages 411–414. Springer Verlag, 1996.

[Pau87] Lawrence C. Paulson. Logic and Computation: Interactive Proof with Cambridge LCF.Cambridge University Press, 1987.

[Pau90] Lawrence C. Paulson. Isabelle: The next 700 theorem provers. In Piergiorgio Odifreddi,editor, Logic and Computer Science, pages 361–386. Academic Press, 1990.

[Sho84] R. E. Shostak. Deciding combinations of theories. Journal of the Association forComputing Machinery, 31(1):1–12, 1984.

[SLKN01] Stephan Schmitt, Lori Lorigo, Christoph Kreitz, and Alexey Nogin. JProver: Integrat-ing connection-based theorem proving into interactive proof assistants. In R. Gore,A. Leitsch, and T. Nipkow, editors, International Joint Conference on Automated Rea-soning, volume 2083 of Lecture Notes in Artificial Intelligence, pages 421–426. SpringerVerlag, 2001.

215

http://www.maplesoft.com/

www.nuprl.org/mathbus/mathbusTOC.htm

http://metaprl.org

[SVC] The Stanford Validity Checker home page. http://verify.stanford.edu/SVC/.

[WAL+90] Pierre Weis, Maria-Virginia Aponte, Alain Laville, Michel Mauny, and AcsanderSuarez. The CAML reference manual. Rapports Techniques 121, Institut National deRecherche en Informatique et en Automatique, September 1990.

[Wol88] S. Wolfram. Mathematica: A System for Doing Mathematics by Computer. AddisonWesley, 1988.

[WWM+90] L. Wos, S. Winker, W. McCune, R. Overbeek, E. Lusk, R. Stevens, and R. Butler.Automated reasoning contributes to mathematics and logic. In M. E. Stickel, editor,10th Conference on Automated Deduction, volume 449 of Lecture Notes in ComputerScience, pages 485–499. Springer Verlag, 1990.

216

http://verify.stanford.edu/SVC/

the nuprl proof development system, version 5 reference ... · ematical knowledge as well as for...

Documents