X-Git-Url: https://jxself.org/git/?a=blobdiff_plain;f=md%2Flanguage.md;h=7a8b684274a250efdcfcaa81595794e78952f2d8;hb=839164c67217cd5b62dec08989386e102cac2ae4;hp=0abf4dfc4871ddb754e8fc4025f2acc9678de879;hpb=875775f36b5fe75bbda679fd130075bd57c485f6;p=mudman.git diff --git a/md/language.md b/md/language.md index 0abf4df..7a8b684 100644 --- a/md/language.md +++ b/md/language.md @@ -19,21 +19,21 @@ This document is free of known copyright restrictions. Abstract ======== -The Muddle programming language began existence in late 1970 (under -the name Muddle) as a successor to Lisp (Moon, 1974), a candidate -vehicle for the Dynamic Modeling System, and a possible base for -implementation of Planner (Hewitt, 1969). The original design goals -included an interactive integrated environment for programming, -debugging, loading, and editing: ease in learning and use; facilities -for structured, modular, shared programs; extensibility of syntax, -data types and operators: data-type checking for debugging and -optional data-type declarations for compiled efficiency; associative -storage, coroutining, and graphics. Along the way to reaching those -goals, it developed flexible input/output (including the ARPA -Network), and flexible interrupt and signal handling. It now serves as -a base for software prototyping, research, development, education, and -implementation of the majority of programs at MIT-DMS: a library of -sharable modules, a coherent user interface, special research +The Muddle programming language began existence in late 1970 as a +successor to Lisp (Moon, 1974), a candidate vehicle for the Dynamic +Modeling System, and a possible base for implementation of Planner +(Hewitt, 1969). The original design goals included an interactive +integrated environment for programming, debugging, loading, and +editing: ease in learning and use; facilities for structured, +modular, shared programs; extensibility of syntax, data types and +operators: data-type checking for debugging and optional data-type +declarations for compiled efficiency; associative storage, +coroutining, and graphics. Along the way to reaching those goals, it +developed flexible input/output (including the ARPA Network), and +flexible interrupt and signal handling. It now serves as a base for +software prototyping, research, development, education, and +implementation of the majority of programs at MIT-DMS: a library of +sharable modules, a coherent user interface, special research projects, autonomous daemons, etc. This document was originally intended to be a simple low-level @@ -125,16 +125,16 @@ on. There are no "practice problems"; you are assumed to be learning Muddle for some purpose, and your work in achieving that purpose will -be more useful and motivated than artificial problems. In several +be more useful and motivating than artificial problems. In several cases, the examples contain illustrations of important points which -are not covered in the text. Ignore examples as your peril. +are not covered in the text. Ignore examples at your peril. This document does not assume knowledge of any specific programming -language on the \[sic\] your part. However, "computational literacy" -is assumed: you should have written at least one program before. Also -very little familiarity is assumed with the interactive time-sharing -operating systems under which Muddle runs -- ITS, Tenex, and Tops-20 --- namely just file and user naming conventions. +language on your part. However, "computational literacy" is assumed: +you should have written at least one program before. Also very little +familiarity is assumed with the interactive time-sharing operating +systems under which Muddle runs -- ITS, Tenex, and Tops-20 -- namely +just file and user naming conventions. ### Notation @@ -175,8 +175,8 @@ especially upon reaching chapter 5 (Simple Functions). ------------------------- First, catch your rabbit. Somehow get the interpreter running -- the -program in the file `SYS:TS.Muddle` in the ITS version or -`SYS:Muddle.SAV` in the Tenex version or `SYS:Muddle.EXE` in the +program in the file `SYS:TS MDL` in the ITS version or +`SYS:MDL.SAV` in the Tenex version or `SYS:MDL.EXE` in the Tops-20 version. The interpreter will first type out some news relating to Muddle, if any, then type @@ -231,9 +231,8 @@ except that, if your terminal is a "display" terminal (for example, IMLAC, ARDS, Datapoint), it firsts clears the screen. Typing `^G` (`CTRL`+`G`) causes Muddle to stop whatever it is doing -and act as if an error had occurred ([section -1.4](#14-errors-simple-considerations-1)). `^G` is generally most -useful for temporary interruptions to check the progress of a +and act as if an error had occurred (section 1.4). `^G` is generally +most useful for temporary interruptions to check the progress of a computation. `^G` is "reversible" -- that is, it does not destroy any of the "state" of the computation it interrupts. To "undo" a `^G`, type the characters @@ -243,11 +242,11 @@ type the characters (This is discussed more fully far below, in section 16.4.) Typing `^S` (`CTRL`+`S`) causes Muddle to **throw away** what it is -currently doing and return a normal "listening" state. (In the Tenex -and Tops-20 versions, `^O` also should have the same effect.) `^S` is -generally most useful for aborting infinite loops and similar terrible -things. `^S` **destroys** whatever is going on, and so it is **not** -reversible. +currently doing and return to a normal "listening" state. (In the +Tenex and Tops-20 versions, `^O` also should have the same effect.) +`^S` is generally most useful for aborting infinite loops and similar +terrible things. `^S` **destroys** whatever is going on, and so it is +**not** reversible. Most expressions in Muddle include "brackets" (generically meant) that must be correctly paired and nested. If you end your typing with the @@ -1180,7 +1179,7 @@ re-bound....) One way to "name" a `FUNCTION` is )>$ - #FUNCTION ((X) <* .X .X> + #FUNCTION ((X) <* .X .X>) So that @@ -1192,7 +1191,7 @@ So that Another way, which is somewhat cleaner in its typing: >>$ - #FUNCTION ((X) <* .X .X> + #FUNCTION ((X) <* .X .X>) `FUNCTION` is an `FSUBR` which simply makes a `FUNCTION` out of its arguments and returns the created `FUNCTION`. @@ -4132,30 +4131,30 @@ used on the `CHANNEL`, and whether or not the *device* is a terminal. The following table tells which `SUBR`s can be used with which modes, where `OK` indicates an allowed use: - ------------------------------------------------------------------------------------------------------------------------------------------------- - "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs - -------------------- --------------------- --------------------- -------------------------------------------- ----------------------------------- - OK OK `READ` `READCHR` `NEXTCHR` - `READSTRING` `FILECOPY` - `FILE-LENGTH LOAD` + ------------------------------------------------------------------------- + "READ" "PRINT" "READB" "PRINTB", "PRINTO" mode / SUBRs + ------ ------- ------- ------------------ ------------ + OK OK `READ` `READCHR` `NEXTCHR` + `READSTRING` `FILECOPY` + `FILE-LENGTH LOAD` - OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE` - `CRLF` `TERPRI` `FILECOPY` - `PRINTSTRING` `BUFOUT` `NETS` - `RENAME` + OK OK\* `PRINT` `PRIN1` `PRINC` `IMAGE` + `CRLF` `TERPRI` `FILECOPY` + `PRINTSTRING` `BUFOUT` `NETS` + `RENAME` - OK `READB` `GC-READ` + OK `READB` `GC-READ` - OK `PRINTB` `GC-DUMP` + OK `PRINTB` `GC-DUMP` - OK OK OK `ACCESS` + OK OK OK `ACCESS` - OK OK OK OK `RESET` + OK OK OK OK `RESET` - OK OK `ECHOPAIR` + OK OK `ECHOPAIR` - OK `TTYECHO` `TYI` - ------------------------------------------------------------------------------------------------------------------------------------------------- + OK `TTYECHO` `TYI` + ------------------------------------------------------------------------- `*` PRINTing (or `PRIN1`ing) an `RSUBR` (chapter 19) on a `"PRINTB"` or `"PRINTO"` `CHANNEL` has special effects. @@ -4278,52 +4277,52 @@ each element, and an interpretation. The format used is the following: *element-number: type interpretation* - ---------------------------------------------------------------------------------------------------- - element-number type interpretation - -------------------------- ------------------ ------------------------------------------------------ - -1 `LIST` transcript channel(s) (see below) + ------------------------------------------------------------------------------------- + element-number type interpretation + ---------------- ------------- ------------------------------------------------------ + -1 `LIST` transcript channel(s) (see below) - \* 0 varies device-dependent information + \* 0 varies device-dependent information - \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20), `0` - for internal or closed + \* 1 `FIX` channel number (ITS) or JFN (Tenex and Tops-20), `0` + for internal or closed - \* 2 `STRING` mode + \* 2 `STRING` mode - \* 3 `STRING` first file name argument + \* 3 `STRING` first file name argument - \* 4 `STRING` second file name argument + \* 4 `STRING` second file name argument - \* 5 `STRING` device name argument + \* 5 `STRING` device name argument - \* 6 `STRING` directory name argument + \* 6 `STRING` directory name argument - \* 7 `STRING` real first file name + \* 7 `STRING` real first file name - \* 8 `STRING` real second file name + \* 8 `STRING` real second file name - \* 9 `STRING` real device name + \* 9 `STRING` real device name - \* 10 `STRING` real directory name + \* 10 `STRING` real directory name - \* 11 `FIX` various status bits + \* 11 `FIX` various status bits - \* 12 `FIX` PDP-10 instruction used to do one I/O operation + \* 12 `FIX` PDP-10 instruction used to do one I/O operation - 13 `FIX` number of characters per line of output + 13 `FIX` number of characters per line of output - 14 `FIX` current character position on a line + 14 `FIX` current character position on a line - 15 `FIX` number of lines per page + 15 `FIX` number of lines per page - 16 `FIX` current line number on a page + 16 `FIX` current line number on a page - 17 `FIX` access pointer for file-oriented devices + 17 `FIX` access pointer for file-oriented devices - 18 `FIX` radix for `FIX` conversion + 18 `FIX` radix for `FIX` conversion - 19 `FIX` sink for an internal `CHANNEL` - ---------------------------------------------------------------------------------------------------- + 19 `FIX` sink for an internal `CHANNEL` + ------------------------------------------------------------------------------------- N.B.: The elements of a `CHANNEL` below number 1 are usually invisible but are obtainable via ` fix>`, for some appropriate @@ -8400,9 +8399,9 @@ when space becomes full varies, as discussed below. Most storage used explicitly by Muddle programs is obtained from a pool of free storage managed by a "garbage collector". Storage is -obtained from this pool by the `SUBR`s which construct objects. When a -`SUBR` finds that the pool of available storage is exhausted, it -automatically calls the garbage collector. +obtained from this pool by the `SUBR`s which construct objects. When +such a `SUBR` finds that the pool of available storage is exhausted, +it automatically calls the garbage collector. The garbage collector has two algorithms available to it: the "copying" algorithm, which is used by default, and the "mark-sweep" @@ -8431,7 +8430,7 @@ Only when the total system resources are exhausted will you finally lose. Thus, if you just "forget about" an object, that is, lose all possible -means of referencing it, its storage is automatically reclaimed. +means of referencing it, its storage area is automatically reclaimed. "Object" in this context includes that stack-structured storage space used in `PROCESS`es for functional application. @@ -8556,8 +8555,9 @@ becomes full, Muddle goes through the following procedure: 5. Finally, the "mark-sweep" algorithm sweeps through the storage space, adding unmarked objects to the internal free lists for later re-use. The "copying" algorithm maps the inferior process's - address space into Muddle's own, replacing old garbagey with the - new compact storage, and the inferior process is destroyed. + address space into Muddle's own, replacing old garbagey storage + with the new compact storage, and the inferior process is + destroyed. 22.5 GC ------- @@ -8566,24 +8566,44 @@ becomes full, Muddle goes through the following procedure: causes the garbage collector to run and returns the total number of words of storage reclaimed. All of its arguments are optional: if they -are not supplied, a call to GC simply causes a "copying" garbage +are not supplied, a call to `GC` simply causes a "copying" garbage collection. If *min* is explicitly supplied as an argument, a garbage-collection parameter is changed permanently before the garbage collector runs. *min* is the smallest number of words of "free" (unclaimed, available for use) movable garbage-collected storage the garbage collector will -be satisfied with having after it is done. Initially it is 8192 words. -If the total amount of reclaimed storage is less than *min*, the -garbage collector will ask the operating system for enough storage (in -1024 word blocks) to make it up. N.B.: the system may be incivil -enough not to grant the request; in that case, the garbage collector -will be content with what it has, **unless** that is not enough to -satisfy a **pending** request for storage. Then it will inform you -that it is losing. A large *min* will result in fewer total garbage -collections, but they will take longer since the total quantity of -storage to be dealt with will generally be larger. Smaller *min*s -result in shorter, more frequent garbage collections. +be satisfied with having after it is done each time. Initially it is +8192 words. If the total amount of reclaimed storage is less than +*min*, the garbage collector will ask the operating system for enough +storage (in 1024-word blocks) to make it up. N.B.: the system may be +incivil enough not to grant the request; in that case, the garbage +collector will be content with what it has, **unless** that is not +enough to satisfy a **pending** request for storage. Then it will +inform you that it is losing. A large *min* will result in fewer total +garbage collections, but they will take longer since the total +quantity of storage to be dealt with will generally be larger. Smaller +*min*s result in shorter, more frequent garbage collections. + +*exh?* tells whether or not this garbage collection should be +"exhaustive". It is optional, a `FALSE` by default. The difference +between normal and exhaustive "copying" garbage collections is whether +certain kinds of storage that require complicated treatment (for +example, associations) are reclaimed. An exhaustive garbage collection +occurs every eighth time that the "copying" algorithm is used, or when +`GC` is called with this argument true, or when a normal garbage +collection cannot satisfy the storage request. + +*ms-freq* gives the number of times the "mark-sweep" algorithm should +be used hereafter for every time the normal "copying" algorithm is +used. Giving `0` for *ms-freq* means never to use the "mark-sweep" +algorithm, and giving ` FIX>` means (effectively) always +to use it. The "mark-sweep" algorithm uses considerably less processor +time than the "copying" algorithm, but it never shrinks the +free-storage pool, and in fact the pool can become fragmented. The +"mark-sweep" algorithm could be useful in a program system (such as +the compiler) where the size of the pool rarely changes, but objects +are created and thrown away continuously. 22.6. BLOAT ----------- @@ -8624,8 +8644,8 @@ by default), and indicate the following: `READ`ing large `STRING`s, and calling routines within the interpreter and compiled programs) -Arguments on the second line are also `FIX` and optional, but they set -garbage-collection parameters permanently, as follows: +Arguments on the second line above are also `FIX` and optional, but +they set garbage-collection parameters permanently, as follows: - *min*: as for `GC` - *plcl*: number of slots for `LVAL`s added when the space for @@ -8694,7 +8714,7 @@ about certain areas of storage. In detail: 22.8. GC-MON ------------ - + ("garbage-collector monitor") determines whether or not the interpreter will hereafter print information on the terminal when a @@ -8720,7 +8740,7 @@ of `GIN` and `GOUT`. Two `SUBR`s, described next, use only part of the garbage-collector algorithm, in order to find all pointers to an object. `GC-DUMP` and `GC-READ`, as their names imply, also use part in order to translate -between Muddle objects and binary representation thereof. +between Muddle objects and binary representations thereof. ### 22.9.1. SUBSTITUTE @@ -8735,7 +8755,7 @@ the few legitimate uses for it is to substitute the "right" `ATOM` for the "wrong" one, after `OBLIST`s have been in the wrong state. This is more or less the way `ATOM`s are impurified. It is also useful for unlinking `RSUBR`s. `SUBSTITUTE` returns *old* as a favor: unless you -hang onto *old* at that point, it will be garbage-collected. +hang onto *old* at that point, it will be garbage. 22.9.2 PURIFY -------------