1%% Oh Emacs, this is a -*- Makefile -*-, so give me tabs. 2\documentclass{article} 3\usepackage{axiom} 4 5\title{\File{src/boot/Makefile} Pamphlet} 6\author{Timothy Daly \and Gabriel Dos~Reis} 7 8\begin{document} 9\maketitle 10 11\begin{abstract} 12 \Tool{Axiom} is built in layers. The first layer is constructed into 13 an image called {\bf bootsys}. The \Tool{bootsys} image is used 14 to translate Boot code to Common Lisp code. Since a Boot coded 15 interpreter is needed to translate the code for the Boot coded 16 interpreter we have a ``boot-strapping'' problem. In order to get 17 the whole process to start we need certain files kept in 18 common lisp form. This directory contains those files. 19\end{abstract} 20\eject 21 22\tableofcontents 23\eject 24 25\section{Introduction} 26\label{sec:intro} 27 28The Scratchpad language is implemented by using a mixture of Lisp and 29a more convenient language for writing Lisp called \emph{Boot}. 30This document contains a description of the Boot language, and some 31details of the resulting Lisp programs. 32The description of the translation 33functions available are at the end of this file. 34 35The main difference between Lisp and Boot is in the syntax for 36the application of a function to its argument. 37The Lisp format [[(F X Y Z)]], means, when [[F]] is a function, 38the application of [[F]] to its arguments [[X]], [[Y]], and [[Z]], 39is written in Boot as [[F(X,Y,Z)]]. 40When [[F]] is a special Lisp word it will be written 41in Boot by using some other syntactic construction, such as spelling 42in CAPITAL LETTERS. 43 44Boot contains an easy method of writing expressions that denote lists, 45and provides an analogous method of writing patterns containing variables 46and constants which denote a particular class of lists. The pattern 47is matched against a particular list at run time, 48and if the list belongs to the class then its variables will 49take on the values of components of the list. Similarly, Boot provides 50an easy way of writing discriminated unions or algebraic types, and 51pattern matching as found in ML. 52 53 A second convenient feature provided by Boot is a method of 54writing programs that iterate over the elements of one or more lists 55and which either transform the state of the machine, or 56produce some object from the list or lists. 57 58 59\section{Boot To Common Lisp Translaters} 60\label{sec:boot-to-cl} 61 62The Boot to Common Lisp translation is organized in several 63separate logical phases. At the moment, those phases are not 64really separate; but from a logical point of view, it is better 65to think of them that way. 66 67 68\subsection{The Boot Includer} 69\label{sec:boot-to-cl:includer} 70 71The Boot Includer is the module that reads Boot codes from source files. 72The details of the Includer, as well as the grammar of the include 73files are to be found in \File{btscan2.boot} 74 75 76\subsection{The Scanner} 77\label{sec:boot-to-cl:scanner} 78 79The tokenization process is implemented in \File{btscan2.boot}. Further 80details about keywords and reserved identifiers are available in 81\File{typrops.boot}. 82 83 84\subsection{Piling} 85\label{sec:boot-to-cl:piling} 86 87The Boot language uses layout to delimit blocks of expressions. After 88the scanner pass, and before the parser pass is another pass called 89\emph{piling}. The piling pass inserts tokens to unambiguously delimit 90the boundaries of piles. This is implemented in 91\File{btpile2.boot} 92 93 94\subsection{The Parser} 95\label{sec:boot-to-cl:piling} 96 97The Boot parser is implemented in \File{typars.boot}. It is a hand-written 98recursive descent parser 99based on \emph{parser combinators} methodology. Thoe files also 100implicitly defines the grammar of the Boot language. 101 102 103\subsection{The Transformer} 104\label{sec:boot-to-cl:transfo} 105 106As observed earlier, the Boot language was originally defined as a syntactic 107sugar over Common Lisp. Consequently, it semantics is defined by 108transformation to Lisp. The transformers are defined in 109\File{tytree1.boot}. 110 111\subsection{Utils} 112\label{sec:boot-to-cl:utils} 113 114Finally, the file \File{ptyout.boot} is a pot-pourri of many utility 115functions. It also contains the entry points to the Boot translater. 116 117 118\section{Boot} 119\label{sec:boot} 120 121\subsection{Lines and Commands} 122 123If the first character of a line is a closing parenthesis the line 124is treated as a command which controls the lines that will be 125passed to the translater rather than being passed itself. 126The command [[)include filename]] filemodifier will for example 127be replaced by the lines in the file [[filename filemodifier]]. 128 129If a line starts with a closing parenthesis it will be called a command 130line, otherwise it will be called a plain line. 131The command lines are 132\begin{verbatim} 133name as written 134 135Include )include filename filemodifier 136IncludeLisp )includelisp filename filemodifier 137If )if bootexpression 138Else )else 139ElseIf )elseif bootexpression 140EndIf )endif 141Fin )fin 142Say )say string 143Eval )eval bootexpression 144EvalStrings )evalstrings bootexpression 145Package )package packagename 146 147SimpleLine::= PlainLine | Include | IncludeLisp |Say | Eval | EvalStrings 148 | Package 149\end{verbatim} 150 151A [[PlainLine]] is delivered to the translater as is. 152 153An [[Include]] delivers the lines in the file filename.filemodifier, 154treated as boot lines. 155 156An [[IncludeLisp]] delivers the lines in the specified file, treated as Lisp 157lines. The only comments allowed in lisp files that are included in 158this way require that the semicolon is at the beginning of the line. 159 160A [[Say]] outputs the remainder of the line to the console, 161 delivering nothing to the translater. 162 163An [[Eval]] translates the reminder of the line, assumed to be 164 written in Boot, to Lisp, and evaluates it, delivering nothing to 165 the translater. 166 167An [[EvalStrings]] also translates and evaluates the rest of the line 168 but this time assumes that the Boot expression denotes a list 169 of strings which are then delivered to the translater 170 instead of the EvalString line. The strings are treated as Boot lines. 171 172It is also possible to include or exclude lines based upon some 173condition which is the result of translating and evaluating 174the boot expression that follows an )if or )elseif command. 175This construction will be called a Conditional. A file will be 176composed from SimpleLines and Conditionals. A file is either 177terminated by the end of file or by a Fin line. 178\begin{verbatim} 179Components ::=(SimpleLine | Conditional)* 180 181File ::= Components ( Fin | empty) 182 183A conditional is bracketed by an If and an EndIf. 184 185Conditional ::= If Components Elselines EndIf 186\end{verbatim} 187 188If the boot expression following the )if has value true then the 189Components are delivered but not the ElseLines, 190otherwise the Components are ignored ,and the ElseLines 191are delivered to the translater. In any case the lines after 192the EndIf are then processed. 193\begin{verbatim} 194ElseLines ::= Else Components | ElseIf Components ElseLines | empty 195\end{verbatim} 196 197When the Elselines of a Conditional is being included then if an 198"Else Components" phrase is encountered then the following 199Components are included 200otherwise if an "ElseIf Components ElseLines" phrase is encountered then 201the boot expression following the )elseif is evaluated and 202if true the following Components are included, if false the 203following ElseLines is included. 204 205 206\subsection{Boot syntax and semantics} 207 208The semantics of Boot was originally defined by translation to Lisp. 209Ideally, we would like to give it a self-contained semantics, 210without explicitly referring to Lisp, or if we must we should use 211lambda calculus. 212 213\subsubsection{Source character set} 214\label{sec:boot:char-set} 215 216???What is the source character set??? That of Common Lisp? 217 218\subsubsection{Identifiers} 219\label{sec:boot:identifier} 220 221The standard identifiers start with a letter ([[a-z]] or [[A-Z]]) 222dollar sign ([[$]]), question mark ([[?]]), or the percent sign 223([[\%]]), and are followed by any number of letters, digits, single 224quotes([[']]), question marks, or percent signs. 225It is possible however, by using the escape character ([[\_]]), 226to construct identifiers that contain any 227characters except the blank or newline character. The rules in this case 228are that an escape character followed by any non-blank character 229will start an identifier with that character. Once an identifier 230has been started either in this way or by a letter, [[$]], or 231[[%]], then it may be continued either with a letter, digit, 232quote , question mark or percent sign, or with 233an escape character followed by any non-blank character. 234Certain words having the form of identifiers are not classified as 235such, but are reserved words. They are listed below. 236 237An identifier ends when a blank or end of line is encountered, or 238an escape character followed by a blank or end of line, or a 239character which is not a letter, digit, quote, question mark 240or percent sign is found. Two identifiers are equal if the 241strings produced by replacing each escape followed by a character 242by that character are equal character by character. 243 244\subsubsection{Numbers} 245\label{sec:boot:number} 246 247Integers start with a digit ([[0-9]]) and are followed by any number 248of digits. The syntax for floating point numbers is 249\begin{verbatim} 250<.I | I. | I.I> <E|e> <+ | - | empty> I 251\end{verbatim} 252where I is an integer. 253 254\subsubsection{Strings} 255\label{sec:boot:string} 256 257Strings of characters are enclosed by double quote signs. They cannot 258span two or more lines and an escape character within a string will 259include the next character regardless of its nature. 260The meaning of a string depends somewhat on the context in which 261it is found, but in general a bare string denotes the interned atom 262making up its body whereas when it is preceded by a single quote (') 263it denotes the string of characters enclosed. 264 265\subsubsection{S-expressions} 266\label{sec:boot:s-expression} 267 268An s-expression is preceded by a single quote and is followed by 269a Lisp s-expression. 270\begin{verbatim} 271sexpression ::=identifier | integer | MINUS integer | float | string 272 | QUOTE sexpression | parenthesized sexpression1 273 274sexpression1 ::=sexpression (DOT sexpression | sexpression1)| empty 275\end{verbatim} 276 277There are two ways to quote an iddentifier: either 'name or "name", which 278both give rise to (QUOTE name). However a string that is a 279component of an sexpression will denote the string unless it is the 280sole component of the s-expression in which case it denotes a string 281i.e. '"name" gives rise to "name" in Lisp rather than (QUOTE "name"). 282 283 284\subsubsection{Keywords} 285\label{sec:boot:keyword} 286 287The table of key words follows, each is given an upper case 288name for use in the description of the syntax. 289\begin{verbatim} 290 as written name 291 292 and AND 293 by BY 294 case CASE 295 cross CROSS 296 else ELSE 297 for FOR 298 if IF 299 in IN 300 is IS 301 isnt ISNT 302 of OF 303 or OR 304 repeat REPEAT 305 return RETURN 306 structure STRUCTURE 307 then THEN 308 until UNTIL 309 where WHERE 310 while WHILE 311 . DOT 312 : COLON 313 , COMMA 314 ; SEMICOLON 315 * TIMES 316 ^ POWER 317 / SLASH 318 + PLUS 319 - MINUS 320 < LT 321 > GT 322 <= LE 323 >= GE 324 = SHOEEQ 325 ~ NOT 326 ~= NE 327 .. SEG 328 # LENGTH 329 => EXIT 330 := BEC 331 == DEF 332 ==> MDEF 333 ( OPAREN 334 ) CPAREN 335 (| OBRACK 336 |) CBRACK 337 [ OBRACK 338 ] CBRACK 339 ' QUOTE 340 | BAR 341\end{verbatim} 342 343\subsubsection{Primary} 344\label{sec:boot:primar-expr} 345 346\begin{verbatim} 347constant::= integer | string | float | sexpression 348\end{verbatim} 349 350The value of a constant does not depend on the context in which it 351is found. 352\begin{verbatim} 353primary::= name | constant | construct | block | tuple | pile 354\end{verbatim} 355 356The primaries are the simplest constituents of the language and 357either denote some object or perform some transformation of the 358machine state, or both. 359The statements are the largest constituents and enclosing them 360in parentheses converts them into a primary. 361 362An alternative method of grouping uses indentation to indicate the 363parenthetical structure. 364A number of lines whose first non-space characters are in the same 365column will be called a \emph{pile}. The translater first tokenizes the 366lines producing identifier, key word, integer, string or float tokens, 367and then examines the pile structure of a Boot program 368in order to add additional tokens called [[SETTAB]], [[BACKTAB]] 369and [[BACKSET]]. 370These tokens may be considered as commands for creating a pile. 371The [[SETTAB]] starts a new line indented from the previous line and 372pushes the resulting column number on to a stack of tab positions. 373The [[BACKTAB]] will start a new line at the column position found 374at the head of the stack and removes it from the stack. 375The [[BACKSET]] has the same effect as a [[BACKTAB]] immediately followed 376by a [[SETTAB]]. 377The meaning of a sequence of tokens containing [[SETTAB]], 378[[BACKTAB]], and [[BACKSET]] is the same the sequence in which each 379[[SETTAB]] is replaced by [[OPAREN]] , each [[BACKTAB]] is replaced by 380[[CPAREN]], and each [[BACKSET]] is replaced by [[SEMICOLON]]. By 381construction the [[BACKTABS]] and [[SETTABS]] are properly nested. 382\begin{verbatim} 383listof(p,s)== p | p s ... s p 384 385parenthesized s ::= OPAREN s CPAREN 386piled s ::= SETTAB s BACKTAB 387 388blockof s ::= parenthesized (listof (s,SEMICOLON)) 389pileof s ::= piled (listof (s,BACKSET )) 390\end{verbatim} 391 392A pileof s has the same meaning as a blockof s. 393There is however a slight difference because piling is weaker than 394separation by semicolons. In other words the pile items 395may be listof(s,SEMICOLON). 396In other words if statements::= listof(statement,SEMICOLON) then 397we can have a pileof statements which has the same meaning as 398the flattened sequence formed by replacing 399all [[BACKSET]]'s by [[SEMICOLON]]'s. 400 401A blockof statement is translated to a compound statement 402e.g. in the absence of any exits, 403(a;b;c;d) is translated to (PROGN a b c d). 404 405\subsubsection{Selectors} 406\label{sec:boot:selector} 407 408\begin{verbatim} 409selector::= leftassociative(primary, DOT) 410\end{verbatim} 411 412A selector [[a.b]] denotes some component of a structure, and in 413general is translated to [[(ELT a b)]]. There are some special identifiers 414that may be used in the [[b]] position to denote list components, of which 415more later. 416The [[DOT]] has a greater precedence than juxtaposition and is 417left associative, For example 418\begin{verbatim} 419a.b.c is grouped as (a.b).c which is translated to 420 (ELT (ELT a b) c) 421 422application ::= selector selector ... selector 423 424\end{verbatim} 425 426Application of function to argument is denoted by juxtaposition. 427 428A sequence of selectors is right associative and so 429[[f g h x]] is grouped as [[f(g(h x))]]. The applications [[f x]] and 430[[f(x)]] 431mean the application of [[f]] to [[x]] and get translated to 432the Lisp [[(f x)]]. The application of a function to the empty list 433is written [[f()]], meaning the Lisp [[(f)]]. [[f(x,y,z)]] gets translated to 434the Lisp [[(f x y z)]]. 435Common Lisp does not permit a variable to occur in operator position, 436so that when f is a variable its application has to be 437put in argument position of a [[FUNCALL]] or [[APPLY]]. 438[[f(x,y,z)]] has to be replaced by [[FUNCALL(f,x,y)]] which gets translated to 439the Lisp [[(FUNCALL f x y z)]]. 440In Common Lisp each symbol might refer 441to two objects a function and a non-function. In order to resolve 442this ambiguity when a function symbol appears in a context other 443than operator position it has to be preceded by the symbol [[FUNCTION]]. 444Also it is possible to produce the function type symbol from the 445non-function symbol by applying [[SYMBOL-FUNCTION]] to it. 446 447Certain reserved words called infixed operators namely 448[[POWER]], [[TIMES]], [[SLASH]], [[PLUS]], [[MINUS]], [[IS]], 449[[EQ]], [[NE]] , [[GT]], [[GE]], [[LT]], [[LE]], [[IN]], [[AND]], 450[[OR]], indicate application by being placed between their 2 arguments. 451 452Infixed application may be either right- or left-associative. 453\begin{verbatim} 454rightassociative(p,o)::= p o p o p o ... o p 455 == p o (p o (p o ... o p))) 456 457leftassociative(p,o)::= p o p o p o ... o p 458 == (((p o p) o p) o ...) o p 459 460 461exponent ::= rightassociative(application,POWER) 462 463reduction ::= (infixedoperator |string | thetaname) SLASH application 464\end{verbatim} 465 466In a reduction the application denotes a list of items and 467operator [[SLASH]] application accumulates the list elements from the 468left using the operator 469\begin{verbatim} 470e.g. +/[a,b,c] means (((0+a)+b)+c) 471\end{verbatim} 472 473Only certain operators are provided with values when the list is empty 474they are [[and]], [[or]], [[+]], [[*]], [[max]], [[min]], [[append]], 475[[union]]. However any function can be used as an operator by enclosing it 476in double quotes. In this case the reduction is not applicable to an 477empty list. 478\begin{verbatim} 479multiplication ::= rightassociative(exponent,TIMES|SLASH) | reduction 480 481minus ::= MINUS multiplication | multiplication 482 483arith ::= leftasscociative(minus,PLUS | MINUS) 484 485is ::= arith | arith (IS | ISNT) pattern 486 487comparison ::= is (EQ | NE | GT | GE | LT | LE | IN) is | is 488 489and ::= leftassociative (comparison,AND) 490 491return ::= and | RETURN and 492 493expression ::= leftassociative(return,OR) 494\end{verbatim} 495 496The infixed operators denote application of the function to its 497two arguments. To summarize, 498the infixed operators are, in order of decreasing precedence 499strengths. 500\begin{verbatim} 501 . 502 juxtaposition 503 ** 504 * / 505 + - 506 is 507 = ^= > >= < <= in 508 and 509 or 510\end{verbatim} 511 512\subsubsection{Conditionals} 513\label{sec:boot:conditional} 514 515\begin{verbatim} 516conditional ::= IF where THEN where | 517 IF where THEN where ELSE where 518 519IF a THEN b is translated to (COND (a b)) and 520IF a THEN b else c is translated to (COND (a b) (T c)) 521 522statement::= conditional | loop | expression 523\end{verbatim} 524 525\subsubsection{Loops} 526\label{sec:boot:iteration} 527 528\begin{verbatim} 529loop ::= crossproduct REPEAT statement | REPEAT statement 530 531iterator ::= forin | suchthat | until | while 532 533iterators ::= iterator iterator ... iterator 534 535crossproduct ::=rightassociative(iterators,CROSS) 536 537suchthat ::= BAR where 538 539while ::= WHILE expression 540 541until ::= UNTIL expression 542 543forin ::= for variable IN segment | 544 for variable IN segment BY arith 545 546segment::= arith | arith SEG arith | arith SEG 547\end{verbatim} 548 549A loop performs an iterated transformation of the state which is 550specified by its statement component and its iterators. 551The forin construction introduces a new variable which is assigned 552the elements of the list which is the value of the segment in the order 553in which they appear in the list . 554 555A segment of the form [[arith]] denotes a list, 556and segments of the form [[arith SEG arith]] and 557[[arith SEG]] denote terminating and non-terminating 558arithmetic progressions. 559The [[BY arith]] option is the step size, if omitted the step is [[1]]. 560 561Two or more [[forin]]'s may control a loop. 562The associated lists are scanned in parallel and 563a variable of one [[forin]] may not appear in the segment expression that 564denotes the list in a second [[forin]]. 565Such a variable may however occur in the conditions for filtering or 566introduced by a [[suchthat]], or for termination introduced by a 567while iterator, and in the statement of the loop. 568The [[forin]] variables are local to the statement, the conditions 569that follow a [[while]] or [[suchthat]] in the same list of iterators and 570have no meaning outside them. 571The loop will be terminated when one of its [[forin]] lists is null, or 572if the condition in a [[while]] is not satisfied. The list 573elements are filtered by all the [[suchthat]] conditions. 574The ordering of the iterators is irrelevant to the meaning, so it is 575best to avoid side effects within the conditions for filtering and 576termination. 577 578It is possible to control a loop by using a \emph{cross-product} of iterators. 579The iteration in the case [[iterators1 CROSS iterators2]] is over 580all pairs of list items one from the list denoted by 581iterators1 and the other from the list denoted by iterators2. 582In this case the variables introduced [[forin]] statements in 583[[iterators1]] may be used in [[iterators2]]. 584 585\subsubsection{Lists} 586\label{sec:boot:list} 587 588Boot contains a simple way of specifying lists that are constructed 589by [[CONS]] and [[APPEND]], or by transforming one list to another in a 590systematic manner. 591\begin{verbatim} 592construct ::= OBRACK construction CBRACK 593 594construction ::= comma | comma iteratortail 595 596iteratortail ::= REPEAT iterators | iterators 597\end{verbatim} 598 599A construct expression denotes a list and may also have a list 600of controlling iterators having the same syntax as a loop. In this 601case the expression is enclosed in brackets and the iterators follow 602the expression they qualify, rather than preceding it. 603 604In the case that there are no iterators the construct expression 605denotes a list by listing its components separated by commas, or by 606a comma followed by a colon. In the simple case in which there are no 607colons the Boot expression [a,b,c,d] translates to the Lisp 608[[(LIST a b c d)]] or [[(CONS a (CONS b (CONS c (CONS d NIL))))]]. 609 610When elements are separated by comma colon, however, the expression 611that follows will be assumed to denote a list which will be appended 612to the following list, rather than consed. An exception to this rule 613is that a colon preceding the last expression is translated to 614the expression itself. If it immediately preceded by a CONS 615then it need not denote a list. 616 617For example: 618\begin{verbatim} 619[] is translated to the empty list NIL 620[a] is translated to the 1-list (LIST a) or (CONS a NIL) 621[:a] is translated to a 622[a,b] is translated to the 2-list (LIST a b) or (CONS a (CONS b NIL)) 623[:a,b] is translated to (APPEND a (CONS b NIL)) 624[a,:b] is translated to (CONS a b) 625[:a,:b] is translated to (APPEND a b) 626[:a,b,c] is translated to (APPEND a (CONS b (CONS c NIL))) 627[a,:b,c] is translated to (CONS a (APPEND b (CONS c NIL))) 628[a,b,:c] is translated to (CONS a (CONS b c)) 629\end{verbatim} 630 631If the construct expression has iterators that control the production 632of the list the resulting list depends on the form of the comma 633expression. 634i.e. 635\begin{verbatim} 636construction ::= comma iteratortail 637\end{verbatim} 638 639If the comma expression is recognised as denoting a list 640by either preceding it by a colon, or having commas at top level 641as above, then the successive values are appended. If not then 642the successive values are consed. 643e.g. 644\begin{verbatim} 645[f i for i in x] denotes the list formed by applying f to each 646 member of the list x. 647 648[:f i for i in 0..n] denotes the list formed by appending the 649 lists f i for each i in 0..n. 650\end{verbatim} 651 652\subsubsection{Patterns} 653\label{sec:boot:pattern} 654 655\begin{verbatim} 656is ::= arith | arith IS pattern 657\end{verbatim} 658 659The pattern in the proposition [[arith IS pattern]] has the same form 660as the construct phrase without iterators. In this case, however it 661denotes a class of lists rather than a list, and is composed 662from identifiers rather than expressions. The proposition 663is translated into a program that tests whether the arith expression 664denotes a list that belongs to the class. If it does then the value 665of the is expression is true and the identifiers in 666the pattern are assigned the values of the corresponding 667components of the list. If the list does not match the pattern 668the value of the is expression is false and the values of the 669identifier might be changed in some unknown way that reflects the 670partial success of the matching. 671Because of this uncertainty, 672it is advisable to use the variables in a pattern 673as new definitions rather than assigning to variables that are 674defined elsewhere. 675\begin{verbatim} 676pattern::= identifier | constant | [ patternlist ] 677\end{verbatim} 678 679The value of [[arith IS identifier]] is [[true]] and the value of 680[[arith]] is assigned to the [[identifier]]. 681[[(PROGN (SETQ identifier arith) T)]] 682The expression [[arith IS constant]] is translated to 683[[(EQUAL constant arith)]]. 684The expression arith [[IS [ pattenlist ] ]] 685produces a program which tests whether arith denotes a list 686of the right length and that each patternitem matches the corresponding 687list component. 688 689\begin{verbatim} 690patternitem ::= EQ application | DOT | pattern | name := pattern 691\end{verbatim} 692 693If the [[patternitem]] is [[EQ application]] then the value is true if 694the component is [[EQUAL]] to the value of the application expression. 695If the [[patternitem]] is [[DOT]] then the value is [[true]] regardless of the 696nature of the component. It is used as a place-holder to test 697whether the component exists. 698If the patternitem is pattern then the component is matched against 699the pattern as above. 700If the [[patternitem]] is [[name:=pattern]] then the component is 701matched against 702the pattern as above, and if the value is [[true]] the component is assigned 703to the name. This last provision enables both a component and 704its components to be given names. 705\begin{verbatim} 706patternlist ::= listof(patternitem,COMMA)| 707 listof(patternitem,COMMA) COMMA patterntail 708 patterntail 709 710patterncolon ::= COLON patternitem 711 712patterntail ::= patterncolon | 713 patterncolon COMMA listof(patternitem,COMMA) 714\end{verbatim} 715 716The [[patternlist]] may contain one colon to indicate that the following 717patternitem can match a list of any length. In this case 718the matching rule is to construct the expression 719with [[CONS]] and [[APPEND]] from the pattern as shown above and then test 720whether the list can be constructed in this way, and if so 721deduce the components and assign them to identifiers. 722 723The effect of a pattern that occurs as a variable in a for iterator 724is to filter the list by the pattern. 725\begin{verbatim} 726forin ::= for pattern IN segment 727\end{verbatim} 728 729is translated to two iterators 730\begin{verbatim} 731 for g IN segment | g IS pattern 732\end{verbatim} 733where [[g]] is an invented identifier. 734\begin{verbatim} 735forin ::= for (name:=pattern) IN segment 736\end{verbatim} 737 738is translated to two iterators 739\begin{verbatim} 740 for name IN segment BAR name IS pattern 741\end{verbatim} 742 743in order to both filter the list elements, and name both elements and 744their components. 745 746\subsubsection{Assignments} 747\label{sec:boot:assignment} 748 749A pattern may also occur on the left hand side of an assignment 750statement, and has a slightly different meaning. 751The purpose in this case is to give names to the components 752of the list which is the value of the right hand side. 753In this case no checking 754is done that the list matches the pattern precisely and the only 755effect is to construct the selectors that correspond to 756the identifiers in the pattern, apply them to the value of the 757right hand side and assign the selected components 758to the corresponding identifiers. 759The effect of applying [[CAR]] or [[CDR]] to arguments to which they are not 760applicable will depend on the underlying Lisp system. 761\begin{verbatim} 762assignment::= assignvariable BECOMES assignment| statement 763 764assignvariable := OBRACK patternlist CBRACK | assignlhs 765\end{verbatim} 766 767The assignment having a pattern as its left hand side is reduced 768as explained above to one or more assignments having an identifier 769on the left hand side. 770The meaning of the assignment depends on whether the identifier 771starts with a dollar sign or not, if it is and whether it is followed by 772[[:local]] or [[:fluid]]. 773If the identifier does not start with a dollar sign it 774is treated as local to the body of the function in which it 775occurs, and 776if it is not already an argument of the function, 777a declaration to that effect is added to the Lisp code 778by adding a [[PROG]] construction at top level within the body of the 779function definition. Note also the all local variables and fluid variables 780are treated this way, resulting in initialization to [[nil]] before 781execution of the body of the function. Consequently care must be 782exercised when assigning to Lisp special global variables. If you 783do not want that implicitly initialization to [[nil]], then use the 784explicit [[SETQ]] Lisp special form in an application syntax. 785 786If such an identifier assignment does not occur in the body 787of a function but in a top level expression then 788it is also treated as a local. The sole exception to this rule 789is when the top level expression is an assignment to an identifier 790in which case it is treated as global. 791 792If the left hand side of an assignment is an identifier that starts with 793a dollar sign it will not be classified as a local but will 794be treated as non-local. If it is also followed by [[:local]] then it 795will be treated as a declaration of a [[FLUID]] (VMLisp) or [[SPECIAL]] 796variable (Common Lisp) which will be given an initial value which is the 797value of the right hand side of the assignment statement. 798The [[FLUID]] or [[SPECIAL]] variables may be referred to or assigned to 799by functions that are applied in the body of the declaration. 800 801If the left hand side of an assignment statement is 802an identifier that does not start with a dollar sign followed 803by [[:local]] then it will also be treated as a [[FLUID]] or [[SPECIAL]] 804declaration, however it may only be assigned to in the body 805of the function in which the assignment it occurs. 806\begin{verbatim} 807assignment::= assignvariable BECOMES assignment | statement 808 809assignvariable := OBRACK patternlist CBRACK | assignlhs 810 811assignlhs::= name | name COLON local | 812 name DOT primary DOT ... DOT primary 813\end{verbatim} 814 815If the left hand side of an assignment has the form 816\begin{verbatim} 817 name DOT primary DOT ... DOT primary 818\end{verbatim} 819the assignment statement will denote an updating of some component 820of the value of name. In general [[name DOT primary := statement]] 821will get translated to [[(SETELT name primary statement)]] or 822[[(SETF (ELT name primary) statement)]] 823There are however certain identifiers that denote components of 824a list which will get translated to statements that update that 825component (see appendix) e.g. 826\begin{verbatim} 827a.car:=b is translated to (SETF (CAR a) b) in Common Lisp. 828\end{verbatim} 829The iterated [[DOT]] is used to update components of components 830and e.g 831 832\begin{verbatim} 833a.b.c:=d is translated to (SETF (ELT (ELT a b)c) d) 834 835exit::= assignment | assignment EXIT where 836\end{verbatim} 837 838The exit format [[assignment EXIT where]] is used to give a value to 839a blockof or pileof statements in which it occurs at top level. 840 841The expression 842\begin{verbatim} 843 (a =>b;c) will be translated to if a then b else c or 844 (COND (a b) (T c)) 845\end{verbatim} 846 847If the exit is not a component of a blockof or pileof statements 848then 849\begin{verbatim} 850a=>b will be translated to (COND (a b)) 851\end{verbatim} 852 853\subsubsection{Definitions} 854 855Functions may be defined using the syntax 856\begin{verbatim} 857functiondefinition::= name DEF where | name variable DEF where 858 859 860variable ::= parenthesized variablelist | pattern 861 862variableitem ::= 863 name| pattern | name BECOMES pattern | name IS pattern 864 865variablelist ::= variableitem | COLON name | 866 variableitem COMMA variablelist 867\end{verbatim} 868 869Function definitions may only occur at top level or after a [[where]]. 870The [[name]] is the name of the function being defined, and the 871most frequently used form of the [[variable]] is either a single name 872or a parenthesized list of names separated by commas. 873In this case the translation to Lisp is straightforward, for example: 874\begin{verbatim} 875f x == E or f(x)==E is translated to (DEFUN f (x) TE) 876f (x,y,z)==E is translated to (DEFUN f (x y z) TE) 877f ()==E is translated to (DEFUN f () TE) 878\end{verbatim} 879 880where [[TE]] is the translation of [[E]]. 881At top level 882\begin{verbatim} 883f==E is translated to (DEFUN f () TE) 884\end{verbatim} 885 886The function being defined is that which when applied to its arguments 887produces the value of the body as result where the variables 888in the body take on the values of its arguments. 889 890A pattern may also occur in the variable of a definition of a function 891and serves the purpose, similar to the left hand side of assignments, 892of naming the list components. 893The phrase 894\begin{verbatim} 895 name pattern DEF where 896is translated to 897 name g DEF (pattern:=g;where) 898\end{verbatim} 899 900similarly 901\begin{verbatim} 902 name1 name2 := pattern DEF where or name1 name2 is pattern DEF where 903 904are both translated to 905 name1 name2 DEF (pattern:=name2;where) 906\end{verbatim} 907 908similarly for patterns that occur as components of a list of 909variables. order 910\begin{verbatim} 911variablelist ::= 912 variableitem | COLON name | variableitem COMMA variablelist 913\end{verbatim} 914 915The parenthesized [[variablelist]] that occurs as a variable of a function 916definition can contain variables separated by commas but can also 917have a comma colon as its last separator. 918 919This means that the function is applicable to lists of different 920sizes and that only the first few elements corresponding to the 921variables separated by commas are named, and 922the last name after the colon denotes the rest of the list. 923 924Macros may be defined only at top level, and must always have a variable 925\begin{verbatim} 926macrodefinition::= name variable MDEF where 927\end{verbatim} 928 929The effect of a [[macrodefinition]] is to produce a Lisp macro 930which is applied to arguments that are treated as expressions, rather 931than their values, and whose result if formed by first substituting 932the expressions for occurrences of the variables within the body 933and then evaluating the resulting expression. 934 935\subsubsection{Where Clauses} 936\label{sec:boot:where-clause} 937 938Expressions may be qualified by one or more function definitions 939using the syntax 940\begin{verbatim} 941where ::= exit | exit WHERE qualifier 942 943qualifier ::= functiondefinition | 944 pileof (functiondefinition) | blockof functiondefinition 945\end{verbatim} 946 947The functions may only be used within the expression that is qualified. 948This feature has to be used with some care, however, because 949a where clause may only occur within a function body, and 950the component functions are extruded, so to speak, from their contexts 951renamed, and made into top level function definitions. 952As a result the variables of the outer function cannot be referred to 953within the inner function. 954If a qualifying function has the format [[name DEF where]] then 955the [[where]] phrase is substituted for all occurrences of the name 956within the expression qualified. 957If an expression is qualified by a phrase that is not a 958function definition then the result will be a compound statement 959in which the qualifying phrase is followed by the qualified phrase. 960 961\subsubsection{Tuples} 962\label{sec:boot:tuples} 963 964Although a tuple may appear syntactically 965in any position occupied by a primary 966it will only be given meaning when it is the argument to a function. 967To denote a list it has to be enclosed in brackets rather than 968parentheses. A tuple at top level is treated as if its components 969appeared at top level in the order of the list. 970\begin{verbatim} 971tuple::= parenthesized (listof (where,COMMA)) 972\end{verbatim} 973 974\subsubsection{Blocks and Piles} 975\label{sec:boot:block} 976 977\begin{verbatim} 978block::= parenthesized (listof (where,SEMICOLON)) 979pile::= piled (listof (listof(where,SEMICOLON),BACKSET)) 980A block or a pile get translated to a compound statement or PROGN 981\end{verbatim} 982 983\subsubsection{Top Level} 984\label{sec:boot:top-level} 985 986\begin{verbatim} 987toplevel ::= functiondefinition | macrodefinition | primary 988\end{verbatim} 989 990\subsubsection{Translation Functions} 991\label{sec:boot:translation} 992 993\begin{verbatim} 994(boottocl "filename") 995translates the file "filename.boot" to 996the common lisp file "filename.clisp" 997\end{verbatim} 998 999\begin{verbatim} 1000(bootclam "filename") 1001translates the file "filename.boot" to 1002the common lisp file "filename.clisp" 1003\end{verbatim} 1004 1005producing, for each function a 1006hash table to store previously computed values indexed by argument 1007list. The function first looks in the hash table for the result 1008if there returns it, if not computes the result and stores it in the 1009table. 1010 1011\begin{verbatim} 1012(boottoclc "filename") 1013translates the file "filename.boot" to 1014the common lisp file "filename.clisp" 1015with the original boot code as comments 1016\end{verbatim} 1017 1018\begin{verbatim} 1019(boot "filename") 1020translates the file "filename.boot" to 1021the common lisp file "filename.clisp", 1022compiles it to the file "filename.bbin" 1023and loads the bbin file. 1024\end{verbatim} 1025 1026\begin{verbatim} 1027(bo "filename") 1028translates the file "filename.boot" 1029and prints the result at the console 1030\end{verbatim} 1031 1032\begin{verbatim} 1033(stout "string") translates the string "string" 1034and prints the result at the console 1035\end{verbatim} 1036 1037\begin{verbatim} 1038(sttomc "string") translates the string "string" 1039to common lisp, and compiles the result. 1040\end{verbatim} 1041 1042\begin{verbatim} 1043(fc "functionname" "filename") 1044attempts to find the boot function 1045functionname in the file filename, 1046if found it translates it to common 1047lisp, compiles and loads it. 1048\end{verbatim} 1049 1050\begin{verbatim} 1051BOOT_-COMPILE_-DEFINITION_-FROM_-FILE(fn,symbol) 1052 is similar to fc, fn is the file name but symbol is the symbol 1053 of the function name rather than the string. 1054(fn,symbol) 1055\end{verbatim} 1056 1057\begin{verbatim} 1058BOOT_-EVAL_-DEFINITION_-FROM_-FILE(fn,symbol) 1059attempts to find the definition of symbol in file fn, but this time 1060translation is followed by EVAL rather than COMPILE 1061\end{verbatim} 1062 1063\begin{verbatim} 1064(defuse "filename") 1065Translates the file filename, and writes a report of the 1066functions defined and not used, and used and not defined in the 1067file filename.defuse 1068\end{verbatim} 1069 1070\begin{verbatim} 1071(xref "filename") 1072Translates the file filename, and writes a report of the 1073names used, and where used to the file filename.xref 1074\end{verbatim} 1075 1076\subsection{Reserved identifiers} 1077\label{sec:boot:reserved-identifiers} 1078 1079The following identifiers are reserved by Boot. 1080\begin{verbatim} 1081 and append apply atom car cdr cons copy 1082 croak drop exit false first function genvar IN 1083 is isnt lastNode LAST list member mkpf nconc 1084 nil not NOT nreverse null or otherwise PAIRP 1085 removeDuplicates rest reverse setDifference 1086 setIntersection setPart setUnion size strconc substitute 1087 take true PLUS MINUS TIMES POWER SLASH LT 1088 GT LE GE SHOEEQ NE T 1089\end{verbatim} 1090 1091The following identifiers designate special accessor functions in Boot. 1092\begin{verbatim} 1093 setName setLabel setLevel setType setVar setLeaf 1094 setLeaf setDef aGeneral aMode aTree aValue 1095 attributes cacheCount cacheName cacheReset cacheType env 1096 expr CAR mmCondition mmDC mmImplementation 1097 mmSignature mmTarget mode op opcode opSig 1098 CDR sig source streamCode streamDef streamName 1099 target 1100\end{verbatim} 1101 1102 1103\section{The Makefile} 1104\label{sec:Makefile} 1105 1106When all of the native object files are produced we construct a 1107lisp image that contains the boot translator, called [[bootsys]], which 1108lives in the [[$(axiom_target_bindir)]] directory. This [[bootsys]] image 1109is critical for the rest of the makefiles to succeed. 1110 1111There are two halves of this file. the first half compiles the .lisp files 1112that live in the src/boot directory. the second half compiles the .clisp 1113files (which are generated from the .boot files). It is important that 1114the .clisp files are kept in the src/boot directory for the boot translator 1115as they cannot be recreated without a boot translator (a bootstrap problem). 1116 1117An important subtlety is that files in the boot translator depend on the 1118file npextras. there are 3 macros in npextras that must be in the lisp 1119workspace (\verb$|shoeOpenInputFile| |shoeOpenOutputFile| memq$). 1120 1121\section{Special Commands} 1122\label{sec:special-commands} 1123 1124We are working in a build environment that combines Makefile 1125technology with Lisp technology. Instead of invoking a command 1126like {\bf gcc} and giving it arguments we will be creating 1127Lisp S-expressions and piping them into a Lisp image. The 1128Lisp image starts, reads the S-expression from standard input, 1129evaluates it, and finding an end-of-stream on standard input, exits. 1130 1131 1132\section{The Boot Compiler} 1133\label{sec:boot-compiler} 1134 1135This section describes the set of object files that make the Boot compiler. 1136 1137\subsection{The Bootstrap files} 1138\label{sec:boot-compiler:bootstrap} 1139 1140This is a list of all of the files that must be loaded to construct the 1141boot translator image. 1142<<environment>>= 1143boot_objects = $(boot_sources:.boot=.$(FASLEXT)) 1144 1145boot_SOURCES = $(addsuffix .pamphlet, $(boot_sources)) 1146 1147pamphlets = Makefile.pamphlet $(AXIOM_LOCAL_LISP_SOURCES) $(boot_SOURCES) 1148@ 1149 1150[[$(boot_sources)]] is a list of the boot file targets. If you modify a 1151boot file you'll have to explicitly build the clisp files and 1152merge the generated code back into the pamphlet by hand. The 1153assumption is that if you know enough to change the fundamental 1154bootstrap files you know how to migrate the changes back. 1155This process, by design, does not occur automatically (though it 1156could). 1157 1158The Boot compiler, [[bootsys]], is built from a set of source files 1159written in Boot. Note that the order is 1160important as earlier files will contain code needed by later files. 1161<<environment>>= 1162boot_sources = ptyout.boot btincl2.boot \ 1163 btscan2.boot typrops.boot btpile2.boot \ 1164 typars.boot tytree1.boot 1165 1166boot_clisp = $(boot_sources:.boot=.clisp) 1167boot_data = $(boot_sources:.boot=.data) 1168boot_fn = $(boot_sources:.boot=.fn) 1169@ 1170These source files use macros defined in the first set, and they be compiled 1171in an environment where those macros are present. 1172 1173Since the Boot language is defined as a syntactic sugar over Lisp 1174(a reasonably tasty sugar), the 1175the second set of source files (written in Boot) is first translated 1176to Lisp, and the result of that translation is subsequently compiled to 1177native object files. 1178 1179Partly for bootstrapping reasons, and partly because Axiom (therefore 1180Boot) is not yet widespread, the pamphlets for the source files written 1181in Boot currently keep a cache of their translated versions. Hopefully 1182the maintenance of that cache will be unnecessary as the build machinery 1183becomes more and more improved, and Axiom gets in widespread use. 1184<<environment>>= 1185boot_cached_clisp = $(boot_sources:.boot=.clisp) 1186@ 1187 1188\section{Bootstrapping Boot} 1189\label{sec:bootstrapping} 1190 1191When the system is configured for bootstrap, we build the Boot compiler --- 1192[[bootsys]] --- in three steps: 1193\begin{enumerate} 1194\item a stage-0 Boot compiler, built from the cached (Lisp) source files; 1195 1196\item a stage-1 Boot compiler, built the original Boot source files using the 1197 stage-0 Boot compiler; 1198 1199\item and a stage-2 Boot compiler, built from original Boot source files 1200 using the stage-2 Boot compiler. 1201\end{enumerate} 1202Notice that in last two steps, the source file written in Boot are first 1203translated to Lisp using the freshly built Boot compiler, and the resulting 1204Lisp files subsequently compiled to natve object files. 1205 1206Ideally, we should also compare the intermediate Lisp source files from 1207stage 1 and 2 to detect possible miscompilation. We don't do that 1208for the moment. 1209 1210\subsection{Compiling the Boot source files} 1211\label{sec:bootstrapping:source-files} 1212 1213We compile the Boot compiler source files written in Boot only 1214at stage 1 and 2 (when bootstrapping). As explained earlier, the 1215compilation of these files proceeds in two steps: 1216\begin{enumerate} 1217\item Translate the Boot source files to Lisp code, 1218\item compile the resulting Lisp source files to native object code. 1219\end{enumerate} 1220These files depend on macros defined in the Lisp source files without 1221dependency (see previous section). 1222<<compile Boot files from pamphlets>>= 1223.PRECIOUS: %.$(FASLEXT) 1224.PRECIOUS: %.clisp 1225.PRECIOUS: %.boot 1226 1227$(boot_objects): %.$(FASLEXT): %.clisp 1228 $(COMPILE_LISP) --use=$(AXIOM_LOCAL_LISP) $< 1229 1230%.clisp: %.boot 1231 $(BOOT_TO_LISP) 1232 1233<<boot from pamphlet>> 1234@ 1235 1236\subsection{The various bootstrapping stages} 1237\label{sec:bootstrapping:stages} 1238 1239\subsubsection{Stage 0} 1240\label{sec:bootstrapping:stages:stage-0} 1241 1242We build the stage-0 Boot compiler from the cached Lisp sources code. 1243<<stage 0 boot compiler>>= 1244.PRECIOUS: stage0/%.clisp 1245.PRECIOUS: stage0/%.$(FASLEXT) 1246 1247stage0_boot_clisp = $(addprefix stage0/, $(boot_clisp)) 1248 1249stage0_boot_objects = $(addprefix stage0/, $(boot_objects)) 1250 1251stage0/bootsys$(EXEEXT): 1252 @echo Building stage 0 1253 [ -d stage0 ] || $(mkinstalldirs) stage0 1254 rm -rf prev-stage 1255 rm -f $(stage0_boot_objects) 1256 rm -f $(stage0_boot_clisp) 1257 $(MAKE) $(AX_FLAGS) OBJECTS="$(stage0_boot_objects)" bootsys$(EXEEXT) 1258 mv bootsys$(EXEEXT) stage0 1259 $(LN_S) stage0 prev-stage 1260 1261$(stage0_boot_objects): $(AXIOM_LOCAL_LISP) 1262 1263stage0/%.$(FASLEXT): stage0/%.clisp 1264 $(COMPILE_LISP) --use=$(AXIOM_LOCAL_LISP) $< 1265 1266@ 1267 1268\subsubsection{Stage 1} 1269\label{sec:bootstrapping:stages:stage-1} 1270 1271<<stage 1 boot compiler>>= 1272stage1/bootsys$(EXEEXT): stage0/bootsys$(EXEEXT) 1273 @echo Building stage 1 1274 [ -d stage1 ] || $(mkinstalldirs) stage1 1275 $(MAKE) $(AX_FLAGS) OBJECTS="$(boot_objects)" bootsys$(EXEEXT) 1276 -rm -f $(addprefix stage1/, $(boot_objects)) 1277 -rm -f $(addprefix stage1/, $(boot_clisp)) 1278 mv $(boot_objects) stage1 1279 mv $(boot_clisp) stage1 1280 -mv $(boot_data) $(boot_fn) stage1 1281 mv bootsys$(EXEEXT) stage1 1282 -rm -rf prev-stage 1283 $(LN_S) stage1 prev-stage 1284@ 1285 1286\subsubsection{Stage 2} 1287\label{sec:bootstrapping:stages:stage-2} 1288 1289<<stage 2 boot compiler>>= 1290stage2/bootsys$(EXEEXT): stage1/bootsys$(EXEEXT) 1291 @echo Building stage 2 1292 [ -d stage2 ] || $(mkinstalldirs) stage2 1293 $(MAKE) $(AX_FLAGS) OBJECTS="$(boot_objects)" bootsys$(EXEEXT) 1294 -rm -rf prev-stage 1295 -rm -f $(addprefix stage2/, $(boot_objects)) 1296 -rm -f $(addprefix stage2/, $(boot_clisp)) 1297 mv $(boot_objects) stage2 1298 mv $(boot_clisp) stage2 1299 -mv $(boot_data) $(boot_fn) stage2 1300 mv bootsys$(EXEEXT) stage2 1301@ 1302 1303<<bootstrap>>= 1304<<stage 0 boot compiler>> 1305 1306<<stage 1 boot compiler>> 1307 1308<<stage 2 boot compiler>> 1309@ 1310 1311\section{Global variables} 1312 1313The Boot implementation uses a number of global variables 1314for communication between several routines. Some of them follow 1315the syntactic convention of starting their names with [[$]]. Some 1316don't. 1317 1318\subsection{[[$linepos]]} 1319 1320\subsection{[[$f]]} 1321 1322\subsection{[[$r]]} 1323 1324\subsection{[[$ln]]} 1325 1326\subsection{[[$sz]]} 1327 1328\subsection{[[$n]]} 1329 1330\subsection{[[$floatok]]} 1331 1332\subsection{[[$bfClamming]]} 1333 1334\subsection{[[$GenVarCounter]]} 1335 1336\subsection{[[$inputstream]]} 1337 1338\subsection{[[$stack]]} 1339 1340\subsection{[[$stok]]} 1341 1342\subsection{[[$ttok]]} 1343 1344\subsection{[[$op]]} 1345 1346\subsection{[[$wheredefs]]} 1347 1348\subsection{[[$typings]]} 1349 1350\subsection{[[$returns]]} 1351 1352\subsection{[[$bpCount]]} 1353 1354\subsection{[[$bpParentCount]]} 1355 1356\subsection{[[$lispWordTable]]} 1357 1358\subsection{[[$bootUsed]]} 1359 1360\subsection{[[$bootDefinedTwice]]} 1361 1362\subsection{[[$used]]} 1363 1364\subsection{[[$letGenVarCounter]]} 1365 1366\subsection{[[$isGenVarCounter]]} 1367 1368\subsection{[[$inDefIS]]} 1369 1370\subsection{[[$fluidVars]]} 1371 1372\subsection{[[$locVars]]} 1373 1374\subsection{[[$dollarVars]]} 1375 1376 1377 1378 1379\section{The Makefile} 1380<<*>>= 1381<<environment>> 1382 1383subdir = src/boot/ 1384 1385# this stanza will create the final bootsys image 1386all: all-ax 1387 1388all-ax: stage2/bootsys$(EXEEXT) 1389 $(INSTALL_PROGRAM) stage2/bootsys$(EXEEXT) $(axiom_build_bindir) 1390 1391<<bootstrap>> 1392 1393<<build bootsys>> 1394 1395<<compile Boot files from pamphlets>> 1396<<initial-env.lisp>> 1397 1398<<cleanup>> 1399@ 1400 1401\eject 1402\begin{thebibliography}{99} 1403\bibitem{1} \$SPAD/src/boot/boothdr.lisp.pamphlet 1404\bibitem{2} \$SPAD/src/boot/btincl2.boot.pamphlet 1405\bibitem{3} \$SPAD/src/boot/btpile2.boot.pamphlet 1406\bibitem{4} \$SPAD/src/boot/btscan2.boot.pamphlet 1407\bibitem{5} \$SPAD/src/boot/exports.lisp.pamphlet 1408\bibitem{6} \$SPAD/src/boot/npextras.lisp.pamphlet 1409\bibitem{7} \$SPAD/src/boot/ptyout.boot.pamphlet 1410\bibitem{8} \$SPAD/src/boot/typars.boot.pamphlet 1411\bibitem{9} \$SPAD/src/boot/typrops.boot.pamphlet 1412\bibitem{10} \$SPAD/src/boot/tytree1.boot.pamphlet 1413\end{thebibliography} 1414\end{document} 1415