[Indigo]<KRL>document>sys!2

Page Numbers: Yes First Page: 1
Heading:

[IVY]<KRL>document>sys July 12, 1977 5:11 PM

INTRODUCTION TO THE KRL-1 SYSTEM ENVIRONMENT

I. Introduction

II. A sample dialog

III. Data and file management

A. The structure of files

1. The COMSLIST

2. The documentation section

3. The body of stored entities

B. Creating functions, records, variables, and units

C. Creating a file

D. File ownership

E. Version protection

IV. KRL data structures

A. Data types

B. Editing

V. The NAMEFNS facility

A. Terminology and miscellaneous remarks

B. The NAMEFNS dialogue

C. Functions for interacting with the NAMEFNS facility

VI. The library

A. Overview of files

B. Description of global variables and functions

VII. Loading the system

A. Loading USYS

B. Loading KRL

I. Introduction

This document provides an overview of the documentation, debugging, and file manipulation packages available to the implementers of KRL-1. It is useful to think of KRL as a multi-layered construct. The lowest level is INTERLISP, which provides an extensive (and extensible) set of facilities for editing and file manipulation. The next level, called USYS, is a set of functions and constraints on the basic INTERLISP environment which provide: more extensive file manipulation, documentation, and printing facilities, and a number of useful utility functions. The top level is KRL-1 itself, which further tailors the environment by defining specific KRL data types, and modifies the file manipulation routines to recognize them.

This document is in a state of flux, and will expand in the weeks and months ahead. Since multiple versions will exist, make sure to check the creation date (in the upper right hand corner of each page) to be relatively certain that you are reading the latest update. Unless you want to use this document as a reference for a specific question, the best strategy is to read the section immediately following, which presents an annotated dialog illustrating data structure manipulation and some of the documentation facilities.

II. A sample dialogue

This dialogue illustrates some of the standard operations in the KRL system environment. In particular it reveals some of a user’s interactions with the NAMEFNS facility, a facility which permits documentation of data objects and the arbitration of name conflicts. (See section V for more detail.) In this dialogue that follows, the user’s input is printed in underlined HELVETICA10, the system’s prompts and responses are in HELVETICA10, and additional commentary is indented in TIMESROMAN10.

**********************************************************

