|
|
1.1 root 1:
2:
3:
4:
5:
6:
7:
8: CHAPTER 13
9:
10:
11: The CMU User Toplevel and the File Package
12:
13:
14:
15: This documentation was written by Don Cohen, and the func-
16: tions described below were imported from PDP-10 CMULisp.
17:
18: _N_o_n _C_M_U _u_s_e_r_s _n_o_t_e: this is not the default top level for
19: your Lisp system. In order to start up this top level, you
20: should type (_l_o_a_d '_c_m_u_e_n_v).
21:
22:
23:
24:
25: 13.1. User Command Input Top Level
26:
27: The top-level is the function that reads what you
28: type, evaluates it and prints the result. The _n_e_w_l_i_s_p
29: top-level was inspired by the CMULisp top-level (which
30: was inspired by interlisp) but is much simpler. The
31: top-level is a function (of zero arguments) that can
32: be called by your program. If you prefer another
33: top-level, just redefine the top-level function and
34: type "(reset)" to start running it. The current top-
35: level simply calls the functions tlread, tleval and
36: tlprint to read, evaluate and print. These are sup-
37: posed to be replaceable by the user. The only one
38: that would make sense to replace is tlprint, which
39: currently uses a function that refuses to go below a
40: certain level and prints "...]" when it finds itself
41: printing a circular list. One might want to pretty-
42: print the results instead. The current top-level
43: numbers the lines that you type to it, and remembers
44: the last n "events" (where n can be set but is
45: defaulted to 25). One can refer to these events in
46: the following "top-level commands":
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60: 9
61:
62: 9The CMU User Toplevel and the File Package 13-1
63:
64:
65:
66:
67:
68:
69:
70: The CMU User Toplevel and the File Package 13-2
71:
72:
73:
74: ____________________________________________________
75:
76: _T_O_P_L_E_V_E_L _C_O_M_M_A_N_D _S_U_M_M_A_R_Y
77:
78: ?? prints events - both the input and the result. If you just type
79: "??" you will see all of the recorded events. "?? 3" will show
80: only event 3, and "?? 3 6" will show events 3 through 6.
81:
82: redo pretends that you typed the same thing that was typed before. If
83: you type "redo 3" event number 3 is redone. "redo -3" redoes the
84: thing 3 events ago. "redo" is the same as "redo -1".
85:
86: ed calls the editor and then does whatever the editor returns. Thus
87: if you want to do event 5 again except for some small change, you
88: can type "ed 5", make the change and leave the editor. "ed -3"
89: and "ed" are analogous to redo.
90: ____________________________________________________
91:
92:
93:
94: Finally, you can get the value of event 7 with the function
95: (valueof 7). The other interesting feature of the top-level
96: is that it makes outermost parentheses superfluous for the
97: most part. This works the same way as in CMULisp, so you
98: can use the help for an explanation. If you're not sure and
99: don't want to risk it you can always just include the
100: parentheses.
101:
102:
103: (top-level)
104:
105: SIDE EFFECT: _t_o_p-_l_e_v_e_l is the LISP top level function.
106: As well as being the top level function
107: with which the user interacts, it can be
108: called recursively by the user or any
109: function. Thus, the top level can be
110: invoked from inside the editor, break
111: package, or a user function to make its
112: commands available to the user.
113:
114: NOTE: The CMU FRANZ LISP top-level uses _l_i_n_e_r_e_a_d
115: rather than _r_e_a_d. The difference will not usu-
116: ally be noticeable. The principal thing to be
117: careful about is that input to the function or
118: system being called cannot appear on the same
119: line as the top-level call. For example, typing
120: (_e_d_i_t_f _f_o_o)_f_P _o_n _o_n_e _l_i_n_e _w_i_l_l _e_d_i_t _f_o_o _a_n_d
121: _e_v_a_l_u_a_t_e _P, _n_o_t _e_d_i_t _f_o_o _a_n_d _e_x_e_c_u_t_e _t_h_e _p _c_o_m_-
122: _m_a_n_d _i_n _t_h_e _e_d_i_t_o_r. _t_o_p-_l_e_v_e_l _s_p_e_c_i_a_l_l_y _r_e_c_o_g_-
123: _n_i_z_e_s _t_h_e _f_o_l_l_o_w_i_n_g _c_o_m_m_a_n_d_s:
124:
125: 9
126:
127: 9 Printed: July 21, 1983
128:
129:
130:
131:
132:
133:
134:
135: The CMU User Toplevel and the File Package 13-3
136:
137:
138: (valueof '_g__e_v_e_n_t_s_p_e_c)
139:
140: RETURNS: the value(s) of the event(s) specified by
141: g_eventspec. If a single event is specified,
142: its value will be returned. If more than one
143: event is specified, or an event has more than
144: one subevent (as for _r_e_d_o, etc), a list of
145: vlaues will be returned.
146:
147:
148:
149:
150: 13.2. The File Package
151:
152: Users typically define functions in lisp and then want
153: to save them for the next session. If you do
154: (_c_h_a_n_g_e_s), a list of the functions that are newly
155: defined or changed will be printed. When you type
156: (_d_s_k_o_u_t_s), the functions associated with files will be
157: saved in the new versions of those files. In order to
158: associate functions with files you can either add them
159: to the _f_i_l_e_f_n_s list of an existing file or create a
160: new file to hold them. This is done with the _f_i_l_e
161: function. If you type (_f_i_l_e _n_e_w) the system will
162: create a variable called _n_e_w_f_n_s. You may add the
163: names of the functions to go into that file to _n_e_w_f_n_s.
164: After you do (_c_h_a_n_g_e_s), the functions which are in no
165: other file are stored in the value of the atom
166: _c_h_a_n_g_e_s. To put these all in the new file, (_s_e_t_q
167: _n_e_w_f_n_s (_a_p_p_e_n_d _n_e_w_f_n_s _c_h_a_n_g_e_s)). Now if you do
168: (_c_h_a_n_g_e_s), all of the changed functions should be
169: associated with files. In order to save the changes
170: on the files, do (_d_s_k_o_u_t_s). All of the changed files
171: (such as NEW) will be written. To recover the new
172: functions the next time you run FRANZ LISP, do (_d_s_k_i_n
173: _n_e_w).
174:
175:
176:
177:
178:
179:
180:
181:
182:
183:
184:
185:
186:
187:
188:
189:
190: 9
191:
192: 9 Printed: July 21, 1983
193:
194:
195:
196:
197:
198:
199:
200: The CMU User Toplevel and the File Package 13-4
201:
202:
203:
204: ____________________________________________________
205:
206: Script started on Sat Mar 14 11:50:32 1981
207: $ newlisp
208: Welcome to newlisp...
209: 1.(defun square (x) (* x x)) ; define a new function
210: square
211: 2.(changes) ; See, this function is associated
212: ; with no file.
213: <no-file> (square)nil
214: 3.(file 'new) ; So let's declare file NEW.
215: new
216: 4.newfns ; It doesn't have anything on it yet.
217: nil
218: 5.(setq newfns '(square)) ; Add the function associated
219: (square) ; with no file to file NEW.
220: 6.(changes) ; CHANGES magically notices this fact.
221:
222: new (square)nil
223: 7.(dskouts) ; We write the file.
224: creating new
225: (new)
226: 8.(dskin new) ; We read it in!
227: (new)
228: 14.Bye
229: $
230: script done on Sat Mar 14 11:51:48 1981
231:
232: ____________________________________________________
233:
234:
235:
236:
237:
238: (changes s_flag)
239:
240: RETURNS: Changes computes a list containing an entry
241: for each file which defines atoms that have
242: been marked changed. The entry contains the
243: file name and the changed atoms defined
244: therein. There is also a special entry for
245: changes to atoms which are not defined in any
246: known file. The global variable _f_i_l_e_l_s_t con-
247: tains the list of "known" files. If no flag
248: is passed this result is printed in human
249: readable form and the value returned is t if
250: there were any changes and nil if not. Other-
251: wise nothing is printed and the computer list
252: is returned. The global variable _c_h_a_n_g_e_s con-
253: tains the atoms which are marked changed but
254: not yet associated with any file. The _c_h_a_n_g_e_s
255: function attempts to associate these names
256:
257:
258: Printed: July 21, 1983
259:
260:
261:
262:
263:
264:
265:
266: The CMU User Toplevel and the File Package 13-5
267:
268:
269: with files, and any that are not found are
270: considered to belong to no file. The _c_h_a_n_g_e_s
271: property is the means by which changed func-
272: tions are associated with files. When a file
273: is read in or written out its _c_h_a_n_g_e_s property
274: is removed.
275:
276: (dc s_word s_id [ g_descriptor1 ... ] <text> <esc>)
277:
278: RETURNS: _d_c defines comments. It is exceptional in
279: that its behavior is very context dependent.
280: When _d_c is executed from _d_s_k_i_n it simply
281: records the fact that the comment exists. It
282: is expected that in interactive mode comments
283: will be found via _g_e_t_d_e_f - this allows large
284: comments which do not take up space in your
285: core image. When _d_c is executed from the ter-
286: minal it expects you to type a comment. _d_s_k_o_u_t
287: will write out the comments that you define
288: and also copy the comments on the old version
289: of the file, so that the new version will keep
290: the old comments even though they were never
291: actually brought into core. The optional id
292: is a mechanism for distinguishing among
293: several comments associated with the same
294: word. It defaults to nil. However if you
295: define two comments with the same id, the
296: second is considered to be a replacement for
297: the first. The behavior of _d_c is determined by
298: the value of the global variable _d_e_f-_c_o_m_m_e_n_t.
299: _d_e_f-_c_o_m_m_e_n_t contains the name of a function
300: that is run. Its arguments are the word, id
301: and attribute list. _d_e_f-_c_o_m_m_e_n_t is initially
302: _d_c-_d_e_f_i_n_e. Other functions rebind it to _d_c-
303: _h_e_l_p, _d_c-_u_s_e_r_h_e_l_p, and the value of _d_s_k_i_n-
304: _c_o_m_m_e_n_t. The comment property of an atom is a
305: list of entries, each representing one com-
306: ment. Atomic entries are assumed to be iden-
307: tifiers of comments on a file but not in core.
308: In-core comments are represented by a list of
309: the id, the attribute list and the comment
310: text. The comment text is an uninterned atom.
311: Comments may be deleted or reordered by edit-
312: ing the comment property.
313:
314:
315:
316:
317:
318:
319:
320:
321: 9
322:
323: 9 Printed: July 21, 1983
324:
325:
326:
327:
328:
329:
330:
331: The CMU User Toplevel and the File Package 13-6
332:
333:
334: (dskin l_filenames)
335:
336: SIDE EFFECT: READ-EVAL-PRINTs the contents of the
337: given files. This is the function to use
338: to read files created by _d_s_k_o_u_t. _d_s_k_i_n
339: also declares the files that it reads (if
340: a _f_i_l_e-_f_n_s list is defined and the file is
341: otherwise declarable by _f_i_l_e ), so that
342: changes to it can be recorded.
343:
344:
345: (dskout s_file1 ...)
346:
347: SIDE EFFECT: For each file specified, _d_s_k_o_u_t assumes
348: the list named filenameFNS (i.e., the
349: file name, excluding extension, con-
350: catenated with _f_n_s ) contains a list
351: of function names, etc., to be loaded Any
352: previous version of the file will be
353: renamed to have extension ".back".
354:
355: (dskouts s_file1 ...)
356:
357: SIDE EFFECT: applies _d_s_k_o_u_t to and prints the name of
358: each s_filei (with no additional
359: arguments, assuming filenameFNS to be a
360: list to be loaded) for which s_file_i is
361: either not in _f_i_l_e_l_s_t (meaning it is a
362: new file not previously declared by _f_i_l_e
363: or given as an argument to _d_s_k_i_n,
364: _d_s_k_o_u_t_s, or _d_s_k_o_u_t_s) or is in _f_i_l_e_l_s_t and
365: has some recorded changes to definitions
366: of atoms in filenameFNS, as recorded by
367: _m_a_r_k!_c_h_a_n_g_e_d and noted by changes. If
368: _f_i_l_ei is not specified, _f_i_l_e_l_s_t will be
369: used. This is the most common way of
370: using dskouts. Typing (_d_s_k_o_u_t_s) will
371: save every file reported by (_c_h_a_n_g_e_s)
372: to have changed definitions.
373:
374:
375: (dv s_atom g_value)
376:
377: EQUIVALENT TO: (_s_e_t_q _a_t_o_m '_v_a_l_u_e). _d_v calls
378: _m_a_r_k!_c_h_a_n_g_e_d.
379:
380:
381:
382:
383:
384:
385:
386: 9
387:
388: 9 Printed: July 21, 1983
389:
390:
391:
392:
393:
394:
395:
396: The CMU User Toplevel and the File Package 13-7
397:
398:
399: (file 's_file)
400:
401: SIDE EFFECT: declares its argument to be a file to be
402: used for reporting and saving changes to
403: functions by adding the file name to a
404: list of files, _f_i_l_e_l_s_t. _f_i_l_e is called
405: for each file argument of _d_s_k_i_n, _d_s_k_o_u_t,
406: and _d_s_k_o_u_t_s.
407:
408: (file-fns 's_file)
409:
410: RETURNS: the name of the fileFNS list for its file
411: argument s_file.
412:
413: (getdef 's_file ['s_i1 ...])
414:
415: SIDE EFFECT: selectively executes definitions for atoms
416: s_i1 ... from the specified file. Any of
417: the words to be defined which end with "@"
418: will be treated as patterns in which the @
419: matchs any suffix (just like the editor).
420: _g_e_t_d_e_f is driven by _g_e_t_d_e_f_t_a_b_l_e (and thus
421: may be programmed). It looks for lines in
422: the file that start with a word in the
423: table. The first character must be a "("
424: or "[" followed by the word, followed by a
425: space, return or something else that will
426: not be considered as part of the identif-
427: ier by _r_e_a_d, e.g., "(" is unacceptable.
428: When one is found the next word is read.
429: If it matches one of the identifiers in
430: the call to _g_e_t_d_e_f then the table entry is
431: executed. The table entry is a function
432: of the expression starting in this line.
433: Output from _d_s_k_o_u_t is in acceptable format
434: for _g_e_t_d_e_f. _g_e_t_d_e_f
435:
436: RETURNS: a list of the words which match the ones it
437: looked for, for which it found (but, depending
438: on the table, perhaps did not execute) in the
439: file.
440:
441: NOTE: _g_e_t_d_e_f_t_a_b_l_e is the table that drives _g_e_t_d_e_f. It
442: is in the form of an association list. Each ele-
443: ment is a dotted pair consisting of the name of a
444: function for which _g_e_t_d_e_f searches and a function
445: of one argument to be executed when it is found.
446:
447:
448:
449:
450:
451: 9
452:
453: 9 Printed: July 21, 1983
454:
455:
456:
457:
458:
459:
460:
461: The CMU User Toplevel and the File Package 13-8
462:
463:
464: (mark!changed 's_f)
465:
466: SIDE EFFECT: records the fact that the definition of
467: s_f has been changed. It is automatically
468: called by _d_e_f, _d_e_f_u_n, _d_e, _d_f, _d_e_f_p_r_o_p, _d_m,
469: _d_v, and the editor when a definition is
470: altered.
471:
472:
473:
474:
475:
476:
477:
478:
479:
480:
481:
482:
483:
484:
485:
486:
487:
488:
489:
490:
491:
492:
493:
494:
495:
496:
497:
498:
499:
500:
501:
502:
503:
504:
505:
506:
507:
508:
509:
510:
511:
512:
513:
514:
515:
516: 9
517:
518: 9 Printed: July 21, 1983
519:
520:
521:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.