![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to lispnews CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 42BSD / ucb / lisp|
Return to lispnews CVS log | Up to [CSRG BSD Unix] / 42BSD / ucb / lisp |
1.1 root 1: From jkf Tue Apr 13 00:12:22 1982
2: To: /na/doe/jkf/lispnews
3: Subject: new features
4: Status: RO
5:
6: In response to requests from franz users, these enhancements have been
7: made:
8:
9: In Lisp 38.07, if the lisp variable 'displace-macros' is set to non-nil,
10: then when a macro expansion is done by the evaluator, the resulting
11: expansion replaces the original call. This means that macro expansion
12: is only done once.
13:
14: In Liszt 8.03, the 'function' function is open coded. If you have
15: (function (lambda ....))
16: in your code then the lambda expression is compiled as a separate function
17: and the result of the function call is a 'bcd' object which points
18: to that compiled lambda.
19:
20:
21:
22: From jkf Sun Apr 18 13:16:46 1982
23: To: local-lisp
24: Subject: opus 38.09
25: Status: RO
26:
27: The new features of this version are:
28: If the load function ends up fasl'ing in a file, then load will
29: do what is necessary to insure that the new functions are linked in
30: correctly. Previously, if you turned on the transfer tables with
31: (sstatus translink on) or (sstatus translink t) and then fasl'ed in
32: functions which already existed, the old versions of the functions
33: would still be used, unless you did (sstatus translink on) yourself.
34: Now this is done automatically.
35:
36: tyi now accepts a second argument which is the object to return
37: upon eof. -1 is the default.
38:
39: (pp-form 'g_obj ['p_port]) should be used instead of $prpr
40: for pretty printing a form.
41:
42: The storage allocator and collector has been modified to add
43: two new data types: vector and vector immediate. They are not in
44: their final form so I suggest that you not try to use them.
45: However, be on the lookout for garbage collection bugs.
46:
47:
48:
49: From jkf Wed Apr 21 07:45:54 1982
50: To: local-lisp
51: Subject: liszt 8.04
52: Status: RO
53:
54: the new features of liszt 8.04 are:
55:
56: 1) init files:
57: Before liszt begins compiling, it looks for an init file to load in.
58: It first searches in the current directory, and then it searches
59: your home directory (getenv 'HOME).
60: It looks for file names:
61: .lisztrc.o .lisztrc.l lisztrc.o lisztrc.l
62: It loads only the first one it finds.
63:
64: 2) interrupt handling
65: If you interrupt liszt (with ^C typically), it will remove its
66: temporary file and exit.
67:
68: 3) preallocation of space
69: It preallocates space in order to reduce the number of gc's done
70: during compiling.
71:
72:
73:
74:
75:
76: From jkf Wed Apr 21 13:47:50 1982
77: To: local-lisp
78: Subject: lisp opus 38.10
79: Status: RO
80:
81: lisp will now look for a lisprc in a way similar to liszt.
82:
83: It will first search in . and then in $HOME
84: It will look for the file .lisprc or lisprc ending with .o, .l and then
85: just .lisprc or lisprc.
86:
87: Shortly, it will only look for files ending in .l and .o since we don't
88: want to encourage files with non-standard filename extensions.
89:
90:
91:
92:
93:
94: From jkf Wed Apr 21 23:40:59 1982
95: To: local-lisp
96: Subject: lisp opus 38.11
97: Status: RO
98:
99: I finally got sick of showstack and baktrace and rewrote them in lisp,
100: rincorporating some of the features people have been requesting.
101: Showstack now works as follows:
102: (showstack) : show all interesting forms. Forms resulting from
103: the trace package are not printed as well as
104: extraneous calls to eval. In the form printed,
105: the special form <**> means 'the previous expression
106: printed'. prinlevel and prinlength are set to
107: reasonable values to prevent the expression from
108: getting too large
109: (showstack t) : same as above but print all expressions.
110: (showstack 5) : print only the first 5 expressions. of course, 5
111: is not the only possible numeric argument.
112: (showstack lev 3) : set prinlevel to 3 before printing
113: (showstack len 4) : set prinlength to 4 before printing
114: the above arguments can be used in combination.
115:
116: The default value of prinlevel is showstack-prinlevel, that of prinlength
117: is showstack-prinlength. the default showstack printer is the
118: value of showstack-printer (default is 'print').
119:
120: baktrace accepts the same arguments as showstack, but it ignores the
121: prinlevel and prinlength arguments.
122:
123:
124:
125:
126: From jkf Sat Apr 24 08:55:18 1982
127: To: local-lisp
128: Subject: lisp opus 38.12, liszt 8.05
129: Status: RO
130:
131: these changes and enhancements were made:
132:
133: 1) the function 'function' in the interpreter acts just like 'quote'
134: In the compiler, 'function' will act like 'quote' unless the
135: argument is a lambda expression, in which case liszt will replace
136: the lambda expression with a unique symbol. That unique symbol's
137: function cell will contain a compiled version of the lambda
138: expression. These changes will make Franz compatible with Maclisp
139: type lisps, as far as the treatment of 'function'
140:
141: 2) Mechanisms were added to permit user written C or Fortran code to call
142: lisp code. Everything isn't quite ready yet.
143:
144: 3) Signal was fixed so that if you ask for a signal to be ignored, the
145: operating system will be notified. The correct way to fork a lisp
146: is now:
147: (cond ((fork) (signal 2 (prog1 (signal 2) (wait)))))
148:
149: 4) You can select the default function trace uses to print the arguments and
150: results. Just lambda bind trace-printer to the name of the function
151: you want it to use. The standard trace-printer sets prinlevel and
152: prinlength to the values of trace-prinlevel and trace-prinlength before
153: printing. By default, trace-prinlevel is 4, and trace-prinlength is 5
154:
155:
156:
157:
158:
159: From jkf Sun Apr 25 23:46:16 1982
160: To: local-lisp
161: Subject: lisp opus 38.13
162: Status: RO
163:
164: Functions 1+ and 1- are now part of the interpreter, rather than
165: being made equivalent to add1 and sub1.
166:
167:
168:
169: From jkf Wed Apr 28 09:52:43 1982
170: To: local-lisp
171: Subject: Opus 38.14
172: Status: RO
173:
174: Has these new features:
175: 1) the message [load filename] will appear before load
176: reads in a lisp source file. This can be disabled by
177: setting $ldprint to nil.
178: 2) a function 'truename' as been added. It takes a port
179: and returns the name of the file associated with that port.
180: It returns a string if there is a file associated with
181: the port, otherwise it returns nil.
182:
183:
184:
185: From jkf Wed Apr 28 10:36:34 1982
186: To: local-lisp
187: Subject: more on opus 38.14
188: Status: RO
189:
190: $ldprint is lambda bound to nil during the loading of the lisprc file.
191:
192:
193:
194:
195: From jkf Wed May 5 08:30:00 1982
196: To: local-lisp
197: Subject: opus 38.15
198: Status: RO
199:
200: a minor modification: 'makhunk' is now more efficient.
201:
202:
203: From jkf Wed May 5 20:56:40 1982
204: To: local-lisp
205: Subject: Opus 38.16
206: Status: RO
207:
208: A new function was added:
209: (hunk-to-list 'h_hunk)
210: returns the elements of h_hunk as a list.
211:
212: Also, the error message printed when an oversized print name is encountered
213: has been improved.
214:
215:
216:
217: From jkf Fri May 7 20:03:40 1982
218: To: local-lisp
219: Subject: Liszt version 8.06
220: Status: RO
221:
222:
223: Local declarations are now supported. You can say:
224: (defun foo (a b)
225: (declare (special a))
226: ... body ...)
227:
228: and the special declaration for 'a' will affect the body of function
229: foo only. The 'a' which is an argument to foo will also be special
230: in this case. Declarations may be
231: 1) at the top level, not within a function body.
232: 2) at the beginning of a 'lambda' body.
233: 3) at the beginning of a 'prog' body
234: 4) at the beginning of a 'do' body.
235:
236: 'the beginning' means either the first, second or third form in the body.
237: When the compiler is searching for declarations, it will not macroexpand.
238:
239:
240: Fixnum declarations now have meaning. If you do
241: (declare (fixnum i j))
242: then
243: (greaterp i j) will be converted to (>& i j)
244:
245: The declare function is now defined in the compiler. Previously,
246: the only way to declare something was for the compiler to 'compile'
247: the declaration form. Now, if you load or fasl in a file with
248: a declare statement in it, the declare statement will have the
249: proper effect in the compiler.
250:
251:
252: (function (lambda () ...)), (function (nlambda () ...)) and
253: (function (lexpr () ...)) are all supported.
254:
255:
256:
257: From jkf Wed May 12 08:15:37 1982
258: To: local-lisp
259: Subject: Lisp Opus 38.17
260: Status: RO
261:
262: ... has a minor bug fix: The port returned by 'fileopen' will now print
263: correctly.
264:
265:
266:
267: From jkf Tue May 25 06:18:04 1982
268: Date: 25-May-82 06:17:51-PDT (Tue)
269: From: jkf
270: Subject: opus 38.18
271: Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue)
272: To: local-lisp
273: Status: RO
274:
275: The msg macro will now evaluate all atom arguments except the ones
276: for carriage control (N B). Thus if you used (msg foo) you should
277: now use (msg "foo").
278:
279:
280:
281: From jkf Thu May 27 08:29:29 1982
282: To: local-lisp
283: Subject: liszt 8.08
284: Status: RO
285:
286: Fixes a bug in the code which converts generic arithmetic to fixnum only
287: arithmetic. Liszt was converting from generic to fixnum operators based on
288: the first argument only due to a typo in the code.
289:
290:
291:
292:
293: From jkf Wed Jun 9 07:25:19 1982
294: To: local-lisp
295: Subject: lisp Opus 38.20
296: Status: RO
297:
298: There is now a character macro for reading hexadecimal.
299: #x1f = #X1f = #X1F = 31
300: #x-1f = -31
301:
302:
303:
304: From jkf Thu Jun 17 15:42:54 1982
305: To: local-lisp
306: Subject: Lisp Opus 38.21
307: Status: RO
308:
309: Has two routines for interfacing with termcap. These routines were
310: written by morris djavaher and are meant to be called by lisp programs
311: which have yet to be installed.
312:
313:
314:
315:
316: From jkf Tue Jun 22 09:09:25 1982
317: Date: 22-Jun-82 09:09:13-PDT (Tue)
318: From: jkf
319: Subject: opus 38.22
320: Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue)
321: To: local-lisp
322: Status: RO
323:
324: setq with no arguments will now return nil.
325:
326:
327:
328: From jkf Wed Jun 30 19:05:54 1982
329: Date: 30-Jun-82 19:05:32-PDT (Wed)
330: From: jkf (John Foderaro)
331: Subject: liszt 8.09
332: Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed)
333: To: local-lisp
334: Status: RO
335:
336: liszt will now look in 12 places for an init file when it starts up.
337: It will load in the first one it comes to only.
338: The files it looks for are:
339:
340: { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , }
341:
342:
343:
344:
345: From jkf Tue Sep 14 08:53:03 1982
346: Date: 14-Sep-82 08:52:44-PDT (Tue)
347: From: jkf (John Foderaro)
348: Subject: lisp opus 38.26
349: Message-Id: <[email protected]>
350: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999;
351: 14-Sep-82 08:53:03-PDT (Tue)
352: To: local-lisp
353: Status: RO
354:
355: Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx. Now it reads
356: them (and other similar symbols) correctly.
357:
358:
359:
360:
361: From jkf Sat Oct 2 15:15:48 1982
362: Date: 2-Oct-82 15:15:32-PDT (Sat)
363: From: jkf (John Foderaro)
364: Subject: lisp opus 38.27
365: Message-Id: <[email protected]>
366: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796;
367: 2-Oct-82 15:15:48-PDT (Sat)
368: To: local-lisp
369: Status: RO
370:
371: If you set the variable top-level-print to a non nil value, then that
372: value will be used by the top-level to print out the result of the
373: evaluation. This has effect in break loops too.
374: For example, if you want the pretty printer to print out the top level
375: values, type (setq top-level-print 'pp-form).
376:
377:
378:
379:
380:
381: From jkf Sun Oct 3 19:28:45 1982
382: Date: 3-Oct-82 19:28:29-PDT (Sun)
383: From: jkf (John Foderaro)
384: Subject: lisp opus 38.28
385: Message-Id: <[email protected]>
386: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829;
387: 3-Oct-82 19:28:45-PDT (Sun)
388: To: local-lisp
389: Status: RO
390:
391: A modification has been made to the load function.
392: Normally if you type (load 'x), the load function will first try to fasl
393: the file x.o and failing that it will try to load x.l
394: If you (setq load-most-recent t), and if x.l and x.o both exist, then
395: load will fasl or load the most recently modified file.
396: The load-most-recent flag only has an effect if you type the filename
397: without a trailing .l or .o.
398:
399:
400:
401:
402: From jkf Tue Oct 5 21:01:55 1982
403: Date: 5-Oct-82 21:01:33-PDT (Tue)
404: From: jkf (John Foderaro)
405: Subject: liszt 8.12, lisp 38.29
406: Message-Id: <[email protected]>
407: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358;
408: 5-Oct-82 21:01:55-PDT (Tue)
409: To: local-lisp
410: Status: RO
411:
412: Liszt will now check that you are passing the correct number of arguments
413: to functions. As a result, some files which have compiled without
414: complaint in the past may compile now with warnings or errors. In this
415: note, I'll explain what the compiler knows, what it looks for in your
416: program, and how you can help the compiler understand your program.
417:
418: For each function, liszt either knows nothing about the the number of
419: arguments to a function, or it knows the minimum number of arguments, or the
420: maximum number of arguments, or both the minimum and maximum number of
421: arguments. This information comes about in one of three ways:
422: 1) it is known when liszt starts (by virtue of a value stored under the
423: fcn-info indicator on a function's property list)
424: 2) it is declared by the user, either via (declare (*arginfo ...))
425: or (declare (*args ...)) [see below]
426: 3) it is determined when a (lambda) function is compiled.
427: When a lambda is compiled, the compiler can easily figure out the
428: minimum and maximum number of arguments.
429: When an nlambda or lexpr function is compiled, the compiler doesn't
430: make a guess as to how many arguments are expected. The user should
431: use the (declare (*args ...)) form to tell the compiler how many
432: arguments are expected.
433: For lexpr's generated via 'defun' using &optional and &rest keywords,
434: the correct declaration is generated automatically.
435: Once liszt determines the number of arguments to a function, it uses that
436: information to check that the function is called with the correct number of
437: arguments. It does not check calls to the function that occured before it
438: determined the correct number of arguments. [This backward checking will
439: be added sometime in the future.]
440:
441: If liszt finds that a function is called with the wrong number of
442: arguments, it prints an informative message. That message is a error if the
443: function being called is one which is open coded by the compiler. The
444: message is a warning otherwise. The reason for the distinction is that
445: you are free to redefine functions not open coded by the compiler. If the
446: number of arguments is not correct, it may just be that the compiler's
447: database and your code are refering to two different functions.
448: If you redefine system functions, you should use the
449: (declare (*arginfo ...)) form to let the compiler know about the number
450: of arguments expected by your version of the functions.
451:
452: You can declare the number of arguments to functions using this form
453:
454: (declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...))
455: where each min or max is either a fixnum or nil (meaning "I don't know")
456:
457: for example, here are some `correct' declarations:
458:
459: (declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil)))
460:
461: explanation:
462: (read 0 2) means that the function read expects between 0 and 2
463: arguments (inclusive).
464: (cons 2 2) means that cons expects 2 arguments.
465: (boole 3 nil) means that boole expects at least 3 arguments.
466: (append nil nil) means that append expects any number of arguments,
467: this is equivalent to (append 0 nil).
468:
469:
470: The *arginfo declaration is usually made at the top level of a file.
471:
472: To declare the argument characteristics of the current function being
473: compiled use the '*args' declaration. It looks somewhat like the
474: *arginfo declaration.
475:
476: It is best explained with examples
477:
478: (def read
479: (lexpr (n)
480: (declare (*args 0 2))
481: ... code for read
482: ))
483:
484: (def process
485: (nlambda (x)
486: (declare (*args 1 3))
487: ... code for process
488: ))
489:
490: Note: the *args declaration is not needed for lambda's.
491:
492:
493:
494: If you get an error or warning which you believe is incorrect, it is
495: probably due to an incorrect database entry. Please let me know and I will
496: fix it immediately. I expect that there will be quite a few of these
497: errors because much of the database was built by hand.
498:
499:
500:
501:
502:
503:
504: From jkf Fri Oct 8 12:55:45 1982
505: Date: 8-Oct-82 12:55:31-PDT (Fri)
506: From: jkf (John Foderaro)
507: Subject: lisp 38.30, liszt 8.13
508: Message-Id: <[email protected]>
509: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140;
510: 8-Oct-82 12:55:45-PDT (Fri)
511: To: local-lisp
512: Status: RO
513:
514: There are now three new functions for dealing with processes:
515: *process
516: *process-send
517: *process-receive
518:
519: These functions are designed to replace the 'process' function, which, due
520: to its nlambda'ness, was difficult to use. All of the above functions
521: are lambda's or lexpr's.
522:
523: See chapter 6 of the manual (its on-line) for the details of these
524: functions. This is a quick summary:
525:
526: (*process-send 'st_command)
527: tells the shell to run the command st_command concurrently, and returns
528: a write-only port. Characters written to this port will appear at
529: the standard input of st_command.
530: example:
531: (setq p (*process-send "mail jkf"))
532: (print 'HiThere p)
533: (close p)
534:
535:
536: (*process-receive 'st_command)
537: tells the shell to run st_command concurrently, and returns a
538: read-only port. Characters written to the standard output by
539: st_command will be available by reading from the given port.
540: Characters written on the standard error by st_command will
541: appear on lisp's the standard error (the terminal most likely).
542: example:
543: ; to see if foo is logged in:
544: (setq p (*process-receive "u"))
545: (do ((user (read p '**eof**) (read p '**eof**)))
546: ((eq '**eof** user) (print 'Not-Logged-In))
547: (cond ((eq 'foo user) (print 'Is-Logged-In))))
548: (close p)
549:
550:
551: (*process 'st_command ['g_readp ['g_writep]])
552: this is the general function which process, *process-send and
553: *process-receive call. If called with one argument it
554: starts the new process and waits for it to end, e.g:
555: (*process (concat "vi " filename))
556: In this case *process return the exit code of the process.
557:
558: The g_readp and g_writep arguments, if given, tell *process to
559: run the process concurrently. If g_read is non nil then
560: *process will return a port just like *process-receive.
561: If g_writep is non-nil, then *process will set up a pipe like
562: *process-send.
563: *process will return a list of the form
564: (readport writeport process-id)
565: where readport and writeport will only be a port if g_readp
566: or g_writep are non nil.
567:
568:
569: A little know fact about processes is that a process, once started,
570: cannot die and disappear until its parent asks about its status.
571: Take the mail example given above:
572: (setq p (*process-send "mail jkf"))
573: (print 'HiThere p)
574: (close p)
575: after the mail process finishes it work, it will attempt to die, returning
576: an integer called the 'exit status'. However until the lisp program
577: asks about its status the mail process will remain in existence
578: in a Zombie state, somewhere between life and death. ps will show this:
579:
580: PID TT STAT TIME COMMAND
581: 3876 p0 Z 0:01 <exiting>
582:
583: A user is only allowed a small number of processes, so if you continue
584: to generate processes and leave them around as Zombies, you will eventually
585: run out of processes. The way to let the Zombie die is to call
586: the wait function, e.g.
587: -> (wait)
588: (3876 . 0)
589: ->
590: this says that process 3876 died with exit status 0.
591:
592: Also, when you exit lisp the shell will clean up the Zombies.
593:
594: If you start a process with (*process "vi foo") then lisp will wait
595: for it to complete before continuing, so you don't have to worry about
596: Zombies. You only have to worry if you run a process concurrently,
597: such as when you use *process-send or *process-receive.
598:
599:
600:
601:
602:
603:
604:
605: From jkf Tue Oct 12 10:44:22 1982
606: Date: 12-Oct-82 10:43:52-PDT (Tue)
607: From: jkf (John Foderaro)
608: Subject: lisp opus 38.31
609: Message-Id: <[email protected]>
610: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
611: id A29800; 12-Oct-82 10:44:22-PDT (Tue)
612: To: local-lisp
613: Status: RO
614:
615: new function: (time-string ['x_time])
616: if given no arguments, it returns the current time as a string.
617:
618: if given an argument, x_time, then it converts that argument to
619: a time string and returns that string.
620: The argument should represent the number of seconds since
621: Jan 1, 1970 (GMT).
622:
623: note that this makes (status ctime) obsolete.
624:
625:
626:
627: From jkf Tue Oct 12 14:35:26 1982
628: Date: 12-Oct-82 14:34:10-PDT (Tue)
629: From: jkf (John Foderaro)
630: Subject: also in opus 38.31
631: Message-Id: <[email protected]>
632: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
633: id A05086; 12-Oct-82 14:35:26-PDT (Tue)
634: To: local-lisp
635: Status: RO
636:
637: If top-level-read is set to a non nil value, then the lisp
638: top level will funcall it to read a form for evaluation.
639: It will be funcalled with two arguments, a port and an eof marker.
640: top-level-read will be used in break levels too.
641: Be very careful when setting top-level-read because if you set it
642: to an illegal value, there is no way to correct it.
643:
644:
645:
646:
647:
648: From jkf Tue Oct 19 18:54:18 1982
649: Date: 19-Oct-82 18:54:02-PDT (Tue)
650: From: jkf (John Foderaro)
651: Subject: lisp tags
652: Message-Id: <[email protected]>
653: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
654: id A00195; 19-Oct-82 18:54:18-PDT (Tue)
655: To: franz-friends
656: Status: RO
657:
658: We also use vi style tags so emacs users and vi users can share the same
659: tags file. Rather than modify ctags, we use this shell script:
660:
661: #!/bin/csh
662: # make a tags file for lisp source files.
663: # use:
664: # lisptags foo.l bar.l baz.l ... bof.l
665: # generate the file 'tags'
666: #
667: awk -f /usr/local/lib/ltags $* | sort > tags
668:
669:
670: where the file /usr/local/lib/ltags is
671:
672: /^\(DEF/ { print $2 " " FILENAME " ?^" $0 "$?" }
673: /^\(def/ { print $2 " " FILENAME " ?^" $0 "$?" }
674:
675:
676:
677: From jkf Tue Oct 19 22:50:40 1982
678: Date: 19-Oct-82 22:50:29-PDT (Tue)
679: From: jkf (John Foderaro)
680: Subject: Lisp Opus 38.32, Liszt 8.14
681: Message-Id: <[email protected]>
682: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
683: id A03968; 19-Oct-82 22:50:40-PDT (Tue)
684: To: local-lisp
685: Status: RO
686:
687:
688: Topic 1:
689: liszt can now autoload macros. If liszt encounters a symbol without
690: a function definition but with a macro-autoload indicator on the
691: property list, then the value of the indicator is a file to load which
692: should define the macro.
693:
694: The interpreter's undefined function handler will also look for
695: macro-autoload properties, thus you needn't give a symbol both an
696: autoload and a macro-autoload property.
697:
698: The default lisp contains macro-autoload properties for the macros
699: defstruct, loop and defflavor.
700:
701: Topic 2:
702: It is now possible to define 'compiler only macros' or cmacros.
703: A cmacro acts like a normal macro, but will only be used by the
704: compiler. A cmacro is stored on the property list of a
705: symbol under the indicator 'cmacro'. Thus a function can
706: have a normal definition and a cmacro definition.
707: The macro 'defcmacro' has a syntax identical to 'defmacro' and
708: creates cmacros instead of macros.
709: For an example of the use of cmacros, see the definitions
710: of nthcdr and nth in /usr/lib/lisp/common2.l
711:
712: Topic 3:
713: If the form (foo ...) is macro expanded and the result also begins
714: with the symbol foo, then liszt will stop macro expanding (previously
715: it got into an infinite loop).
716:
717: Topic 4:
718: The function nth has been added to Franz.
719: (nth 'x_index 'l_list)
720: returns the nth element of l_list, where the car of the list
721: is accessed with (nth 0 'l_list)
722:
723: The macros (push 'g_value 'g_stack), and
724: (pop 'g_stack ['g_into])
725: have been added to franz.
726: typical uses
727: (setq foo nil)
728: (push 'xxx foo)
729: (push 123 foo)
730: now foo = (123 xxx)
731: (pop foo) returns 123
732: now foo = (xxx)
733: (pop foo yyy) returns xxx and sets yyy to xxx
734:
735:
736: Topic 5:
737: The version of Flavors written at Mit for Franz have been transported
738: here. Flavors is a system for doing object oriented programming in
739: lisp. The documentation for flavors in the Lisp Machine manual
740: from Mit. Since Lisp Machine manuals are rather scarce around here,
741: perhaps we can find someone to make copies of the flavor chapter for
742: those interested in it. There is a description of the unique
743: features of the Franz Flavors in /usr/lib/lisp/flavors.usage.
744: As mentioned above, the flavors code will be autoloaded
745: when you call 'defflavor' for the first time.
746: Our local flavors expert is Eric Cooper (r.ecc).
747:
748:
749:
750:
751:
752:
753:
754: From jkf Fri Oct 22 15:46:51 1982
755: Date: 22-Oct-82 15:46:32-PDT (Fri)
756: From: jkf (John Foderaro)
757: Subject: lisp opus 38.34
758: Message-Id: <[email protected]>
759: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
760: id A05610; 22-Oct-82 15:46:51-PDT (Fri)
761: To: local-lisp
762: Status: RO
763:
764:
765: Franz lisp now has a form of closure called an fclosure. A fclosure is a
766: compromise between a funarg and the type of functional object that we
767: currently have in Franz. In this short note, I'll explain through examples
768: what fclosures are and where you might use them, and finally describe the new
769: functions. The fclosure system was designed to be compatible with the Lisp
770: Machine closures, so you may want to look at a Lisp Machine manual for more
771: information. fclosure are related to closures in this way:
772: (fclosure '(a b) 'foo) <==> (let ((a a) (b b)) (closure '(a b) 'foo))
773:
774: A example of the use of fclosures:
775:
776: ->(setq counter 0)
777: 0
778: ->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
779: fclosure[1]
780:
781: The function 'fclosure' creates a new type of object called a fclosure.
782: A fclosure object contains a functional object, and a set of symbols and
783: values for the symbols. In the above example, the fclosure functional
784: object is (lambda (val) (setq counter (+ val counter)))
785: and the set of symbols and values just contains the symbol 'counter' and
786: zero, the value of counter when the fclosure was created.
787:
788: When a fclosure is funcall'ed:
789: 1) the lisp system lambda binds the symbols in the fclosure to their
790: values in the fclosure.
791: 2) it continues the funcall on the functional object of the fclosure
792: 3) finally it un-lambda binds the symbols in the fclosure and at the
793: same time stores the current values of the symbols in the fclosure.
794:
795: To see what that means, let us continue the example:
796: -> (funcall x 32)
797: 32
798: -> (funcall x 21)
799: 53
800:
801: Notice that the fclosure is saving the value of the symbol 'counter'.
802: Each time a fclosure is created, new space is allocated for saving
803: the values of the symbols.
804: If we executed the same fclosure function:
805: ->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
806: fclosure[1]
807:
808: We now have two independent counters:
809: -> (funcall y 2)
810: 2
811: -> (funcall y 12)
812: 14
813: -> (funcall x 3)
814: 56
815:
816: To summarize:
817:
818: (fclosure 'l_vars 'g_funcobj)
819: l_vars is a list of symbols (not containing nil)
820: g_funcobj is lambda expression or a symbol or another fclosure
821:
822: examples: (fclosure '(foo bar baz) 'plus)
823: (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #'
824: which will make the compiler compile the
825: lambda expression.
826:
827:
828: There are time when you want to share variables between fclosures.
829: This can be done if the fclosures are created at the time times using
830: fclosure-list:
831:
832: (fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...])
833: This creates a list of closures such that if a symbol appears in
834: l_varsN and l_varsM then its value will be shared between the
835: closures associated with g_funcobjN and g_funcobjM.
836:
837: example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y))
838: '(c a) '(lambda () (setq c a))))
839: (fclosure[4] fclosure[7])
840: -> (funcall (car x) 123) ; set the value of a in the 1st fclosure
841: 123
842: -> (funcall (cadr x)) ; read the same value in the 2nd fclosure
843: 123
844:
845:
846: Other fclosure functions:
847:
848: (fclosure-alist 'c_fclosure)
849: returns an assoc list giving the symbols and values in the fclosure
850:
851: (fclosurep 'g_obj)
852: returns t iff g_obj is a fclosure
853:
854: (fclosure-function 'c_fclosure)
855: returns the functional object of the fclosure
856:
857:
858:
859: Note: If a throw (or error) occurs during the evaluation of a fclosure,
860: which passes control out of the fclosure, then current values of the
861: symbols will not be stored. This may be a bug. We could set up
862: an unwind-protect, but it would then take longer to funcall
863: a fclosure. If you think an unwind protect is important, let me know.
864:
865: Note 2: you can also 'apply' a fclosure.
866:
867:
868:
869:
870:
871:
872: From jkf Sat Oct 23 08:58:07 1982
873: Date: 23-Oct-82 08:57:53-PDT (Sat)
874: From: jkf (John Foderaro)
875: Subject: more on closures
876: Message-Id: <[email protected]>
877: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
878: id A21572; 23-Oct-82 08:58:07-PDT (Sat)
879: To: local-lisp
880: Status: RO
881:
882: I sent the maryland people the flavors.usage file from mit so that they
883: could compare their implementation with mit's. What follows is their
884: analysis. Some of the differences between the two versions is due to
885: different schemes for getting around the fact that franz didn't have a form
886: of closure. RZ has indicated that now that franz has fclosures, it may be
887: possible to use more of the 'official' lisp machine flavor code. fclosures
888: will probably affect the maryland implementation too:
889: Date: 22 Oct 82 15:39:18 EDT (Fri)
890: From: Liz Allen <liz.umcp-cs@UDel-Relay>
891: Subject: flavors
892: To: jkf at Ucb-C70
893: Via: UMCP-CS; 23 Oct 82 9:09-EDT
894:
895: Wow, implementing closure in one day is amazing. We had thought
896: about writing some kind of closure... We've been discussing how
897: having closures would affect our code. It might make it easier to
898: read and modify, but it might be less efficient. Can you tell us
899: how your implementation works and what it looks like to a user?
900:
901: About the MIT implementation. Ours is probably better in a couple
902: of respects but probably loses a couple of places, too. Pros:
903:
904: 1. With ours, there is no need to discard instances when
905: redefining a flavor. The only time this would be necessary
906: is if the instance variables change which rarely happens
907: since methods change much more often than the instance
908: variables. Without a structure editor, you tend to reload the
909: file containing flavors in order to change a method.
910:
911: 2. We can compile files with flavors (he didn't say if you
912: can compile MIT's Franz flavors) and when they are compiled
913: they run *fast*. Most of the overhead occurs at combine
914: time and compiled flavors shouldn't have to be recombined.
915:
916: 3. We use hunks to store instance variables (actually, an
917: instance is a hunk whose cxr 0 is the name of the flavor and
918: whose cxr n (> 0) are the values of instance variables). We
919: pay a price at combine time since instance variable references
920: in method code are replaced with cxr and rplacx calls (but MIT
921: pays the same price in putting hash calls in the methods), but
922: we win over MIT since the cxr calls are much faster than the
923: hash table calls. We do have to have "ghost" methods which
924: are copies of methods containing different cxr calls when the
925: referenced variables of a method don't align in flavors
926: which inherit the method. This, however, happens only
927: rarely.
928:
929: 4. We handle getting and setting instance variables better
930: than the MIT implementation -- we don't need to send a message
931: and the syntax is much better. We recently added the
932: functions << and >> which get and set instance variables, eg:
933:
934: (<< foo 'instance-var)
935: and
936: (>> foo 'instance-var 'value)
937:
938: where foo is a flavor instance.
939:
940: 5. Our describe function has a hook which (if the variable
941: *debugging-flavors* is set to non-nil) allows the user to
942: follow pointers to any instances referenced in the describe.
943: This is done by assigning to a variable (made from its unique
944: id) the value of the instance.
945:
946: Cons:
947:
948: 1. They implement more things from Lisp Machine flavors
949: (like wrappers/whoppers, init-keywords), but we really haven't
950: found the need for them. We implement less closely to LM
951: flavors, but in a way that's better suited to Franz Lisp.
952:
953: 2. We didn't implement the method table as a hash table, but
954: there's no reason why we couldn't.
955:
956: 3. Things we don't have, but could easily implement include:
957: describe-method, defun-method/declare-flavor-instance-variables,
958: and storing flavor information in hunks instead of on the
959: property lists.
960:
961: 4. We don't handle method types like :and and :or. We just
962: have primary/untyped methods and :before and :after daemons.
963:
964: We have people reading our documentation. After we get some feedback
965: from them, we'll send the tape and docs to you. That should be early
966: next week.
967:
968: -Liz Allen and Randy Trigg
969:
970:
971:
972:
973:
974:
975:
976: From jkf Mon Oct 25 12:56:59 1982
977: Date: 25-Oct-82 12:55:44-PDT (Mon)
978: From: jkf (John Foderaro)
979: Subject: lisp Opus 38.35, liszt 8.15
980: Message-Id: <[email protected]>
981: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
982: id A17542; 25-Oct-82 12:56:59-PDT (Mon)
983: To: local-lisp
984: Status: RO
985:
986:
987: New features:
988: 1) tilde-expansion: franz will now expand filenames which begin with ~
989: just like csh does. It will only do the expansion if
990: the symbol tilde-expansion has a non-nil value. The default
991: value for tilde-expansion is t.
992: These functions do tilde expansion: If I've left any out, let
993: me know:
994: load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir
995: sys:access, sys:unlink [these are new functions, see below]
996:
997: 2) liszt will remove its temporary file if given a SIGTERM signal
998: (SIGTERM is sent by default when you give the kill command from the shell)
999:
1000: 3) load will now print a helpful message if an read error occurs when it
1001: is reading a file.
1002:
1003: 4) new functions:
1004:
1005: (lexpr-funcall 'function 'arg1 ... 'argn)
1006: This is a cross between funcall and apply.
1007: The last argument, argn, must be a list (possibly empty).
1008: The element of list argn are stacked and then the function is
1009: funcalled.
1010: For example:
1011: (lexpr-funcall 'list 'a 'b 'c '(d e f))
1012: is the same as
1013: (funcall 'list 'a 'b 'c 'd 'e 'f)
1014:
1015: Also
1016: (lexpr-funcall 'list 'a 'b 'c nil)
1017: is the same as
1018: (funcall 'list 'a 'b 'c)
1019:
1020: (tilde-expand 'st_filename)
1021: returns: symbol whose pname is the filename, with a leading tilde
1022: expanded. if st_filename doesn't begin with a tilde, it
1023: just returns st_filename
1024:
1025: (username-to-dir 'st_name)
1026: returns: the home directory of the given user, if that user exists.
1027: Saves old information so doesn't have to keep searching
1028: the passwd file.
1029:
1030: Some low level system functions. These are listed here for completeness.
1031: The perform a function from the unix library (see the unix manual
1032: for details).
1033: (sys:getpwnam 'st_username)
1034: return passwd file info.
1035: (sys:access 'st_file 'x_mode)
1036: (sys:unlink 'st_file)
1037:
1038:
1039: Bug fixes:
1040: 1) patom will handle prinlevel and prinlength correctly.
1041: 2) it is now safe for an interpreted function to redefine itself.
1042: 3) the information return by 'evalframe' about a funcall'ed function
1043: is now correct.
1044:
1045:
1046:
1047:
1048:
1049:
1050: From jkf Mon Oct 25 14:57:00 1982
1051: Date: 25-Oct-82 14:56:25-PDT (Mon)
1052: From: jkf (John Foderaro)
1053: Subject: 'if' macro: request for comments
1054: Message-Id: <[email protected]>
1055: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1056: id A21567; 25-Oct-82 14:57:00-PDT (Mon)
1057: To: local-lisp
1058: Status: RO
1059:
1060: Would anyone object if we added a macro called 'if' to the default franz
1061: system? 'if' is a common name and I want to make sure that it doesn't
1062: break any existing code before I add it.
1063:
1064: Some background:
1065: At mit the 'if' macro is used all over the place.
1066: Its form is
1067: (if <predicate> <then-expr> [ <else-expr>])
1068:
1069: I've always felt that macros should make the code more readable and
1070: that the 'if' macro makes code more obscure because it isn't easy
1071: to tell in complicated 'if' expressions where the <then-expr>
1072: and <else-expr>'s begin. Also, there is no provision for
1073: an 'elseif' expression.
1074:
1075: I wrote a macro called 'If' which uses keywords to separate clauses.
1076: (If <pred>
1077: then <then-expr>
1078: [elseif <pred> then <then-expr>]*
1079: [else <else-expr>])
1080:
1081: These two macros are not incompatible. one macro could do the job
1082: of both. There is an ambigous case:
1083: (if p then x) could be (cond (p then) (t x))
1084: or (cond (p x))
1085: but it isn't likely that 'if' macro users would write something like
1086: that.
1087:
1088: Thus I propose that we add a macro, if, which act's like 'If' if
1089: its second arg is 'then' or like 'if' it the second arg is not 'then'
1090: and there are two or three arguments. Other cases would cause
1091: an error.
1092:
1093:
1094:
1095:
1096:
1097: From jkf Mon Oct 25 22:37:24 1982
1098: Date: 25-Oct-82 22:37:09-PDT (Mon)
1099: From: jkf (John Foderaro)
1100: Subject: opus 38.36
1101: Message-Id: <[email protected]>
1102: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1103: id A01666; 25-Oct-82 22:37:24-PDT (Mon)
1104: To: local-lisp
1105: Status: RO
1106:
1107: I've added the 'if' macro to franz. If you have any objections, it is still
1108: not too late to voice them.
1109: I've also defined 'If' to be the same as 'if'.
1110:
1111: As I mentioned in my earlier request for comments, the 'if' macro is a
1112: cross between the mit version and a locally written version using keywords.
1113: The following documentation describes the various forms.
1114: As you know, you can test out the 'if' macro by using apply. for example:
1115:
1116: => (apply 'if '(if a then b c elseif d thenret else e))
1117: (cond (a b c) (d) (t e))
1118:
1119:
1120: ;
1121: ; This macro is compatible with both the crufty mit-version and
1122: ; the keyword version at ucb.
1123: ;
1124: ; simple summary:
1125: ; non-keyword use:
1126: ; (if a b) ==> (cond (a b))
1127: ; (if a b c d e ...) ==> (cond (a b) (t c d e ...))
1128: ; with keywords:
1129: ; (if a then b) ==> (cond (a b))
1130: ; (if a thenret) ==> (cond (a))
1131: ; (if a then b c d e) ==> (cond (a b c d e))
1132: ; (if a then b c else d) ==> (cond (a b c) (t d))
1133: ; (if a then b c elseif d thenret else g)
1134: ; ==> (cond (a b c) (d) (t g))
1135: ;
1136: ;
1137: ;
1138: ;
1139: ; In the syntax description below,
1140: ; optional parts are surrounded by [ and ],
1141: ; + means one or more instances.
1142: ; | means 'or'
1143: ; <expr> is an lisp expression which isn't a keyword
1144: ; The keywords are: then, thenret, else, elseif.
1145: ; <pred> is also a lisp expression which isn't a keyword.
1146: ;
1147: ; <if-stmt> ::= <simple-if-stmt>
1148: ; | <keyword-if-stmt>
1149: ;
1150: ; <simple-if-stmt> ::= (if <pred> <expr>)
1151: ; | (if <pred> <expr> <expr>)
1152: ;
1153: ; <keyword-if-stmt> ::= (if <pred> <then-clause> [ <else-clause> ] )
1154: ;
1155: ; <then-clause> ::= then <expr>+
1156: ; | thenret
1157: ;
1158: ; <else-clause> ::= else <expr>+
1159: ; | elseif <pred> <then-clause> [ <else-clause> ]
1160:
1161:
1162:
1163:
1164:
1165:
1166: From jkf Tue Oct 26 09:20:25 1982
1167: Date: 26-Oct-82 09:20:04-PDT (Tue)
1168: From: jkf (John Foderaro)
1169: Subject: no more jkfmacs
1170: Message-Id: <[email protected]>
1171: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1172: id A11552; 26-Oct-82 09:20:25-PDT (Tue)
1173: To: local-lisp
1174: Status: RO
1175:
1176:
1177: Since Franz now has the push, pop, if and msg macros, there is no
1178: reason for jkfmacs to exist. I've removed the code in jkfmacs and
1179: replaced it with a warning message which will be printed if you load it.
1180: If you used the jkfmacs version of 'push' you will have to go through
1181: your code and switch the order of arguments. The Franz version is
1182: (push value stack)
1183: Also, the unpush macro, defined in jkfmacs, no longer exists: just use
1184: pop with one argument.
1185:
1186:
1187:
1188: From jkf Wed Oct 27 20:35:07 1982
1189: Date: 27-Oct-82 20:34:25-PDT (Wed)
1190: From: jkf (John Foderaro)
1191: Subject: liszt 8.16
1192: Message-Id: <[email protected]>
1193: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1194: id A27561; 27-Oct-82 20:35:07-PDT (Wed)
1195: To: local-lisp
1196: Status: RO
1197:
1198: Back on May 6, a modification to liszt was made which turned 'declare'
1199: into a user callable function which provided information to the compiler.
1200: The purpose of the change was to permit one to 'load' a file containing
1201: declarations, instead of 'include'ing it. It turns out that this was a bad
1202: idea since if the compiler were to evaluate an interpreted function with
1203: local declarations, it would assume that those local declarations were
1204: describing the current file being compiled.
1205: Thus declare has it old meaning: it is a no-op unless the compiler is
1206: compiling the form. If one really wants to actively declare something,
1207: we've added the function 'liszt-declare', which looks just like declare
1208: but can be evaluated within the compiler.
1209:
1210: If you are confused by all this, don't worry. There is very little chance
1211: that it will affect you.
1212:
1213:
1214:
1215: From jkf Fri Oct 29 09:34:11 1982
1216: Date: 29-Oct-82 09:33:59-PDT (Fri)
1217: From: jkf (John Foderaro)
1218: Subject: cmacros
1219: Message-Id: <[email protected]>
1220: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1221: id A08411; 29-Oct-82 09:34:11-PDT (Fri)
1222: To: local-lisp
1223: Status: RO
1224:
1225: A week ago, Joe Faletti mentioned that one problem with cmacros is that if
1226: you redefine a function, the cmacro property stays around and thus the
1227: redefinition of the function isn't communicate to the compiler.
1228: He suggested that whenever a function is defined (via 'def' or when fasl'ed
1229: in) any cmacro properties should be remprop'ed. I've been trying to think
1230: of an alternative to this, but I can't think of one. Unless someone
1231: has a better idea, I'll implement his suggestion.
1232: This means that if you want to define the function 'foo' and a cmacro for
1233: 'foo', the cmacro definition must appear later in the file than 'foo's
1234: definition.
1235:
1236:
1237:
1238:
1239: From jkf Fri Oct 29 10:11:36 1982
1240: Date: 29-Oct-82 10:10:54-PDT (Fri)
1241: From: jkf (John Foderaro)
1242: Subject: LetS: An Expressional Loop Notation
1243: Message-Id: <[email protected]>
1244: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1245: id A09176; 29-Oct-82 10:11:36-PDT (Fri)
1246: To: local-lisp
1247: Status: RO
1248:
1249: I've got a copy of a paper by Richard Waters (at mit) describing a system
1250: for writing loops in lisp (and other languages). Basically you describe the
1251: loop in functional programming terms (similar to Backus's FP, or apl) and
1252: the LetS package converts it into an iterative form for efficient execution
1253: in lisp.
1254: We don't have the LetS code here to play with, and we probably won't be
1255: able to get it for a while since our arpanet connection is hopelessly
1256: clogged for anything but tiny messages. However you might be interested in
1257: stopping by my office and looking at the paper.
1258:
1259:
1260:
1261:
1262: From jkf Fri Oct 29 12:06:47 1982
1263: Date: 29-Oct-82 12:06:08-PDT (Fri)
1264: From: jkf (John Foderaro)
1265: Subject: Re: cmacros
1266: Message-Id: <[email protected]>
1267: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1268: id A12141; 29-Oct-82 12:06:47-PDT (Fri)
1269: To: baden, local-lisp
1270: In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday)
1271: Status: RO
1272:
1273: I could make it a 'Note'. I would prefer not to make it a warning because
1274: such redefinition is guaranteed to occur when the compiler compiles itself
1275: and the lisp code part of the lisp system.
1276:
1277:
1278:
1279: From fateman Sat Oct 30 09:17:49 1982
1280: To: franz-friends
1281: Subject: fugue # 2
1282: Status: RO
1283:
1284: FUGUE Notes
1285:
1286: An occasional publication of the
1287: Franz Lisp User Group under Unix and Eunice (FUGUE)
1288:
1289: Number 2 (October, 1982)
1290: edited by Richard J. Fateman
1291: University of California
1292: Berkeley CA 94720
1293: USA
1294: fateman@berkeley
1295:
1296: 1. Welcome!
1297:
1298: It seems about time to publish the second of these
1299: newsletters, since we have accumulated a number of new
1300: items. We would also like to relay to others such informa-
1301: tion as has been forwarded to us. The reports of projects at
1302: Berkeley (and elsewhere) may strike sympathetic chords with
1303: other research.
1304:
1305: 2. New programs
1306:
1307: 2.1. OPS-5
1308:
1309: OPS-5 is a "production system" written by Charles Forgy
1310: of CMU. It appears to work just fine in Franz, and is in
1311: wide use. Interested persons may obtain copies of documen-
1312: tation and the program from Charles.Forgy@CMU-10A. ( Charles
1313: Forgy, Computer Science Department, Carnegie-Mellon Univer-
1314: sity, Pittsburgh, PA 15213)
1315:
1316: It is their policy to send it to anyone who wants it free of
1317: charge.
1318:
1319: 2.2. GLISP
1320:
1321: GLISP is a system which provides interesting linguistic
1322: features for generic operations and data abstraction. Writ-
1323: ten by Gordon Novak at Stanford University, it was origi-
1324: nally developed for Interlisp, but has been ported to other
1325: lisps, including Franz.
1326:
1327: 2.3. Flavors
1328:
1329: There are now two distinct implementations, apparently
1330: with identical functionally, of "flavors" as appearing in
1331: the MIT Lisp Machine software. One is described in TR-1174,
1332: ____________________
1333: 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
1334: SRI Int'l, and Univ. of Calif.
1335:
1336:
1337:
1338: 9
1339:
1340:
1341:
1342:
1343:
1344:
1345:
1346:
1347:
1348:
1349: "Franz Flavors" by Richard J. Wood (Dept of C.S., Univ. of
1350: Maryland, College Pk, MD 20742). The other was written by
1351: Juan R. Loaiza of MIT, Laboratory for Computer Science. We
1352: have a copy of the latter on-line here, and expect to
1353: receive a copy of the Maryland one, shortly. Eric Cooper
1354: here at Berkeley is in charge of the flavors situation.
1355:
1356: There is an implementation of closures, mostly compati-
1357: ble with the Lisp Machine specification, announced by John
1358: Foderaro for Opus 38.33. The incompatibility is a result of
1359: what we perceive to be a high performance penalty for eso-
1360: terica.
1361:
1362: 2.4. Database Interfaces
1363:
1364: Jim Larus at UCB has cooked up interfaces to both the
1365: INGRES relational database system, and the simpler TROLL
1366: database system. These will be described in his forthcoming
1367: MS report, along with the next item.
1368:
1369: 2.5. Cursor-control and Menus
1370:
1371: Larus has provided an implementation of screen manage-
1372: ment which uses the UNIX "curses" package for primitive win-
1373: dow management. A menu-based interface has also been
1374: developed as part of this.
1375:
1376: 2.6. Vaxima and Algebraic Manipulation
1377:
1378: A new version of vaxima, the VAX version of the MACSYMA
1379: algebraic manipulation system, was released in July by UCB,
1380: incorporating some bug fixes, improved programs, and a large
1381: number of user-contributed subroutine libraries. This was
1382: made available to test-site licensees. Unfortunately, MIT
1383: has suspended new test-site licensing since about April,
1384: 1982. We hope that MIT will be liberalizing its distribu-
1385: tion policy to non-commercial sites.
1386:
1387: See the note below about MACSYMA being sold.
1388:
1389: As a counterpoint to this, UC Berkeley has received a
1390: substantial grant from the System Development Foundation for
1391: work on Mathematical Representation and Manipulation, which
1392: should result in some more advanced systems for application
1393: of computers to symbolic mathematics. Recruiting for
1394: researchers, staff, and students is underway now, and
1395: interested persons should contact Richard Fateman.
1396:
1397: 2.7. VLSI Design Rule Checker
1398:
1399: Lyra, written in Lisp by Michael Arnold, is a retarget-
1400: able, hierarchical, design rule checker for VLSI circuits.
1401: Lyra features a rule compiler (also written in Lisp of
1402:
1403:
1404:
1405:
1406:
1407:
1408:
1409:
1410:
1411:
1412:
1413:
1414:
1415: course!) which translates symbolic design rule descriptions
1416: to lisp code for checking the rules. Lyra was used for the
1417: RISC project. It is currently being used extensively at
1418: Berkeley, and will be included in the Fall-82 distribution
1419: of of the Berkeley CAD tools. For more information contact
1420: Michael Arnold or John Ousterhout at Berkeley.
1421:
1422: 2.8. Generic Arithmetic
1423:
1424: As a proposed extension to Franz arithmetic, Richard
1425: Fateman, Keith Sklower and Scott Morrison, have written a
1426: simple-minded generic arithmetic package which includes
1427: modules which can be loaded to support exact rational arith-
1428: metic, software-simulated IEEE extended arithmetic, arbi-
1429: trary precision floating point, complex, interval, and mul-
1430: tivariate polynomial. Combinations of some of these are sup-
1431: ported, although the package is as yet incomplete in some
1432: areas. The IEEE arithmetic simulation is written in C.
1433: These packages are probably not in good enough shape for
1434: casual use by others.
1435:
1436:
1437: 3. New features
1438:
1439: Various performance enhancements and bug fixes have
1440: been incorporated in versions of Franz (now on Opus 38.33
1441: and the compiler, Liszt 8.14) These are mentioned in brief
1442: here; more details accompany updates of the system and
1443: manual included in the forthcoming Berkeley 4.2BSD UNIX dis-
1444: tribution.
1445:
1446: 3.1. Franz
1447:
1448: We added a switch to cause the evaluator to save macro
1449: expansions so they need only be expanded once.
1450:
1451: We added vector and vector-immediate data types.
1452:
1453: We rewrote showstack and backtrace so they are easier
1454: to use.
1455:
1456: We made the lisp to foreign function interface more
1457: secure. The system now allows foreign function to call lisp
1458: functions.
1459:
1460: We added closures and support flavors, features from
1461: the Lisp Machine.
1462:
1463: 3.2. Liszt
1464:
1465: Liszt will check the number of arguments to system
1466: functions and user defined functions.
1467: 9
1468:
1469: 9
1470:
1471:
1472:
1473:
1474:
1475:
1476:
1477:
1478:
1479:
1480: Liszt supports local declarations.
1481:
1482: Liszt will automatically compile lambda expressions
1483: headed by the function `function'.
1484:
1485: Liszt supports compiler-only macros and will autoload
1486: macros if necessary.
1487:
1488: 4. MC68000
1489:
1490: Keith Sklower and Kevin Layer have been working on the
1491: MC68000 version of Franz under the UNIX operating system
1492: (using a DUAL System 83). While the current configuration is
1493: a swapping system, the Lisp should be able to use the full
1494: address space of the CPU. We expect to have this system run-
1495: ning on the UNIX 4.2 BSD SUN software, too. The base system
1496: on the DUAL, including the interpreter, reader, bignums,
1497: fasl, works; the compiler is being perfected.
1498:
1499:
1500: 5. Other Lisps
1501:
1502: We now have, in-house tried 4 (other) VAX UNIX lisp
1503: systems: YLISP, Interlisp, PSL, and VLISP. We know that
1504: Interlisp can run also on VMS using the Eunice package.
1505: Interested parties can contact David Dyer at USC-ISI. There
1506: is also a version of lisp which runs on VMS only, namely
1507: NIL, from MIT, which appears to be undergoing limited dis-
1508: tribution. Two other lisps under development under UNIX are
1509: Yale's answer to NIL, namely "T", and Common Lisp, from CMU
1510: and friends.
1511:
1512: Counting Franz, that makes 7 lisp systems for the VAX
1513: computer line. Not counting variants on 2 operating systems.
1514: A Paen to standardization.
1515:
1516: Dick Gabriel states some useful principles for com-
1517: parisons in the conference record of the 1982 ACM Lisp and
1518: Functional Programming Conference, which was held in August.
1519: We understand he now has a collection of some 18 programs
1520: which he is continuing to time on various systems.
1521:
1522: 6. Work in Progress
1523:
1524: 6.1. BITGRAPH SUN AED-512
1525:
1526: Greg Foster at UCB is working on raster-graphics sup-
1527: port in Franz for the 800 by 1000 b/w raster displays of the
1528: BBN Bitgraph and/or the SUN Workstation, and possibly the
1529: color 512 by 512 AED system. We are probably going to han-
1530: dle mice and Bitpad (stylus) input for pointing. There are
1531: lots of projects we hear about with similar systems, e.g.
1532: just recently from the University of Maryland, using UNIX
1533:
1534:
1535:
1536:
1537:
1538:
1539:
1540:
1541:
1542:
1543:
1544:
1545:
1546: and multiplexed files for window management of a 68000-based
1547: home-grown workstation.
1548:
1549: 6.2. RISC-LISP
1550:
1551: Yes, Reduced Instruction Set Computer fans, who else
1552: but UCB would be so bold... Carl Ponder is examining the
1553: issues involved in constructing a fast lisp interpreter and
1554: compiler for the RISC architecture. You see, we have all
1555: these chips...
1556:
1557:
1558: 7. Work Contemplated
1559:
1560: 7.1. Fast Number Compiler
1561:
1562: Undergraduate Jeff Cohen at Berkeley is starting to
1563: look at this. There are several industrial concerns that
1564: have expressed interest in using such a system, but expected
1565: it to be subsidized by someone else.
1566:
1567: 7.2. IBM Franz
1568:
1569: Even more nibbles on this one, but not yet.
1570:
1571: 8. Business News
1572:
1573: 8.1. Eunice SOLD
1574:
1575: Some of you may have heard that the Eunice software
1576: package was sold by SRI to the Wollongong Group, a UNIX sup-
1577: port group in Palo Alto. Prices range from $2k (educa-
1578: tional) to $5k (commercial). Naturally this package is of
1579: interest beyond the availability of Franz Lisp. We have not
1580: compared this product to other similar ones, but we know
1581: that TWG has been distributing a working Franz opus 38.
1582:
1583: As far as alternatives to Eunice, we are aware of a
1584: system developed at Rice University, and another by Human
1585: Computing Resources (HCR) in Toronto. We have not
1586: evaluated either of these.
1587:
1588: 8.2. MACSYMA SOLD
1589:
1590: MIT has sold exclusive rights to MACSYMA, a large alge-
1591: braic manipulation system, to Symbolics, Inc. of Cambridge
1592: Mass. This package runs in Franz Lisp, (among other Lisps)
1593: We hope that soon it will again be available to educational
1594: institutions with VAX systems either from us or Symbolics,
1595: at a nominal charge. We understand that commercial licenses
1596: (from Symbolics) for versions of MACSYMA on PDP-10s, Lisp
1597: Machines, etc. will distributed at non-nominal prices and
1598: offered with maintenance contracts.
1599:
1600:
1601:
1602:
1603:
1604:
1605:
1606: From liz.umcp-cs@UDel-Relay Mon Nov 1 17:43:52 1982
1607: Date: 29 Oct 82 12:04:24 EDT (Fri)
1608: From: Liz Allen <liz.umcp-cs@UDel-Relay>
1609: Subject: Re: Flavor system
1610: To: ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc
1611: Cc: randy.umcp-cs at UDel-Relay
1612: In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley
1613: Via: UMCP-CS; 30 Oct 82 5:40-EDT
1614: Status: RO
1615:
1616: Date: 25 October 1982 16:29-EDT
1617: From: ECC@MIT-MC@Berkeley
1618: Subject: Flavor system
1619: To: FRANZ-FRIENDS at MIT-MC
1620:
1621: Can someone give me a pointer to the Franz flavor system
1622: developed by U. Maryland? I am looking for information on how to
1623: FTP the files -- what machine, whether public, what files, etc.
1624:
1625: Since the U. of Maryland is not (yet) an Arpanet host, you can't
1626: FTP files directly from here. We are right now completing some
1627: documentation for all of our hacks -- including documentation for
1628: some recent improvements for our flavors system. When that
1629: documentation is complete, we will be ready to distribute the
1630: packages developed here. Besides flavors, this includes a top
1631: level called userexec which is based on INTERLISP's top level and
1632: a production system called YAPS similar to but more flexible than
1633: OPS5.
1634:
1635: We are supposed to become an Arpanet host in a few months... (Read
1636: open ended period of time.) Meanwhile, if you would like to get
1637: our code, mail me a tape, and I will mail it back with the code and
1638: documentation on it. I'd appreciate it if someone would volunteer
1639: to let other folks FTP the files from their machine until we do
1640: become an Arpanet host. My address is:
1641:
1642: Liz Allen
1643: Univ of Maryland
1644: Dept of Computer Science
1645: College Park MD 20783
1646: (301) 454-4247
1647: liz.umcp-cs@udel-relay
1648:
1649: -Liz
1650:
1651:
1652:
1653: From jkf Wed Nov 3 15:49:29 1982
1654: Date: 3-Nov-82 15:48:50-PST (Wed)
1655: From: jkf (John Foderaro)
1656: Subject: lisp opus 38.40
1657: Message-Id: <[email protected]>
1658: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1659: id A16460; 3-Nov-82 15:49:29-PST (Wed)
1660: To: local-lisp
1661: Status: RO
1662:
1663: putprop will now put new properties at the head of the property list.
1664:
1665:
1666:
1667:
1668: From ecc@UCBARPA Thu Nov 4 10:28:49 1982
1669: Date: 4-Nov-82 10:19:26-PST (Thu)
1670: From: ecc@UCBARPA (Eric C. Cooper)
1671: Subject: Lisp song
1672: Message-Id: <[email protected]>
1673: Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82])
1674: id A24537; 4-Nov-82 10:19:28-PST (Thu)
1675: Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1676: id A00305; 4-Nov-82 10:28:49-PST (Thu)
1677: To: local-lisp@kim
1678: Status: O
1679:
1680: [This has been forwarded from uucp through Xerox through info-lispm.]
1681:
1682: >From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
1683:
1684: Another Glitch in the Call
1685: ------- ------ -- --- ----
1686: (Sung to the tune of a recent Pink Floyd song.)
1687:
1688:
1689: We don't need no indirection
1690: We don't need no flow control
1691: No data typing or declarations
1692: Hey! Did you leave the lists alone?
1693:
1694: Chorus:
1695: All in all, it's just a pure-LISP function call.
1696:
1697: We don't need no side effect-ing
1698: We don't need no scope control
1699: No global variables for execution
1700: Hey! Did you leave those args alone?
1701:
1702: (Chorus)
1703:
1704: We don't need no allocation
1705: We don't need no special nodes
1706: No dark bit-flipping in the functions
1707: Hey! Did you leave the bits alone?
1708:
1709: (Chorus)
1710:
1711: We don't need no compilation
1712: We don't need no load control
1713: No link edit for external bindings
1714: Hey! Did you leave that source alone?
1715:
1716: (Chorus, and repeat)
1717:
1718: From jkf Sat Nov 13 20:53:41 1982
1719: Date: 13-Nov-82 20:53:16-PST (Sat)
1720: From: jkf (John Foderaro)
1721: Subject: lisp opus 38.41
1722: Message-Id: <[email protected]>
1723: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1724: id A00490; 13-Nov-82 20:53:41-PST (Sat)
1725: To: local-lisp
1726: Status: O
1727:
1728: added functions:
1729: (remq 'g_val 'l_list) - just like remove but uses eq instead of equal
1730: (command-line-args) - returns a list of the command line arguments
1731: when lisp was started. This function will return
1732: only those arguments typed by the user, even if the
1733: lisp was started with the autorun feature (liszt -r).
1734: (sys:gethostname) - returns the name of the machine.
1735: (status domain) - returns 'ucb' here.
1736:
1737:
1738:
1739: From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982
1740: Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST
1741: Date: 28 Nov 1982 11:47:28-EST
1742: From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A
1743: Subject: (random) problems
1744: Status: RO
1745:
1746: I am having two problems using (random) in Franz lisp. The first problem is
1747: that I can't find any way to set the seed. Every time I enter lisp, the
1748: generator is in the same state. I have had to resort to cfasling a c
1749: procedure that calls srand() (as (random) seems to be defined in c by a call
1750: on rand()). Is there a way to do this within lisp? The other problem is
1751: more serious. The generator seems to generate tight cycles for (at least)
1752: arguments that are small powers of 2. For example, repeatedly executing
1753: (random 2) yields the sequence 01010101..., and (random 4) yields
1754: 01230123.... These sequences apparently occur no matter to what value I set
1755: the seed. Does anyone one know what I could be doing wrong, or have a
1756: working random number generator?
1757:
1758:
1759: From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982
1760: Status: O
1761:
1762: From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982
1763: Date: 28 Nov 82 22:40:14 EST (Sun)
1764: From: Tim Maroney <tim.unc@UDel-Relay>
1765: Subject: rng
1766: To: franz-friends at Ucb-C70
1767: Via: UNC; 28 Nov 82 23:38-EST
1768: Status: O
1769:
1770: To the person who asked about random number generators and deficiencies
1771: in (random) [I can't write mail to you for some reason]:
1772:
1773: You're not doing anything wrong; that's the way the sucker works.
1774: One good way to get random numbers is to do the syscall that gets
1775: you the number of seconds since whenever-it-is, and use the mod
1776: function. This is especially good for getting a random one or zero,
1777: by using the evenp function.
1778:
1779: Tim Maroney
1780: tim@unc@udel-relay
1781:
1782:
1783: From jkf Tue Nov 30 09:21:10 1982
1784: Date: 30-Nov-82 09:21:10-PST (Tue)
1785: From: jkf (John Foderaro)
1786: Subject: opus 38.42
1787: Message-Id: <[email protected]>
1788: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1789: id AA11699; 30-Nov-82 09:21:10-PST (Tue)
1790: To: local-lisp
1791: Status: O
1792:
1793: added: (sys:link 'oldname 'newname) that what the ln program does.
1794:
1795: changed: the order of arguments to the vset functions is now:
1796: (vset 'vector 'index 'value).
1797:
1798: [This shouldn't affect anyone since vectors haven't been officially
1799: released yet and won't be until I make one more major modification]
1800:
1801: setf now knows about vectors. You can say
1802: (setf (vref 'vector 'index) 'value)
1803: and not have to worry about the order of arguments to vset.
1804:
1805:
1806:
1807: From jkf Tue Nov 30 10:42:00 1982
1808: Date: 30-Nov-82 10:42:00-PST (Tue)
1809: From: jkf (John Foderaro)
1810: Subject: Re: opus 38.42
1811: Message-Id: <[email protected]>
1812: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1813: id AA13143; 30-Nov-82 10:42:00-PST (Tue)
1814: To: jeffc, local-lisp
1815: In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday)
1816: Status: O
1817:
1818: It can't do symbolic links (I've only been adding system calls that I had
1819: a use for).
1820:
1821: setf is a generalized setq. The target can be an expression which locates
1822: a value. setf figures out how to store in the target.
1823: for example:
1824:
1825: (setf x 3) == (setq x 3)
1826: (setf (car x) 3) == (rplaca x 3)
1827: (setf (get foo 'bar) 3) == (putprop foo 3 'bar)
1828:
1829: the target must be something it has been 'taught' to understand, or it can
1830: be a macro, in which case setf macro-expands it and takes another look.
1831:
1832: The setf macro (and a list of targets it knows about is in
1833: /usr/lib/lisp/common2.l)
1834:
1835:
1836:
1837:
1838: From jkf@UCBKIM Wed Dec 1 09:13:23 1982
1839: Date: 1-Dec-82 09:13:03-PST (Wed)
1840: From: jkf@UCBKIM (John Foderaro)
1841: Subject: Random Numbers in Franz
1842: Message-Id: <[email protected]>
1843: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1844: id AA03615; 1-Dec-82 09:13:03-PST (Wed)
1845: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82])
1846: id A18406; 1-Dec-82 09:13:23-PST (Wed)
1847: To: franz-friends@berkeley
1848: Status: RO
1849:
1850: Date: 29-Nov-82 15:56:09-PST (Mon)
1851: From: alice!sola!mitch
1852: Subject: Random Numbers in Franz
1853: To: alice!ucbvax!franz-friends
1854:
1855: In general, it is very bad practice to compute a random number between 0
1856: and n by any expression such as (mod (random) n). In fact, Franz's
1857: random function does exactly that, returning the number generated by the
1858: C function rand(3) modulo n. This technique uses only the rightmost
1859: bits of successive calls to rand, and the righmost n bits of congruential
1860: sequences (like that returned by rand(3)) have a period of AT MOST 2**n
1861: (See Knuth vol.2 p. 12). So using the rightmost two bits will indeed give
1862: you sequences of at most period 4. (If your lisp doesn't have this
1863: behavior, you're not using the standard rand.)
1864:
1865: A better way to do it is to use the high order bits, by dividing the entire
1866: range up into n pieces and then seeing where you fall. (This method is
1867: biased if n is of the same order as the range, though.)
1868:
1869: The code I use is:
1870:
1871:
1872: (or (getd '$old-random) (putd '$old-random (getd 'random)))
1873:
1874: (defun random n
1875: (cond ((eq n 0) ($old-random))
1876: ((fix (quotient (boole 1 ($old-random) #o 7777777777)
1877: (quotient #o 7777777777 (arg 1)))))))
1878:
1879: Mitch Marcus
1880:
1881:
1882:
1883:
1884:
1885: From jkf Thu Dec 2 08:04:37 1982
1886: Date: 2-Dec-82 08:04:37-PST (Thu)
1887: From: jkf (John Foderaro)
1888: Subject: Franz Lisp distribution
1889: Message-Id: <[email protected]>
1890: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1891: id AA14414; 2-Dec-82 08:04:37-PST (Thu)
1892: To: franz-friends, net-lang-lisp@k
1893: Status: O
1894:
1895:
1896: Franz Lisp Distribution
1897:
1898: This note describes our distribution policy for Franz Lisp.
1899:
1900: What is being distributed:
1901: We distribute only source code in order to keep the distribution
1902: small and relatively Unix independent. Makefiles are provided to
1903: build the entire lisp system from source, even if you don't have
1904: a version of lisp running already. This process takes about 3 cpu
1905: hours on a Vax 780. [This version for the Vax only, a 68000 version
1906: is being worked on. Contact ucbkim.sklower@berkeley or
1907: ucbkim.layer@berkeley]
1908:
1909: The following source is provided:
1910: lisp interpreter,
1911: compiler (liszt),
1912: cross reference program (lxref),
1913: lisp manual,
1914: and other utility programs:
1915: trace, step, debug, cmu library functions, (and other minor ones),
1916: and these packages from the MIT lisp library:
1917: defstruct, loop, flavors.
1918: [These programs are provided as a convenience to those who can't
1919: access the arpanet and copy them. There is no documentation for
1920: them in the Franz Lisp manual. The best source of documentation
1921: is the Lisp Machine manual (available from MIT, Symbolics
1922: or LMI)]
1923:
1924: Regarding Flavors: there are two implementations of flavors for
1925: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
1926: and one from the University of Maryland (contact person
1927: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
1928: exactly like flavors on the Lisp Machine (due to differences between
1929: Lisp Machine lisp and Franz Lisp), and the implementations differ
1930: from each other. We incorporated the Mit version into the
1931: standard distribution because the high bandwidth between here and
1932: MIT will insure that it keeps up to date with the current Franz.
1933: This is not to imply that it is the better implementation.
1934: We haven't had enough experience with flavors to judge.
1935: Those seriously interested in Flavors should contact Liz
1936: Allen and ask for the Tech Report on the Univ Of Maryland Flavors
1937: system.
1938:
1939: What is the form of the distribution:
1940: The files are packaged in a giant (2.1Mbyte) shell script. Running this
1941: shell script through 'sh' will result in a directory tree. A ReadMe file
1942: in the current directory will contain instructions on building the lisp
1943: system. The shell script is broken into a number of smaller files.
1944: The current distribution looks like:
1945: % ls
1946: total 2092
1947: 195 opus38.40.aa 195 opus38.40.ae 195 opus38.40.ai
1948: 195 opus38.40.ab 195 opus38.40.af 195 opus38.40.aj
1949: 195 opus38.40.ac 195 opus38.40.ag 142 opus38.40.ak
1950: 195 opus38.40.ad 195 opus38.40.ah
1951:
1952: The '38.40' means Opus 38, minor version 40. These numbers may be different
1953: by the time you get your distribution. In order to extract the lisp
1954: files from this shell script, you need only type:
1955: cat * | sh
1956:
1957:
1958: To get a copy of the distribution:
1959: The distribution may be obtained either using FTP from an arpanet site,
1960: or on a magnetic tape through the U.S Mail.
1961:
1962: Arpanet:
1963: The files are stored on the ucb-c70 (NCP) arpanet host in the
1964: directory /users/lisp/lispuser. If you have an account on the ucb-c70,
1965: you are free to take FTP a copy of these files.
1966: If you do not have an account on the ucb-c70, send me (jkf@berkeley) a
1967: message and I will set up a temporary account for you.
1968: If you are on a TCP host, write me and we will set up an account on one
1969: of our Vax's for you to FTP the files. Eventually we will have an
1970: anonymous login on a TCP machine.
1971:
1972: Mag Tape:
1973: In order to get a copy of the distribution mailed to you, send a check to
1974: cover our tape copying and mailing costs (fees are listed below). We will
1975: purchase the mag tape and you are free to keep it. Please do NOT
1976: send us a tape.
1977:
1978: Fees:
1979: $50 - distribution tape mailed 3rd class
1980: add $10 - a copy of the Lisp Manual (we will only
1981: send one copy, you are free to photocopy it)
1982: add $7 - send tape via 1st class mail.
1983:
1984: -or-
1985: $15 - for just a copy of the Lisp Manual
1986:
1987: The address to send checks to is
1988:
1989: Keith Sklower
1990: EECS/Computer Science Division
1991: 524 Evans Hall
1992: University of California
1993: Berkeley, CA 94720
1994:
1995: All checks should be made out to "Regents, University of California."
1996: We require pre-payment. We will not invoice or process purchase orders.
1997:
1998:
1999:
2000: Disclaimers:
2001: This distribution works on the latest versions of Unix running at
2002: Berkeley (4.1a). We can't guarantee that it will work on older
2003: versions (although, if you are running 4.1, it is almost certain
2004: that it will work, but we have not verified it).
2005: VMS users who are using a typical Unix compatibility package will
2006: probably not be able to build a lisp from this distribution unless they
2007: know a great deal about VMS and their compatibility package.
2008: At least one package (Eunice) supports Franz at this time.
2009:
2010: Redistribution:
2011: If you get a copy of the distribution, you are free to give it to
2012: other people. We appreciate being informed of new sites so they
2013: can be put on a mailing list (electronic and conventional). This
2014: list is used to announce new releases. To be put on this list,
2015: send U.S. Mail to Keith Sklower (address above) or to
2016: franz-friends-request@berkeley or ucbvax!franz-friends-request
2017:
2018:
2019:
2020: From jkf Mon Dec 6 08:50:45 1982
2021: Date: 6-Dec-82 08:50:45-PST (Mon)
2022: From: jkf (John Foderaro)
2023: Subject: opus 38.43
2024: Message-Id: <[email protected]>
2025: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2026: id AA12951; 6-Dec-82 08:50:45-PST (Mon)
2027: To: local-lisp
2028: Status: O
2029:
2030: The size of vectors is now recorded in bytes rather than longwords.
2031: We've imported a few more commands to deal with fclosures.
2032: (symeval-in-fclosure 'fclosure 'symbol)
2033: (set-in-fclosure 'fclosure 'symbol 'value)
2034:
2035: (let-fclosed vars function)
2036:
2037:
2038:
2039:
2040: From jkf Mon Dec 13 10:35:43 1982
2041: Date: 13-Dec-82 10:35:43-PST (Mon)
2042: From: jkf (John Foderaro)
2043: Subject: enhancemants to trace
2044: Message-Id: <[email protected]>
2045: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2046: id AA12160; 13-Dec-82 10:35:43-PST (Mon)
2047: To: local-lisp
2048: Status: O
2049:
2050: The function 'retrace' will insure that all functions which should be
2051: traced are indeed traced. This will solve the problem of reloading
2052: a file whose functions are traced. After you load a file, you can
2053: type (retrace) and those functions which became untraced during the loading
2054: process, will be traced again.
2055:
2056: The top-level-print and top-level-read variables will now take effect
2057: within a trace break.
2058:
2059:
2060:
2061:
2062:
2063: From jkf Tue Dec 14 12:40:41 1982
2064: Date: 14-Dec-82 12:40:41-PST (Tue)
2065: From: jkf (John Foderaro)
2066: Subject: Re: #!, exec and lisp
2067: Message-Id: <[email protected]>
2068: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2069: id AA10379; 14-Dec-82 12:40:41-PST (Tue)
2070: To: lime!burdvax!puder
2071: Cc: franz-friends
2072: In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon)
2073: Status: O
2074:
2075: It is easy to make #! do a zapline. If you have a recent version of
2076: lisp, just execute:
2077:
2078: (defsharp ! (x) (zapline))
2079:
2080: (this could be put in your .lisprc, if you don't want to affect other
2081: people). The problem with adding this to Franz by default is that the
2082: sharpsign macro is shared by a number of lisps and few of them run under
2083: Unix. Therefore, few other lisps are going to want #! to be zapline.
2084:
2085:
2086: Regarding the -f switch: The -f switch is used to communicate between the
2087: bootstrap at the beginning of a fasl file and the lisp interpreter. It
2088: wasn't meant as a general 'fasl this file' switch for users to make use of.
2089: The choice of '-f' was bad, it should have been something more unique like
2090: '-- autorun' so that a user would be unlikely to type it. We have avoided
2091: assigning meanings to switches on lisp's command line because we want to give
2092: each user the opportunity to assign whatever meaning he wants to whatever
2093: switch he wants. It isn't difficult to write a program to scan the command
2094: line.
2095:
2096: Re:
2097: The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be
2098: necessary, because the exec syscall supplies the full path name, because
2099: the shell has already done the path searching on the command name. The
2100: only place that might have to be searched is the current directory.
2101:
2102: This isn't true. (argv 0) is the command that you typed, not the full path
2103: name to the command. Only by prepending all the directories in the
2104: search list can you find the location of the command.
2105:
2106:
2107: ---john foderaro
2108:
2109:
2110:
2111: From jkf Mon Jan 10 15:04:02 1983
2112: Date: 10-Jan-83 15:04:02-PST (Mon)
2113: From: jkf (John Foderaro)
2114: Subject: opus 38.45
2115: Message-Id: <[email protected]>
2116: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2117: id AA19240; 10-Jan-83 15:04:02-PST (Mon)
2118: To: local-lisp
2119: Status: O
2120:
2121: showstack will again report correctly for compiled calls if the
2122: transfer tables are unlinked (status translink nil).
2123:
2124:
2125:
2126: From jkf Mon Jan 10 19:46:06 1983
2127: Date: 10-Jan-83 19:46:06-PST (Mon)
2128: From: jkf (John Foderaro)
2129: Subject: opus 38.46
2130: Message-Id: <[email protected]>
2131: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2132: id AA24831; 10-Jan-83 19:46:06-PST (Mon)
2133: To: local-lisp
2134: Status: O
2135:
2136: This version incorporates some fixes from mit. You shouldn't notice
2137: any differences but if you do, let me know.
2138:
2139:
2140:
2141:
2142:
2143: From jkf Wed Jan 12 09:03:32 1983
2144: Date: 12-Jan-83 09:03:32-PST (Wed)
2145: From: jkf (John Foderaro)
2146: Subject: opus38.47
2147: Message-Id: <[email protected]>
2148: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2149: id AA01981; 12-Jan-83 09:03:32-PST (Wed)
2150: To: local-lisp
2151: Status: O
2152:
2153: The setf macro will now handle all car and cdr forms (i.e. c{ad}+r).
2154: Thanks to peter norvig for this.
2155:
2156: There is a new macro called 'defvar'. It is used to declare special
2157: variables and optionally to give them an initial value. It is used
2158: at top level in a file (outside of defuns).
2159:
2160: forms:
2161: (defvar foo) ; declares foo to be special
2162: (defvar bar 3) ; declares bar to be special and when this file is read in
2163: ; bar will be given the value 3 if it is unbound.
2164: An advantage of '(defvar foo)' over '(declare (special foo))' is that if
2165: a file containing defvars is loaded (or fasl'ed) in during compilation,
2166: the variables mentioned in the defvar's will be declared special. The only
2167: way to have that effect with '(declare (special foo))' is to 'include'
2168: the file.
2169:
2170: There is a new macro, 'environment', which can be used at the beginning of
2171: a file to specify what sort of environment this file needs in order to be
2172: compiled or run. For example:
2173: (environment (compile eval) (files mymacros othermacros)
2174: (compile) (syntax maclisp))
2175:
2176: says that when compiling or loading into the interpreter, the files
2177: mymacros and othermacros should be loaded (if they aren't loaded already).
2178: When compiling, the maclisp syntax should be used.
2179: The general form of 'environment' is:
2180: (environment when1 what1
2181: when2 what2
2182: ... ...
2183: whenN whatN)
2184: the when's are a subset of (eval compile load), and the symbols have the
2185: same meaning as they do in 'eval-when'.
2186: The what's are either
2187: (files file1 file2 ... fileN)
2188: insure that the named files are loaded. To see if fileX
2189: is loaded, it looks for a 'version' property under
2190: fileX's property list. Thus to prevent multiple loading,
2191: you should put
2192: (putprop 'myfile t 'version) at the end of myfile.l
2193: (syntax type)
2194: type is either maclisp, intlisp, ucilisp, franzlisp
2195: This sets the syntax correctly.
2196:
2197: There are additional macros to set of standard environments:
2198: (environment-maclisp) sets up the maclisp environment. This is what
2199: you would get by using the -m switch to liszt.
2200:
2201: (environment-lmlisp) sets up the lisp machine environment. This is like
2202: maclisp but it has additional macros.
2203:
2204:
2205: It is possible to add when's and what's to the specialized environments,
2206: e.g.
2207: (environment-maclisp (compile eval) (files foo bar))
2208:
2209:
2210:
2211:
2212:
2213:
2214:
2215: From norvig Wed Jan 12 13:12:45 1983
2216: To: jkf local-lisp
2217: Subject: defvar
2218: Status: O
2219:
2220: Shouldn't defvar take any number of arguments, like setq? As it is,
2221: (defvar a 1 b 2) sets a to 1, but ignores the other arguments.
2222:
2223: From fateman Wed Jan 12 13:23:08 1983
2224: To: jkf local-lisp norvig
2225: Subject: Re: defvar
2226: Status: O
2227:
2228: I suspect the extra arguments to defvar are used in other systems for
2229: storage of documentation strings in appropriate places. E.g.
2230: (defvar dozen 12 "initially 12 except in the baker system when it is 13")
2231: causes some association with defvar and documentation should be put on
2232: a file.
2233:
2234:
2235: From jkf Wed Jan 12 14:25:02 1983
2236: Date: 12-Jan-83 14:25:02-PST (Wed)
2237: From: jkf (John Foderaro)
2238: Subject: Re: defvar
2239: Message-Id: <[email protected]>
2240: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2241: id AA13079; 12-Jan-83 14:25:02-PST (Wed)
2242: To: norvig, local-lisp
2243: In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday)
2244: Status: O
2245:
2246: fateman is correct that there is an optional third argument for
2247: documentation. We don't want to add multiple arguments because defvar
2248: it will mean that code we write here can't be transported to
2249: other lisp which only expect one defvar argument.
2250:
2251:
2252:
2253: From jkf Thu Jan 13 09:49:13 1983
2254: Date: 13-Jan-83 09:49:13-PST (Thu)
2255: From: jkf (John Foderaro)
2256: Subject: liszt 8.17
2257: Message-Id: <[email protected]>
2258: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2259: id AA00331; 13-Jan-83 09:49:13-PST (Thu)
2260: To: local-lisp
2261: Status: O
2262:
2263: The vector reference functions are open coded. These are
2264: vref, vrefi-byte, vrefi-word, vrefi-long
2265:
2266:
2267:
2268: From G:alpines Thu Jan 13 20:31:34 1983
2269: Date: 13 Jan 1983 20:24-PST
2270: From: alpines@G (Harry Weeks at Vax-Populi)
2271: Subject: Franz on 68000's
2272: Message-Id: <83/01/13 2024.733@Vax-Populi>
2273: Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
2274: id AA12970; 13-Jan-83 20:28:37-PST (Thu)
2275: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2276: id AA14908; 13-Jan-83 20:31:34-PST (Thu)
2277: To: franz@BERKELEY
2278: Cc: franz-friends@BERKELEY
2279: Status: O
2280:
2281: >Date: 13 Jan 1983 20:01-PST
2282: From: G.alpines at Berkeley (Harry Weeks at Vax-Populi)
2283: Subject: Franz on 68000's.
2284: To: franz-friends-request@Berkeley
2285: Message-Id: <83/01/13 2001.733@Vax-Populi>
2286:
2287: Please put me on your mailing list for information concerning
2288: implementation of Franz, esp. on 68000's, but I'd like to keep
2289: informed generally as well. Thanks.
2290:
2291: Harry Weeks
2292: Bytek
2293: 1730 Solano Avenue
2294: Berkeley, CA 94707
2295:
2296: (415) 527-1157
2297:
2298:
2299: From jkf Sun Jan 16 21:22:54 1983
2300: Date: 16-Jan-83 21:22:54-PST (Sun)
2301: From: jkf (John Foderaro)
2302: Subject: change to lisptags program
2303: Message-Id: <[email protected]>
2304: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2305: id AA23656; 16-Jan-83 21:22:54-PST (Sun)
2306: To: local-lisp
2307: Status: O
2308:
2309: lisptags will now surround the search string with /'s instead of ?'s
2310: in order to be compatible with ctags. Both types should work with vi,
2311: emacs people will probably have to make a minor modification to their
2312: tags.ml file.
2313: My version in ~jkf/elib/tags.ml.
2314:
2315:
2316:
2317:
2318:
2319:
2320: From jkf Tue Jan 18 16:43:23 1983
2321: Date: 18-Jan-83 16:43:23-PST (Tue)
2322: From: jkf (John Foderaro)
2323: Subject: lisp opus 38.48, liszt 8.19
2324: Message-Id: <[email protected]>
2325: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2326: id AA10935; 18-Jan-83 16:43:23-PST (Tue)
2327: To: local-lisp
2328: Status: O
2329:
2330: This is a long message so I'll put the most important thing first, in case
2331: you choose not to read the rest of the message:
2332: *** object files generated by liszt 8.19 will not run in any lisp
2333: *** older than 38.48. Object files which were generated by
2334: *** liszt's before 8.19 will continue to work in the new lisp.
2335:
2336:
2337: There were two major changes to lisp and liszt:
2338: 1) compiled functions will test at runtime to make sure that they
2339: are passed the correct number of arguments.
2340:
2341: 2) the lambda list keywords &optional, &rest and &aux are open compiled
2342: in an efficient manner.
2343:
2344: I'll refresh your memory on what the possible forms are for the & keywords:
2345:
2346: the formal parameter list of a def has this form
2347: ( required-args
2348: [ &optional optional-arguments ]
2349: [ &rest rest-argument ]
2350: [ &aux aux-arguments ])
2351:
2352: as in this example which shows all possible forms:
2353:
2354: (def foo
2355: (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g)
2356: (compute)))
2357:
2358:
2359: the meaning and forms of the various parts of the formal parameter list are:
2360:
2361: required-args: a sequence of n (zero or more) symbols which will be bound
2362: to the first n actual arguments.
2363:
2364: optional-args: a sequence of m (zero or more) symbols which will be
2365: bound to the next m actual arguments if they are present, or
2366: to default values.
2367: the forms of an optional argument are:
2368:
2369: foo - bind foo to the argument if it present, otherwise bind it
2370: to nil
2371: (foo (expr)) - bind foo to the argument if it is present, otherwise
2372: evaluate (expr) and bind foo to the result.
2373:
2374: (foo (expr) foo-p) - bind foo to the argument if it is present,
2375: otherwise evaluate (expr) and bind foo to the result.
2376: Also, bind foo-p to t if the argument is present, otherwise
2377: bind foo-p to nil. foo-p will be treated like an &aux
2378: variable (see below) but it should NOT be declared in the
2379: &aux list!
2380:
2381: rest-arg : a single symbol which will be bound to a list of the rest of the
2382: arguments. This list is cons'ed up each time the function is called.
2383:
2384: aux-args : these args are just like arguments to let or prog within the
2385: function body so this & keyword isn't really necessary (but there
2386: are few things in lisp that really are necessary).
2387:
2388: the forms of the aux arg are:
2389:
2390: foo - bind foo to nil
2391: (foo (expr)) - evaluate (expr) and bind foo to the result.
2392:
2393:
2394:
2395: The compiler understands the &keywords but the interpreter does not. 'def'
2396: will convert a form with &keywords to a lexpr which is almost equivalent.
2397: The differences are:
2398: The interpreted form, being a lexpr, is allowed to use the 'arg'
2399: function. The compiled form, even with optional args,
2400: is not a lexpr and thus 'arg' is illegal.
2401:
2402: The order that &aux variables are lambda bound is slightly different
2403: between interpreted and compiled code. As long as default
2404: expressions reference no formal parameters after them in the
2405: formal parameter list, there should be no problems.
2406:
2407: The interpreted version will not check for the correct number of
2408: arguments.
2409:
2410: Local functions cannot have &keywords.
2411:
2412: If you have any questions on this, send me mail. This change should
2413: only break functions which expect a variable number of argument and
2414: which don't declare the fact using &optional programs. There may be,
2415: of course, implementation errors. If you notice anything unusual
2416: please let me know right away. The old compiler will be
2417: in /usr/ucb/oliszt for a while.
2418:
2419:
2420:
2421:
2422:
2423:
2424:
2425:
2426:
2427: From layer Thu Jan 20 01:55:55 1983
2428: Date: 20-Jan-83 01:55:55-PST (Thu)
2429: From: layer (Kevin Layer)
2430: Subject: liszt 8.20
2431: Message-Id: <[email protected]>
2432: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2433: id AA17788; 20-Jan-83 01:55:55-PST (Thu)
2434: To: local-lisp
2435: Phone: (415) 652-2405
2436: Status: O
2437:
2438: There are now three new command line features for liszt:
2439:
2440: 1. -E <s-expr>, where <s-expr> will be evaluated before compilation
2441: starts. For example, the setting of constants can be done in this way:
2442:
2443: liszt -E '(setq foobar "***foobar-string***")' foobar.l
2444:
2445: and in the file being compiled, foobar is accessed as '#.foobar.
2446:
2447: 2. -I <include-file>, where <include-file> will be loaded (via load)
2448: before compilation starts.
2449:
2450: 3. A combination of the -S and -o switches will set the .s file, as in:
2451:
2452: liszt -S -o foo.vax.s foo.l
2453:
2454: where previously, the -S determined the name of the .s file (foo.s in
2455: the above example).
2456:
2457:
2458:
2459: From jkf Thu Jan 20 19:42:38 1983
2460: Date: 20-Jan-83 19:42:38-PST (Thu)
2461: From: jkf (John Foderaro)
2462: Subject: some mods to liszt 8.20
2463: Message-Id: <[email protected]>
2464: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2465: id AA07334; 20-Jan-83 19:42:38-PST (Thu)
2466: To: local-lisp
2467: Status: O
2468:
2469: the -E and -I flags are now -e and -i
2470: there may be more than one -i flag given on the command line.
2471:
2472:
2473:
2474: From fateman Thu Jan 20 20:20:31 1983
2475: To: local-lisp
2476: Subject: fame, if not fortune
2477: Status: RO
2478:
2479: In the latest Scientific American, Feb. 1983, Hofstader's column
2480: is the first of several on the programming language "lisp". He
2481: mentions the particular dialect he is using .... Franz !
2482:
2483: From wilensky Thu Jan 20 20:57:27 1983
2484: Date: 20-Jan-83 20:57:27-PST (Thu)
2485: From: wilensky (Robert Wilensky)
2486: Subject: Re: fame, if not fortune
2487: Message-Id: <[email protected]>
2488: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2489: id AA08824; 20-Jan-83 20:57:27-PST (Thu)
2490: To: fateman, local-lisp
2491: In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday)
2492: Status: RO
2493:
2494:
2495: On the other hand, being referenced by Hofstader is a dubious honor.
2496:
2497:
2498: From UCBKIM:jkf Fri Jan 21 08:15:04 1983
2499: Date: 21-Jan-83 08:11:01-PST (Fri)
2500: From: UCBKIM:jkf (John Foderaro)
2501: Subject: test message, ignore
2502: Message-Id: <[email protected]>
2503: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2504: id AA18650; 21-Jan-83 08:11:01-PST (Fri)
2505: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2506: id AA24887; 21 Jan 83 08:09:27 PST (Fri)
2507: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2508: id AA18766; 21-Jan-83 08:15:04-PST (Fri)
2509: To: franz-friends@BERKELEY
2510: Status: O
2511:
2512: This will give our mailer a chance to tell me how many of our franz friends
2513: are no longer reachable.
2514:
2515:
2516:
2517: From JTSCHUDY@USC-ISIE Sat Jan 22 16:42:19 1983
2518: Date: 22 Jan 1983 1634-PST
2519: From: JTSCHUDY@USC-ISIE
2520: Subject: MAILINGLIST ADDITION
2521: Message-Id: <[email protected]>
2522: Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2523: id AA01747; 22 Jan 83 16:37:17 PST (Sat)
2524: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2525: id AA18903; 22-Jan-83 16:42:19-PST (Sat)
2526: To: franz-friends@BERKELEY
2527: Status: O
2528:
2529: Hi! My name is Jim. I am presently attending the Naval Post Graduate
2530: School in Monterey California. I am in the Air Force enrolled in a
2531: DOD sponsored graduate degree in Command Control and Communications
2532: Systems Technology.
2533:
2534: i would like to be added to your mailing list. My net address is
2535: JTSCHUDY at ISIE.
2536:
2537: Thanks - Jim.
2538: -------
2539:
2540:
2541: From jkf Sat Jan 22 17:38:41 1983
2542: Date: 22-Jan-83 17:38:41-PST (Sat)
2543: From: jkf (John Foderaro)
2544: Subject: opus 38.49
2545: Message-Id: <[email protected]>
2546: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2547: id AA20020; 22-Jan-83 17:38:41-PST (Sat)
2548: To: local-lisp
2549: Status: O
2550:
2551: A longstanding bug in the determination of the number of free dtpr objects
2552: has been found and fixed. The effect of this bug was that the function
2553: which is responsible for allocating more memory pages didn't allocate
2554: enough dtpr pages because it thought that there were a large number of
2555: cells free.
2556:
2557:
2558:
2559: From MCLINDEN@RUTGERS Mon Jan 24 10:33:14 1983
2560: Date: 24 Jan 1983 1324-EST
2561: From: Sean McLinden <MCLINDEN@RUTGERS>
2562: Subject: Franz Lisp and floating point accelerator
2563: Message-Id: <[email protected]>
2564: Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2565: id AA19602; 24 Jan 83 10:25:06 PST (Mon)
2566: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2567: id AA27143; 24-Jan-83 10:33:14-PST (Mon)
2568: To: franz-friends@UCBVAX
2569: Status: O
2570:
2571:
2572: Has anyone determined if a floating point accelerator speeds up
2573: Vax Franz Lisp jobs in any significant fashion?
2574:
2575: Pointers would be appreciated.
2576:
2577: Sean McLinden
2578: Decision Systems Lab
2579: -------
2580:
2581: From mike@rand-unix Mon Jan 24 18:47:03 1983
2582: Date: Monday, 24 Jan 1983 15:34-PST
2583: From: mike@RAND-UNIX
2584: Subject: emacs interface to franz?
2585: Message-Id: <[email protected]>
2586: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2587: id AA00058; 24 Jan 83 16:08:36 PST (Mon)
2588: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2589: id AA00921; 24-Jan-83 18:47:03-PST (Mon)
2590: To: franz-friends@BERKELEY
2591: Status: O
2592:
2593:
2594: Does anyone have a snazzy interface to emacs for franz?
2595:
2596: Thanks,
2597: Michael
2598:
2599:
2600: From @udel-relay.ARPA,@UDel-Relay:[email protected] Tue Jan 25 16:29:19 1983
2601: Date: 25 Jan 1983 9:58-EST
2602: From: Tim Finin <Tim.UPenn@UDel-Relay>
2603: Subject: emacs interface to franz?
2604: Message-Id: <[email protected]>
2605: Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2606: id AA29320; 25 Jan 83 16:22:57 PST (Tue)
2607: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2608: id AA01561; 25-Jan-83 16:29:19-PST (Tue)
2609: Return-Path: <[email protected]@UDel-Relay>
2610: To: mike@Rand-Unix
2611: Cc: franz-friends@BERKELEY
2612: Via: UPenn; 25 Jan 83 19:21-EST
2613: Status: O
2614:
2615:
2616: We have a simple interface from Franz to Emacs, but I much prefer to go the
2617: other way, i.e. run Franz as a inferior job under Emacs. I believe there
2618: are several Emacs packages which allow one to run inferior jobs in an Emacs
2619: window (I have my own which is, unfortunately totally undocumented). Some of
2620: the benefits of this set up include:
2621:
2622: - one has all of the text editing functions available in Emacs
2623: - one has many lisp-based editing functions available in Emacs
2624: (thru mock-lisp packages like electriclisp)
2625: - one has a history of the session in the editing buffer
2626: - one has an environment which supports multiple concurrent
2627: processes running in seperate windows.
2628: - it is very easy to experiment with new interface features such as
2629: symbol completion and re-evaluation of previously issued commands
2630:
2631: Tim
2632:
2633:
2634: From CARR@UTAH-20 Fri Jan 28 08:19:08 1983
2635: Date: 28 Jan 1983 0912-MST
2636: From: Harold Carr <CARR@UTAH-20>
2637: Subject: franz distribution
2638: Message-Id: <[email protected]>
2639: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2640: id AA20646; 28 Jan 83 08:15:18 PST (Fri)
2641: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2642: id AA16991; 28-Jan-83 08:19:08-PST (Fri)
2643: To: franz-friends@UCBVAX
2644: Status: O
2645:
2646: What is the distribution policy?
2647:
2648: I work for a company that has opus 36 and is now currently running opus 37.
2649: Here at the University of Utah we are running opus 38.04. Is it OK to
2650: make a tape of the University's 38.04 to bring my company more up to
2651: date? Do I have to make it more formal by signing a transfer agreement
2652: or by obtaining the release directly from Berkeley?
2653:
2654: Thanks in advance,
2655: Harold Carr
2656: CARR@UTAH-20
2657: -------
2658:
2659: From UCBKIM:jkf Fri Jan 28 15:09:32 1983
2660: Date: 28-Jan-83 08:34:33-PST (Fri)
2661: From: UCBKIM:jkf
2662: Subject: Re: franz distribution
2663: Message-Id: <[email protected]>
2664: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2665: id AA17319; 28-Jan-83 08:34:33-PST (Fri)
2666: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2667: id AA02275; 28 Jan 83 14:58:37 PST (Fri)
2668: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2669: id AA00402; 28-Jan-83 15:09:32-PST (Fri)
2670: To: CARR@UTAH-20
2671: Cc: franz-friends@UCBVAX
2672: In-Reply-To: Your message of 28 Jan 1983 0912-MST
2673: Status: O
2674:
2675: Here is our current distribution policy. This differs a bit from
2676: the one sent out a month ago [in particular, we now have anonymous ftp]
2677:
2678: -[Fri Jan 28 08:31:45 1983 by jkf]-
2679: Franz Lisp Distribution
2680:
2681: This note describes our distribution policy for Franz Lisp.
2682:
2683: What is being distributed:
2684: We distribute only source code in order to keep the distribution
2685: small and relatively Unix independent. Makefiles are provided to
2686: build the entire lisp system from source, even if you don't have
2687: a version of lisp running already. This process takes about 3 cpu
2688: hours on a Vax 780. [This version for the Vax only, a 68000 version
2689: is being worked on. Contact ucbkim.sklower@berkeley or
2690: ucbkim.layer@berkeley]
2691:
2692: The following source is provided:
2693: lisp interpreter,
2694: compiler (liszt),
2695: cross reference program (lxref),
2696: lisp manual,
2697: and other utility programs:
2698: trace, step, debug, cmu library functions, (and other minor ones),
2699: and these packages from the MIT lisp library:
2700: defstruct, loop.
2701: [These programs are provided as a convenience to those who can't
2702: access the arpanet and copy them. There is no documentation for
2703: them in the Franz Lisp manual. The best source of documentation
2704: is the Lisp Machine manual (available from MIT, Symbolics
2705: or LMI)]
2706:
2707: Regarding Flavors: there are two implementations of flavors for
2708: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
2709: and one from the University of Maryland (contact person
2710: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
2711: exactly like flavors on the Lisp Machine (due to differences between
2712: Lisp Machine lisp and Franz Lisp), and the implementations differ
2713: from each other. The MIT version cannot be distributed by
2714: us (yet) due to licensing problems. If you have a Lisp Machine
2715: Source license from Symbolics, you should be able to get a copy
2716: from MIT.
2717: For a Tech Report on Maryland flavors, write to Liz Allen.
2718:
2719: What is the form of the distribution:
2720: The files are packaged in a giant (2.1Mbyte) shell script. Running this
2721: shell script through 'sh' will result in a directory tree. A ReadMe file
2722: in the current directory will contain instructions on building the lisp
2723: system. The shell script is broken into a number of smaller files.
2724: The current distribution looks like:
2725:
2726: total 2089
2727: 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
2728: 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
2729: 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
2730: 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
2731: 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
2732:
2733: The '38.50' means Opus 38, minor version 50. These numbers may be different
2734: by the time you get your distribution. In order to extract the lisp
2735: files from this shell script, you need only type:
2736: cat * | sh
2737:
2738:
2739: To get a copy of the distribution:
2740: The distribution may be obtained either using FTP from an arpanet site,
2741: or on a magnetic tape through the U.S Mail.
2742:
2743: Arpanet:
2744: The files are stored on the arpanet host 'ucb-vax' [ if you have an out
2745: of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
2746: internet number is 10.2.0.78].
2747: You can login as 'anonymous'. Use your name as the password.
2748: The files are in the subdirectory pub/lisp.
2749:
2750: For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
2751:
2752: Mag Tape:
2753: In order to get a copy of the distribution mailed to you, send a check to
2754: cover our tape copying and mailing costs (fees are listed below). We will
2755: purchase the mag tape and you are free to keep it. Please do NOT
2756: send us a tape.
2757:
2758: Fees:
2759: $50 - distribution tape mailed 3rd class
2760: add $10 - a copy of the Lisp Manual (we will only
2761: send one copy, you are free to photocopy it)
2762: add $7 - send tape via 1st class mail.
2763:
2764: -or-
2765: $15 - for just a copy of the Lisp Manual
2766:
2767: The address to send checks to is
2768:
2769: Keith Sklower
2770: EECS/Computer Science Division
2771: 524 Evans Hall
2772: University of California
2773: Berkeley, CA 94720
2774:
2775: All checks should be made out to "Regents, University of California."
2776: We require pre-payment. We will not invoice or process purchase orders.
2777:
2778:
2779:
2780: Disclaimers:
2781: This distribution works on the latest versions of Unix running at
2782: Berkeley (4.1a). We can't guarantee that it will work on older
2783: versions (although, if you are running 4.1, it is almost certain
2784: that it will work, but we have not verified it).
2785: VMS users who are using a typical Unix compatibility package will
2786: probably not be able to build a lisp from this distribution unless they
2787: know a great deal about VMS and their compatibility package.
2788: At least one package (Eunice) supports Franz at this time.
2789:
2790: Redistribution:
2791: If you get a copy of the distribution, you are free to give it to
2792: other people. We appreciate being informed of new sites so they
2793: can be put on a mailing list (electronic and conventional). This
2794: list is used to announce new releases. To be put on this list,
2795: send U.S. Mail to Keith Sklower (address above) or to
2796: franz-friends-request@berkeley or ucbvax!franz-friends-request
2797:
2798:
2799:
2800: From Kim:fateman Sun Jan 30 02:12:28 1983
2801: Date: 28 Jan 83 08:32:08 PST (Fri)
2802: From: Kim:fateman (Richard Fateman)
2803: Subject: Re: franz distribution
2804: Message-Id: <[email protected]>
2805: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2806: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
2807: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2808: id AA10132; 30-Jan-83 02:12:28-PST (Sun)
2809: To: CARR@UTAH-20
2810: Cc: franz-friends@ucbvax
2811: Status: O
2812:
2813: Our policy is that you may move copies of Franz elsewhere
2814: without notifying us. We continue to be interested in sharing anything
2815: you or your company wish to provide us, in suggestions, programs, etc.
2816:
2817:
2818: From UCBCAD:pettengi Sun Jan 30 02:33:52 1983
2819: Date: 28-Jan-83 10:54:51-PST (Fri)
2820: From: UCBCAD:pettengi (Rob Pettengill)
2821: Subject: emacs interface to franz?
2822: Message-Id: <[email protected]>
2823: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
2824: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
2825: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2826: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
2827: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2828: id AA10578; 30-Jan-83 02:33:52-PST (Sun)
2829: To: mike@rand-unix, franz-friends@ucbvax
2830: Cc: pettengi@UCBCAD
2831: Status: O
2832:
2833: While I was at TI I used a very nice interface that let one start up
2834: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
2835: under our VMS. Try Kashtan@SRI-AI.
2836:
2837: Rob Pettengill
2838: E-Systems, Dallas, Tx.
2839:
2840: From UCBKIM:jkf Sun Jan 30 02:44:27 1983
2841: Date: 28-Jan-83 08:34:33-PST (Fri)
2842: From: UCBKIM:jkf (John Foderaro)
2843: Subject: Re: franz distribution
2844: Message-Id: <[email protected]>
2845: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2846: id AA17319; 28-Jan-83 08:34:33-PST (Fri)
2847: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2848: id AA02275; 28 Jan 83 14:58:37 PST (Fri)
2849: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2850: id AA10772; 30-Jan-83 02:44:27-PST (Sun)
2851: To: CARR@UTAH-20
2852: Cc: franz-friends@UCBVAX
2853: In-Reply-To: Your message of 28 Jan 1983 0912-MST
2854: Status: RO
2855:
2856: Here is our current distribution policy. This differs a bit from
2857: the one sent out a month ago [in particular, we now have anonymous ftp]
2858:
2859: -[Fri Jan 28 08:31:45 1983 by jkf]-
2860: Franz Lisp Distribution
2861:
2862: This note describes our distribution policy for Franz Lisp.
2863:
2864: What is being distributed:
2865: We distribute only source code in order to keep the distribution
2866: small and relatively Unix independent. Makefiles are provided to
2867: build the entire lisp system from source, even if you don't have
2868: a version of lisp running already. This process takes about 3 cpu
2869: hours on a Vax 780. [This version for the Vax only, a 68000 version
2870: is being worked on. Contact ucbkim.sklower@berkeley or
2871: ucbkim.layer@berkeley]
2872:
2873: The following source is provided:
2874: lisp interpreter,
2875: compiler (liszt),
2876: cross reference program (lxref),
2877: lisp manual,
2878: and other utility programs:
2879: trace, step, debug, cmu library functions, (and other minor ones),
2880: and these packages from the MIT lisp library:
2881: defstruct, loop.
2882: [These programs are provided as a convenience to those who can't
2883: access the arpanet and copy them. There is no documentation for
2884: them in the Franz Lisp manual. The best source of documentation
2885: is the Lisp Machine manual (available from MIT, Symbolics
2886: or LMI)]
2887:
2888: Regarding Flavors: there are two implementations of flavors for
2889: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
2890: and one from the University of Maryland (contact person
2891: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
2892: exactly like flavors on the Lisp Machine (due to differences between
2893: Lisp Machine lisp and Franz Lisp), and the implementations differ
2894: from each other. The MIT version cannot be distributed by
2895: us (yet) due to licensing problems. If you have a Lisp Machine
2896: Source license from Symbolics, you should be able to get a copy
2897: from MIT.
2898: For a Tech Report on Maryland flavors, write to Liz Allen.
2899:
2900: What is the form of the distribution:
2901: The files are packaged in a giant (2.1Mbyte) shell script. Running this
2902: shell script through 'sh' will result in a directory tree. A ReadMe file
2903: in the current directory will contain instructions on building the lisp
2904: system. The shell script is broken into a number of smaller files.
2905: The current distribution looks like:
2906:
2907: total 2089
2908: 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
2909: 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
2910: 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
2911: 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
2912: 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
2913:
2914: The '38.50' means Opus 38, minor version 50. These numbers may be different
2915: by the time you get your distribution. In order to extract the lisp
2916: files from this shell script, you need only type:
2917: cat * | sh
2918:
2919:
2920: To get a copy of the distribution:
2921: The distribution may be obtained either using FTP from an arpanet site,
2922: or on a magnetic tape through the U.S Mail.
2923:
2924: Arpanet:
2925: The files are stored on the arpanet host 'ucb-vax' [ if you have an out
2926: of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
2927: internet number is 10.2.0.78].
2928: You can login as 'anonymous'. Use your name as the password.
2929: The files are in the subdirectory pub/lisp.
2930:
2931: For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
2932:
2933: Mag Tape:
2934: In order to get a copy of the distribution mailed to you, send a check to
2935: cover our tape copying and mailing costs (fees are listed below). We will
2936: purchase the mag tape and you are free to keep it. Please do NOT
2937: send us a tape.
2938:
2939: Fees:
2940: $50 - distribution tape mailed 3rd class
2941: add $10 - a copy of the Lisp Manual (we will only
2942: send one copy, you are free to photocopy it)
2943: add $7 - send tape via 1st class mail.
2944:
2945: -or-
2946: $15 - for just a copy of the Lisp Manual
2947:
2948: The address to send checks to is
2949:
2950: Keith Sklower
2951: EECS/Computer Science Division
2952: 524 Evans Hall
2953: University of California
2954: Berkeley, CA 94720
2955:
2956: All checks should be made out to "Regents, University of California."
2957: We require pre-payment. We will not invoice or process purchase orders.
2958:
2959:
2960:
2961: Disclaimers:
2962: This distribution works on the latest versions of Unix running at
2963: Berkeley (4.1a). We can't guarantee that it will work on older
2964: versions (although, if you are running 4.1, it is almost certain
2965: that it will work, but we have not verified it).
2966: VMS users who are using a typical Unix compatibility package will
2967: probably not be able to build a lisp from this distribution unless they
2968: know a great deal about VMS and their compatibility package.
2969: At least one package (Eunice) supports Franz at this time.
2970:
2971: Redistribution:
2972: If you get a copy of the distribution, you are free to give it to
2973: other people. We appreciate being informed of new sites so they
2974: can be put on a mailing list (electronic and conventional). This
2975: list is used to announce new releases. To be put on this list,
2976: send U.S. Mail to Keith Sklower (address above) or to
2977: franz-friends-request@berkeley or ucbvax!franz-friends-request
2978:
2979:
2980:
2981: From Kim:fateman Mon Jan 31 19:30:20 1983
2982: Date: 28 Jan 83 08:32:08 PST (Fri)
2983: From: Kim:fateman (Richard Fateman)
2984: Subject: Re: franz distribution
2985: Message-Id: <[email protected]>
2986: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2987: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
2988: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2989: id AA03502; 31-Jan-83 19:30:20-PST (Mon)
2990: To: CARR@UTAH-20
2991: Cc: franz-friends@ucbvax
2992: Status: O
2993:
2994: Our policy is that you may move copies of Franz elsewhere
2995: without notifying us. We continue to be interested in sharing anything
2996: you or your company wish to provide us, in suggestions, programs, etc.
2997:
2998:
2999: From UCBCAD:pettengi Mon Jan 31 19:55:02 1983
3000: Date: 28-Jan-83 10:54:51-PST (Fri)
3001: From: UCBCAD:pettengi (Rob Pettengill)
3002: Subject: emacs interface to franz?
3003: Message-Id: <[email protected]>
3004: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
3005: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
3006: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3007: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
3008: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3009: id AA03987; 31-Jan-83 19:55:02-PST (Mon)
3010: To: mike@rand-unix, franz-friends@ucbvax
3011: Cc: pettengi@UCBCAD
3012: Status: O
3013:
3014: While I was at TI I used a very nice interface that let one start up
3015: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
3016: under our VMS. Try Kashtan@SRI-AI.
3017:
3018: Rob Pettengill
3019: E-Systems, Dallas, Tx.
3020:
3021: From Kim:fateman Mon Jan 31 21:34:44 1983
3022: Date: 28 Jan 83 08:32:08 PST (Fri)
3023: From: Kim:fateman (Richard Fateman)
3024: Subject: Re: franz distribution
3025: Message-Id: <[email protected]>
3026: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3027: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
3028: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3029: id AA00642; 31-Jan-83 21:34:44-PST (Mon)
3030: To: CARR@UTAH-20
3031: Cc: franz-friends@ucbvax
3032: Status: RO
3033:
3034: Our policy is that you may move copies of Franz elsewhere
3035: without notifying us. We continue to be interested in sharing anything
3036: you or your company wish to provide us, in suggestions, programs, etc.
3037:
3038:
3039: From UCBCAD:pettengi Mon Jan 31 22:12:30 1983
3040: Date: 28-Jan-83 10:54:51-PST (Fri)
3041: From: UCBCAD:pettengi (Rob Pettengill)
3042: Subject: emacs interface to franz?
3043: Message-Id: <[email protected]>
3044: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
3045: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
3046: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3047: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
3048: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3049: id AA01266; 31-Jan-83 22:12:30-PST (Mon)
3050: To: mike@rand-unix, franz-friends@ucbvax
3051: Cc: pettengi@UCBCAD
3052: Status: O
3053:
3054: While I was at TI I used a very nice interface that let one start up
3055: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
3056: under our VMS. Try Kashtan@SRI-AI.
3057:
3058: Rob Pettengill
3059: E-Systems, Dallas, Tx.
3060:
3061: From UCBKIM:jkf Tue Feb 1 10:35:21 1983
3062: Date: 1-Feb-83 10:32:24-PST (Tue)
3063: From: UCBKIM:jkf (John Foderaro)
3064: Subject: multiple messages
3065: Message-Id: <[email protected]>
3066: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3067: id AA00599; 1-Feb-83 10:32:24-PST (Tue)
3068: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3069: id AA00473; 1 Feb 83 10:32:35 PST (Tue)
3070: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3071: id AA00644; 1-Feb-83 10:35:21-PST (Tue)
3072: To: franz-friends@ucbvax
3073: Status: RO
3074:
3075: I'm sorry for the multiple messages. The franz-friends mailing list is
3076: huge and the machine which does the mailing is crashing often. Our local
3077: mail wizard informs me that if it crashes while in the middle of sending
3078: mail it will not have a record of who it sent to before the crash.
3079: I hope you don't get too many copies of this message.
3080:
3081:
3082:
3083:
3084:
3085: From mike@rand-unix Wed Feb 2 05:33:01 1983
3086: Date: Tuesday, 1 Feb 1983 15:06-PST
3087: From: mike@RAND-UNIX
3088: Subject: response to "emacs interface to franz?"
3089: Message-Id: <[email protected]>
3090: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3091: id AA00221; 2 Feb 83 05:25:50 PST (Wed)
3092: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3093: id AA24463; 2-Feb-83 05:33:01-PST (Wed)
3094: To: franz-friends@BERKELEY
3095: Cc: mike@RAND-UNIX
3096: Status: RO
3097:
3098:
3099: Here are the responses that I received to my question "What's out
3100: there for emacs?"
3101:
3102:
3103: ------- Forwarded Messages
3104:
3105: Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983
3106: Date: Mon 24 Jan 83 22:43:01-PST
3107: From: Jay Lark <[email protected]>
3108: Subject: Re: emacs interface to franz?
3109: To: [email protected]
3110: In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST
3111:
3112: I'm sure you've probably received several messages similar to this one,
3113: but just in case...
3114:
3115: There exists the capability in Unix Emacs to run a process in its own
3116: buffer. Typein can be directed to the process, and output is just sent
3117: right to the buffer. This is an excellent way of running Lisp, because
3118: you get all of the nice Emacs features (paren balancing, local sexpr
3119: editing) at essentially no cost. I have been largely unsuccessful with
3120: trying to run Emacs under Lisp.
3121:
3122: The process package is part of the standard Unix Emacs distribution.
3123:
3124: Jay Lark
3125: -------
3126:
3127:
3128: ------- Message 2
3129:
3130: Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983
3131: Date: 25 Jan 1983 7:20-MST
3132: From: Russ Fish <utah-gr!fish@UTAH-CS> (host 10.0.0.4)
3133: Subject: Re: emacs interface to franz?
3134: To: mike@RAND-UNIX
3135: Cc: utah-gr!galway@UTAH-CS
3136: In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST
3137:
3138: We have been running our PSL (Portable Standard Lisp) in gemacs
3139: (Gosling's emacs) windows for some time. I suspect it would be a minor
3140: hack to convert it to Franz, but haven't done it and am not a Franz
3141: user. I could mail you our .ml code if you wanted to undertake
3142: converting it to Franz (or just using it for inspiration and hacking
3143: your own) and distributing it to Franz folks.
3144:
3145: It works like this: The lisp process is associated with a gemacs
3146: buffer/window. In that window you can carry on a normal line-by-line
3147: conversation, if you wish. <CR> sends the current line, (back to mark,
3148: which is left after the prompt) into the lisp. We mostly use the PSL
3149: in Rlisp syntax, which is algol-like, but this part of the code is just
3150: a wrapping for the new-shell function in process.ml with appropriate
3151: editting syntax set, so you could do the same with no work for any
3152: Lisp.
3153:
3154: You can send an expression, fn def, etc. from any other lisp-mode
3155: window with a single keypress. Echoing as input in the dialog window
3156: is inhibited if a prefix arg is provided, so you don't have to look at
3157: long exprs or fn defs again, just the lisp response.
3158:
3159: Sending multiple line exprs in response to a single prompt depends on
3160: the fact that PSL numbers the prompts for history, like the c-shell. A
3161: gemacs mlisp output filter process monitors the output for toploop
3162: prompts and feeds another line of input if the same prompt number comes
3163: back, instead of printing the prompt.
3164:
3165: The result is pretty classy. You get the full many-window gemacs
3166: editing environment with tags, etc. for random-access navigation and
3167: just send chunks of code as you change them. The extreme of usage is
3168: "menu" like windows which contain debugging code in clusters rather
3169: than sequences. You select exprs with the cursor and send them in any
3170: order.
3171:
3172: We also provide key fns for the common case of sending single lines to
3173: the toploop or single-character commands to the break-loop without
3174: editting them into a buffer.
3175:
3176: Best respond directly to me, since I am not on Franz-Friends.
3177:
3178: -Russ Fish (Fish@Utah-20, utah-cs!fish)
3179:
3180:
3181:
3182: ------- Message 3
3183:
3184: Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983
3185: Return-Path: <israel.umcp-cs@UDel-Relay>
3186: Date: 25 Jan 83 15:13:51 EST (Tue)
3187: From: Bruce Israel <israel.umcp-cs@UDel-Relay>
3188: Subject: Re: emacs interface to franz?
3189: To: mike@RAND-UNIX
3190: In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX
3191: <[email protected]>
3192: Via: UMCP-CS; 25 Jan 83 20:45-EST
3193:
3194: We have a few franz<->emacs interfaces, but I'm not sure what you mean.
3195: One is the process.ml package that comes with gosling's emacs (the emacs
3196: that I assume you are talking about). With this package, you can run
3197: franz inside a window from within emacs and have the facilities of an
3198: editor along with lisp. The other thing we have is a local Franz
3199: package called the load1 package. This package was written for
3200: compiling flavors (like in the lisp machine; another local package)
3201: and has a function called vi. (vi 'lisp-function) will call the
3202: editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the
3203: file which contains the definition of the lisp function, positioning
3204: the editor at the point in the file where the function is defined. Upon
3205: exiting the editor, it asks you if you want to reload the modified file.
3206: To edit a function from a file this way, the file must have been load1'ed
3207: previously so that the info on where the function is stored and what type
3208: it is will have been saved. Load1 will distinguish between different
3209: types of functions, ie. defflavors, defmethods, defmacros, defuns etc.
3210: and will search for the correct definition in the file. Is this what
3211: you mean? If you like I can send you the four or five files necessary.
3212: - Bruce
3213:
3214:
3215: ------- Message 4
3216:
3217: Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983
3218: Date: 27 Jan 1983 09:44-EST
3219: From: Carl.Ebeling@CMU-CS-VLSI
3220: Subject: Re: emacs interface to franz?
3221: To: mike@RAND-UNIX
3222: Message-Id: <412526661/ce@CMU-CS-VLSI>
3223: In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14
3224:
3225: I have an electric lisp package and process package for emacs. It
3226: includes 'zap-function-to-lisp' among other things. It is for
3227: Gosling's emacs and uses the subprocess facility. I can mail them to
3228: you if you like.
3229: Carl
3230:
3231:
3232: ------- End of Forwarded Messages
3233:
3234: From UCBKIM:jkf Wed Feb 2 08:19:19 1983
3235: Date: 2-Feb-83 08:14:21-PST (Wed)
3236: From: UCBKIM:jkf (John Foderaro)
3237: Subject: multiple messages fixed?
3238: Message-Id: <[email protected]>
3239: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3240: id AA25937; 2-Feb-83 08:14:21-PST (Wed)
3241: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3242: id AA00384; 2 Feb 83 08:10:26 PST (Wed)
3243: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3244: id AA00477; 2 Feb 83 08:14:35 PST (Wed)
3245: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3246: id AA26020; 2-Feb-83 08:19:19-PST (Wed)
3247: To: franz-friends@ucbvax
3248: Status: RO
3249:
3250: I've broken the franz-friends mailing list over two machines. I hope that
3251: this will fix the problem of mail to franz-friends crashing ucbvax every
3252: thirty minutes. If you get multiple copies of this message, please do not
3253: tell me about it, I will already know.
3254:
3255:
3256:
3257:
3258: From jkf Thu Feb 10 21:45:17 1983
3259: Date: 10-Feb-83 21:45:17-PST (Thu)
3260: From: jkf (John Foderaro)
3261: Subject: liszt 8.21
3262: Message-Id: <[email protected]>
3263: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3264: id AA16021; 10-Feb-83 21:45:17-PST (Thu)
3265: To: local-lisp
3266: Status: O
3267:
3268: more functions open coded: vsize, vsize-byte, vsize-word,
3269: vectorp, vectorip
3270:
3271:
3272:
3273: From PSI.KROHNFELDT@UTAH-20 Fri Feb 11 15:09:11 1983
3274: Date: 11 Feb 1983 1601-MST
3275: From: Jed Krohnfeldt <PSI.KROHNFELDT@UTAH-20>
3276: Subject: cfasl
3277: Message-Id: <[email protected]>
3278: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3279: id AA07475; 11 Feb 83 15:02:05 PST (Fri)
3280: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3281: id AA07565; 11 Feb 83 15:06:37 PST (Fri)
3282: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3283: id AA14422; 11-Feb-83 15:09:11-PST (Fri)
3284: To: Franz-friends@UCBVAX
3285: Status: O
3286:
3287: I am having trouble using cfasl in franz 38.04. I keep getting the
3288: message "ld: /usr/ucb/lisp : no namelist". Can anyone decipher this
3289: for me? Thanks...
3290: -------
3291:
3292: From apm@cmu-ri-isl Mon Feb 14 07:31:54 1983
3293: Date: 14 Feb 1983 10:24:21-EST
3294: From: Andrew.Mendler@CMU-RI-ISL
3295: Subject: franz lisp under5 vms 3.0
3296: Message-Id: <[email protected]>
3297: Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3)
3298: id AA27879; 14 Feb 83 07:31:54 PST (Mon)
3299: Received: by UCBKIM.ARPA (3.310/3.3)
3300: id AA01172; 14 Feb 83 15:50:41 PST (Mon)
3301: To: [email protected]
3302: Status: O
3303:
3304: Does anyone have a copy of Franz Lisp and the compiler that works under
3305: VMS version 3.0?
3306:
3307: From @udel-relay:tim.unc@UDel-Relay Mon Feb 14 02:52:18 1983
3308: Date: 13 Feb 83 14:34:48 EST (Sun)
3309: From: Tim Maroney <tim.unc@UDel-Relay>
3310: Subject: cfasl: no namelist
3311: Return-Path: <tim.unc@UDel-Relay>
3312: Message-Id: <[email protected]>
3313: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3)
3314: id AA25792; 14 Feb 83 02:52:18 PST (Mon)
3315: Received: by UCBKIM.ARPA (3.310/3.3)
3316: id AA02234; 14 Feb 83 16:18:42 PST (Mon)
3317: To: [email protected]
3318: Via: UNC; 14 Feb 83 5:43-EST
3319: Status: O
3320:
3321: I don't seem to be able to write Jed Krohnfeldt, and this
3322: answer is probably of general interest anyway. The message
3323: "ld: no namelist" means that some well-meaning system admin
3324: has stripped the lisp executable file to save space;
3325: unfortunately, this makes the dynamic loading used by cfasl
3326: impossible. Lisp will have to be recompiled (groan). No Franz
3327: Lisp executable file should EVER be stripped.
3328:
3329: Tim Maroney
3330: tim.unc@udel-relay
3331: decvax!duke!unc!tim
3332:
3333: From Mark.Sherman@CMU-CS-A Sat Feb 12 21:38:46 1983
3334: Date: 13 February 1983 0034-EST (Sunday)
3335: From: Mark.Sherman@CMU-CS-A
3336: Subject: Space and Leakage
3337: Message-Id: <13Feb83 003422 MS40@CMU-CS-A>
3338: Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3339: id AA07842; 12 Feb 83 21:38:46 PST (Sat)
3340: Received: by UCBKIM.ARPA (3.310/3.3)
3341: id AA02341; 14 Feb 83 16:21:29 PST (Mon)
3342: To: franz-friends@UCB-VAX
3343: Status: O
3344:
3345: Can someone tell me how the maximum amount of storage that franz
3346: lisp uses is decided? I can force the size up to (about) 3050
3347: pages (according to "ps") and then get the message "storage exhausted".
3348: I have been told (and have seen) other jobs get substantially more
3349: space; can franz get more pages as well? (I am using the cshell
3350: and have already used the limit command to raise my process
3351: size up to 32 megabytes, or so I think.)
3352:
3353: I have also been told that the garbage collector leaks, that is,
3354: not all of the garbage is really collected. Does anyone have good
3355: ideas about how much (or fast) this happens, or if there is some way
3356: to minimize the lost space?
3357:
3358: (Please send responses directly to me as I am not on this list.)
3359: -Mark Sherman (Sherman@CMU-CS-A)
3360:
3361: From @udel-relay:Mac.uvacs.Virginia@UDel-Relay Fri Feb 18 21:04:31 1983
3362: Date: 18 Feb 83 12:42:40-EST (Fri)
3363: From: Mac.uvacs@UDel-Relay
3364: Subject: global nonspecial variables
3365: Return-Path: <Mac.uvacs.Virginia@UDel-Relay>
3366: Message-Id: <[email protected]>
3367: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5)
3368: id AA26020; 18 Feb 83 21:04:31 PST (Fri)
3369: Received: by UCBKIM.ARPA (3.310/3.5)
3370: id AA00656; 21 Feb 83 01:59:26 PST (Mon)
3371: To: [email protected]
3372: Via: Virginia; 18 Feb 83 23:58-EST
3373: Status: O
3374:
3375: Does the Liszt compiler have any notion of global variables --
3376: free variables with fast access, without any rebinding?
3377:
3378: I think the MACLISP compiler has something like this for variables
3379: beginning "**".
3380:
3381: Alex Colvin
3382:
3383: uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac
3384: csnet:mac@virginia
3385: arpa: mac.uvacs@udel-relay
3386:
3387: From jkf@UCBKIM Mon Feb 21 09:19:56 1983
3388: Date: 21 Feb 83 09:19:43 PST (Mon)
3389: From: jkf@UCBKIM (John Foderaro)
3390: Subject: Re: global nonspecial variables
3391: Message-Id: <[email protected]>
3392: Received: by UCBKIM.ARPA (3.310/3.5)
3393: id AA02798; 21 Feb 83 09:19:43 PST (Mon)
3394: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
3395: id AA13982; 21 Feb 83 09:11:52 PST (Mon)
3396: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3397: id AA02805; 21 Feb 83 09:19:56 PST (Mon)
3398: To: Mac.uvacs@UDel-Relay, [email protected]
3399: In-Reply-To: Your message of 18 Feb 83 12:42:40-EST (Fri)
3400: Status: O
3401:
3402: I don't understand the distinction between what you call a global variable
3403: and a special variable. A special variable in Franz Lisp (and any other
3404: shallow bound lisp) can be accessed rapidly and is only rebound if you
3405: put it in a lambda, prog or do variable list.
3406:
3407:
3408:
3409: From jkf@UCBKIM Fri Feb 25 08:29:01 1983
3410: Date: 25 Feb 83 08:28:45 PST (Fri)
3411: From: jkf@UCBKIM (John Foderaro)
3412: Subject: research position at edinburgh
3413: Message-Id: <[email protected]>
3414: Received: by UCBKIM.ARPA (3.310/3.5)
3415: id AA00528; 25 Feb 83 08:28:45 PST (Fri)
3416: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
3417: id AA00867; 25 Feb 83 08:18:48 PST (Fri)
3418: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3419: id AA00537; 25 Feb 83 08:29:01 PST (Fri)
3420: To: [email protected]
3421: Status: O
3422:
3423:
3424: DEPARTMENT OF ARTIFICIAL INTELLIGENCE
3425: UNIVERSITY OF EDINBURGH
3426:
3427: RESEARCH FELLOW
3428:
3429: A Research Fellowship is available within the Programming Systems Development
3430: Group. The post has been created specifically to provide a modern LISP system
3431: for the Perq computer running under ICL MicroCode UNIX, and is funded by the
3432: Science and Engineering Research Council.
3433:
3434: Experience in implementing systems would be advantageous, as would be a
3435: knowledge of LISP and C. Access will be available to an SERC DECsystem-10
3436: running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as
3437: to Perqs.
3438:
3439: The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds
3440: sterling, according to age and experience. The post is funded for a period of
3441: two years from the date of appointment.
3442:
3443: Further particulars of the post can be obtained from:
3444:
3445: Administrative Assistant
3446: Department of Artificial Intelligence
3447: University of Edinburgh
3448: Forrest Hill
3449: Edinburgh EH1 2QL
3450: SCOTLAND
3451: phone
3452: 031-667-1011 x2554
3453:
3454: or by contacting
3455:
3456: RAE%EDXA%UCL-CS@ISID (Networks permitting)
3457:
3458: Applications should be made by March 17th, 1983.
3459:
3460:
3461:
3462:
3463: From layer Sat Mar 5 20:12:57 1983
3464: Date: 5 Mar 83 20:12:57 PST (Sat)
3465: From: layer (Kevin Layer)
3466: Subject: process function
3467: Message-Id: <[email protected]>
3468: Received: by UCBKIM.ARPA (3.310/3.5)
3469: id AA18927; 5 Mar 83 20:12:57 PST (Sat)
3470: Phone: (415) 652-2405
3471: To: local-lisp
3472: Status: O
3473:
3474: The process function now looks in the environment at the SHELL variable.
3475: If present, it will use this as the default shell to execute your command.
3476: If not present, csh and then sh are tried (in that order).
3477:
3478:
3479: From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay Tue Mar 8 06:04:10 1983
3480: Date: 8 Mar 1983 2:32-EST
3481: From: Susan Pintzuk <Pintzuk.UPenn@UDel-Relay>
3482: Subject: lisp statistical packages
3483: Return-Path: <Pintzuk.UPenn.UPenn@UDel-Relay>
3484: Message-Id: <[email protected]>
3485: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14)
3486: id AA13004; 8 Mar 83 06:01:54 PST (Tue)
3487: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3488: id AA08297; 8 Mar 83 06:04:10 PST (Tue)
3489: To: [email protected]
3490: Via: UPenn; 8 Mar 83 3:49-EST
3491: Status: O
3492:
3493: do any franz-lisp packages exist which calculate mean, standard deviation,
3494: %n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.? if so, how
3495: do i obtain a copy?
3496:
3497: From jkf Tue Mar 8 09:10:46 1983
3498: Date: 8 Mar 83 09:10:46 PST (Tue)
3499: From: jkf (John Foderaro)
3500: Subject: opus38.56
3501: Message-Id: <[email protected]>
3502: Received: by UCBKIM.ARPA (3.310/3.5)
3503: id AA09423; 8 Mar 83 09:10:46 PST (Tue)
3504: To: local-lisp
3505: Status: O
3506:
3507: If $gcprint is set to a non nil value, then just before a garbage
3508: collection is begun, the message 'gc:' will be printed on the tty.
3509: As before, after the garbage collection is finished, the statistics
3510: message in square brackets will be printed.
3511:
3512:
3513:
3514: From fateman Wed Mar 9 09:54:31 1983
3515: Date: 9 Mar 83 09:54:31 PST (Wed)
3516: From: fateman (Richard Fateman)
3517: Subject: need a job
3518: Message-Id: <[email protected]>
3519: Received: by UCBKIM.ARPA (3.310/3.5)
3520: id AA14754; 9 Mar 83 09:54:31 PST (Wed)
3521: To: local-lisp
3522: Status: O
3523:
3524: porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP
3525: computer? Wanna live in Denver? There is a recruiter in
3526: town from Denelcor at Marriot Inn, Jim Holly. There is an
3527: ad posted on 5th floor bulletin board.
3528:
3529: From jkf Sat Mar 19 17:44:33 1983
3530: Date: 19 Mar 83 17:44:33 PST (Sat)
3531: From: jkf (John Foderaro)
3532: Subject: liszt 8.24
3533: Message-Id: <[email protected]>
3534: Received: by UCBKIM.ARPA (3.310/3.5)
3535: id AA25091; 19 Mar 83 17:44:33 PST (Sat)
3536: To: local-lisp
3537: Status: O
3538:
3539: The vax and 68k versions of liszt have been combined into one set of
3540: source files. This is mainly a textual change, but some functions
3541: in the compiler have been modified in reduce the machine dependent code.
3542: Be on the lookout for strange errors.
3543:
3544:
3545:
3546: From fateman Tue Mar 22 20:52:11 1983
3547: Date: 22 Mar 83 20:52:11 PST (Tue)
3548: From: fateman (Richard Fateman)
3549: Subject: T Lisp
3550: Message-Id: <[email protected]>
3551: Received: by UCBKIM.ARPA (3.310/3.5)
3552: id AA05935; 22 Mar 83 20:52:11 PST (Tue)
3553: To: local-lisp
3554: Status: RO
3555:
3556: I have a preliminary manual for the T dialect of Lisp, created
3557: at Yale. It is being offered for sale by Cognitive Systems, Inc.
3558: for $1000/CPU (educational price). It offers features from Lisp
3559: and Scheme. It runs on VAX and Apollo 68000 systems.
3560:
3561: From jkf Thu Mar 24 08:29:31 1983
3562: Date: 24 Mar 83 08:29:31 PST (Thu)
3563: From: jkf (John Foderaro)
3564: Subject: liszt 8.25
3565: Message-Id: <[email protected]>
3566: Received: by UCBKIM.ARPA (3.310/3.5)
3567: id AA06735; 24 Mar 83 08:29:31 PST (Thu)
3568: To: local-lisp
3569: Status: O
3570:
3571:
3572: If you do this:
3573:
3574: liszt -x a/b/c.l -o x/y/z.o
3575:
3576: then the cross reference file will be put in x/y/z.x
3577: Before this version, it would have gone into a/b/c.x
3578:
3579:
3580:
3581: From jkf Thu Mar 24 15:00:37 1983
3582: Date: 24 Mar 83 15:00:37 PST (Thu)
3583: From: jkf (John Foderaro)
3584: Subject: liszt 8.26
3585: Message-Id: <[email protected]>
3586: Received: by UCBKIM.ARPA (3.310/3.5)
3587: id AA11144; 24 Mar 83 15:00:37 PST (Thu)
3588: To: local-lisp
3589: Status: O
3590:
3591: liszt will now pass the assembler the -V switch. This tells the assembler
3592: to keep its intermediate file in core rather than putting it in /tmp.
3593: This should make assembly slightly faster and also permit large lisp files to
3594: be compiled on systems with small /tmp's.
3595:
3596:
3597:
3598: From @udel-relay.ARPA:tim.unc@UDel-Relay Sat Mar 26 03:41:05 1983
3599: Date: 25 Mar 83 15:03:29 EST (Fri)
3600: From: Tim Maroney <tim.unc@UDel-Relay>
3601: Subject: open coding of (function (lambda ...))
3602: Return-Path: <tim.unc@UDel-Relay>
3603: Message-Id: <[email protected]>
3604: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17)
3605: id AB02371; 26 Mar 83 03:37:13 PST (Sat)
3606: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3607: id AA00854; 26 Mar 83 03:41:05 PST (Sat)
3608: To: [email protected]
3609: Via: UNC; 25 Mar 83 19:43-EST
3610: Status: O
3611:
3612: This doesn't seem to work. I'm using Liszt version 8.10, University
3613: of Maryland distribution. The documentation in the file "lispnews"
3614: is sketchy, but it seems that compiling and loading the file:
3615:
3616: (setq appsum (function (lambda (x) (apply 'sum x))))
3617:
3618: should leave a bcd object in appsum's value, but it doesn't. It
3619: leaves the uncompiled lambda. Am I doing something wrong?
3620:
3621: Tim Maroney
3622: decvax!duke!unc!tim
3623: tim.unc@udel-relay
3624:
3625: From jkf@UCBKIM Sat Mar 26 08:46:44 1983
3626: Date: 26 Mar 83 08:46:28 PST (Sat)
3627: From: jkf@UCBKIM (John Foderaro)
3628: Subject: Re: open coding of (function (lambda ...))
3629: Message-Id: <[email protected]>
3630: Received: by UCBKIM.ARPA (3.310/3.5)
3631: id AA02453; 26 Mar 83 08:46:28 PST (Sat)
3632: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17)
3633: id AA05012; 26 Mar 83 08:42:50 PST (Sat)
3634: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3635: id AA02462; 26 Mar 83 08:46:44 PST (Sat)
3636: To: tim.unc@UDel-Relay
3637: Cc: [email protected]
3638: In-Reply-To: Your message of 25 Mar 83 15:03:29 EST (Fri)
3639: Status: O
3640:
3641:
3642: Liszt only compiles functions, not literals it finds in files.
3643: To make this statement be compiled:
3644: (setq appsum (function (lambda (x) (apply 'sum x))))
3645:
3646: you should surround it with a function defintion:
3647: (defun junk ()
3648: (setq appsum (function (lambda (x) (apply 'sum x)))))
3649:
3650:
3651:
3652: From CARR@UTAH-20 Mon Apr 4 14:53:09 1983
3653: Date: 4 Apr 1983 0922-MST
3654: From: Harold Carr <CARR@UTAH-20>
3655: Subject: Franz/Common lisp
3656: Message-Id: <[email protected]>
3657: Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20)
3658: id AA07020; 4 Apr 83 09:11:40 PST (Mon)
3659: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3660: id AA01683; 4 Apr 83 14:53:09 PST (Mon)
3661: To: [email protected]
3662: Cc: KROHNFELDT@UTAH-20
3663: Status: O
3664:
3665: Does anyone have any sort of Common Lisp compatibility package for Franz?
3666: If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20).
3667: -------
3668:
3669: From jeff@aids-unix Tue Apr 5 12:42:46 1983
3670: Date: 4 Apr 1983 11:06:49 PST (Monday)
3671: From: Jeff Dean <jeff@aids-unix>
3672: Subject: knowledge representation language
3673: Message-Id: <[email protected]>
3674: Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20)
3675: id AA26557; 5 Apr 83 12:42:11 PST (Tue)
3676: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3677: id AA16443; 5 Apr 83 12:42:46 PST (Tue)
3678: To: [email protected]
3679: Status: O
3680:
3681: Does anyone have a knowledge representation language (such as FRL or
3682: KL-ONE) available under Franz Lisp?
3683:
3684: Jeff Dean
3685: arpa: jeff@aids-unix
3686: uucp: ...ucbvax!jeff@aids-unix
3687:
3688:
3689: From jkf Tue Apr 5 13:08:06 1983
3690: Date: 5 Apr 83 13:08:06 PST (Tue)
3691: From: jkf (John Foderaro)
3692: Subject: lisp opus 38.57
3693: Message-Id: <[email protected]>
3694: Received: by UCBKIM.ARPA (3.310/3.5)
3695: id AA16969; 5 Apr 83 13:08:06 PST (Tue)
3696: To: local-lisp
3697: Status: RO
3698:
3699: This version has a number of internal changes to make it compilable
3700: on 68k. If you notice it acting abnormally, let me know.
3701:
3702:
3703:
3704: From FAHLMAN@CMU-CS-C Thu Apr 7 07:50:06 1983
3705: Date: Thu, 7 Apr 1983 10:46 EST
3706: From: Scott E. Fahlman <Fahlman@CMU-CS-C>
3707: Subject: Franz/Common lisp
3708: Message-Id: <[email protected]>
3709: Received: ID <FAHLMAN@CMU-CS-C>; 7 Apr 83 10:46:59 EST
3710: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20)
3711: id AA13873; 7 Apr 83 07:49:42 PST (Thu)
3712: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3713: id AA18082; 7 Apr 83 07:50:06 PST (Thu)
3714: To: Harold Carr <CARR@UTAH-20>
3715: Cc: [email protected]
3716: In-Reply-To: Msg of 4 Apr 1983 11:22-EST from Harold Carr <CARR at UTAH-20>
3717: Status: RO
3718:
3719:
3720: Harold,
3721:
3722: A couple of things make it seem unlikely that anyone would have such a
3723: package right now. First, we don't even have a final Common Lisp manual
3724: yet -- Guy's next draft is due very soon, but there will be some tuning
3725: and hassling after that. Second, there are things in Common Lisp that
3726: would be very tough to fake on Franz: lexical binding, generic
3727: sequences, some of the hairy number types, character objects, etc.
3728: Common Lisp is pretty close to being a superset of Franz, so I would
3729: expect to see Franz compatibility packages in Common Lisp, but not vice
3730: versa. Third, if anyone were writing such a package, they would be
3731: crazy not to have arranged for access to our code that implements all of
3732: the hairy functions, and nobody has done this to my knowledge.
3733:
3734: My standard advice is for people to continue to code in Franz with the
3735: knowledge that they can easily convert their code to Common Lisp
3736: whenever the DEC Common Lisp is available to them. This should be a
3737: one-time conversion, since moving the other way after "going native" in
3738: Common Lisp would be very tough.
3739:
3740: If someone does pop up with a compatibility package -- even a partial
3741: one -- I would be interested in hearing about it.
3742:
3743: -- Scott
3744:
3745: From fateman@UCBKIM Sun Apr 10 19:52:14 1983
3746: Date: 10 Apr 83 19:50:59 PST (Sun)
3747: From: fateman@UCBKIM (Richard Fateman)
3748: Subject: Re: Franz/Common lisp
3749: Message-Id: <[email protected]>
3750: Received: by UCBKIM.ARPA (3.310/3.5)
3751: id AA06176; 10 Apr 83 19:50:59 PST (Sun)
3752: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
3753: id AA10019; 10 Apr 83 19:49:55 PST (Sun)
3754: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3755: id AA06192; 10 Apr 83 19:52:14 PST (Sun)
3756: To: carr@utah-20, fahlman@cmu-cs-c
3757: Cc: [email protected]
3758: Status: RO
3759:
3760: I think that a common-lisp-compatibility package written
3761: in Franz would not be as difficult as all that.
3762:
3763: If Common Lisp (TM of DEC?) were available on all the same
3764: machines at the same price, (appx. $0.) and CL were
3765: in fact a superset of Franz for all practical purposes, and
3766: with similar or better efficiency, etc. Why would anyone bother?
3767:
3768: Of course if CL does not meet all of the objectives (e.g. price, machines),
3769: then a CL-to-Franz "translator" might make sense.
3770:
3771: With that in mind,
3772: I would like to officially request a copy of the Common Lisp
3773: language (as implemented in CL, presumably), as soon as it
3774: becomes available (i.e. no later than when it is a "product"
3775: of DEC, and probably at "beta" test time).
3776: I agree fully with Scott that trying to do this with an incomplete
3777: language specification is unwise.
3778:
3779: I am also not making any commitment to do anything with CL at
3780: Berkeley, but since we are building tools for our own applications,
3781: and CL might be useful, we might consider an efficient merge of
3782: ideas.
3783:
3784: From jkf@UCBKIM Mon Apr 11 08:07:39 1983
3785: Date: 11 Apr 83 06:42:43 PST (Mon)
3786: From: jkf@UCBKIM (John Foderaro)
3787: Subject: mail to this mailing list
3788: Message-Id: <[email protected]>
3789: Received: by UCBKIM.ARPA (3.310/3.5)
3790: id AA11378; 11 Apr 83 06:42:43 PST (Mon)
3791: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
3792: id AA07288; 11 Apr 83 08:05:32 PST (Mon)
3793: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3794: id AA11949; 11 Apr 83 08:07:39 PST (Mon)
3795: To: [email protected]
3796: Status: RO
3797:
3798: I'm sorry that people who mail to this mailing list must put up with lots
3799: of mail errors from our local mailer. The problem is not that we have a
3800: lot of illegal addresses, but that over the three day period that the
3801: mailer tries to deliver the mail, some of the destination sites never
3802: respond. I think that this is due primarily to the fact that many sites
3803: are running new mail and networking software. Hopefully this will
3804: improve over time.
3805: john foderaro
3806:
3807:
3808:
3809:
3810: From jkf Fri Apr 22 09:59:09 1983
3811: Date: 22 Apr 83 09:59:09 PST (Fri)
3812: From: jkf (John Foderaro)
3813: Subject: lisp opus 38.59
3814: Message-Id: <[email protected]>
3815: Received: by UCBKIM.ARPA (3.310/3.5)
3816: id AA20996; 22 Apr 83 09:59:09 PST (Fri)
3817: To: local-lisp
3818: Status: RO
3819:
3820: Input like 1.2.3 and 1..2 will now be read as single symbols rather
3821: than two consecutive numbers.
3822:
3823:
3824:
3825: From jkf Sun May 8 00:02:54 1983
3826: Date: 8 May 83 00:02:54 PDT (Sun)
3827: From: jkf (John Foderaro)
3828: Subject: opus 38.60
3829: Message-Id: <[email protected]>
3830: Received: by UCBKIM.ARPA (3.310/3.5)
3831: id AA22344; 8 May 83 00:02:54 PDT (Sun)
3832: To: local-lisp
3833: Cc: rms
3834: Status: RO
3835:
3836: Thanks to some suggestions from rms we are now one step closer to
3837: full closures. fclosures will now work if called recursively.
3838: It is still true that the only way to make fclosures share variables
3839: is to use fclosure-list.
3840:
3841: symeval-in-fclosure may return the wrong value if the closure is
3842: 'active'. This will be fixed eventually.
3843:
3844:
3845:
3846: From mbr@nprdc Sat May 21 07:37:23 1983
3847: Date: 20 May 1983 14:57:55-PDT
3848: From: mbr@NPRDC
3849: Subject: lam9.c and curses
3850: Message-Id: <[email protected]>
3851: Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29)
3852: id AA16172; 21 May 83 07:34:43 PDT (Sat)
3853: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3854: id AA08856; 21 May 83 07:37:23 PDT (Sat)
3855: Reply-To: mbr <mbr@NPRDC>
3856: To: [email protected]
3857: Cc: mbr@NPRDC
3858: Status: O
3859:
3860: When we attempted to cfasl a file that used the curses package
3861: of screen control routines into Franz 38.40, we got the message
3862: _ospeed: /usr/libcurses.a (cr_tty.o) multiply defined.
3863: The apparent cause of this cryptic remark is that in lam9.c
3864: there is an extern variable ospeed. There are a number of
3865: tantalizing routines in this source file dealing with termcaps that
3866: are apparently not called by anyone. Are there plans for these
3867: routines? Does anyone use them (heaven forbid they should be
3868: documented!). Our current fix is to just change ospeed to ospiid
3869: which so far has had no dire effects, but I am interested in others
3870: experience. The curses stuff seems to work fine after this
3871: modification.
3872: Mark Rosenstein
3873:
3874:
3875: From jkf Wed May 25 12:15:54 1983
3876: Date: 25 May 83 12:15:54 PDT (Wed)
3877: From: jkf (John Foderaro)
3878: Subject: opus 38.61
3879: Message-Id: <[email protected]>
3880: Received: by UCBKIM.ARPA (3.340/3.5)
3881: id AA01144; 25 May 83 12:15:54 PDT (Wed)
3882: To: local-lisp
3883: Status: O
3884:
3885: symeval-in-fclosure and set-in-fclosure now work (thanks to keith).
3886:
3887: selectq is now a part of standard franz. selectq is just like
3888: caseq except it allows 'otherwise' as well as 't' for the
3889: key which means 'if nothing else matches, use this clause'.
3890:
3891:
3892:
3893:
3894: From cornwell@nrl-css Wed May 25 12:51:17 1983
3895: Date: Wed, 25 May 83 15:14:19 EDT
3896: From: Mark Cornwell <cornwell@NRL-CSS>
3897: Subject: Franz on the Sun
3898: Message-Id: <[email protected]>
3899: Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29)
3900: id AA02600; 25 May 83 12:50:26 PDT (Wed)
3901: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3902: id AA01878; 25 May 83 12:51:17 PDT (Wed)
3903: To: [email protected]
3904: Cc: cornwell@NRL-CSS
3905: Status: O
3906:
3907:
3908: Our group at NRL is planning to purchase Sun workstations. I
3909: currently have a substantial amount of code written in Franz Lisp that
3910: I want to run on the Sun.
3911:
3912: What is the status of the Berkeley group porting Franz to the Sun?
3913: How do I get a copy?
3914:
3915: Also, I have a few concerns about configuring a Sun to run Franz well.
3916: The basic desktop Sun workstation provides 1 Mbyte of physical memory.
3917: This can be extended to 2 Mbyte or one can add an Ethernet interface
3918: *but not both*. Since I am unwilling to give up my Ethernet
3919: interface I may be forced to run Franz in 1 Mbyte and contend with
3920: the added paging overhead (using a 68010 running 4.2bsd and a local disk).
3921:
3922: Has anyone out there had experience running Franz Lisp on a Sun in
3923: such a configuration? Can I get away without the 2 Mbyte extension?
3924: I think your answers would be of general interest.
3925:
3926: -- Mark (caught between a rock and a hard place?) Cornwell
3927:
3928:
3929:
3930: From baden@UCBKIM Wed May 25 13:51:39 1983
3931: Date: 25 May 83 13:32:01 PDT (Wed)
3932: From: baden@UCBKIM (Scott B. Baden)
3933: Subject: Re: Franz on the Sun
3934: Message-Id: <[email protected]>
3935: Received: by UCBKIM.ARPA (3.340/3.5)
3936: id AA02716; 25 May 83 13:32:01 PDT (Wed)
3937: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29)
3938: id AA03753; 25 May 83 13:50:52 PDT (Wed)
3939: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3940: id AA03002; 25 May 83 13:51:39 PDT (Wed)
3941: To: [email protected]
3942: Cc: cornwell@NRL-CSS
3943: Status: O
3944:
3945: Which sun are you using? My office mate says that
3946: he has seen a sun configured with 2MB of memory AND
3947: an Ethernet board.
3948:
3949: From mike%Rice.Rice@Rand-Relay Fri May 27 19:51:33 1983
3950: Date: Fri, 27 May 83 18:18:47 CDT
3951: From: Mike.Caplinger <mike.rice@Rand-Relay>
3952: Subject: Re: Franz on the Sun
3953: Return-Path: <mike%Rice.Rice@Rand-Relay>
3954: Message-Id: <[email protected]>
3955: Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29)
3956: id AA19088; 27 May 83 19:50:15 PDT (Fri)
3957: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3958: id AA02221; 27 May 83 19:51:33 PDT (Fri)
3959: To: [email protected]
3960: In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed)
3961: Via: Rice; 27 May 83 19:14-PDT
3962: Status: RO
3963:
3964: As I type I'm bringing up the 68K version of Opus 38 (now FTPable from
3965: UCB-VAX) on a SUN running 4.1c. There don't seem to be any major
3966: problems so far, but the compiler doesn't run on a system with all the
3967: net servers on it because it runs out of memory. I've been told this
3968: is because there's a bug in 4.1c that forces it to only use 1/2 of the
3969: swap partition. I'm having to run standalone to compile the compiler;
3970: I don't yet know whether I'll be able to compile other stuff without
3971: this rather extreme fix.
3972:
3973: As I use the system more I will post more info to this group.
3974:
3975: From narain@rand-unix Tue May 31 10:49:00 1983
3976: Date: Tuesday, 31 May 1983 10:45-PDT
3977: From: narain@rand-unix
3978: Subject: Interrupt question
3979: Message-Id: <[email protected]>
3980: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29)
3981: id AA10893; 31 May 83 10:47:26 PDT (Tue)
3982: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3983: id AA13428; 31 May 83 10:49:00 PDT (Tue)
3984: To: [email protected]
3985: Cc: narain@rand-unix
3986: Status: O
3987:
3988:
3989: Hi, I would be grateful if you could tell me what is the equivalent of
3990: Interlisp's control-h (followed by OK) in Franzlisp. In other words, I
3991: wish to interrupt a Franzlisp program, from time to time, examine its state
3992: and allow it to continue from the interrupted point.
3993:
3994: -- Sanjai
3995:
3996: From [email protected] Tue May 31 19:31:04 1983
3997: Date: 31 May 83 17:28:35 PDT (Tue)
3998: From: [email protected]
3999: Subject: packages
4000: Message-Id: <[email protected]>
4001: Received: by LBL-CSAM.ARPA (3.320/3.21)
4002: id AA16451; 31 May 83 17:28:35 PDT (Tue)
4003: Received: by UCBVAX.ARPA (3.341/3.31)
4004: id AA02877; 31 May 83 19:30:00 PDT (Tue)
4005: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4006: id AA22745; 31 May 83 19:31:04 PDT (Tue)
4007: To: [email protected]
4008: Status: O
4009:
4010:
4011: Does a version of LispMachine ``packages'' or some similar oblist partitioning
4012: scheme exist for franz? Having just integrated several independently coded
4013: modules, I think something like that would be very useful.
4014: -thanks
4015: Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve
4016:
4017:
4018: From fateman Tue Jun 14 11:48:32 1983
4019: Date: 14 Jun 83 11:48:32 PDT (Tue)
4020: From: fateman (Richard Fateman)
4021: Subject: "macsyma on a chip?"
4022: Message-Id: <[email protected]>
4023: Received: by UCBKIM.ARPA (3.340/3.5)
4024: id AA06756; 14 Jun 83 11:48:32 PDT (Tue)
4025: To: macsyma-i@mit-mc
4026: Cc: franz-friends
4027: Status: O
4028:
4029: Well, sort of. We now have Macsyma running on a Motorola 68000 - based
4030: system with 6 megabytes of real memory. The operating system is a
4031: Unisoft UNIX system, which has been ported to some large number (>65) boxes.
4032: The Pixel people were kind enough to lend us a machine with enough
4033: real memory to make virtual memory unnecessary.
4034:
4035: It takes a long time to load up, but once running, it is quite responsive,
4036: and appears to be about 60% of a VAX 11/780 in terms of CPU time.
4037:
4038: We have not shaken down everything, but since the source code is unchanged
4039: from the VAX, we expect the bugs to be limited to lisp compilation
4040: glitches, or differences between versions of the UNIX system.
4041:
4042:
4043: From jkf Wed Jun 15 10:42:05 1983
4044: Date: 15 Jun 83 10:42:05 PDT (Wed)
4045: From: jkf (John Foderaro)
4046: Subject: Opus 38.62
4047: Message-Id: <[email protected]>
4048: Received: by UCBKIM.ARPA (3.340/3.5)
4049: id AA20591; 15 Jun 83 10:42:05 PDT (Wed)
4050: To: local-lisp
4051: Status: O
4052:
4053: There is no longer a limit on the size of bignums, strings or
4054: symbol names which can be read by the reader [other than the size of
4055: virtual memory].
4056:
4057: The value of lisp-library-directory will determine where cfasl finds
4058: its private version of the loader.
4059:
4060: (changes by sklower)
4061:
4062:
4063: From @CMU-CS-C:UI.TYJ@CU20D Wed Jun 15 18:22:55 1983
4064: Date: 14 Jun 1983 1812-EDT
4065: From: Tai Jin <UI.TYJ@CU20D>
4066: Subject: franz mailing liszt
4067: Message-Id: <[email protected]>
4068: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
4069: id AA16599; 14 Jun 83 15:14:36 PDT (Tue)
4070: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4071: id AA28806; 15 Jun 83 18:22:55 PDT (Wed)
4072: To: franz-friends%berkeley@CMCSC
4073: Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC
4074: Status: O
4075:
4076:
4077: Hi, we would like to be added to your mailing list.
4078:
4079: We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS)
4080: running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center
4081: for Computing Activities).
4082:
4083: Is anyone out there working on an UTS/IBM implementation? Any information will
4084: be greatly appreciated.
4085:
4086:
4087: Thanks,
4088:
4089: Tai Jin <UI.TYJ%CU20D@CMCSC>
4090: Travis Winfrey <UI.TRAVIS%CU20D@CMCSC>
4091: -------
4092:
4093: From @CMU-CS-C:Ui.Travis@CU20D Thu Jun 16 09:47:39 1983
4094: Date: 16 Jun 1983 1243-EDT
4095: From: Travis Lee Winfrey <Ui.Travis@CU20D>
4096: Subject: Porting Franz lisp to Amdahl Unix
4097: Message-Id: <[email protected]>
4098: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
4099: id AA25470; 16 Jun 83 09:46:15 PDT (Thu)
4100: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4101: id AA06352; 16 Jun 83 09:47:39 PDT (Thu)
4102: To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC
4103: Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D,
4104: kim.fateman%berkeley@CMCSC
4105: Status: O
4106:
4107: Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's
4108: Unix running on a IBM 4341. We are working from a copy that runs on the VAX.
4109:
4110: We would be very interested in seeing any versions that runs both on the VAX
4111: and some other machine, such as the 68000. We are also interested in seeing
4112: any documentation on other porting efforts, regardless of what machine.
4113:
4114: Thanks,
4115:
4116: Tai Jin <ui.tyj%cu20d@cmu-cs-c>
4117: Travis Winfrey <ui.travis%cu20d@cmu-cs-c>
4118: -------
4119:
4120: From jkf Sun Jun 19 15:43:34 1983
4121: Date: 19 Jun 83 15:43:34 PDT (Sun)
4122: From: jkf (John Foderaro)
4123: Subject: opus 38.63
4124: Message-Id: <[email protected]>
4125: Received: by UCBKIM.ARPA (3.340/3.5)
4126: id AA19626; 19 Jun 83 15:43:34 PDT (Sun)
4127: To: local-lisp
4128: Status: O
4129:
4130: Added functions:
4131: (vputprop 'Vv_vector 'g_value 'g_indicator)
4132: (vget 'Vv_vector 'g_indicator)
4133:
4134: work just like putprop and get, but modify the vector property list.
4135:
4136: Also:
4137: you can determine which function is called by lisp to print a vector
4138: by placing the function to call on the vector's property list under
4139: indicator 'print'. The print function is called with two arguments:
4140: the vector and the port.
4141:
4142: For example:
4143: => (defun printv (v port)
4144: (patom "A vector of size " port)
4145: (print (vsize v) port))
4146: printv
4147: => (setq xx (new-vector 10))
4148: vector[40]
4149: => (vputprop xx 'printv 'print)
4150: printv
4151: => xx
4152: A vector of size 10
4153: =>
4154:
4155:
4156:
4157: From jkf Sun Jun 19 22:47:42 1983
4158: Date: 19 Jun 83 22:47:42 PDT (Sun)
4159: From: jkf (John Foderaro)
4160: Subject: opus 38.64
4161: Message-Id: <[email protected]>
4162: Received: by UCBKIM.ARPA (3.340/3.5)
4163: id AA23164; 19 Jun 83 22:47:42 PDT (Sun)
4164: To: local-lisp
4165: Cc: jpg@Mit-mc
4166: Status: O
4167:
4168:
4169: added the function (^ 'x_a 'x_b) which computes x_a to the x_b
4170: power and always returns a fixnum result (it currently wraps around
4171: on overflow).
4172:
4173:
4174:
4175: From JPG@MIT-MC Sun Jun 19 22:54:00 1983
4176: Date: 20 June 1983 01:53 EDT
4177: From: Jeffrey P. Golden <JPG@MIT-MC>
4178: Subject: ^
4179: Message-Id: <[email protected]>
4180: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33)
4181: id AA15160; 19 Jun 83 22:53:57 PDT (Sun)
4182: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4183: id AA23228; 19 Jun 83 22:54:00 PDT (Sun)
4184: To: jkf@UCBKIM
4185: Cc: JPG@MIT-MC, local-lisp@UCBKIM
4186: Status: O
4187:
4188: Date: 19 Jun 83 22:47:42 PDT
4189: From: jkf%UCBKIM@Berkeley
4190: Subject: opus 38.64
4191: To: local-lisp%UCBKIM@Berkeley
4192: Cc: jpg@Mit-mc
4193: added the function (^ 'x_a 'x_b) which computes x_a to the x_b
4194: power and always returns a fixnum result (it currently wraps around
4195: on overflow).
4196: The Maclisp ^ errors out in this case with the message:
4197: ;RESULT LARGER THAN FIXNUM - ^
4198:
4199:
4200: From narain@rand-unix Mon Jun 20 22:09:31 1983
4201: Date: Monday, 20 Jun 1983 22:00-PDT
4202: From: narain@rand-unix
4203: Subject: Re: Interrrupt question
4204: Message-Id: <[email protected]>
4205: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
4206: id AA00276; 20 Jun 83 22:09:20 PDT (Mon)
4207: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4208: id AA09633; 20 Jun 83 22:09:31 PDT (Mon)
4209: To: [email protected]
4210: Cc: narain@rand-unix
4211: Status: O
4212:
4213:
4214: TWIMC
4215: -----
4216:
4217: Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp:
4218: i.e. if you wish to interrupt a Franzlisp computation, browse around the state
4219: and resume computation:
4220:
4221: Hit DEL;
4222: Browse;
4223: (return t)
4224:
4225: This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay).
4226:
4227: -- Sanjai
4228:
4229: From Tim%UPenn.UPenn@UDel-Relay Tue Jun 21 14:52:53 1983
4230: Date: Tue, 21 Jun 83 10:33 EDT
4231: From: Tim Finin <Tim.UPenn@UDel-Relay>
4232: Subject: interrupting Franz
4233: Return-Path: <Tim%UPenn.UPenn@UDel-Relay>
4234: Message-Id: <[email protected]>
4235: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4236: id AA12930; 21 Jun 83 14:52:36 PDT (Tue)
4237: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4238: id AA21097; 21 Jun 83 14:52:53 PDT (Tue)
4239: To: [email protected]
4240: Via: UPenn; 21 Jun 83 17:40-EDT
4241: Status: O
4242:
4243:
4244: Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.
4245:
4246: From jkf Sat Jun 25 13:49:37 1983
4247: Date: 25 Jun 83 13:49:37 PDT (Sat)
4248: From: jkf (John Foderaro)
4249: Subject: opus 38.65
4250: Message-Id: <[email protected]>
4251: Received: by UCBKIM.ARPA (3.340/3.5)
4252: id AA25527; 25 Jun 83 13:49:37 PDT (Sat)
4253: To: local-lisp
4254: Status: O
4255:
4256: If you have automatic case conversion set (i.e. (sstatus uctolc t)),
4257: then symbols with lower case letters will be escaped by print.
4258:
4259:
4260:
4261: From layer Tue Jul 5 00:26:29 1983
4262: Date: 5 Jul 1983 0026-PDT (Tuesday)
4263: From: layer (Kevin Layer)
4264: Subject: lisp opus 38.67
4265: Message-Id: <5390.30.426237985@ucbkim>
4266: Received: by UCBKIM.ARPA (3.340/3.5)
4267: id AA05911; 5 Jul 83 00:26:29 PDT (Tue)
4268: Phone: (415) 652-2405
4269: To: local-lisp
4270: Cc: layer
4271: Status: O
4272:
4273: The function 'sortcar' has been slightly changed: if the second
4274: arg is nil, then the ordering function 'alphalessp' is assumed
4275: ('sort' does it this way).
4276:
4277: Kevin
4278:
4279: From layer Wed Jul 6 00:02:33 1983
4280: Date: 6 Jul 83 00:02:33 PDT (Wed)
4281: From: layer (Kevin Layer)
4282: Subject: liszt opus 8.30
4283: Message-Id: <[email protected]>
4284: Received: by UCBKIM.ARPA (3.340/3.5)
4285: id AA24776; 6 Jul 83 00:02:33 PDT (Wed)
4286: Phone: (415) 652-2405
4287: To: local-lisp
4288: Cc: sklower, jkf
4289: Status: O
4290:
4291: All modifications should be transparent, but if there are problems
4292: relating to the autorun feature (-r flag), please let me know.
4293:
4294: Kevin
4295:
4296:
4297:
4298: From sklower Thu Jul 7 00:27:52 1983
4299: Date: 7 Jul 83 00:27:52 PDT (Thu)
4300: From: sklower (Keith Sklower)
4301: Subject: Franz, opus38.68
4302: Message-Id: <[email protected]>
4303: Received: by UCBKIM.ARPA (3.340/3.5)
4304: id AA10697; 7 Jul 83 00:27:52 PDT (Thu)
4305: To: local-lisp
4306: Status: O
4307:
4308: Franz now escapes UPPER case letters instead of lower case letters when
4309: (status uctolc) is enabled, so that (read (print x)) is an identity operation
4310: on atom printnames. Also, we made (explode) conform to what maclisp does
4311: with opposite-than-normal character-cases.
4312:
4313: From Ira%UPenn.UPenn@UDel-Relay Fri Jul 8 01:46:25 1983
4314: Date: Thu, 7 Jul 83 22:13 EDT
4315: From: Ira Winston <Ira.UPenn@UDel-Relay>
4316: Subject: Eliza
4317: Return-Path: <Ira%UPenn.UPenn@UDel-Relay>
4318: Message-Id: <[email protected]>
4319: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4320: id AA16294; 8 Jul 83 01:45:43 PDT (Fri)
4321: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4322: id AA01687; 8 Jul 83 01:46:25 PDT (Fri)
4323: To: [email protected]
4324: Via: UPenn; 8 Jul 83 3:07-EDT
4325: Status: O
4326:
4327: Does anyone have a version of Eliza that runs under Franz Lisp?
4328:
4329: From layer Fri Jul 8 18:04:10 1983
4330: Date: 8 Jul 1983 1804-PDT (Friday)
4331: From: layer (Kevin Layer)
4332: Subject: lisp opus 38.69
4333: Message-Id: <7031.30.426560643@ucbkim>
4334: Received: by UCBKIM.ARPA (3.340/3.5)
4335: id AA07142; 8 Jul 83 18:04:10 PDT (Fri)
4336: Phone: (415) 652-2405
4337: To: local-lisp
4338: Cc: layer
4339: Status: O
4340:
4341: 'setf' now knows about 'nthelem', and there are two new functions:
4342:
4343: (readdir 's_direct)
4344: returns a list of the contents of the directory s_direct.
4345:
4346: (dirp 's_name)
4347: returns s_name if s_name is a directory. This doesn't
4348: insure that you can read the directory, though (only
4349: uses stat(2)).
4350:
4351: Kevin
4352:
4353: From layer Fri Jul 8 20:57:13 1983
4354: Date: 8 Jul 1983 2057-PDT (Friday)
4355: From: layer (Kevin Layer)
4356: Subject: new function readdir
4357: Message-Id: <465.30.426571029@ucbkim>
4358: Received: by UCBKIM.ARPA (3.340/3.5)
4359: id AA00480; 8 Jul 83 20:57:13 PDT (Fri)
4360: Phone: (415) 652-2405
4361: To: local-lisp
4362: Fcc: record
4363: Status: O
4364:
4365: The function 'readdir' and 'dirp' should not be relied on yet, since
4366: they are provisional, because they are implemented with C library
4367: functions only available on 4.1+ systems.
4368:
4369: Kevin
4370:
4371: From Pwh%GaTech.GATech@UDel-Relay Tue Jul 12 18:08:46 1983
4372: Date: 11 Jul 83 20:36:32-EDT (Mon)
4373: From: <pwh.gatech@UDel-Relay>
4374: Subject: Franz flavors?
4375: Return-Path: <Pwh%GaTech.GATech@UDel-Relay>
4376: Message-Id: <[email protected]>
4377: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4378: id AA03336; 12 Jul 83 18:07:40 PDT (Tue)
4379: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4380: id AA20140; 12 Jul 83 18:08:46 PDT (Tue)
4381: To: [email protected]
4382: Cc: jlk.Gatech@UDel-Relay
4383: Via: GATech; 12 Jul 83 2:43-EDT
4384: Status: O
4385:
4386: We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our
4387: long awaited Symbolics Lisp Machine up and running and are trying to establish
4388: some measure of compatability between Franz and Zeta Lisp (as appropriate).
4389: Janet seems to recall some mention of a flavor package for Franz. Is this
4390: Berkley based or can anyone provide some clues as to where to check next?
4391:
4392: Also, when is the next release of Franz scheduled and what features will it
4393: incorporate?
4394:
4395: If the flavor package is non-existent, we will probably be forced to develop
4396: one here and will, of course, be glad to pass anything useful along.
4397:
4398: phil hutto
4399:
4400: From narain@rand-unix Tue Jul 12 20:10:42 1983
4401: Date: Tuesday, 12 Jul 1983 19:49-PDT
4402: From: narain@rand-unix
4403: Subject: Re: Franz flavors?
4404: Message-Id: <[email protected]>
4405: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
4406: id AA05908; 12 Jul 83 20:09:41 PDT (Tue)
4407: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4408: id AA21387; 12 Jul 83 20:10:42 PDT (Tue)
4409: To: <pwh.gatech@UDEL-RELAY>
4410: Cc: [email protected], jlk.Gatech@UDEL-RELAY
4411: In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon).
4412: <[email protected]>
4413: Status: O
4414:
4415:
4416: We at Rand are interested in developing a set of guidelines for writing
4417: code that will be compatible with each of Zeta- Franz- and PSL Lisps. I
4418: would be grateful if you could tell us of what your experiences have been with
4419: making Franzlisp code work on the Symbolics machine. We would gladly share
4420: our own with you if you wish; incidentally we also have an IJCAI paper on a
4421: related issue.
4422:
4423: -- Sanjai Narain
4424:
4425: From liz.umcp-cs@UDel-Relay Wed Jul 13 00:55:26 1983
4426: Date: 13 Jul 83 03:09:39 EDT (Wed)
4427: From: Liz Allen <liz.umcp-cs@UDel-Relay>
4428: Subject: Re: Franz flavors?
4429: Return-Path: <liz.umcp-cs@UDel-Relay>
4430: Message-Id: <[email protected]>
4431: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4432: id AA10367; 13 Jul 83 00:54:32 PDT (Wed)
4433: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4434: id AA24477; 13 Jul 83 00:55:26 PDT (Wed)
4435: To: pwh.gatech@UDel-Relay, [email protected]
4436: Cc: jlk.Gatech@UDel-Relay
4437: Via: UMCP-CS; 13 Jul 83 3:23-EDT
4438: Status: O
4439:
4440: Here at the Univ of Maryland, we do have an implementation of
4441: flavors in Franz Lisp and have used it successfully in several
4442: large systems. It doesn't contain all the features of the Lisp
4443: Machine Flavors, but it does implement all the major ones. It is
4444: also different in a few ways that are necessitated by the limitations
4445: of Franz Lisp (shallow binding without invisible pointers or true
4446: closures -- though closures may be in the very newest versions of
4447: Franz -- we have opus 38.26). The package uses a hashing scheme
4448: for looking up methods, and the function <- which is used to send
4449: a message to an object is written in C. Together, this makes it
4450: an efficient implementation.
4451:
4452: We are currently working on a new policy for distributing flavors,
4453: our other lisp packages and our window package. When we have worked
4454: it out, I will announce the details here.
4455:
4456: -Liz
4457:
4458: From @MIT-MC:mdm@cmu-ri-isl Thu Jul 14 11:07:57 1983
4459: Date: 14 Jul 1983 14:03:01-EDT
4460: From: Malcolm.McRoberts@CMU-RI-ISL
4461: Subject: random numbers
4462: Message-Id: <[email protected]>
4463: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35)
4464: id AA05735; Thu, 14 Jul 83 11:06:45 PDT
4465: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4466: id AA13687; 14 Jul 83 11:07:57 PDT (Thu)
4467: Apparently-To: <franz-friends@UCB-VAX>
4468: Status: O
4469:
4470: I am interested in obtaining a GOOD random number generator that is callable
4471: from Franz. My only real requirements are that it accept a seed (so that I
4472: can duplicate the same series), is fairly good (try doing several (random
4473: 4)'s in Franz and see what you get), and is of intermediate speed. If you
4474: know of such an animal please send me mail telling me how to get it.
4475: thanks
4476:
4477:
4478: From kanderso@bbn-vax Thu Jul 14 12:49:58 1983
4479: Date: 14 Jul 1983 15:47:19 EDT (Thursday)
4480: From: Ken Anderson <kanderso@bbn-vax>
4481: Subject: Random numbers
4482: Message-Id: <[email protected]>
4483: Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35)
4484: id AA06936; Thu, 14 Jul 83 12:48:49 PDT
4485: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4486: id AA15607; 14 Jul 83 12:49:58 PDT (Thu)
4487: To: [email protected]
4488: Cc: Malcolm.McRoberts@CMU-RI-ISL
4489: Status: O
4490:
4491: Here is a random number generator i use. It seems to work fairly well, but i have
4492: not looked to closely at the statistics. Since it will occasionally require
4493: bignums, it is probably not the fastest either. I was just looking for something
4494: that was likely to be portable between LISP's.
4495: I would be very interested in hearing your evaluation of it.
4496:
4497: k
4498:
4499: ;;; RANDOM NUMBERS
4500: (declare (macros t))
4501: (include math.h)
4502:
4503: (defvar $uniform-a 16807) ; = 7^5
4504: (defvar $mersenne-prime 2147483647) ; = 2^31 - 1
4505: (defvar $mersenne-prime-1 (- $mersenne-prime 1))
4506:
4507: (defmacro with-seed (s-newseed . body)
4508: ; evaluates body with the seed of the random numbers set to s-newseed.
4509: ; the value of s-newseed is updated. Thus this is a way of
4510: ; Keepining several sequences of random numbers with their own seeds
4511: `(let (($uniform-seed ,s-newseed))
4512: (prog1 (progn ,@body)
4513: (setq ,s-newseed $uniform-seed))))
4514:
4515: (defun uniform-basic (previous-fixnum)
4516: ; -> a fixnum 0 < fixnum < 2^31 - 1
4517: ; Repeated calls will generate fixnums in the range
4518: ; 1 -> 2^31 - 2.
4519:
4520: ; The basic idea is new = A^k * old (mod p)
4521: ; where A is a primitive root of p, k is not a factor of p-1
4522: ; and p is a large prime.
4523:
4524: ; This is a good random number generator but is not be the fastest!
4525: ; On FRANZ LISP, and LISP MACHINE it will require bignums since
4526: ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder
4527: ; can be done more efficiently.
4528: ; See: Linus Schrage, A More Portable Fortran Random Number Generator,
4529: ; ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979.
4530: (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime))
4531:
4532: (defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1
4533:
4534: (defun uniform ()
4535: ; -> the next uniform random number in the sequence
4536: ; To have your own sequence, rebind $uniform-seed.
4537: (setq $uniform-seed (uniform-basic $uniform-seed)))
4538:
4539: (defun uniform-between (low-num high-num)
4540: ; -> a uniform random number, x, low-num <= x <= high-num
4541: ; If low-num and high-num are fixnums, a fixnum is returned.
4542: (cond ((not (and (fixp low-num) (fixp high-num)))
4543: (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1))
4544: (-$ high-num low-num))))
4545: (t (+ low-num (// (uniform)
4546: (// $mersenne-prime-1 (max 1 (- high-num low-num -1))))))))
4547:
4548: (defun gaussian-random-1 ()
4549: ; -> a gaussian random variable with mean 0.0 and
4550: ; standard deviation 1.0.
4551: ; Good tails.
4552: (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0))))
4553: (sin (*$ $2pi (uniform-between 0.0 1.0)))))
4554:
4555: (defun gaussian-random (mean standard-deviation)
4556: (+$ mean (*$ (gaussian-random-1) standard-deviation)))
4557:
4558: ;;(defun gaussian (x)
4559: ;; (* (sqrt $2pi)
4560: ;; (exp (minus (// (square x) 2.0)))))
4561:
4562: (defun random-yes-no (fraction-yes)
4563: (<= (uniform-between 0.0 1.0) fraction-yes))
4564:
4565:
4566: From layer Sat Jul 30 15:46:42 1983
4567: Date: 30 Jul 1983 1546-PDT (Saturday)
4568: From: layer (Kevin Layer)
4569: Subject: liszt opus 8.33
4570: Message-Id: <19472.30.428453197@ucbkim>
4571: Received: by UCBKIM.ARPA (3.340/3.5)
4572: id AA19498; 30 Jul 83 15:46:42 PDT (Sat)
4573: Phone: (415) 652-2405
4574: To: local-lisp
4575: Status: O
4576:
4577: Vset is now open coded. There should be no visible change in the
4578: behaviour of vectors, except in speed (greater, that is), and
4579: vsize-{byte,word} work properly now.
4580:
4581: Bugs to me.
4582:
4583: Kevin
4584:
4585: From jkf Mon Aug 1 14:41:28 1983
4586: Received: by ucbkim.ARPA (4.2/4.2)
4587: id AA03743; Mon, 1 Aug 83 14:41:28 PDT
4588: Date: Mon, 1 Aug 83 14:41:28 PDT
4589: From: jkf (John Foderaro)
4590: Message-Id: <[email protected]>
4591: To: local-lisp
4592: Subject: defstruct
4593: Status: O
4594:
4595: defstruct now understands two more types of structures:
4596: :vector
4597: :named-vector
4598:
4599: A named vector has the defstruct structure name on the vector property
4600: list, thus an instance of the foo structure would print as 'foo[8]'.
4601:
4602:
4603: :named-vector is now the default structure type (instead of :hunk).
4604:
4605:
4606:
4607:
4608: From jkf Tue Aug 2 15:20:04 1983
4609: Received: by ucbkim.ARPA (4.2/4.2)
4610: id AA26686; Tue, 2 Aug 83 15:20:04 PDT
4611: Date: Tue, 2 Aug 83 15:20:04 PDT
4612: From: jkf (John Foderaro)
4613: Message-Id: <[email protected]>
4614: To: local-lisp
4615: Subject: lisp opus 38.70
4616: Status: RO
4617:
4618: When a vector is printed, the size in square brackets will be the number
4619: of entries (not the number of bytes). The size printed for vectori
4620: objects will continue to be the number of bytes.
4621:
4622: Also, if the property of a vector is a list with the car being a non nil
4623: symbol, and if that list doesn't have a print property, then that
4624: symbol will be printed rather than 'vector' or 'vectori'.
4625:
4626:
4627:
4628: From layer Thu Aug 4 02:10:12 1983
4629: Received: by ucbkim.ARPA (4.2/4.2)
4630: id AA11660; Thu, 4 Aug 83 02:10:12 PDT
4631: From: layer (Kevin Layer)
4632: Phone: (415) 652-2405
4633: Date: 4 Aug 1983 0210-PDT (Thursday)
4634: Message-Id: <11649.30.428836207@ucbkim>
4635: To: local-lisp
4636: Subject: liszt opus 8.34
4637: Status: RO
4638:
4639: I just installed a new compiler. For the vax, there shouldn't be
4640: any visible changes, though a couple of vector bugs were fixed. For
4641: the 68000, the vector access functions are now open coded, and the
4642: new one was installed on mike, rob, and chip in /usr/ucb.
4643:
4644: Kevin
4645:
4646: From FRD@SU-AI Fri Aug 5 15:57:17 1983
4647: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4648: id AA10610; Fri, 5 Aug 83 15:57:17 PDT
4649: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
4650: id AA10357; Fri, 5 Aug 83 15:54:22 PDT
4651: Message-Id: <[email protected]>
4652: Date: 05 Aug 83 1353 PDT
4653: From: Fred Lakin <FRD@SU-AI>
4654: Subject: Franz & SUNs
4655: To: franz-friends@BERKELEY
4656: Status: RO
4657:
4658: I am interested in connectons between Franz and SUN workstations.
4659: Like how far along is Franz on the SUN? Is there some package
4660: which allows Franz on a VAX to use a SUN as a display device?
4661:
4662: Any info on this matter would be appreciated.
4663: Thnaks, Fred Lakin
4664:
4665:
4666: From tektronix!ogcvax!metheus!tombl Sat Aug 6 09:49:57 1983
4667: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4668: id AA21229; Sat, 6 Aug 83 09:49:57 PDT
4669: Received: by UCBVAX.ARPA (3.347/3.35)
4670: id AA13549; Sat, 6 Aug 83 09:40:11 PDT
4671: Message-Id: <[email protected]>
4672: From: ogcvax!metheus!tombl
4673: To: ogcvax!tektronix!ucbvax!franz-friends
4674: Cc: ogcvax!tektronix!ucbvax!sklower
4675: Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT
4676: Subject: bug in Opus 38.66
4677: Date: Fri Aug 5 20:46:56 1983
4678: Status: O
4679:
4680:
4681: A bug present in previous versions is also present in 38.66 of Franz.
4682: cfasl fails (in most cases) to close the file it reads from.
4683: Consequently, mysterious events occur when the maximum number of open
4684: file descriptors is reached.
4685:
4686: The fix is made in the file ffasl.c. "close(fildes)" should be
4687: prepended to the two return sequences from (the Unix code for)
4688: Lcfasl:
4689:
4690: ------------------------------------------------------------------
4691: Old: 146c146
4692: < {Restorestack(); return(nil);}
4693: ---
4694: Fixed: > {close(fildes); Restorestack(); return(nil);}
4695: 149a150
4696: > close(fildes);
4697: ------------------------------------------------------------------
4698:
4699:
4700: Tom Blenko
4701: Metheus Corp.
4702: ucbvax!tektronix!ogcvax!metheus!tombl
4703: allegra!ogcvax!metheus!tombl
4704:
4705:
4706:
4707: From FRD@SU-AI Sun Aug 7 12:34:43 1983
4708: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4709: id AA10610; Fri, 5 Aug 83 15:57:17 PDT
4710: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
4711: id AA10357; Fri, 5 Aug 83 15:54:22 PDT
4712: Message-Id: <[email protected]>
4713: Date: 05 Aug 83 1353 PDT
4714: From: Fred Lakin <FRD@SU-AI>
4715: Subject: Franz & SUNs
4716: To: franz-friends@BERKELEY
4717: Status: O
4718:
4719: I am interested in connectons between Franz and SUN workstations.
4720: Like how far along is Franz on the SUN? Is there some package
4721: which allows Franz on a VAX to use a SUN as a display device?
4722:
4723: Any info on this matter would be appreciated.
4724: Thnaks, Fred Lakin
4725:
4726:
4727: From jkf Mon Aug 8 09:06:49 1983
4728: Received: by ucbkim.ARPA (4.2/4.2)
4729: id AA06584; Mon, 8 Aug 83 09:06:49 PDT
4730: Date: Mon, 8 Aug 83 09:06:49 PDT
4731: From: jkf (John Foderaro)
4732: Message-Id: <[email protected]>
4733: To: local-lisp
4734: Subject: opus 38.72
4735: Status: O
4736:
4737: A bug was fixed in defmacro which caused the &protect option and
4738: displace-macros to interact poorly.
4739:
4740:
4741:
4742: From jkf Fri Aug 12 22:11:13 1983
4743: Received: by ucbkim.ARPA (4.2/4.2)
4744: id AA25610; Fri, 12 Aug 83 22:11:13 PDT
4745: Date: Fri, 12 Aug 83 22:11:13 PDT
4746: From: jkf (John Foderaro)
4747: Message-Id: <[email protected]>
4748: To: local-lisp
4749: Subject: opus 38.73
4750: Status: O
4751:
4752: 'equal' will now compare all types of vectors for equality.
4753:
4754: 'copy' will now copy all types of vectors.
4755:
4756:
4757:
4758:
4759: From layer Mon Aug 15 20:03:53 1983
4760: Received: by ucbkim.ARPA (4.2/4.2)
4761: id AA03597; Mon, 15 Aug 83 20:03:53 PDT
4762: From: layer (Kevin Layer)
4763: Phone: (415) 652-2405
4764: Date: 15 Aug 1983 2003-PDT (Monday)
4765: Message-Id: <3556.30.429851029@ucbkim>
4766: To: local-lisp
4767: Subject: liszt opus 8.35
4768: Fcc: record
4769: Status: RO
4770:
4771: Several things have changed:
4772:
4773: 1) Bugs in the open coding of vectors have been fixed.
4774:
4775: 2) Minor re-organization of the compiler source code.
4776:
4777: 3) The routine to determine whether or not tail merging is
4778: possible underwent major modification.
4779:
4780: 4) Lexpr's are compiled differently, or rather the way lexpr args
4781: are accessed has changed. For those that want to know, here is
4782: the nitty gritty:
4783:
4784: Consider a the following lexpr: (defun test nargs ...).
4785: The arguments to the lexpr are stacked on the name stack
4786: (low to high number), and then nargs is stacked. The user
4787: is allowed to change the binding of 'nargs' to anything
4788: he likes, so we have to have another way to access the arguments
4789: on the name stack (i.e., other than an offset from nargs).
4790: Before, a pointer to the argument base was pushed on the
4791: C stack, so that indexing could be done from there.
4792: The addressing modes used to do this are not available
4793: on the MC68000 (something like *n(fp)[Rx]), so now
4794: nargs is pushed on the name stack twice, and the location
4795: of an argument can be easily calculated as an offset from nargs.
4796:
4797: In short, lots of thing changed. The SUN's should be updated
4798: in the next couple of days (after I test it out). Bugs to me...
4799:
4800: Kevin
4801:
4802: From jkf Mon Aug 15 23:11:08 1983
4803: Received: by ucbkim.ARPA (4.2/4.2)
4804: id AA05928; Mon, 15 Aug 83 23:11:08 PDT
4805: Date: Mon, 15 Aug 83 23:11:08 PDT
4806: From: jkf (John Foderaro)
4807: Message-Id: <[email protected]>
4808: To: local-lisp
4809: Subject: opus 38.74
4810: Status: O
4811:
4812:
4813: If a vector has a 'unique' property on it's property list, then it will
4814: not be copied by 'copy'.
4815:
4816: 'untrace' will now autoload /usr/lib/lisp/trace.
4817:
4818: A number of functions and macros were contributed by the bair group:
4819:
4820:
4821:
4822:
4823:
4824:
4825:
4826:
4827: (<= 'fx_arg1 'fx_arg2 ...)
4828: (<=& 'x_arg1 'x_arg2)
4829:
4830: RETURNS: t iff (> 'fx_arg1 'fx_arg2) [or (>& 'x_arg1
4831: 'x_arg2)] is nil, otherwise nil. The general
4832: function, <=, can take more than two argu-
4833: ments.
4834:
4835: (>= 'fx_arg1 'fx_arg2)
4836: (>=& 'x_arg1 'x_arg2)
4837:
4838: RETURNS: t iff (< 'fx_arg1 'fx_arg2 ...) [or (<&
4839: 'x_arg1 'x_arg2)] is nil, otherwise nil.
4840:
4841: NOTE: The general function, >=, can take more than two
4842: arguments.
4843:
4844: (litatom 'g_arg)
4845:
4846: RETURNS: t iff g_arg is an atom, but not a number.
4847:
4848: (nequal 'g_x 'g_y)
4849:
4850: RETURNS: t iff g_x is not equal to g_y, otherwise nil.
4851:
4852: (lineread [['p_port] ['s_flag]])
4853:
4854: RETURNS: a list consisting of s-expressions on a line
4855: from the port p_port (or piport if p_port is
4856: not given). If an s-expression (e.g., a list)
4857: takes more than one line, or a line terminates
4858: in a space or tab, then lineread continues
4859: reading until an expression ends at the end of
4860: a line.
4861:
4862: NOTE: If s_flag is t, then if the first character on a
4863: line is a newline, lineread performs a tyi and
4864: returns nil. If s_flag is nil or not present,
4865: lineread does a read skipping over any blank
4866: lines to make sure that an s-expression is actu-
4867: ally read.
4868:
4869: SIDE EFFECT: lineread uses read, advancing the port
4870: character pointer.
4871:
4872:
4873:
4874:
4875:
4876:
4877:
4878:
4879: 9
4880:
4881: 9
4882:
4883:
4884:
4885:
4886:
4887:
4888:
4889:
4890:
4891:
4892: (defv g_arg1 g_arg2)
4893:
4894: EQUIVALENT TO: (set g_arg1 g_arg2)
4895:
4896: (pp-form 'g_form ['p_port] ['n_lmar])
4897:
4898: RETURNS: nil
4899:
4900: SIDE EFFECT: g_form is pretty-printed to the port
4901: p_port (or poport if p_port is not given).
4902: If pp-form is also supplied with an
4903: integer (n_lmar), that integer will be
4904: used as a left margin setting (0 is the
4905: default). This is the function which pp
4906: uses (n_lmar = 0). pp-form does not look
4907: for function definitions or values of
4908: variables, it just prints out the form it
4909: is given.
4910:
4911: NOTE: This is useful as a top-level-printer, c.f. top-
4912: level in Chapter 6.
4913:
4914: (sload 's_file1 ...)
4915:
4916: SIDE EFFECT: The files named are opened for reading and
4917: each form is read, optionally printed, and
4918: evaluated.
4919:
4920: NOTE: What sload prints is controlled by the special
4921: atom $sldprint. If $sldprint is t (default),
4922: then if a form is recognizable as a function
4923: definition, only the function name is printed,
4924: otherwise the whole form is printed. If
4925: $sldprint is eq to value, then the result of each
4926: form's evaluation will also be printed. Printing
4927: the forms' values can be controlled by setting
4928: sload-print equal to the name of the function to
4929: be called. sload recognizes named functions by
4930: looking at the sloadprintarg property of the
4931: function name. The value of the sloadprintarg
4932: property should be the argument number of the
4933: function name. For the standard Franz Lisp func-
4934: tions, the properties are already set.
4935:
4936: EXAMPLE: (defprop def 1 sloadprintarg) ; This is the
4937: default--declaring that
4938: ; the name of
4939: the function definition is the
4940: ; first argu-
4941: ment.
4942:
4943:
4944: 9
4945:
4946: 9
4947:
4948:
4949:
4950:
4951:
4952:
4953:
4954:
4955:
4956:
4957: The functions described below are an alternative
4958: to the gensym facility. They generate new symbols by
4959: attaching counter numbers to the ends of the symbols'
4960: names. An example follows of how the functions are
4961: used.
4962:
4963:
4964: ____________________________________________________
4965:
4966: -> (initsym joe (john 5)) ; initializing new symbol counters
4967: (joe0 john5)
4968: -> (newsym john) ; create a new symbol
4969: john6
4970: -> (newsym chuck) ; symbol need not be initsym'ed
4971: chuck0
4972: -> (oldsym john) ; get current symbol
4973: john6
4974: -> (allsym john) ; get all symbols between 0 and counter
4975: (john0 john1 john2 john3 john4 john5 john6)
4976: -> (allsym (john 5)) ; get all symbols between 5 and counter
4977: (john5 john6)
4978: -> (remsym joe (john 4)) ; remob all interned symbols
4979: ; associated with joe and from
4980: ; john4 to the current john
4981: ; symbol--returns symbols with symbol counters
4982: ; before doing remsym
4983: (joe0 john6)
4984: -> (symstat joe john)
4985: ((joe nil) (john 3))
4986: ____________________________________________________
4987:
4988:
4989:
4990:
4991: (initsym g_arg1 ...)
4992:
4993: WHERE: g_argi is a list (n_counteri s_argi) or a
4994: string s_argi (which is equivalent to (0
4995: s_argi)).
4996:
4997: RETURNS: a list of interned identifiers using the sym-
4998: bol counters n_counteri, i.e., the result of
4999: concatenating s_argi to n_counteri.
5000:
5001: EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5)
5002:
5003: NOTE: See also newsym, oldsym, allsym, remsym, and sym-
5004: stat functions.
5005:
5006:
5007:
5008:
5009: 9
5010:
5011: 9
5012:
5013:
5014:
5015:
5016:
5017:
5018:
5019:
5020:
5021:
5022: (newsym s_arg)
5023:
5024: RETURNS: an interned identifier formed by concatenating
5025: the name s_arg to the symbol counter for
5026: s_arg. The symbol counter is stored on the
5027: property list of s_arg under symctr. If there
5028: is no counter, a counter of 0 is used and
5029: added to the property list. Thus, a symbol
5030: need not be initsymed.
5031:
5032: EXAMPLE: (initsym joe (john5)) ==> (joe0 john5)
5033: (newsym john) ==> john6
5034: (newsym joe) ==> joe1
5035:
5036: NOTE: See also initsym, oldsym, allsym, remsym, and
5037: symstat functions.
5038:
5039: (oldsym s_arg)
5040:
5041: RETURNS: the identifier using the current symbol
5042: counter for s_arg, rather than creating a new
5043: identifier. If no symbol counter exists for
5044: s_arg, then s_arg is returned.
5045:
5046: NOTE: See also initsym, newsym, allsym, remsym, and
5047: symstat functions.
5048:
5049: (allsym g_arg)
5050:
5051: WHERE: g_arg is a list (s_arg n_counter) or a string
5052: s_arg (equivalent to (s_arg 0)).
5053:
5054: RETURNS: a list of all the created identifiers between
5055: n_counter and the current symbol counter for
5056: s_arg.
5057:
5058: EXAMPLE: (allsym john) ==> (john0 john1 john2)
5059:
5060: NOTE: See also initsym, newsym, oldsym, remsym, and
5061: symstat functions.
5062:
5063: (remsym g_arg1 ...)
5064:
5065: WHERE: g_argi is a list (s_argi n_counteri) or a
5066: string s_argi (which is equivalent to (s_argi
5067: 0)).
5068:
5069: RETURNS: a list of symbols s_argi with the current sym-
5070: bol counters.
5071:
5072: SIDE EFFECT: remsym remob's all the created identifiers
5073: between zero and the current symbol
5074: counter for s_argi.
5075:
5076:
5077:
5078:
5079:
5080:
5081:
5082:
5083:
5084:
5085:
5086:
5087:
5088: NOTE: See also initsym, newsym oldsym, allsym, and sym-
5089: stat functions.
5090:
5091: (symstat s_arg1 ...)
5092:
5093: RETURNS: a list of pairs consisting of (s_argi symctri)
5094: where symctri is s_argi's current symbol
5095: counter.
5096:
5097: NOTE: See also initsym, newsym, oldsym, allsym, and
5098: remsym functions.
5099:
5100:
5101:
5102:
5103:
5104:
5105:
5106:
5107:
5108:
5109:
5110:
5111:
5112:
5113:
5114:
5115:
5116:
5117:
5118:
5119:
5120:
5121:
5122:
5123:
5124:
5125:
5126:
5127:
5128:
5129:
5130:
5131:
5132:
5133:
5134:
5135:
5136:
5137:
5138:
5139:
5140: 9
5141:
5142: 9
5143:
5144:
5145:
5146:
5147:
5148:
5149: From jkf Thu Aug 18 19:25:45 1983
5150: Received: by ucbkim.ARPA (4.2/4.2)
5151: id AA09885; Thu, 18 Aug 83 19:25:45 PDT
5152: Date: Thu, 18 Aug 83 19:25:45 PDT
5153: From: jkf (John Foderaro)
5154: Message-Id: <[email protected]>
5155: To: local-lisp
5156: Subject: opus 38.75
5157:
5158: evalhook and funcallhook can now be executed without setting (*rset t)
5159: and (sstatus evalhook t). Although they can be executed, they won't
5160: have any effect unless and until (*rset t) and (sstatus evalhook t) are
5161: done.
5162: The reason for this change is that now one can turn off stepping
5163: by (sstatus evalhook nil) and then continue the evaluation with
5164: evalhook and funcallhook.
5165:
5166: Those who use the new top-level 'tpl' will notice a few new commands
5167: dealing with stepping when you type '?help'. These new commands
5168: are ?step, ?soff, and ?sc. Details of the commands are available
5169: using the help mechanism (e.g. '?help step').
5170:
5171:
5172:
5173:
5174: From jkf Fri Aug 19 13:54:26 1983
5175: Received: by ucbkim.ARPA (4.2/4.2)
5176: id AA20017; Fri, 19 Aug 83 13:54:26 PDT
5177: Date: Fri, 19 Aug 83 13:54:26 PDT
5178: From: jkf (John Foderaro)
5179: Message-Id: <[email protected]>
5180: To: local-lisp
5181: Subject: liszt 8.36
5182:
5183: The compiler will now compile the form
5184: (*no-macroexpand* <form>)
5185: in a special way: if <form> is a function call, e.g. (name arg1 ...),
5186: then any macro properties of 'name' will be ignored for this
5187: invocation. This permits one to write macros which attempt
5188: an optimization, and if that fails, then call the standard
5189: function. *no-macroexpand* is not a function that can be called,
5190: thus forms with *no-macroexpand* are likely to be 'cmacros'.
5191: Here is an example:
5192:
5193: (defcmacro length (x &protect (x))
5194: `(if (null ,x)
5195: then 0
5196: elseif (null (cdr ,x))
5197: then 1
5198: else (*no-macroexpand* (length ,x))))
5199:
5200:
5201: [in case you are wondering, the `&protect (x)' means that
5202: should the actual argument to 'length' be a non atom, defcmacro
5203: will lambda bind the value, insuring that it is only evaluated
5204: once]
5205:
5206:
5207:
5208:
5209: From layer Wed Aug 24 22:18:34 1983
5210: Received: by ucbkim.ARPA (4.6/4.2)
5211: id AA12256; Wed, 24 Aug 83 22:18:34 PDT
5212: From: layer (Kevin Layer)
5213: Phone: (415) 652-2405
5214: Date: 24 Aug 1983 2218-PDT (Wednesday)
5215: Message-Id: <12219.30.430636709@ucbkim>
5216: To: local-lisp
5217: Subject: liszt on kim
5218:
5219: The liszt that I installed on kim yesterday, compiled eq's wrong
5220: in some rare cases. I installed a new one this evening that fixes
5221: this, but if you compiled any programs with the bad one, you might
5222: consider re-compiling them...
5223:
5224: Kevin
5225:
5226: From fateman Thu Aug 25 13:58:59 1983
5227: Received: by ucbkim.ARPA (4.6/4.2)
5228: id AA21033; Thu, 25 Aug 83 13:58:59 PDT
5229: Date: Thu, 25 Aug 83 13:58:59 PDT
5230: From: fateman (Richard Fateman)
5231: Message-Id: <[email protected]>
5232: To: local-lisp
5233:
5234: I have a copy of the latest Common Lisp manual... the Excelsior Edition.
5235:
5236: From patel@UCLA-LOCUS Tue Aug 30 21:58:38 1983
5237: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5238: id AA29417; Tue, 30 Aug 83 21:58:38 PDT
5239: Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4)
5240: id AA06203; Tue, 30 Aug 83 21:50:26 PDT
5241: Message-Id: <[email protected]>
5242: Date: Tue, 30 Aug 83 21:44:13 PDT
5243: From: Dorab Patel <patel@UCLA-LOCUS>
5244: To: franz-friends@BERKELEY
5245: Subject: bug fix for 'insert' in opus 38.50
5246:
5247: The function 'insert' in Opus 38.50 does not perform as advertised in
5248: the manual if the last argument is non-nil (i.e. if no duplicates are allowed.
5249: It still insists on putting the duplicate element into the list. The
5250: fix is in /usr/lib/lisp/common2.l. Just change the default setting
5251: of the 'comparefn' to that given below instead of
5252: (function alphalessp). Here is an excerpt from the modified file.
5253:
5254:
5255: [.....]
5256: (def insert
5257: (lambda (x l comparefn nodups)
5258: (cond ((null l) (list x))
5259: ((atom l)
5260: (error "an atom, can't be inserted into" l))
5261: (t (cond
5262: ((null comparefn) (setq comparefn
5263: (function
5264: (lambda (x y)
5265: (or (alphalessp x y)
5266: (equal x y)))))))
5267: (prog (l1 n n1 y)
5268: (setq l1 l)
5269: (setq n (length l))
5270: a (setq n1 (/ (add1 n) 2))
5271: (setq y (Cnth l1 n1))
5272: [..........]
5273:
5274: From jkf Sun Sep 4 09:59:01 1983
5275: Received: by ucbkim.ARPA (4.6/4.2)
5276: id AA03721; Sun, 4 Sep 83 09:59:01 PDT
5277: Date: Sun, 4 Sep 83 09:59:01 PDT
5278: From: jkf (John Foderaro)
5279: Message-Id: <[email protected]>
5280: To: local-lisp
5281: Subject: opus 38.77
5282:
5283: The 'error' function used to print its arguments and then call 'err' to
5284: cause the familar 'call to err' error. The problem with this is that
5285: even if you wrap your compuatation with (errset ... nil), the error message
5286: will still be printed. In opus 38.77, this problem has been fixed.
5287:
5288: A new function was added:
5289: (err-with-message 'st_message ['g_value])
5290: This causes an error to be signaled with the given message. The message
5291: will only be printed if an '(errset ... nil)' isn't being executed.
5292: Normally nil is returned from an errset if an error occured. If you provide
5293: g_value, then it will be returned from the errset.
5294: [Not surprisingly, 'error' now uses 'err-with-message']
5295:
5296:
5297: Also, 'error' now takes any number of arguments. In concatenates them,
5298: separated by spaces, and this is the error message passed to
5299: err-with-message.
5300:
5301:
5302:
5303:
5304: From narain@rand-unix Fri Sep 9 13:32:24 1983
5305: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5306: id AA16481; Fri, 9 Sep 83 13:32:24 PDT
5307: Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7)
5308: id AA11010; Fri, 9 Sep 83 13:31:58 PDT
5309: Message-Id: <[email protected]>
5310: Date: Friday, 9 Sep 1983 10:55-PDT
5311: To: franz-friends@BERKELEY
5312: Cc: narain@rand-unix
5313: Subject: Franzlisp Question
5314: From: narain@rand-unix
5315:
5316:
5317: Hello all:
5318:
5319: I would be grateful if you could answer another question regarding Franzlisp.
5320: How does one make Franzlisp continue from an error? For example when Lisp
5321: gives an error message like "x unbound variable", is it possible to
5322: bind x to a value and make Lisp continue from that point? Right now we have
5323: to start over again and it is very time consuming.
5324:
5325: -- Sanjai
5326:
5327: From [email protected] Fri Sep 9 13:46:45 1983
5328: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5329: id AA16843; Fri, 9 Sep 83 13:46:45 PDT
5330: Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7)
5331: id AA11248; Fri, 9 Sep 83 13:46:26 PDT
5332: Date: 9 Sep 1983 1427-EDT
5333: From: AUSTIN@DEC-MARLBORO
5334: To: FRANZ-FRIENDS@BERKELEY
5335: Subject: LIST MEMBERSHIP
5336: Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO>
5337:
5338: PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION.
5339:
5340: MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO.
5341:
5342: THANKS!
5343: --------
5344:
5345: From jkf Sat Sep 10 12:34:14 1983
5346: Received: by ucbkim.ARPA (4.6/4.2)
5347: id AA28421; Sat, 10 Sep 83 12:34:14 PDT
5348: Date: Sat, 10 Sep 83 12:34:14 PDT
5349: From: jkf (John Foderaro)
5350: Message-Id: <[email protected]>
5351: To: local-lisp
5352: Subject: opus 38.78
5353:
5354: The new functions contributed by the bair group dealing with symbol
5355: creation have been changed from fexprs to exprs (lambdas) and lexprs.
5356:
5357: The new documentation follows:
5358:
5359:
5360:
5361:
5362:
5363:
5364:
5365: The functions described below are an alternative to the
5366: gensym facility. They generate new symbols by attaching
5367: counter numbers to the ends of the symbols' names. An exam-
5368: ple follows of how the functions are used.
5369:
5370:
5371: ____________________________________________________
5372:
5373: -> (initsym 'joe '(john 5)) ; initializing new symbol counters
5374: (joe0 john5)
5375: -> (newsym 'john) ; create a new symbol
5376: john6
5377: -> (newsym 'chuck) ; symbol need not be initsym'ed
5378: chuck0
5379: -> (oldsym 'john) ; get current symbol
5380: john6
5381: -> (allsym 'john) ; get all symbols between 0 and counter
5382: (john0 john1 john2 john3 john4 john5 john6)
5383: -> (allsym '(john 5)) ; get all symbols between 5 and counter
5384: (john5 john6)
5385: -> (remsym 'joe '(john 4)) ; remob all interned symbols
5386: ; associated with joe and from
5387: ; john4 to the current john
5388: ; symbol--returns symbols with symbol counters
5389: ; before doing remsym
5390: (joe0 john6)
5391: -> (symstat 'joe 'john)
5392: ((joe nil) (john 3))
5393: ____________________________________________________
5394:
5395:
5396:
5397:
5398: (initsym 'g_arg1 ...)
5399:
5400: WHERE: g_argi is a list (n_counteri s_argi) or a
5401: string s_argi (which is equivalent to (0
5402: s_argi)).
5403:
5404: RETURNS: a list of interned identifiers using the sym-
5405: bol counters n_counteri, i.e., the result of
5406: concatenating s_argi to n_counteri.
5407:
5408: EXAMPLE: (initsym 'joe '(john 5)) ==> (joe0 john5)
5409:
5410: NOTE: See also newsym, oldsym, allsym, remsym, and sym-
5411: stat functions.
5412:
5413:
5414:
5415:
5416:
5417:
5418:
5419:
5420:
5421:
5422:
5423:
5424:
5425:
5426:
5427:
5428:
5429:
5430:
5431: (newsym 's_arg)
5432:
5433: RETURNS: an interned identifier formed by concatenating
5434: the name s_arg to the symbol counter for
5435: s_arg. The symbol counter is stored on the
5436: property list of s_arg under symctr. If there
5437: is no counter, a counter of 0 is used and
5438: added to the property list. Thus, a symbol
5439: need not be initsymed.
5440:
5441: EXAMPLE: (initsym 'joe '(john5)) ==> (joe0 john5)
5442: (newsym 'john) ==> john6
5443: (newsym 'joe) ==> joe1
5444:
5445: NOTE: See also initsym, oldsym, allsym, remsym, and
5446: symstat functions.
5447:
5448: (oldsym 's_arg)
5449:
5450: RETURNS: the identifier using the current symbol
5451: counter for s_arg, rather than creating a new
5452: identifier. If no symbol counter exists for
5453: s_arg, then s_arg is returned.
5454:
5455: NOTE: See also initsym, newsym, allsym, remsym, and
5456: symstat functions.
5457:
5458: (allsym 'g_arg)
5459:
5460: WHERE: g_arg is a list (s_arg n_counter) or a string
5461: s_arg (equivalent to (s_arg 0)).
5462:
5463: RETURNS: a list of all the created identifiers between
5464: n_counter and the current symbol counter for
5465: s_arg.
5466:
5467: EXAMPLE: (allsym 'john) ==> (john0 john1 john2)
5468:
5469: NOTE: See also initsym, newsym, oldsym, remsym, and
5470: symstat functions.
5471:
5472: (remsym 'g_arg1 ...)
5473:
5474: WHERE: g_argi is a list (s_argi n_counteri) or a
5475: string s_argi (which is equivalent to (s_argi
5476: 0)).
5477:
5478: RETURNS: a list of symbols s_argi with the current sym-
5479: bol counters.
5480:
5481: SIDE EFFECT: remsym remob's all the created identifiers
5482: between zero and the current symbol
5483: counter for s_argi.
5484:
5485:
5486:
5487:
5488:
5489:
5490:
5491:
5492:
5493:
5494:
5495:
5496:
5497: NOTE: See also initsym, newsym oldsym, allsym, and sym-
5498: stat functions.
5499:
5500: (symstat 's_arg1 ...)
5501:
5502: RETURNS: a list of pairs consisting of (s_argi symctri)
5503: where symctri is s_argi's current symbol
5504: counter.
5505:
5506: NOTE: See also initsym, newsym, oldsym, allsym, and
5507: remsym functions.
5508:
5509:
5510:
5511:
5512:
5513:
5514:
5515:
5516:
5517:
5518:
5519:
5520:
5521:
5522:
5523:
5524:
5525:
5526:
5527:
5528:
5529:
5530:
5531:
5532:
5533:
5534:
5535:
5536:
5537:
5538:
5539:
5540:
5541:
5542:
5543:
5544:
5545:
5546:
5547:
5548:
5549:
5550:
5551:
5552:
5553:
5554:
5555:
5556:
5557:
5558:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.