joec@Morgan.COM (Joe Collins) (04/24/89)
A comment on how APL used to handle )SYMBOLS and the workspace in general and thus why )SYMBOLS was fixed in size and did not expand/contract dynamically. In the olden days of APL (certainly pre-APL2 and even older), the workspace was organized thusly: ---top-of-memory--- +-------------------------+ | symbol table | fixed by user | AREA-A | +-------------------------+ | R13 Stack | varies with execution | grows | down | | \|/ | | AREA-B | |-- -- -- -- -- -- -- -- -+ | |shrinks/grows based on | QUAD WA, i.e. |area above and area below | unused |activity level. | AREA-C | |- -- -- -- -- -- -- -- --+ | functions, variables |Varies by user | and other visible | | items. Grows UP | | AREA-D | +-------------------------+ | | | workspace management |Fixed in size. Set by | area, i.e. input buffer |APL, somewhat controllable | QUAD PP, QUAD PW, QUAD |by user. | IO settings, other items| | like wsid, error recovry| | info, and the like. | | AREA-E | +-------------------------+ ---bottom-of-memory--- Area-a is set by )SYMBOLS command. Area-e was set in size by the designers of apl. Area B,D are empty in a )CLEAR ws and Area D grows as objects are )copied or otherwise created. Area B grows as functions execute, i.e. mapping of locals, temporaries within apl expressions, etc. The reason the stack had to be clear when executing )SYMBOLS N was that the R13 STACK (area B) had to be relocated down (taking up QUAD WA). Some APLs were more restricted in that the ws had to be clear - I don't know why except perhaps the symbol table had a complex pointer technique. Anyway, in a design like this, the R13 stack (area-b) grew down from the top and the objects (area-d) grew up from the bottom, leaving QUAD wa in the middle. WS Full meant the top and bottom met (after a garbage collect), i.e. no more room. To have )SYMBOLS be dynamic requires a more complex design overall and the early designers of APL kept this simple scheme for many years. If it were dynamic, symbol table searches might be less efficient (remember, the apl expressions containing symbols pointed to the symbol table internally, not the data - if it moved, all sorts of havoc would result). Anyone know how more recent APLs handle this? I know APL2 allows the symbol table to expand automatically, although they say its more efficient to run with a larger symbol table to start off, even though it consumes quad wa. regards, joec@morgan.com