7←DL(KDR (X) (CDR X]

The user defines a function KDR with the aid of the system function DL (which defines LAMBDA functions). (He could also have typed dl in lower case.) It is important to use DL (and the corresponding function for defining NLAMBDA functions, DN), rather than DEFINEQ, since the documentation prompts are hooked to it.

(KDR)

8←DN(SETK (X Y) (SET X (EVAL Y]

The user defines an NLAMBDA.

(SETK)

9←dr(RECORD TestRec (field1 field2]

Here a record is defined with the function dr, here invoked in lower case.

Do you want to enter a comment? Yes

Comment: Note that the record fields also go into the name file
Field field2
Field field1

TestRec
10←dv(FIXFUNNYFLG)

Here a variable is defined. Actually, since INTERLISP does not have the notion of variable definition, the use of the function DV puts the variable into the name file (which is maintained by the NAMEFNS facility -- see section V) and allows the programmer to document it.

Do you want to enter a comment? Yes

Comment: dv allows commenting of global variables

FIXFUNNYFLG
11←FILES?)

Invoking the function FILES? causes the system to notify the user of all the data structures which have been created but not stored on any files. The user is then asked where they are to be stored, if anywhere.

The user can respond:

<line-feed> in which case the previous response to this question is used
<space> in which case no action is taken
] in which case the item is marked as a dummy
[ or ( followed by the name of a list. If this list is not already in some command in the comslist of some file, the user will be asked what file he wants this command added to.
an atom which is interpreted either as the name of a file or a function list

the records: TestRec...to be dumped.
the functions: KDR,SETK...to be dumped.
want to say where the above go ? Yes
(records)
TestRec List: DMLRECS
new list ? Yes
What file ? DML

Here, after being prompted with the atom TestRec, the user typed ; (semi-colon) and the system responded with the prompt List:. Since the system found no evidence that the list already existed, it then asked whether it was indeed a new list, and onto the comslist of which file the list should be added.

(functions)
KDR File/list: DMLFNS
new file ? No
new list ? Yes
What file ? DML

In this case, when prompted with the atom KDR, the user typed the atom DMLFNS, which is ambiguous between a file name and a list name. The system guessed that it was a file name, and was corrected by the user.

Do you want to enter a comment? Yes

At this point the user is asked if he wants to comment this function. Note that this prompt is being issued when the user is preparing to store the function on a file. If the function were never saved, the user would never be prompted for a comment. Note also that the prompt would not be issued if the function had a comment (i.e. in its normal position immediately after the argument list and the edit date), but the system would still store this comment away.

By typing ? here rather than Y, the user could have gotten a list of allowed responses to this prompt, namely:

Yes + comment
No
Private
Re-use last comment I type
Value of <form>
Show current entry for <name>
Edit current comment of <name>
Break

In general, the user has the option of typing ? when prompted by the system.

Comment: sample fn for didactic dialog

SETK (DMLFNS)

Here the user typed <line feed> (meaning "response is same as last") and the system filled in DMLFNS.

Do you want to enter a comment? Yes

Comment: Another sample fn with a very long comment to
...point out that you are typing to READLINE and must end non-final lines
...with a space to keep from finishing the whole thing

NIL
12←FILES?)
DML...to be dumped.
NIL

A second invokation of FILES? shows that all that remains is to dump the file DML.

13←CLEANUP)

DML...DML is an uncommented file.
Do you want to enter a comment? Yes

Comment: This is a test file for documentation purposes

Just as data structures can be commented, so too can entire files.

Do you want a Masterscope Database for this file? Yes

Responding yes to this question allows the sytem to create and maintain a MASTERSCOPE data base which it can use to analyze the import/export characteristics of the file. (See immediately below.)

Do you want an import/export comment computed for this file? Yes

Responding yes causes the system to determine which data objects are external to the file.

Compute exports? Yes

By responding Set here, the user can force the system to prompt him for lists of functions and variables which he wants to document as external. Note that invoking the function ComputeExports, given a file name as argument, would cause the system to prompt the user with this question.

DML not found, so it will be written anew.
..(F: DMLFNS)

compiling <KRL1>DML.;1

DML.BCOM not found, shall I TCOMPL <KRL1>DML.;1 instead ? Yes

listing? ST

(dwimifying KDR)
(KDR (X) NIL)
(KDR redefined)
(dwimifying SETK)
(SETK (X Y) NIL)
(SETK redefined)
NIL

<KRL1>DML.BCOM;1

<KRL1>DML.DATABASE;1

At this point, in addition to the compiled file, the system has created a MASTERSCOPE data base which has been dumped. For a file named FOO, the system creates a data base file named FOO.DATABASE.

III. Data and file management

The major data structures in the KRL-1 environment are:

* INTERLISP functions

* INTERLISP records

* INTERLISP variables

* KRL units

* KRL descriptions (??)

This section describes the facilities available for creating, documenting, and storing these entities on files.

A. The Structure of Files

The three major components of a KRL/INTERLISP file are its comslist, a documentation section, and a body of stored entities (functions, units, etc.) (See section 14 of the INTERLISP manual for a complete description.)

1. The comslist. While INTERLISP provides a number of standard commands governing data storage (FNS, VARS, etc.), the KRL environment provides its own related set as well as an accompanying set of conventions governing their use. These new commands or PRETTYDEFMACROs are F:, V:, and UNITS:, for function, variable and unit storage respectively. Each of these commands takes an argument of either a list of entities or an atom to which is bound a list of entities. So, for example, the following two comslist entries function identically, provided that the atom UNITSLIST is bound to the list (U1 U2 U3):

(UNITS: (U1 U2 U3))
(UNITS: UNITSLIST)

A number of other PRETTYDEFMACROs are provided by USYS, including P:, PROPS:, XPROPS:, MACROS:, and CONSTANTS.

It should be noted, however, that the user should rarely have to manipulate the comslist of a file him/herself. Most of the operations on a comslist (including its creation) is done by the system and unnoticed by the user. (See the discussion of FILES? below.)

2. The documentation section. The documentation section of a file is a unique feature of the KRL environment which is unavailable in the larger INTERLISP environment. This section is optional, and will only come into existence if the user responds to certain system prompts at file creation time. Its use is strongly encouraged. (See the discussion of file creation below.) It includes:

1. a comment about the purpose of the file

2. a list of "exportable" functions, which are available for general use.

3. a list of "exportable" variables.

4. the name of the MASTERSCOPE data base associated with this file, if there is one.

5. a list of "imported" functions called, i.e. which are not physically stored in the file.

6. a list of "imported" variables.

For example, the following is the documentation section from an old version of the file <KRL1>DDBFNS:

(* has automatic database maintenance and file documentation stuff)

(DECLARE: DONTCOPY (*
Externally available functions:
LOADDB?: put on file coms to cause loading of database file
ComputeExports: Computes the exported fns for a file and saves them on then value of efn, defulted to fileEXPORTFNS, ditto for
vars and evn

Externally available variables:
None

Masterscope database on file DBFNS.DATABASE

External functions called:

ASKFORCOMMENT: collects a comment for the names file
NEWNAME: puts an entry in the name file
COMMENTFNS: comments a fn in the name file
USE?: looks up a name in the name file

External variables used freely:

FILEDOCFLG: if T enables assking about computing a file doc comment
SAVEDBFLG: If T enables asking about creating a database file
LOADDBFLG: if T enables asking about loading a database file
))

3. The body of stored entities. The only important point to be made here concerns the form in which units are written onto a file. When units are written onto a file (governed by the UNIT: prettydefmacro), they are preceded either by READWHITEUNITS or READBRACKETUNITS and followed by ENDUNITS. These conventions invoke a call on the function READWHITEUNITS or READBRACKETUNITS, the difference being only in the treatment of white space. (For a discussion of the role of white space in the KRL syntax, see <KRL>KRLSYNTAX.BRAVO). READWHITEUNITS reads units which are assumed to obey the white space conventions, while READBRACKETUNITS handles units which are assumed to use bracketing rather than white space. If a unit being read by READWHITEUNITS encounters a syntactic ambiguity, it uses the white space conventions to disambiguate. Under similar conditions, however, READBRACKETUNITS generates an error.

B. Creating functions, records, variables, and units

The KRL environment provides a set of functions for creating functions, records, variables and units. In some cases, other standard INTERLISP functions are available; it is strongly advised that the KRL routines be used, largely because some of the document facilities are dependent on their use. The following functions are available:

DL -- Defines a LAMBDA function, e.g. DL(KAR (X) (CAR X))

DN -- Defines an NLAMBDA function

DR -- Defines a record, e.g. DR(RECORD NAME (FIRST LAST))

DV -- Defines a variable. Actually, since INTERLISP does not have the notion of variable definition, the use of this function puts the variable into the names file and allows the programmer to document it.

When the programmer uses one of these functions (other than DL or DN), the system asks him the question:

Do you want to enter a comment?

This prompt comes from the NAMEFNS package, and the user must respond with one of the following (typing ? to a prompt of this kind always returns the list of acceptable responses):

Yes + comment
No
Private
Re-use last comment I type
Show current entry for <name>
Edit current comment of <name>
Break

C. Creating a file

The simplest and preferred method for creating a file consists in allowing the system to do all the work. When the user wants to cleanup his core image, storing away data structures and the like, s/he types FILES? (although invoking CLEANUP will also cause FILES? to be called). This function notifies the user of all data structures which have been created but not stored, and asks him/her where he wants them saved. The user can respond:

To write out a file, the user invokes the function FILE, e.g. FILE(BLOB). (Actually, a safer and more general method of cleaning up your act is to invoke CLEANUP). If this is a new file, he will be asked the following series of questions:

BLOB is an uncommented file.
Do you want to enter a comment?

The preferred answer is YES. The system then provides the prompt Comment:

Do you want a Masterscope Database for this file?

Responding YES allows the system to create and maintain a MASTERSCOPE data base which it can use to analyze the import/export characteristics of the file. (See immediately below.)

Do you want an import/export comment computed for this file?

Responding YES causes the system to determine which data objects are external to the file, and allows the user to declare that certain objects are available outside of the environment provided by the file.

Compute exports? Yes

By responding Set here, the user can force the system to prompt him for lists of functions and variables which he wants to document as external.

D. File ownership

To prevent users and implementers from accidentally writing system files on the <KRL> directory, KRL maintains a list of file owners. This list, stored on the global variable FILEOWNERS, consists of file names paired with users and the directories onto which they can write, and prevents anyone other than an owner from writing one of these files.

E. Version protection

To help prevent mistakes, before any file is created, KRL checks to see that LISP’s ideas bout the file are consistent with those of TENEX. If not, one of the following messages is printed:

Warning! <file> versions are out of step

Warning! <file> doesn’t exist on this directory. File dates are as follows: <dates>

The second message probably means you are connected to the wrong directory. You will then be asked:

Do you still want to make the file?

The responses and their interpretations are as follows:

Yes -- go ahead

No -- forget it

Exec -- Drop inot a lower exec where you can investigate the state of the files

IV. KRL data structures

A. Data types

There is a separate document describing KRL data types in great detail (<KRL>dataTypes.spec). Included here is some basic information about the forms that one is likely to see on one’s terminal when editing or examining the LISP stack.

One is likely to stumble across three data types: a memory level structure, an intermediate level structure, and a nexus.

A memory level structure or file handle prints as MEM.<type>, e.g. MEM.Anchor.

An intermediate level structure prints as INT.<type>, e.g. INT.Perspective.

A nexus, which is a complex of memory level, intermediate level, and type information, prints as $<type>, e.g. $ANCHOR.

B. Editing

There are four edit macros in the KRL system for hacking descriptors, either independently (via EDITKRL(descriptor), aliases ek and EK, or via EDITUNIT(uname), aliases eu and EU), or inside functions. Intermediate level internal forms print as INT.TYPE, where TYPE is a descriptor type, and memory level forms print as MEM.TYPE. When prettyprinted, intermediate level forms appear in edit format. The edit macros available are for descending into the structure (ES) or notes (EN) of a descriptor, for adding notes to a non-annotated descriptor ((PN \.../)), and for getting at the right half of a dotted pair (DOT). These macros are only of use if you know the record structure of the forms involved, and no validity checks are done on the results, so caveat editor. The following transcript gives examples of all the above:

2←DL(FOO (X) (SET X \a persp with slot = unit/]
(FOO)
3←PP FOO

(FOO
[LAMBDA (X) **COMMENT**
(SET X \A persp with
slot = unit/
])
FOO
4←EF(FOO)
edit
1*P
(LAMBDA (X) **COMMENT** (SET X INT.PERSPECTIVE))
1*-1 P
(SET X INT.PERSPECTIVE)
2*-1 P
INT.PERSPECTIVE
2*PP
\A persp with
slot = unit/

2*ES

Edit the structure of the perspective

3*P
(persp (slot . INT.UNITPOINTER))
3*PP
(persp (slot . \unit/
))
3*(N (newSlot . \an otherPersp/]
4*p
(persp (slot . INT.UNITPOINTER) (newSlot . INT.PERSPECTIVE))
5*-1 p
(newSlot . INT.PERSPECTIVE)
7*dot p

Focus the editor on the right half of the dotted pair

... . INT.PERSPECTIVE)
9*(pn \a footnote/]

Add a footnote to this perspective, note that we are left looking at the new note

10*p
INT.PERSPECTIVE
11*pp
\A footnote/

12*0 p
... . INT.PERSPECTIVE)
14*pp
\An ↑1 otherPersp 1: A footnote/

16*0 p
(newSlot . INT.PERSPECTIVE)
18*dot en

Edit the notes of the perspective

20*pp
\A footnote/

21*↑ pp
[LAMBDA (X) **COMMENT**
(SET X \A persp with
slot = unit
newSlot = An ↑1 otherPersp 1: A footnote/
]
23*ok
FOO
A further macro has been added to create multiple descriptors. It is called KMBD, and embeds the current structure in an Implicit And descriptor (intermediate level).

V. The NAMEFNS facility

This section presents an overview of the NAMEFNS facility, a package which allows the documentation, updating, and name-conflict resolution of functions, records, and variables, as well as arbitrary data types. Some of the information provided here is also available elsewhere in this document (in sections II and III, for example), but is repeated here for convenience.

A. Terminology and miscellaneous remarks

A name file is the primary entity in the NAMEFNS facility. This is a file which contains the names of data objects along with their type, time stamp, creator, and associated comments.

The NAMEFNS facility is normally invoked via two operations: defining and posting data objects. Defining an object means creating it initially, e.g. defining a function. Posting an object is the process of notifying the facility that an object has been modified (e.g. edited) and is a signal that its record of this object should be updated.

The NAMEFNS facility will ignore any functions whose name is included on the global list PRIVATEFNS. This list currently includes such golden oldies as FOO, MUMBLE, FOOBAR, and FOOBAZ.

B. The NAMEFNS dialogue

The name file is checked whenever an object is defined. Following is a sample dialogue with commentary:

10←DL(BLOB (X Y) (CAR X]

The user defines a function, and immediately below the system indicates that a function with the same name already exists (Note that <item number> refers to the number to the left of each NAMEFNS entry. These numbers are dynamically created during a dialogue.)

NOTE: BLOB is already in use:

1. BLOB [LAMBDA (X] LEVY "10-JUL-77 17:42"
This is a test

What do you want to do? ?
one of:
Add new definition.
Replace item number: <item number>
Overwrite--Replace ALL old items.
Change name to: <name>
Type new item.
Show old items.
Nothing -- File won’t be updated!
Delete ALL old items
Delete <item number>

What do you want to do? Change name to: GLOM
(GLOM)
11←PP GLOM

(GLOM
[LAMBDA (X Y) **COMMENT**
(CAR X])
GLOM

The user indicated that he wants to rename his new function.

C. Functions for interacting with the NAMEFNS facility

The following functions are generally useful for both implementers and users.

ADDNAME(name type)

Adds name to the name file with type type.

CLEANNAMES(inFile outFile)

Produces a clean (i.e. garbage-collected) version of the name file inFile on outFile. Invoked without arguments, it cleans the standard (default) name file.

COMMENTFILE(fileName)

Prompts the user for comments for all the functions and records on fileName which have not already been commented.

DELNAME(name)

Removes name from the name file. If there is more than one entry for that name (because there are several different data types with the same name), the system initiates the NAMEFNS dialogue (see below).

DL(functionDef)

e.g. DL(BLOB (X) (CAR X))

Defines a function, reserving its name in the current name file. If the function contains a comment in the standard position (e.g. immediately after the argument list), this comment is placed in the name file. If there is no comment and if ever the user specifies a file to which he wants this function dumped, he will be prompted for a comment.

DN(functionDef)

Like DL, except used to define an NLAMBDA.

DR(recordDef)

Defines a record.

DU(unitDef)

Defines a unit.

DV(variableName)

Unlike the other data object defining functions, this has no use other than for adding a variable name to the name file with a comment.

EN(name)

Puts the user into the INTERLISP editor so that he can edit the entry for name.

POST(functionName)

Alerts the NAMEFNS facility that functionName has been modified and causes it to update its entry for it. Note that the same effect can be achieved by leaving the editor with the command POST rather than OK.

POSTFNS(list of function names)

Permits the posting of several functions.

POSTRECS(list of record names)

Permits the posting of several records.

PRINTNAMES(nameIndex outputFile title)

Creates a printable (EARS) file in outputFile from the name file represented by nameIndex (see immediately below), giving it a title of title. Invoking PRINTNAMES with no arguments creates a printable version of the standard (default) name file.

The following functions are used for manipulating name files. They introduce an additional concept: a name index, which is an in-core index to the items in a name file.

FILTERNAMES(nameIndex filterPred)

Returns a new name index by eliminating all entries from nameIndex which do not satisfy filterPred. filterPred is a function whose arguments should be (name type userName date).

MERGENAMES(list of name indices)

Returns a new name index created by merging the name indices given as an argument. Entries are sorted in alphabetical order. Note that this function takes a single argument which is a list (i.e. it is not a no-spread).

READNAMES(nameFile)

Creates and returns a name index for nameFile.

WRITENAMES(fileName nameIndex)

Creates a name file from nameIndex and writes it onto fileName.

VI. The library

A. Overview of files

The following section presents a brief overview of the files comprising KRL and its environment. The files in USYS are described, followed by the files in KRL-1.

1. USYS

<LISPUSERS>CHANGEFNS

Written and maintained by Ron Kaplan and Henry Thompson. Contains a number of important CLISP constructs like PUSH, POP. See Ron’s documentation (ref).

<LISPUSERS>DATABASEFNS

Written and maintained by Ron Kaplan (?). Contains the functions which make the construction and maintenance of MASTERSCOPE databases an automatic process. See <LISPUSERS>DATABASEFNS.TTY.

<LISPUSERS>EDITDATE

Written and maintained by Larry Masinter. Contains the functions which place a time stamp on newly created and edited INTERLISP functions.

<UNDERSTANDER>FILEFNS

Written and maintained by Ron Kaplan. Contains functions for file maintenance and manipulation (e.g. FILE) as well as some functions for printing data structures (e.g. PPV).

<KAPLAN>KFILEPKG

Written and maintained by Ron Kaplan. Provides support for the INTERLISP files package.

<LISPUSERS>INSTRS

Written and maintained by Ron Kaplan. Contains functions for instrumentation. See <LISPUSERS>INSTRS.TTY.

<UNDERSTANDER>STATS

Written and maintained by Ron Kaplan. Contains functions for gathering statistics on program performance.

<UNDERSTANDER>LOADUSYS

Contains the function LOADUSYS which loads USYS. Also contains LOADFILES, the basic bootstrapping file loader.

<UNDERSTANDER>LOG

Written by Henry Thompson, and maintained by Henry. Contains the code for the logging of time stamped comments into a log file. (See <KRL1>logging.note for details.)

<UNDERSTANDER>LOWERCASE

Contains the function which allows the INTERLISP system to recognize some parts of editor commands when they are typed in lower case. (Because of the idiosyncracies of INTERLISP, only the CAR of an editor command can be recognized in lower case.

<LISPUSERS>NOTECHANGEDRECS

Handles certain idiosyncracies having to do with the interaction between the record package and compiled files. See <LISPUSERS>NOTECHANGEDRECS.TTY.

<LISPUSERS>PERFORMTRAN

Written and maintained by Ron Kaplan. Contains the definition of the CLISP form PERFORM which allows arbitrary operations to be associated with a record definition.

<LISPUSERS>PERMFILE

A package of functions which allows a file to be kept open through various system events like SYSOUTs and SYSINs. This is principally used in GSP to keep the dictionary file open.

<UNDERSTANDER>PRINTOUT

Written and maintained by Ron Kaplan. Creates the CLISP construct PRINTOUT which allows great flexibility in specifying output formats. This is documented in the file <LISPUSERS>PRINTOUT.BRAVO or <LISPUSERS>PRINTOUT.EARS

<UNDERSTANDER>UTILITY

Written and maintained by Ron Kaplan. Provides a number of useful utility functions, including: DETACH, DKILL, EXEC, MAX, MIN, NAND, NOR, TRACER.

2. KRL-1

<KRL1>ACCESSCOMP

Written and maintained by Richard Fikes. The KRL access compiler.

<KRL1>CATALOGFNS

Written and maintained by Henry Thompson. Contains the functions which catalogue (i.e. index) various meta-descriptions, e.g. functional, category, catalogued by, and further specialization definitions.

<KRL1>CONVFNS

Written and maintained by Henry Thompson. Contains the functions which convert intermediate level to memory level structures.

<KRL1>DLINK

Written and maintained by Mitch Model. Sets up a link between the KRL job and a DLISP job.

<KAPLAN>HASH

Written and maintained by Ron Kaplan. Contains the functions which hash strings onto files.

<KRL1>KRLRECORDS

Written and maintained by Henry Thompson. Defines the major KRL datatypes.

<KRL1>LOADKRL

Contains the function LOADKRL which loads the other files comprising KRL.

<LISPUSERS>MACROTRAN

Written and maintained by Larry Masinter. A package for running code which has MACRO’s and ASSEMBLE code interpreted. See <LISPUSERS>MACROTRAN.TTY.

<KRL1>MEMSTRUC

Written and maintained by Henry Thompson. The package which allows KRL memory structures to be stored and manipulated on files.

<UNDERSTANDER>NAMEFNS

Written and maintained by Martin Kay and Ron Kaplan. The NAMEFNS facility.

<LISPUSERS>OPENPUPSTREAM

<KRL1>PARSEFNS

Written and maintained by Henry Thompson. Contains the functions which parse KRL message level structures.

<KRL1>PRINTFNS

Written and maintained by Henry Thompson. Contains the functions which print KRL structures.

<KRL1>PROCESS

Written and maintained by Mitch Model. Contains the agenda-manipulating functions.

<LISPUSERS>SKREADFIX

Implements a fix which allows KRL structures in compiled functions.

<KRL1>UNITFNS

Written and maintained by Henry Thompson. Contains functions which manipulate KRL units.

B. Description of global variables and functions

This section describes key variables and functions in some of the files mentioned in the last section.

VARIABLES

BRACKETFLG is used by the KRL reader to decide whether to resolve syntactic ambiguities with reference to white space. If BRACKETFLG = T, then white space is ignored.

CONVNOWFLG is used by the KRL reader. If T then units are converted to memory level structures one by one as they are read in. (The default is NIL.)

CURRENTMEMORYSPACE is the space in which KRL objects are allocated unless otherwise specified. (The default is NIL, meaning: allocate in neutral space.)

KRLFILEOWNERS is a list of system files, paired with the names of the users who may write them.

KRLTABVAL gives the number of spaces used when a tab is encountered in input. Set by KrlTabWidth(w).

LASTUNIT is bound whenever a significant operation (e.g. EDITUNIT or GETUNIT) is performed at the top level on a unit. This sets the context so that these operations can manipulate the last unit accessed in the absence of a unit argument.

FUNCTIONS

GETUNIT (ATM)

On <KRL1>UNITFNS. Returns a file handle to the unit whose name is ATM. Performs spelling correction.

UnitNameP (ATOM)

On <KRL1>UNITFNS. If ATOM is the name of a unit, returns a pointer to that unit, otherwise NIL. Does not perform spelling correction (??).

UnitP (PTR)

On <KRL1>UNITFNS. Returns PTR if PTR is a file handle to a unit, otherwise NIL.

KrlType (x)

On <KRL1>UNITFNS. If x is a KRL structure, returns an atom specifying its type (e.g. PERSPECTIVE), otherwise returns it LISP type.

VII. Loading the system

A. Loading USYS

Following is the sequence for loading a new USYS (the user’s typing is underlined):

CONN UNDERSTANDER
@<NEWLISP>BYTE.SAV

INTERLISP-MAXC 12-JUL-77 ...

Hello, Henry.
←↑W(LOAD ’LOADUSYS.BCOM)
compiled on 1-JUL-77 10:57:13
FILE CREATED 1-JUL-77 10:56:51
LOADUSYSCOMS
<UNDERSTANDER>LOADUSYS.BCOM;32
←↑W(LOADUSYS)

<KAPLAN>KFILEPKG.COM;33
compiled on 30-APR-77 14:26:35
FILE CREATED 30-APR-77 14:26:24
KFILEPKGCOMS

. . . and so on . . .

<UNDERSTANDER>FILEDOC.BCOM;11
compiled on 23-JUN-77 13:34:19
FILE CREATED 23-JUN-77 13:34:00
FILEDOCCOMS
(F: (ComputeExports DoI/ODoc EXTCALLS EXTVARS InitDoc MAKEFILEDOC PrintI&C))

GAINSPACE dialogue:
erase current Masterscope database ? No
purge history lists ? Yes
purge everything, or just the properties, e.g. SIDE, LISPXPRINT, etc. ? Everything
ARCHIVELST and named commands too ? Yes
discard definitions on property lists ? Yes
discard old values of variables ? Yes
erase properties ? Yes
indicate which ones:
advice information ? Yes
filemaps ? Yes
clisp information (warning: this will disable clisp!) ? No
compiler information (warning: this will disable the compiler!) ? No
definitions of named history commands ? No
context of edits exited via save command ? Yes
erase CLISP translations ? Yes
erase system hash array ? Yes

mapatoms called to erase the indicated properties...
collecting atom name characters
1241, 1241 free cells, 139 pages left

collecting string characters
1051, 1051 free cells, 139 pages left
NIL
2←↑W(SYSOUT ’USYS)
<UNDERSTANDER>USYS.SAV;167
2←↑W(LOAD ’BYTECOMPILER)
FILE CREATED 21-JUN-77 20:24:39
BYTECOMPILERCOMS
compiled on 7-APR-77 00:23:08
FILE CREATED 7-APR-77 00:22:19
COMPRECORDSCOMS
COMPRECORDSCOMS
compiled on 9-JUN-77 00:23:15
FILE CREATED 9-JUN-77 00:14:19
ACOMPCOMS
compiled on 17-FEB-77 06:17:08
FILE CREATED 17-FEB-77 06:17:00
LOCVAGCOMS
compiled on 11-APR-77 00:20:07
FILE CREATED 11-APR-77 00:19:46
POSTOPTCOMS
compiled on 18-MAR-77 10:25:22
FILE CREATED 18-MAR-77 10:19:52
MLAPCOMS
compiled on 14-MAR-77 06:49:17
FILE CREATED 14-MAR-77 06:49:06
MOPCODESCOMS
erase current Masterscope database ? No
discard definitions on property lists ? Yes
discard old values of variables ? Yes
erase filepkg information ? Yes
you can delete just the filemaps -
are you sure you want to delete EVERYTHING ? Yes - everything
BYTECOMPILER
has changes, not wiped.
erase properties ? Yes
indicate which ones:
advice information ? Yes
clisp information (warning: this will disable clisp!) ? No
compiler information (warning: this will disable the compiler!) ? No
definitions of named history commands ? Yes
context of edits exited via save command ? Yes
erase CLISP translations ? Yes
erase system hash array ? Yes

mapatoms called to erase the indicated properties...<UNDERSTANDER>BYTECOMPILER.;5
2←↑W(SYSOUT ’BUSYS)
<UNDERSTANDER>BUSYS.SAV;56
2←LOGOUT)

B. Loading KRL

Following is the sequence for loading a new KRL (the user’s typing is underlined):

@CONN KRL1
@<UNDERSTANDERUSYS.SAV
(<UNDERSTANDER>USYS.SAV;167 . <NEWLISP>BYTE.SAV;22)
2←↑W(LOAD ’LOADKRL)
FILE CREATED 6-JUL-77 15:03:32
LOADKRLCOMS
(V: (KRLFILES KRLFILEOWNERS KRLSTORAGE))
(LOADDOCFLG reset)
(SAVEDOCFLG reset)
(INITIALSLIST reset)
(F: (LOADKRL MAKEKRLSYS))
(E: ((ADVISE (QUOTE SYSOUT) (QUOTE BEFORE) (QUOTE (KrlSysoutAdvice)))))
load database? Yes
<KRL1>LOADKRL.DATABASE;7
<KRL1>LOADKRL.;48
2←↑W(LOADKRL)

collecting atom name characters
981, 1493 free cells, 137 pages left

collecting string characters
1039, 1039 free cells, 137 pages left

collecting arrays
6256, 10352 free cells, 129 pages left

collecting lists
7441, 10001 free cells, 124 pages left

<KRL1>LOG.COM;6
compiled on 3-MAY-77 14:37:39
FILE CREATED 3-MAY-77 14:37:23
LOGCOMS
(F: (OpenInstrLogFile CNT CNT1 LogComment LogDate NewEditE InitEditLog StopEditLog
GetEditComment))
(AFTERSYSOUTFORMS reset)

<UNDERSTANDER>NAMEFNS.BCOM;43
compiled on 5-JUN-77 18:03:15
FILE CREATED 5-JUN-77 18:02:59
(DL redefined)
(DN redefined)
NAMEFNSCOMS
(FILEOWNERS reset)
(MAKEFILEFORMS reset)
(prettytype FNS redeclared)
(USERMACROS reset)
(EDITCOMSA reset)
load database? Yes
<UNDERSTANDER>NAMEFNS.DATABASE;21

. . . and so on, responding Y each time the system asks: load database?

<KRL1>LISTFNS.BCOM;10
compiled on 11-JUL-77 18:31:27
FILE CREATED 11-JUL-77 18:31:00
LISTFNSCOMS
(F: (AddHandleTran AddHandleTran1 EQH FetchLoopTran FromFieldTran FromHandleTran
SetFreeField ToFieldTran ToHandleTran))
load database? Yes
<KRL1>LISTFNS.DATABASE;13

collecting atom name characters
1107, 1107 free cells, 25 pages left

collecting string characters
805, 1317 free cells, 24 pages left

collecting arrays
8034, 10082 free cells, 20 pages left

collecting lists
7983, 10031 free cells, 16 pages left
2←↑W(SYSOUT ’KRL)
<KRL1>KRL.SAV;2
2←LOGOUT)