+From jkf Tue Apr 13 00:12:22 1982
+To: /na/doe/jkf/lispnews
+Subject: new features
+Status: RO
+
+ In response to requests from franz users, these enhancements have been
+made:
+
+In Lisp 38.07, if the lisp variable 'displace-macros' is set to non-nil,
+then when a macro expansion is done by the evaluator, the resulting
+expansion replaces the original call. This means that macro expansion
+is only done once.
+
+In Liszt 8.03, the 'function' function is open coded. If you have
+ (function (lambda ....))
+in your code then the lambda expression is compiled as a separate function
+and the result of the function call is a 'bcd' object which points
+to that compiled lambda.
+
+
+
+From jkf Sun Apr 18 13:16:46 1982
+To: local-lisp
+Subject: opus 38.09
+Status: RO
+
+ The new features of this version are:
+ If the load function ends up fasl'ing in a file, then load will
+ do what is necessary to insure that the new functions are linked in
+ correctly. Previously, if you turned on the transfer tables with
+ (sstatus translink on) or (sstatus translink t) and then fasl'ed in
+ functions which already existed, the old versions of the functions
+ would still be used, unless you did (sstatus translink on) yourself.
+ Now this is done automatically.
+
+ tyi now accepts a second argument which is the object to return
+ upon eof. -1 is the default.
+
+ (pp-form 'g_obj ['p_port]) should be used instead of $prpr
+ for pretty printing a form.
+
+ The storage allocator and collector has been modified to add
+ two new data types: vector and vector immediate. They are not in
+ their final form so I suggest that you not try to use them.
+ However, be on the lookout for garbage collection bugs.
+
+
+
+From jkf Wed Apr 21 07:45:54 1982
+To: local-lisp
+Subject: liszt 8.04
+Status: RO
+
+ the new features of liszt 8.04 are:
+
+1) init files:
+ Before liszt begins compiling, it looks for an init file to load in.
+ It first searches in the current directory, and then it searches
+ your home directory (getenv 'HOME).
+ It looks for file names:
+ .lisztrc.o .lisztrc.l lisztrc.o lisztrc.l
+ It loads only the first one it finds.
+
+2) interrupt handling
+ If you interrupt liszt (with ^C typically), it will remove its
+ temporary file and exit.
+
+3) preallocation of space
+ It preallocates space in order to reduce the number of gc's done
+ during compiling.
+
+
+
+
+
+From jkf Wed Apr 21 13:47:50 1982
+To: local-lisp
+Subject: lisp opus 38.10
+Status: RO
+
+ lisp will now look for a lisprc in a way similar to liszt.
+
+ It will first search in . and then in $HOME
+ It will look for the file .lisprc or lisprc ending with .o, .l and then
+just .lisprc or lisprc.
+
+ Shortly, it will only look for files ending in .l and .o since we don't
+want to encourage files with non-standard filename extensions.
+
+
+
+
+
+From jkf Wed Apr 21 23:40:59 1982
+To: local-lisp
+Subject: lisp opus 38.11
+Status: RO
+
+ I finally got sick of showstack and baktrace and rewrote them in lisp,
+rincorporating some of the features people have been requesting.
+Showstack now works as follows:
+ (showstack) : show all interesting forms. Forms resulting from
+ the trace package are not printed as well as
+ extraneous calls to eval. In the form printed,
+ the special form <**> means 'the previous expression
+ printed'. prinlevel and prinlength are set to
+ reasonable values to prevent the expression from
+ getting too large
+ (showstack t) : same as above but print all expressions.
+ (showstack 5) : print only the first 5 expressions. of course, 5
+ is not the only possible numeric argument.
+ (showstack lev 3) : set prinlevel to 3 before printing
+ (showstack len 4) : set prinlength to 4 before printing
+ the above arguments can be used in combination.
+
+The default value of prinlevel is showstack-prinlevel, that of prinlength
+is showstack-prinlength. the default showstack printer is the
+value of showstack-printer (default is 'print').
+
+baktrace accepts the same arguments as showstack, but it ignores the
+prinlevel and prinlength arguments.
+
+
+
+
+From jkf Sat Apr 24 08:55:18 1982
+To: local-lisp
+Subject: lisp opus 38.12, liszt 8.05
+Status: RO
+
+ these changes and enhancements were made:
+
+1) the function 'function' in the interpreter acts just like 'quote'
+ In the compiler, 'function' will act like 'quote' unless the
+ argument is a lambda expression, in which case liszt will replace
+ the lambda expression with a unique symbol. That unique symbol's
+ function cell will contain a compiled version of the lambda
+ expression. These changes will make Franz compatible with Maclisp
+ type lisps, as far as the treatment of 'function'
+
+2) Mechanisms were added to permit user written C or Fortran code to call
+ lisp code. Everything isn't quite ready yet.
+
+3) Signal was fixed so that if you ask for a signal to be ignored, the
+ operating system will be notified. The correct way to fork a lisp
+ is now:
+ (cond ((fork) (signal 2 (prog1 (signal 2) (wait)))))
+
+4) You can select the default function trace uses to print the arguments and
+ results. Just lambda bind trace-printer to the name of the function
+ you want it to use. The standard trace-printer sets prinlevel and
+ prinlength to the values of trace-prinlevel and trace-prinlength before
+ printing. By default, trace-prinlevel is 4, and trace-prinlength is 5
+
+
+
+
+
+From jkf Sun Apr 25 23:46:16 1982
+To: local-lisp
+Subject: lisp opus 38.13
+Status: RO
+
+ Functions 1+ and 1- are now part of the interpreter, rather than
+being made equivalent to add1 and sub1.
+
+
+
+From jkf Wed Apr 28 09:52:43 1982
+To: local-lisp
+Subject: Opus 38.14
+Status: RO
+
+ Has these new features:
+ 1) the message [load filename] will appear before load
+ reads in a lisp source file. This can be disabled by
+ setting $ldprint to nil.
+ 2) a function 'truename' as been added. It takes a port
+ and returns the name of the file associated with that port.
+ It returns a string if there is a file associated with
+ the port, otherwise it returns nil.
+
+
+
+From jkf Wed Apr 28 10:36:34 1982
+To: local-lisp
+Subject: more on opus 38.14
+Status: RO
+
+ $ldprint is lambda bound to nil during the loading of the lisprc file.
+
+
+
+
+From jkf Wed May 5 08:30:00 1982
+To: local-lisp
+Subject: opus 38.15
+Status: RO
+
+ a minor modification: 'makhunk' is now more efficient.
+
+
+From jkf Wed May 5 20:56:40 1982
+To: local-lisp
+Subject: Opus 38.16
+Status: RO
+
+ A new function was added:
+ (hunk-to-list 'h_hunk)
+ returns the elements of h_hunk as a list.
+
+ Also, the error message printed when an oversized print name is encountered
+has been improved.
+
+
+
+From jkf Fri May 7 20:03:40 1982
+To: local-lisp
+Subject: Liszt version 8.06
+Status: RO
+
+
+ Local declarations are now supported. You can say:
+(defun foo (a b)
+ (declare (special a))
+ ... body ...)
+
+and the special declaration for 'a' will affect the body of function
+foo only. The 'a' which is an argument to foo will also be special
+in this case. Declarations may be
+ 1) at the top level, not within a function body.
+ 2) at the beginning of a 'lambda' body.
+ 3) at the beginning of a 'prog' body
+ 4) at the beginning of a 'do' body.
+
+'the beginning' means either the first, second or third form in the body.
+When the compiler is searching for declarations, it will not macroexpand.
+
+
+ Fixnum declarations now have meaning. If you do
+ (declare (fixnum i j))
+then
+ (greaterp i j) will be converted to (>& i j)
+
+ The declare function is now defined in the compiler. Previously,
+the only way to declare something was for the compiler to 'compile'
+the declaration form. Now, if you load or fasl in a file with
+a declare statement in it, the declare statement will have the
+proper effect in the compiler.
+
+
+ (function (lambda () ...)), (function (nlambda () ...)) and
+ (function (lexpr () ...)) are all supported.
+
+
+
+From jkf Wed May 12 08:15:37 1982
+To: local-lisp
+Subject: Lisp Opus 38.17
+Status: RO
+
+ ... has a minor bug fix: The port returned by 'fileopen' will now print
+correctly.
+
+
+
+From jkf Tue May 25 06:18:04 1982
+Date: 25-May-82 06:17:51-PDT (Tue)
+From: jkf
+Subject: opus 38.18
+Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ The msg macro will now evaluate all atom arguments except the ones
+for carriage control (N B). Thus if you used (msg foo) you should
+now use (msg "foo").
+
+
+
+From jkf Thu May 27 08:29:29 1982
+To: local-lisp
+Subject: liszt 8.08
+Status: RO
+
+ Fixes a bug in the code which converts generic arithmetic to fixnum only
+arithmetic. Liszt was converting from generic to fixnum operators based on
+the first argument only due to a typo in the code.
+
+
+
+
+From jkf Wed Jun 9 07:25:19 1982
+To: local-lisp
+Subject: lisp Opus 38.20
+Status: RO
+
+ There is now a character macro for reading hexadecimal.
+ #x1f = #X1f = #X1F = 31
+ #x-1f = -31
+
+
+
+From jkf Thu Jun 17 15:42:54 1982
+To: local-lisp
+Subject: Lisp Opus 38.21
+Status: RO
+
+ Has two routines for interfacing with termcap. These routines were
+written by morris djavaher and are meant to be called by lisp programs
+which have yet to be installed.
+
+
+
+
+From jkf Tue Jun 22 09:09:25 1982
+Date: 22-Jun-82 09:09:13-PDT (Tue)
+From: jkf
+Subject: opus 38.22
+Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ setq with no arguments will now return nil.
+
+
+
+From jkf Wed Jun 30 19:05:54 1982
+Date: 30-Jun-82 19:05:32-PDT (Wed)
+From: jkf (John Foderaro)
+Subject: liszt 8.09
+Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed)
+To: local-lisp
+Status: RO
+
+ liszt will now look in 12 places for an init file when it starts up.
+It will load in the first one it comes to only.
+The files it looks for are:
+
+ { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , }
+
+
+
+
+From jkf Tue Sep 14 08:53:03 1982
+Date: 14-Sep-82 08:52:44-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.26
+Message-Id: <8208141553.9999@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999;
+ 14-Sep-82 08:53:03-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx. Now it reads
+them (and other similar symbols) correctly.
+
+
+
+
+From jkf Sat Oct 2 15:15:48 1982
+Date: 2-Oct-82 15:15:32-PDT (Sat)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.27
+Message-Id: <8209022215.10796@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796;
+ 2-Oct-82 15:15:48-PDT (Sat)
+To: local-lisp
+Status: RO
+
+ If you set the variable top-level-print to a non nil value, then that
+value will be used by the top-level to print out the result of the
+evaluation. This has effect in break loops too.
+ For example, if you want the pretty printer to print out the top level
+values, type (setq top-level-print 'pp-form).
+
+
+
+
+
+From jkf Sun Oct 3 19:28:45 1982
+Date: 3-Oct-82 19:28:29-PDT (Sun)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.28
+Message-Id: <8209040228.9829@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829;
+ 3-Oct-82 19:28:45-PDT (Sun)
+To: local-lisp
+Status: RO
+
+ A modification has been made to the load function.
+ Normally if you type (load 'x), the load function will first try to fasl
+the file x.o and failing that it will try to load x.l
+ If you (setq load-most-recent t), and if x.l and x.o both exist, then
+load will fasl or load the most recently modified file.
+ The load-most-recent flag only has an effect if you type the filename
+without a trailing .l or .o.
+
+
+
+
+From jkf Tue Oct 5 21:01:55 1982
+Date: 5-Oct-82 21:01:33-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: liszt 8.12, lisp 38.29
+Message-Id: <8209060401.6358@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358;
+ 5-Oct-82 21:01:55-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ Liszt will now check that you are passing the correct number of arguments
+to functions. As a result, some files which have compiled without
+complaint in the past may compile now with warnings or errors. In this
+note, I'll explain what the compiler knows, what it looks for in your
+program, and how you can help the compiler understand your program.
+
+ For each function, liszt either knows nothing about the the number of
+arguments to a function, or it knows the minimum number of arguments, or the
+maximum number of arguments, or both the minimum and maximum number of
+arguments. This information comes about in one of three ways:
+ 1) it is known when liszt starts (by virtue of a value stored under the
+ fcn-info indicator on a function's property list)
+ 2) it is declared by the user, either via (declare (*arginfo ...))
+ or (declare (*args ...)) [see below]
+ 3) it is determined when a (lambda) function is compiled.
+ When a lambda is compiled, the compiler can easily figure out the
+ minimum and maximum number of arguments.
+ When an nlambda or lexpr function is compiled, the compiler doesn't
+ make a guess as to how many arguments are expected. The user should
+ use the (declare (*args ...)) form to tell the compiler how many
+ arguments are expected.
+ For lexpr's generated via 'defun' using &optional and &rest keywords,
+ the correct declaration is generated automatically.
+Once liszt determines the number of arguments to a function, it uses that
+information to check that the function is called with the correct number of
+arguments. It does not check calls to the function that occured before it
+determined the correct number of arguments. [This backward checking will
+be added sometime in the future.]
+
+ If liszt finds that a function is called with the wrong number of
+arguments, it prints an informative message. That message is a error if the
+function being called is one which is open coded by the compiler. The
+message is a warning otherwise. The reason for the distinction is that
+you are free to redefine functions not open coded by the compiler. If the
+number of arguments is not correct, it may just be that the compiler's
+database and your code are refering to two different functions.
+If you redefine system functions, you should use the
+(declare (*arginfo ...)) form to let the compiler know about the number
+of arguments expected by your version of the functions.
+
+ You can declare the number of arguments to functions using this form
+
+(declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...))
+ where each min or max is either a fixnum or nil (meaning "I don't know")
+
+for example, here are some `correct' declarations:
+
+(declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil)))
+
+ explanation:
+ (read 0 2) means that the function read expects between 0 and 2
+ arguments (inclusive).
+ (cons 2 2) means that cons expects 2 arguments.
+ (boole 3 nil) means that boole expects at least 3 arguments.
+ (append nil nil) means that append expects any number of arguments,
+ this is equivalent to (append 0 nil).
+
+
+The *arginfo declaration is usually made at the top level of a file.
+
+To declare the argument characteristics of the current function being
+compiled use the '*args' declaration. It looks somewhat like the
+*arginfo declaration.
+
+It is best explained with examples
+
+(def read
+ (lexpr (n)
+ (declare (*args 0 2))
+ ... code for read
+ ))
+
+(def process
+ (nlambda (x)
+ (declare (*args 1 3))
+ ... code for process
+ ))
+
+Note: the *args declaration is not needed for lambda's.
+
+
+
+ If you get an error or warning which you believe is incorrect, it is
+probably due to an incorrect database entry. Please let me know and I will
+fix it immediately. I expect that there will be quite a few of these
+errors because much of the database was built by hand.
+
+
+
+
+
+
+From jkf Fri Oct 8 12:55:45 1982
+Date: 8-Oct-82 12:55:31-PDT (Fri)
+From: jkf (John Foderaro)
+Subject: lisp 38.30, liszt 8.13
+Message-Id: <8209081955.4140@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140;
+ 8-Oct-82 12:55:45-PDT (Fri)
+To: local-lisp
+Status: RO
+
+There are now three new functions for dealing with processes:
+ *process
+ *process-send
+ *process-receive
+
+ These functions are designed to replace the 'process' function, which, due
+to its nlambda'ness, was difficult to use. All of the above functions
+are lambda's or lexpr's.
+
+ See chapter 6 of the manual (its on-line) for the details of these
+functions. This is a quick summary:
+
+ (*process-send 'st_command)
+ tells the shell to run the command st_command concurrently, and returns
+ a write-only port. Characters written to this port will appear at
+ the standard input of st_command.
+ example:
+ (setq p (*process-send "mail jkf"))
+ (print 'HiThere p)
+ (close p)
+
+
+ (*process-receive 'st_command)
+ tells the shell to run st_command concurrently, and returns a
+ read-only port. Characters written to the standard output by
+ st_command will be available by reading from the given port.
+ Characters written on the standard error by st_command will
+ appear on lisp's the standard error (the terminal most likely).
+ example:
+ ; to see if foo is logged in:
+ (setq p (*process-receive "u"))
+ (do ((user (read p '**eof**) (read p '**eof**)))
+ ((eq '**eof** user) (print 'Not-Logged-In))
+ (cond ((eq 'foo user) (print 'Is-Logged-In))))
+ (close p)
+
+
+ (*process 'st_command ['g_readp ['g_writep]])
+ this is the general function which process, *process-send and
+ *process-receive call. If called with one argument it
+ starts the new process and waits for it to end, e.g:
+ (*process (concat "vi " filename))
+ In this case *process return the exit code of the process.
+
+ The g_readp and g_writep arguments, if given, tell *process to
+ run the process concurrently. If g_read is non nil then
+ *process will return a port just like *process-receive.
+ If g_writep is non-nil, then *process will set up a pipe like
+ *process-send.
+ *process will return a list of the form
+ (readport writeport process-id)
+ where readport and writeport will only be a port if g_readp
+ or g_writep are non nil.
+
+
+ A little know fact about processes is that a process, once started,
+cannot die and disappear until its parent asks about its status.
+Take the mail example given above:
+ (setq p (*process-send "mail jkf"))
+ (print 'HiThere p)
+ (close p)
+after the mail process finishes it work, it will attempt to die, returning
+an integer called the 'exit status'. However until the lisp program
+asks about its status the mail process will remain in existence
+in a Zombie state, somewhere between life and death. ps will show this:
+
+ PID TT STAT TIME COMMAND
+ 3876 p0 Z 0:01 <exiting>
+
+A user is only allowed a small number of processes, so if you continue
+to generate processes and leave them around as Zombies, you will eventually
+run out of processes. The way to let the Zombie die is to call
+the wait function, e.g.
+ -> (wait)
+ (3876 . 0)
+ ->
+this says that process 3876 died with exit status 0.
+
+Also, when you exit lisp the shell will clean up the Zombies.
+
+If you start a process with (*process "vi foo") then lisp will wait
+for it to complete before continuing, so you don't have to worry about
+Zombies. You only have to worry if you run a process concurrently,
+such as when you use *process-send or *process-receive.
+
+
+
+
+
+
+
+From jkf Tue Oct 12 10:44:22 1982
+Date: 12-Oct-82 10:43:52-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.31
+Message-Id: <8209121744.29800@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
+ id A29800; 12-Oct-82 10:44:22-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ new function: (time-string ['x_time])
+ if given no arguments, it returns the current time as a string.
+
+ if given an argument, x_time, then it converts that argument to
+ a time string and returns that string.
+ The argument should represent the number of seconds since
+ Jan 1, 1970 (GMT).
+
+ note that this makes (status ctime) obsolete.
+
+
+
+From jkf Tue Oct 12 14:35:26 1982
+Date: 12-Oct-82 14:34:10-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: also in opus 38.31
+Message-Id: <8209122135.5086@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
+ id A05086; 12-Oct-82 14:35:26-PDT (Tue)
+To: local-lisp
+Status: RO
+
+ If top-level-read is set to a non nil value, then the lisp
+top level will funcall it to read a form for evaluation.
+It will be funcalled with two arguments, a port and an eof marker.
+top-level-read will be used in break levels too.
+ Be very careful when setting top-level-read because if you set it
+to an illegal value, there is no way to correct it.
+
+
+
+
+
+From jkf Tue Oct 19 18:54:18 1982
+Date: 19-Oct-82 18:54:02-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: lisp tags
+Message-Id: <8209200154.195@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A00195; 19-Oct-82 18:54:18-PDT (Tue)
+To: franz-friends
+Status: RO
+
+ We also use vi style tags so emacs users and vi users can share the same
+tags file. Rather than modify ctags, we use this shell script:
+
+#!/bin/csh
+# make a tags file for lisp source files.
+# use:
+# lisptags foo.l bar.l baz.l ... bof.l
+# generate the file 'tags'
+#
+awk -f /usr/local/lib/ltags $* | sort > tags
+
+
+where the file /usr/local/lib/ltags is
+
+/^\(DEF/ { print $2 " " FILENAME " ?^" $0 "$?" }
+/^\(def/ { print $2 " " FILENAME " ?^" $0 "$?" }
+
+
+
+From jkf Tue Oct 19 22:50:40 1982
+Date: 19-Oct-82 22:50:29-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: Lisp Opus 38.32, Liszt 8.14
+Message-Id: <8209200550.3968@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A03968; 19-Oct-82 22:50:40-PDT (Tue)
+To: local-lisp
+Status: RO
+
+
+Topic 1:
+ liszt can now autoload macros. If liszt encounters a symbol without
+ a function definition but with a macro-autoload indicator on the
+ property list, then the value of the indicator is a file to load which
+ should define the macro.
+
+ The interpreter's undefined function handler will also look for
+ macro-autoload properties, thus you needn't give a symbol both an
+ autoload and a macro-autoload property.
+
+ The default lisp contains macro-autoload properties for the macros
+ defstruct, loop and defflavor.
+
+Topic 2:
+ It is now possible to define 'compiler only macros' or cmacros.
+ A cmacro acts like a normal macro, but will only be used by the
+ compiler. A cmacro is stored on the property list of a
+ symbol under the indicator 'cmacro'. Thus a function can
+ have a normal definition and a cmacro definition.
+ The macro 'defcmacro' has a syntax identical to 'defmacro' and
+ creates cmacros instead of macros.
+ For an example of the use of cmacros, see the definitions
+ of nthcdr and nth in /usr/lib/lisp/common2.l
+
+ Topic 3:
+ If the form (foo ...) is macro expanded and the result also begins
+ with the symbol foo, then liszt will stop macro expanding (previously
+ it got into an infinite loop).
+
+ Topic 4:
+ The function nth has been added to Franz.
+ (nth 'x_index 'l_list)
+ returns the nth element of l_list, where the car of the list
+ is accessed with (nth 0 'l_list)
+
+ The macros (push 'g_value 'g_stack), and
+ (pop 'g_stack ['g_into])
+ have been added to franz.
+ typical uses
+ (setq foo nil)
+ (push 'xxx foo)
+ (push 123 foo)
+ now foo = (123 xxx)
+ (pop foo) returns 123
+ now foo = (xxx)
+ (pop foo yyy) returns xxx and sets yyy to xxx
+
+
+ Topic 5:
+ The version of Flavors written at Mit for Franz have been transported
+ here. Flavors is a system for doing object oriented programming in
+ lisp. The documentation for flavors in the Lisp Machine manual
+ from Mit. Since Lisp Machine manuals are rather scarce around here,
+ perhaps we can find someone to make copies of the flavor chapter for
+ those interested in it. There is a description of the unique
+ features of the Franz Flavors in /usr/lib/lisp/flavors.usage.
+ As mentioned above, the flavors code will be autoloaded
+ when you call 'defflavor' for the first time.
+ Our local flavors expert is Eric Cooper (r.ecc).
+
+
+
+
+
+
+
+From jkf Fri Oct 22 15:46:51 1982
+Date: 22-Oct-82 15:46:32-PDT (Fri)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.34
+Message-Id: <8209222246.5610@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A05610; 22-Oct-82 15:46:51-PDT (Fri)
+To: local-lisp
+Status: RO
+
+
+ Franz lisp now has a form of closure called an fclosure. A fclosure is a
+compromise between a funarg and the type of functional object that we
+currently have in Franz. In this short note, I'll explain through examples
+what fclosures are and where you might use them, and finally describe the new
+functions. The fclosure system was designed to be compatible with the Lisp
+Machine closures, so you may want to look at a Lisp Machine manual for more
+information. fclosure are related to closures in this way:
+ (fclosure '(a b) 'foo) <==> (let ((a a) (b b)) (closure '(a b) 'foo))
+
+A example of the use of fclosures:
+
+->(setq counter 0)
+0
+->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
+fclosure[1]
+
+The function 'fclosure' creates a new type of object called a fclosure.
+A fclosure object contains a functional object, and a set of symbols and
+values for the symbols. In the above example, the fclosure functional
+object is (lambda (val) (setq counter (+ val counter)))
+and the set of symbols and values just contains the symbol 'counter' and
+zero, the value of counter when the fclosure was created.
+
+When a fclosure is funcall'ed:
+ 1) the lisp system lambda binds the symbols in the fclosure to their
+ values in the fclosure.
+ 2) it continues the funcall on the functional object of the fclosure
+ 3) finally it un-lambda binds the symbols in the fclosure and at the
+ same time stores the current values of the symbols in the fclosure.
+
+To see what that means, let us continue the example:
+-> (funcall x 32)
+32
+-> (funcall x 21)
+53
+
+Notice that the fclosure is saving the value of the symbol 'counter'.
+Each time a fclosure is created, new space is allocated for saving
+the values of the symbols.
+If we executed the same fclosure function:
+->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
+fclosure[1]
+
+We now have two independent counters:
+-> (funcall y 2)
+2
+-> (funcall y 12)
+14
+-> (funcall x 3)
+56
+
+To summarize:
+
+(fclosure 'l_vars 'g_funcobj)
+ l_vars is a list of symbols (not containing nil)
+ g_funcobj is lambda expression or a symbol or another fclosure
+
+ examples: (fclosure '(foo bar baz) 'plus)
+ (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #'
+ which will make the compiler compile the
+ lambda expression.
+
+
+There are time when you want to share variables between fclosures.
+This can be done if the fclosures are created at the time times using
+fclosure-list:
+
+(fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...])
+ This creates a list of closures such that if a symbol appears in
+ l_varsN and l_varsM then its value will be shared between the
+ closures associated with g_funcobjN and g_funcobjM.
+
+ example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y))
+ '(c a) '(lambda () (setq c a))))
+ (fclosure[4] fclosure[7])
+ -> (funcall (car x) 123) ; set the value of a in the 1st fclosure
+ 123
+ -> (funcall (cadr x)) ; read the same value in the 2nd fclosure
+ 123
+
+
+Other fclosure functions:
+
+(fclosure-alist 'c_fclosure)
+ returns an assoc list giving the symbols and values in the fclosure
+
+(fclosurep 'g_obj)
+ returns t iff g_obj is a fclosure
+
+(fclosure-function 'c_fclosure)
+ returns the functional object of the fclosure
+
+
+
+Note: If a throw (or error) occurs during the evaluation of a fclosure,
+ which passes control out of the fclosure, then current values of the
+ symbols will not be stored. This may be a bug. We could set up
+ an unwind-protect, but it would then take longer to funcall
+ a fclosure. If you think an unwind protect is important, let me know.
+
+Note 2: you can also 'apply' a fclosure.
+
+
+
+
+
+
+From jkf Sat Oct 23 08:58:07 1982
+Date: 23-Oct-82 08:57:53-PDT (Sat)
+From: jkf (John Foderaro)
+Subject: more on closures
+Message-Id: <8209231558.21572@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A21572; 23-Oct-82 08:58:07-PDT (Sat)
+To: local-lisp
+Status: RO
+
+ I sent the maryland people the flavors.usage file from mit so that they
+could compare their implementation with mit's. What follows is their
+analysis. Some of the differences between the two versions is due to
+different schemes for getting around the fact that franz didn't have a form
+of closure. RZ has indicated that now that franz has fclosures, it may be
+possible to use more of the 'official' lisp machine flavor code. fclosures
+will probably affect the maryland implementation too:
+Date: 22 Oct 82 15:39:18 EDT (Fri)
+From: Liz Allen <liz.umcp-cs@UDel-Relay>
+Subject: flavors
+To: jkf at Ucb-C70
+Via: UMCP-CS; 23 Oct 82 9:09-EDT
+
+Wow, implementing closure in one day is amazing. We had thought
+about writing some kind of closure... We've been discussing how
+having closures would affect our code. It might make it easier to
+read and modify, but it might be less efficient. Can you tell us
+how your implementation works and what it looks like to a user?
+
+About the MIT implementation. Ours is probably better in a couple
+of respects but probably loses a couple of places, too. Pros:
+
+ 1. With ours, there is no need to discard instances when
+ redefining a flavor. The only time this would be necessary
+ is if the instance variables change which rarely happens
+ since methods change much more often than the instance
+ variables. Without a structure editor, you tend to reload the
+ file containing flavors in order to change a method.
+
+ 2. We can compile files with flavors (he didn't say if you
+ can compile MIT's Franz flavors) and when they are compiled
+ they run *fast*. Most of the overhead occurs at combine
+ time and compiled flavors shouldn't have to be recombined.
+
+ 3. We use hunks to store instance variables (actually, an
+ instance is a hunk whose cxr 0 is the name of the flavor and
+ whose cxr n (> 0) are the values of instance variables). We
+ pay a price at combine time since instance variable references
+ in method code are replaced with cxr and rplacx calls (but MIT
+ pays the same price in putting hash calls in the methods), but
+ we win over MIT since the cxr calls are much faster than the
+ hash table calls. We do have to have "ghost" methods which
+ are copies of methods containing different cxr calls when the
+ referenced variables of a method don't align in flavors
+ which inherit the method. This, however, happens only
+ rarely.
+
+ 4. We handle getting and setting instance variables better
+ than the MIT implementation -- we don't need to send a message
+ and the syntax is much better. We recently added the
+ functions << and >> which get and set instance variables, eg:
+
+ (<< foo 'instance-var)
+ and
+ (>> foo 'instance-var 'value)
+
+ where foo is a flavor instance.
+
+ 5. Our describe function has a hook which (if the variable
+ *debugging-flavors* is set to non-nil) allows the user to
+ follow pointers to any instances referenced in the describe.
+ This is done by assigning to a variable (made from its unique
+ id) the value of the instance.
+
+Cons:
+
+ 1. They implement more things from Lisp Machine flavors
+ (like wrappers/whoppers, init-keywords), but we really haven't
+ found the need for them. We implement less closely to LM
+ flavors, but in a way that's better suited to Franz Lisp.
+
+ 2. We didn't implement the method table as a hash table, but
+ there's no reason why we couldn't.
+
+ 3. Things we don't have, but could easily implement include:
+ describe-method, defun-method/declare-flavor-instance-variables,
+ and storing flavor information in hunks instead of on the
+ property lists.
+
+ 4. We don't handle method types like :and and :or. We just
+ have primary/untyped methods and :before and :after daemons.
+
+We have people reading our documentation. After we get some feedback
+from them, we'll send the tape and docs to you. That should be early
+next week.
+
+ -Liz Allen and Randy Trigg
+
+
+
+
+
+
+
+From jkf Mon Oct 25 12:56:59 1982
+Date: 25-Oct-82 12:55:44-PDT (Mon)
+From: jkf (John Foderaro)
+Subject: lisp Opus 38.35, liszt 8.15
+Message-Id: <8209251956.17542@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A17542; 25-Oct-82 12:56:59-PDT (Mon)
+To: local-lisp
+Status: RO
+
+
+New features:
+ 1) tilde-expansion: franz will now expand filenames which begin with ~
+ just like csh does. It will only do the expansion if
+ the symbol tilde-expansion has a non-nil value. The default
+ value for tilde-expansion is t.
+ These functions do tilde expansion: If I've left any out, let
+ me know:
+ load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir
+ sys:access, sys:unlink [these are new functions, see below]
+
+ 2) liszt will remove its temporary file if given a SIGTERM signal
+ (SIGTERM is sent by default when you give the kill command from the shell)
+
+ 3) load will now print a helpful message if an read error occurs when it
+ is reading a file.
+
+ 4) new functions:
+
+ (lexpr-funcall 'function 'arg1 ... 'argn)
+ This is a cross between funcall and apply.
+ The last argument, argn, must be a list (possibly empty).
+ The element of list argn are stacked and then the function is
+ funcalled.
+ For example:
+ (lexpr-funcall 'list 'a 'b 'c '(d e f))
+ is the same as
+ (funcall 'list 'a 'b 'c 'd 'e 'f)
+
+ Also
+ (lexpr-funcall 'list 'a 'b 'c nil)
+ is the same as
+ (funcall 'list 'a 'b 'c)
+
+ (tilde-expand 'st_filename)
+ returns: symbol whose pname is the filename, with a leading tilde
+ expanded. if st_filename doesn't begin with a tilde, it
+ just returns st_filename
+
+ (username-to-dir 'st_name)
+ returns: the home directory of the given user, if that user exists.
+ Saves old information so doesn't have to keep searching
+ the passwd file.
+
+ Some low level system functions. These are listed here for completeness.
+ The perform a function from the unix library (see the unix manual
+ for details).
+ (sys:getpwnam 'st_username)
+ return passwd file info.
+ (sys:access 'st_file 'x_mode)
+ (sys:unlink 'st_file)
+
+
+Bug fixes:
+ 1) patom will handle prinlevel and prinlength correctly.
+ 2) it is now safe for an interpreted function to redefine itself.
+ 3) the information return by 'evalframe' about a funcall'ed function
+ is now correct.
+
+
+
+
+
+
+From jkf Mon Oct 25 14:57:00 1982
+Date: 25-Oct-82 14:56:25-PDT (Mon)
+From: jkf (John Foderaro)
+Subject: 'if' macro: request for comments
+Message-Id: <8209252157.21567@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A21567; 25-Oct-82 14:57:00-PDT (Mon)
+To: local-lisp
+Status: RO
+
+ Would anyone object if we added a macro called 'if' to the default franz
+system? 'if' is a common name and I want to make sure that it doesn't
+break any existing code before I add it.
+
+Some background:
+ At mit the 'if' macro is used all over the place.
+ Its form is
+ (if <predicate> <then-expr> [ <else-expr>])
+
+ I've always felt that macros should make the code more readable and
+ that the 'if' macro makes code more obscure because it isn't easy
+ to tell in complicated 'if' expressions where the <then-expr>
+ and <else-expr>'s begin. Also, there is no provision for
+ an 'elseif' expression.
+
+ I wrote a macro called 'If' which uses keywords to separate clauses.
+ (If <pred>
+ then <then-expr>
+ [elseif <pred> then <then-expr>]*
+ [else <else-expr>])
+
+ These two macros are not incompatible. one macro could do the job
+ of both. There is an ambigous case:
+ (if p then x) could be (cond (p then) (t x))
+ or (cond (p x))
+ but it isn't likely that 'if' macro users would write something like
+ that.
+
+Thus I propose that we add a macro, if, which act's like 'If' if
+its second arg is 'then' or like 'if' it the second arg is not 'then'
+and there are two or three arguments. Other cases would cause
+an error.
+
+
+
+
+
+From jkf Mon Oct 25 22:37:24 1982
+Date: 25-Oct-82 22:37:09-PDT (Mon)
+From: jkf (John Foderaro)
+Subject: opus 38.36
+Message-Id: <8209260537.1666@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A01666; 25-Oct-82 22:37:24-PDT (Mon)
+To: local-lisp
+Status: RO
+
+ I've added the 'if' macro to franz. If you have any objections, it is still
+not too late to voice them.
+ I've also defined 'If' to be the same as 'if'.
+
+ As I mentioned in my earlier request for comments, the 'if' macro is a
+cross between the mit version and a locally written version using keywords.
+The following documentation describes the various forms.
+As you know, you can test out the 'if' macro by using apply. for example:
+
+=> (apply 'if '(if a then b c elseif d thenret else e))
+(cond (a b c) (d) (t e))
+
+
+;
+; This macro is compatible with both the crufty mit-version and
+; the keyword version at ucb.
+;
+; simple summary:
+; non-keyword use:
+; (if a b) ==> (cond (a b))
+; (if a b c d e ...) ==> (cond (a b) (t c d e ...))
+; with keywords:
+; (if a then b) ==> (cond (a b))
+; (if a thenret) ==> (cond (a))
+; (if a then b c d e) ==> (cond (a b c d e))
+; (if a then b c else d) ==> (cond (a b c) (t d))
+; (if a then b c elseif d thenret else g)
+; ==> (cond (a b c) (d) (t g))
+;
+;
+;
+;
+; In the syntax description below,
+; optional parts are surrounded by [ and ],
+; + means one or more instances.
+; | means 'or'
+; <expr> is an lisp expression which isn't a keyword
+; The keywords are: then, thenret, else, elseif.
+; <pred> is also a lisp expression which isn't a keyword.
+;
+; <if-stmt> ::= <simple-if-stmt>
+; | <keyword-if-stmt>
+;
+; <simple-if-stmt> ::= (if <pred> <expr>)
+; | (if <pred> <expr> <expr>)
+;
+; <keyword-if-stmt> ::= (if <pred> <then-clause> [ <else-clause> ] )
+;
+; <then-clause> ::= then <expr>+
+; | thenret
+;
+; <else-clause> ::= else <expr>+
+; | elseif <pred> <then-clause> [ <else-clause> ]
+
+
+
+
+
+
+From jkf Tue Oct 26 09:20:25 1982
+Date: 26-Oct-82 09:20:04-PDT (Tue)
+From: jkf (John Foderaro)
+Subject: no more jkfmacs
+Message-Id: <8209261620.11552@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A11552; 26-Oct-82 09:20:25-PDT (Tue)
+To: local-lisp
+Status: RO
+
+
+ Since Franz now has the push, pop, if and msg macros, there is no
+reason for jkfmacs to exist. I've removed the code in jkfmacs and
+replaced it with a warning message which will be printed if you load it.
+ If you used the jkfmacs version of 'push' you will have to go through
+your code and switch the order of arguments. The Franz version is
+ (push value stack)
+Also, the unpush macro, defined in jkfmacs, no longer exists: just use
+pop with one argument.
+
+
+
+From jkf Wed Oct 27 20:35:07 1982
+Date: 27-Oct-82 20:34:25-PDT (Wed)
+From: jkf (John Foderaro)
+Subject: liszt 8.16
+Message-Id: <8209280335.27561@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A27561; 27-Oct-82 20:35:07-PDT (Wed)
+To: local-lisp
+Status: RO
+
+ Back on May 6, a modification to liszt was made which turned 'declare'
+into a user callable function which provided information to the compiler.
+The purpose of the change was to permit one to 'load' a file containing
+declarations, instead of 'include'ing it. It turns out that this was a bad
+idea since if the compiler were to evaluate an interpreted function with
+local declarations, it would assume that those local declarations were
+describing the current file being compiled.
+ Thus declare has it old meaning: it is a no-op unless the compiler is
+compiling the form. If one really wants to actively declare something,
+we've added the function 'liszt-declare', which looks just like declare
+but can be evaluated within the compiler.
+
+ If you are confused by all this, don't worry. There is very little chance
+that it will affect you.
+
+
+
+From jkf Fri Oct 29 09:34:11 1982
+Date: 29-Oct-82 09:33:59-PDT (Fri)
+From: jkf (John Foderaro)
+Subject: cmacros
+Message-Id: <8209291634.8411@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A08411; 29-Oct-82 09:34:11-PDT (Fri)
+To: local-lisp
+Status: RO
+
+ A week ago, Joe Faletti mentioned that one problem with cmacros is that if
+you redefine a function, the cmacro property stays around and thus the
+redefinition of the function isn't communicate to the compiler.
+ He suggested that whenever a function is defined (via 'def' or when fasl'ed
+in) any cmacro properties should be remprop'ed. I've been trying to think
+of an alternative to this, but I can't think of one. Unless someone
+has a better idea, I'll implement his suggestion.
+ This means that if you want to define the function 'foo' and a cmacro for
+'foo', the cmacro definition must appear later in the file than 'foo's
+definition.
+
+
+
+
+From jkf Fri Oct 29 10:11:36 1982
+Date: 29-Oct-82 10:10:54-PDT (Fri)
+From: jkf (John Foderaro)
+Subject: LetS: An Expressional Loop Notation
+Message-Id: <8209291711.9176@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A09176; 29-Oct-82 10:11:36-PDT (Fri)
+To: local-lisp
+Status: RO
+
+ I've got a copy of a paper by Richard Waters (at mit) describing a system
+for writing loops in lisp (and other languages). Basically you describe the
+loop in functional programming terms (similar to Backus's FP, or apl) and
+the LetS package converts it into an iterative form for efficient execution
+in lisp.
+ We don't have the LetS code here to play with, and we probably won't be
+able to get it for a while since our arpanet connection is hopelessly
+clogged for anything but tiny messages. However you might be interested in
+stopping by my office and looking at the paper.
+
+
+
+
+From jkf Fri Oct 29 12:06:47 1982
+Date: 29-Oct-82 12:06:08-PDT (Fri)
+From: jkf (John Foderaro)
+Subject: Re: cmacros
+Message-Id: <8209291906.12141@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A12141; 29-Oct-82 12:06:47-PDT (Fri)
+To: baden, local-lisp
+In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday)
+Status: RO
+
+ I could make it a 'Note'. I would prefer not to make it a warning because
+such redefinition is guaranteed to occur when the compiler compiles itself
+and the lisp code part of the lisp system.
+
+
+
+From fateman Sat Oct 30 09:17:49 1982
+To: franz-friends
+Subject: fugue # 2
+Status: RO
+
+ FUGUE Notes
+
+ An occasional publication of the
+ Franz Lisp User Group under Unix and Eunice (FUGUE)
+
+ Number 2 (October, 1982)
+ edited by Richard J. Fateman
+ University of California
+ Berkeley CA 94720
+ USA
+ fateman@berkeley
+
+1. Welcome!
+
+ It seems about time to publish the second of these
+newsletters, since we have accumulated a number of new
+items. We would also like to relay to others such informa-
+tion as has been forwarded to us. The reports of projects at
+Berkeley (and elsewhere) may strike sympathetic chords with
+other research.
+
+2. New programs
+
+2.1. OPS-5
+
+ OPS-5 is a "production system" written by Charles Forgy
+of CMU. It appears to work just fine in Franz, and is in
+wide use. Interested persons may obtain copies of documen-
+tation and the program from Charles.Forgy@CMU-10A. ( Charles
+Forgy, Computer Science Department, Carnegie-Mellon Univer-
+sity, Pittsburgh, PA 15213)
+
+It is their policy to send it to anyone who wants it free of
+charge.
+
+2.2. GLISP
+
+ GLISP is a system which provides interesting linguistic
+features for generic operations and data abstraction. Writ-
+ten by Gordon Novak at Stanford University, it was origi-
+nally developed for Interlisp, but has been ported to other
+lisps, including Franz.
+
+2.3. Flavors
+
+ There are now two distinct implementations, apparently
+with identical functionally, of "flavors" as appearing in
+the MIT Lisp Machine software. One is described in TR-1174,
+____________________
+\e9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
+SRI Int'l, and Univ. of Calif.
+
+
+
+\e9
+
+
+
+
+
+
+
+
+
+
+"Franz Flavors" by Richard J. Wood (Dept of C.S., Univ. of
+Maryland, College Pk, MD 20742). The other was written by
+Juan R. Loaiza of MIT, Laboratory for Computer Science. We
+have a copy of the latter on-line here, and expect to
+receive a copy of the Maryland one, shortly. Eric Cooper
+here at Berkeley is in charge of the flavors situation.
+
+ There is an implementation of closures, mostly compati-
+ble with the Lisp Machine specification, announced by John
+Foderaro for Opus 38.33. The incompatibility is a result of
+what we perceive to be a high performance penalty for eso-
+terica.
+
+2.4. Database Interfaces
+
+ Jim Larus at UCB has cooked up interfaces to both the
+INGRES relational database system, and the simpler TROLL
+database system. These will be described in his forthcoming
+MS report, along with the next item.
+
+2.5. Cursor-control and Menus
+
+ Larus has provided an implementation of screen manage-
+ment which uses the UNIX "curses" package for primitive win-
+dow management. A menu-based interface has also been
+developed as part of this.
+
+2.6. Vaxima and Algebraic Manipulation
+
+ A new version of vaxima, the VAX version of the MACSYMA
+algebraic manipulation system, was released in July by UCB,
+incorporating some bug fixes, improved programs, and a large
+number of user-contributed subroutine libraries. This was
+made available to test-site licensees. Unfortunately, MIT
+has suspended new test-site licensing since about April,
+1982. We hope that MIT will be liberalizing its distribu-
+tion policy to non-commercial sites.
+
+ See the note below about MACSYMA being sold.
+
+ As a counterpoint to this, UC Berkeley has received a
+substantial grant from the System Development Foundation for
+work on Mathematical Representation and Manipulation, which
+should result in some more advanced systems for application
+of computers to symbolic mathematics. Recruiting for
+researchers, staff, and students is underway now, and
+interested persons should contact Richard Fateman.
+
+2.7. VLSI Design Rule Checker
+
+ Lyra, written in Lisp by Michael Arnold, is a retarget-
+able, hierarchical, design rule checker for VLSI circuits.
+Lyra features a rule compiler (also written in Lisp of
+
+
+
+
+
+
+
+
+
+
+
+
+
+course!) which translates symbolic design rule descriptions
+to lisp code for checking the rules. Lyra was used for the
+RISC project. It is currently being used extensively at
+Berkeley, and will be included in the Fall-82 distribution
+of of the Berkeley CAD tools. For more information contact
+Michael Arnold or John Ousterhout at Berkeley.
+
+2.8. Generic Arithmetic
+
+ As a proposed extension to Franz arithmetic, Richard
+Fateman, Keith Sklower and Scott Morrison, have written a
+simple-minded generic arithmetic package which includes
+modules which can be loaded to support exact rational arith-
+metic, software-simulated IEEE extended arithmetic, arbi-
+trary precision floating point, complex, interval, and mul-
+tivariate polynomial. Combinations of some of these are sup-
+ported, although the package is as yet incomplete in some
+areas. The IEEE arithmetic simulation is written in C.
+These packages are probably not in good enough shape for
+casual use by others.
+
+
+3. New features
+
+ Various performance enhancements and bug fixes have
+been incorporated in versions of Franz (now on Opus 38.33
+and the compiler, Liszt 8.14) These are mentioned in brief
+here; more details accompany updates of the system and
+manual included in the forthcoming Berkeley 4.2BSD UNIX dis-
+tribution.
+
+3.1. Franz
+
+ We added a switch to cause the evaluator to save macro
+expansions so they need only be expanded once.
+
+ We added vector and vector-immediate data types.
+
+ We rewrote showstack and backtrace so they are easier
+to use.
+
+ We made the lisp to foreign function interface more
+secure. The system now allows foreign function to call lisp
+functions.
+
+ We added closures and support flavors, features from
+the Lisp Machine.
+
+3.2. Liszt
+
+ Liszt will check the number of arguments to system
+functions and user defined functions.
+\e9
+
+\e9
+
+
+
+
+
+
+
+
+
+
+ Liszt supports local declarations.
+
+ Liszt will automatically compile lambda expressions
+headed by the function `function'.
+
+ Liszt supports compiler-only macros and will autoload
+macros if necessary.
+
+4. MC68000
+
+ Keith Sklower and Kevin Layer have been working on the
+MC68000 version of Franz under the UNIX operating system
+(using a DUAL System 83). While the current configuration is
+a swapping system, the Lisp should be able to use the full
+address space of the CPU. We expect to have this system run-
+ning on the UNIX 4.2 BSD SUN software, too. The base system
+on the DUAL, including the interpreter, reader, bignums,
+fasl, works; the compiler is being perfected.
+
+
+5. Other Lisps
+
+ We now have, in-house tried 4 (other) VAX UNIX lisp
+systems: YLISP, Interlisp, PSL, and VLISP. We know that
+Interlisp can run also on VMS using the Eunice package.
+Interested parties can contact David Dyer at USC-ISI. There
+is also a version of lisp which runs on VMS only, namely
+NIL, from MIT, which appears to be undergoing limited dis-
+tribution. Two other lisps under development under UNIX are
+Yale's answer to NIL, namely "T", and Common Lisp, from CMU
+and friends.
+
+ Counting Franz, that makes 7 lisp systems for the VAX
+computer line. Not counting variants on 2 operating systems.
+A Paen to standardization.
+
+ Dick Gabriel states some useful principles for com-
+parisons in the conference record of the 1982 ACM Lisp and
+Functional Programming Conference, which was held in August.
+We understand he now has a collection of some 18 programs
+which he is continuing to time on various systems.
+
+6. Work in Progress
+
+6.1. BITGRAPH SUN AED-512
+
+ Greg Foster at UCB is working on raster-graphics sup-
+port in Franz for the 800 by 1000 b/w raster displays of the
+BBN Bitgraph and/or the SUN Workstation, and possibly the
+color 512 by 512 AED system. We are probably going to han-
+dle mice and Bitpad (stylus) input for pointing. There are
+lots of projects we hear about with similar systems, e.g.
+just recently from the University of Maryland, using UNIX
+
+
+
+
+
+
+
+
+
+
+
+
+
+and multiplexed files for window management of a 68000-based
+home-grown workstation.
+
+6.2. RISC-LISP
+
+ Yes, Reduced Instruction Set Computer fans, who else
+but UCB would be so bold... Carl Ponder is examining the
+issues involved in constructing a fast lisp interpreter and
+compiler for the RISC architecture. You see, we have all
+these chips...
+
+
+7. Work Contemplated
+
+7.1. Fast Number Compiler
+
+ Undergraduate Jeff Cohen at Berkeley is starting to
+look at this. There are several industrial concerns that
+have expressed interest in using such a system, but expected
+it to be subsidized by someone else.
+
+7.2. IBM Franz
+
+ Even more nibbles on this one, but not yet.
+
+8. Business News
+
+8.1. Eunice SOLD
+
+ Some of you may have heard that the Eunice software
+package was sold by SRI to the Wollongong Group, a UNIX sup-
+port group in Palo Alto. Prices range from $2k (educa-
+tional) to $5k (commercial). Naturally this package is of
+interest beyond the availability of Franz Lisp. We have not
+compared this product to other similar ones, but we know
+that TWG has been distributing a working Franz opus 38.
+
+ As far as alternatives to Eunice, we are aware of a
+system developed at Rice University, and another by Human
+Computing Resources (HCR) in Toronto. We have not
+evaluated either of these.
+
+8.2. MACSYMA SOLD
+
+ MIT has sold exclusive rights to MACSYMA, a large alge-
+braic manipulation system, to Symbolics, Inc. of Cambridge
+Mass. This package runs in Franz Lisp, (among other Lisps)
+We hope that soon it will again be available to educational
+institutions with VAX systems either from us or Symbolics,
+at a nominal charge. We understand that commercial licenses
+(from Symbolics) for versions of MACSYMA on PDP-10s, Lisp
+Machines, etc. will distributed at non-nominal prices and
+offered with maintenance contracts.
+
+
+
+
+
+
+
+From liz.umcp-cs@UDel-Relay Mon Nov 1 17:43:52 1982
+Date: 29 Oct 82 12:04:24 EDT (Fri)
+From: Liz Allen <liz.umcp-cs@UDel-Relay>
+Subject: Re: Flavor system
+To: ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc
+Cc: randy.umcp-cs at UDel-Relay
+In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley
+Via: UMCP-CS; 30 Oct 82 5:40-EDT
+Status: RO
+
+ Date: 25 October 1982 16:29-EDT
+ From: ECC@MIT-MC@Berkeley
+ Subject: Flavor system
+ To: FRANZ-FRIENDS at MIT-MC
+
+ Can someone give me a pointer to the Franz flavor system
+ developed by U. Maryland? I am looking for information on how to
+ FTP the files -- what machine, whether public, what files, etc.
+
+Since the U. of Maryland is not (yet) an Arpanet host, you can't
+FTP files directly from here. We are right now completing some
+documentation for all of our hacks -- including documentation for
+some recent improvements for our flavors system. When that
+documentation is complete, we will be ready to distribute the
+packages developed here. Besides flavors, this includes a top
+level called userexec which is based on INTERLISP's top level and
+a production system called YAPS similar to but more flexible than
+OPS5.
+
+We are supposed to become an Arpanet host in a few months... (Read
+open ended period of time.) Meanwhile, if you would like to get
+our code, mail me a tape, and I will mail it back with the code and
+documentation on it. I'd appreciate it if someone would volunteer
+to let other folks FTP the files from their machine until we do
+become an Arpanet host. My address is:
+
+ Liz Allen
+ Univ of Maryland
+ Dept of Computer Science
+ College Park MD 20783
+ (301) 454-4247
+ liz.umcp-cs@udel-relay
+
+ -Liz
+
+
+
+From jkf Wed Nov 3 15:49:29 1982
+Date: 3-Nov-82 15:48:50-PST (Wed)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.40
+Message-Id: <8210032349.16460@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A16460; 3-Nov-82 15:49:29-PST (Wed)
+To: local-lisp
+Status: RO
+
+ putprop will now put new properties at the head of the property list.
+
+
+
+
+From ecc@UCBARPA Thu Nov 4 10:28:49 1982
+Date: 4-Nov-82 10:19:26-PST (Thu)
+From: ecc@UCBARPA (Eric C. Cooper)
+Subject: Lisp song
+Message-Id: <8210041819.24539@UCBARPA.BERKELEY.ARPA>
+Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82])
+ id A24537; 4-Nov-82 10:19:28-PST (Thu)
+Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A00305; 4-Nov-82 10:28:49-PST (Thu)
+To: local-lisp@kim
+Status: O
+
+[This has been forwarded from uucp through Xerox through info-lispm.]
+
+>From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
+
+Another Glitch in the Call
+------- ------ -- --- ----
+ (Sung to the tune of a recent Pink Floyd song.)
+
+
+We don't need no indirection
+We don't need no flow control
+No data typing or declarations
+ Hey! Did you leave the lists alone?
+
+Chorus:
+ All in all, it's just a pure-LISP function call.
+
+We don't need no side effect-ing
+We don't need no scope control
+No global variables for execution
+ Hey! Did you leave those args alone?
+
+(Chorus)
+
+We don't need no allocation
+We don't need no special nodes
+No dark bit-flipping in the functions
+ Hey! Did you leave the bits alone?
+
+(Chorus)
+
+We don't need no compilation
+We don't need no load control
+No link edit for external bindings
+ Hey! Did you leave that source alone?
+
+(Chorus, and repeat)
+
+From jkf Sat Nov 13 20:53:41 1982
+Date: 13-Nov-82 20:53:16-PST (Sat)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.41
+Message-Id: <8210140453.490@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
+ id A00490; 13-Nov-82 20:53:41-PST (Sat)
+To: local-lisp
+Status: O
+
+ added functions:
+ (remq 'g_val 'l_list) - just like remove but uses eq instead of equal
+ (command-line-args) - returns a list of the command line arguments
+ when lisp was started. This function will return
+ only those arguments typed by the user, even if the
+ lisp was started with the autorun feature (liszt -r).
+ (sys:gethostname) - returns the name of the machine.
+ (status domain) - returns 'ucb' here.
+
+
+
+From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982
+Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST
+Date: 28 Nov 1982 11:47:28-EST
+From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A
+Subject: (random) problems
+Status: RO
+
+I am having two problems using (random) in Franz lisp. The first problem is
+that I can't find any way to set the seed. Every time I enter lisp, the
+generator is in the same state. I have had to resort to cfasling a c
+procedure that calls srand() (as (random) seems to be defined in c by a call
+on rand()). Is there a way to do this within lisp? The other problem is
+more serious. The generator seems to generate tight cycles for (at least)
+arguments that are small powers of 2. For example, repeatedly executing
+(random 2) yields the sequence 01010101..., and (random 4) yields
+01230123.... These sequences apparently occur no matter to what value I set
+the seed. Does anyone one know what I could be doing wrong, or have a
+working random number generator?
+
+
+From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982
+Status: O
+
+From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982
+Date: 28 Nov 82 22:40:14 EST (Sun)
+From: Tim Maroney <tim.unc@UDel-Relay>
+Subject: rng
+To: franz-friends at Ucb-C70
+Via: UNC; 28 Nov 82 23:38-EST
+Status: O
+
+To the person who asked about random number generators and deficiencies
+in (random) [I can't write mail to you for some reason]:
+
+You're not doing anything wrong; that's the way the sucker works.
+One good way to get random numbers is to do the syscall that gets
+you the number of seconds since whenever-it-is, and use the mod
+function. This is especially good for getting a random one or zero,
+by using the evenp function.
+
+ Tim Maroney
+ tim@unc@udel-relay
+
+
+From jkf Tue Nov 30 09:21:10 1982
+Date: 30-Nov-82 09:21:10-PST (Tue)
+From: jkf (John Foderaro)
+Subject: opus 38.42
+Message-Id: <8210301721.11699@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
+ id AA11699; 30-Nov-82 09:21:10-PST (Tue)
+To: local-lisp
+Status: O
+
+ added: (sys:link 'oldname 'newname) that what the ln program does.
+
+ changed: the order of arguments to the vset functions is now:
+ (vset 'vector 'index 'value).
+
+ [This shouldn't affect anyone since vectors haven't been officially
+ released yet and won't be until I make one more major modification]
+
+ setf now knows about vectors. You can say
+ (setf (vref 'vector 'index) 'value)
+ and not have to worry about the order of arguments to vset.
+
+
+
+From jkf Tue Nov 30 10:42:00 1982
+Date: 30-Nov-82 10:42:00-PST (Tue)
+From: jkf (John Foderaro)
+Subject: Re: opus 38.42
+Message-Id: <8210301842.13143@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
+ id AA13143; 30-Nov-82 10:42:00-PST (Tue)
+To: jeffc, local-lisp
+In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday)
+Status: O
+
+ It can't do symbolic links (I've only been adding system calls that I had
+a use for).
+
+ setf is a generalized setq. The target can be an expression which locates
+a value. setf figures out how to store in the target.
+for example:
+
+ (setf x 3) == (setq x 3)
+ (setf (car x) 3) == (rplaca x 3)
+ (setf (get foo 'bar) 3) == (putprop foo 3 'bar)
+
+the target must be something it has been 'taught' to understand, or it can
+be a macro, in which case setf macro-expands it and takes another look.
+
+The setf macro (and a list of targets it knows about is in
+/usr/lib/lisp/common2.l)
+
+
+
+
+From jkf@UCBKIM Wed Dec 1 09:13:23 1982
+Date: 1-Dec-82 09:13:03-PST (Wed)
+From: jkf@UCBKIM (John Foderaro)
+Subject: Random Numbers in Franz
+Message-Id: <8211011713.3615@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
+ id AA03615; 1-Dec-82 09:13:03-PST (Wed)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82])
+ id A18406; 1-Dec-82 09:13:23-PST (Wed)
+To: franz-friends@berkeley
+Status: RO
+
+Date: 29-Nov-82 15:56:09-PST (Mon)
+From: alice!sola!mitch
+Subject: Random Numbers in Franz
+To: alice!ucbvax!franz-friends
+
+In general, it is very bad practice to compute a random number between 0
+and n by any expression such as (mod (random) n). In fact, Franz's
+random function does exactly that, returning the number generated by the
+C function rand(3) modulo n. This technique uses only the rightmost
+bits of successive calls to rand, and the righmost n bits of congruential
+sequences (like that returned by rand(3)) have a period of AT MOST 2**n
+(See Knuth vol.2 p. 12). So using the rightmost two bits will indeed give
+you sequences of at most period 4. (If your lisp doesn't have this
+behavior, you're not using the standard rand.)
+
+A better way to do it is to use the high order bits, by dividing the entire
+range up into n pieces and then seeing where you fall. (This method is
+biased if n is of the same order as the range, though.)
+
+The code I use is:
+
+
+(or (getd '$old-random) (putd '$old-random (getd 'random)))
+
+(defun random n
+ (cond ((eq n 0) ($old-random))
+ ((fix (quotient (boole 1 ($old-random) #o 7777777777)
+ (quotient #o 7777777777 (arg 1)))))))
+
+ Mitch Marcus
+
+
+
+
+
+From jkf Thu Dec 2 08:04:37 1982
+Date: 2-Dec-82 08:04:37-PST (Thu)
+From: jkf (John Foderaro)
+Subject: Franz Lisp distribution
+Message-Id: <8211021604.14414@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
+ id AA14414; 2-Dec-82 08:04:37-PST (Thu)
+To: franz-friends, net-lang-lisp@k
+Status: O
+
+
+ Franz Lisp Distribution
+
+ This note describes our distribution policy for Franz Lisp.
+
+What is being distributed:
+ We distribute only source code in order to keep the distribution
+ small and relatively Unix independent. Makefiles are provided to
+ build the entire lisp system from source, even if you don't have
+ a version of lisp running already. This process takes about 3 cpu
+ hours on a Vax 780. [This version for the Vax only, a 68000 version
+ is being worked on. Contact ucbkim.sklower@berkeley or
+ ucbkim.layer@berkeley]
+
+ The following source is provided:
+ lisp interpreter,
+ compiler (liszt),
+ cross reference program (lxref),
+ lisp manual,
+ and other utility programs:
+ trace, step, debug, cmu library functions, (and other minor ones),
+ and these packages from the MIT lisp library:
+ defstruct, loop, flavors.
+ [These programs are provided as a convenience to those who can't
+ access the arpanet and copy them. There is no documentation for
+ them in the Franz Lisp manual. The best source of documentation
+ is the Lisp Machine manual (available from MIT, Symbolics
+ or LMI)]
+
+ Regarding Flavors: there are two implementations of flavors for
+ Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
+ and one from the University of Maryland (contact person
+ Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
+ exactly like flavors on the Lisp Machine (due to differences between
+ Lisp Machine lisp and Franz Lisp), and the implementations differ
+ from each other. We incorporated the Mit version into the
+ standard distribution because the high bandwidth between here and
+ MIT will insure that it keeps up to date with the current Franz.
+ This is not to imply that it is the better implementation.
+ We haven't had enough experience with flavors to judge.
+ Those seriously interested in Flavors should contact Liz
+ Allen and ask for the Tech Report on the Univ Of Maryland Flavors
+ system.
+
+What is the form of the distribution:
+ The files are packaged in a giant (2.1Mbyte) shell script. Running this
+shell script through 'sh' will result in a directory tree. A ReadMe file
+in the current directory will contain instructions on building the lisp
+system. The shell script is broken into a number of smaller files.
+The current distribution looks like:
+% ls
+total 2092
+ 195 opus38.40.aa 195 opus38.40.ae 195 opus38.40.ai
+ 195 opus38.40.ab 195 opus38.40.af 195 opus38.40.aj
+ 195 opus38.40.ac 195 opus38.40.ag 142 opus38.40.ak
+ 195 opus38.40.ad 195 opus38.40.ah
+
+The '38.40' means Opus 38, minor version 40. These numbers may be different
+by the time you get your distribution. In order to extract the lisp
+files from this shell script, you need only type:
+ cat * | sh
+
+
+To get a copy of the distribution:
+ The distribution may be obtained either using FTP from an arpanet site,
+or on a magnetic tape through the U.S Mail.
+
+ Arpanet:
+ The files are stored on the ucb-c70 (NCP) arpanet host in the
+ directory /users/lisp/lispuser. If you have an account on the ucb-c70,
+ you are free to take FTP a copy of these files.
+ If you do not have an account on the ucb-c70, send me (jkf@berkeley) a
+ message and I will set up a temporary account for you.
+ If you are on a TCP host, write me and we will set up an account on one
+ of our Vax's for you to FTP the files. Eventually we will have an
+ anonymous login on a TCP machine.
+
+ Mag Tape:
+ In order to get a copy of the distribution mailed to you, send a check to
+ cover our tape copying and mailing costs (fees are listed below). We will
+ purchase the mag tape and you are free to keep it. Please do NOT
+ send us a tape.
+
+ Fees:
+ $50 - distribution tape mailed 3rd class
+ add $10 - a copy of the Lisp Manual (we will only
+ send one copy, you are free to photocopy it)
+ add $7 - send tape via 1st class mail.
+
+ -or-
+ $15 - for just a copy of the Lisp Manual
+
+ The address to send checks to is
+
+ Keith Sklower
+ EECS/Computer Science Division
+ 524 Evans Hall
+ University of California
+ Berkeley, CA 94720
+
+ All checks should be made out to "Regents, University of California."
+ We require pre-payment. We will not invoice or process purchase orders.
+
+
+
+Disclaimers:
+ This distribution works on the latest versions of Unix running at
+ Berkeley (4.1a). We can't guarantee that it will work on older
+ versions (although, if you are running 4.1, it is almost certain
+ that it will work, but we have not verified it).
+ VMS users who are using a typical Unix compatibility package will
+ probably not be able to build a lisp from this distribution unless they
+ know a great deal about VMS and their compatibility package.
+ At least one package (Eunice) supports Franz at this time.
+
+Redistribution:
+ If you get a copy of the distribution, you are free to give it to
+ other people. We appreciate being informed of new sites so they
+ can be put on a mailing list (electronic and conventional). This
+ list is used to announce new releases. To be put on this list,
+ send U.S. Mail to Keith Sklower (address above) or to
+ franz-friends-request@berkeley or ucbvax!franz-friends-request
+
+
+
+From jkf Mon Dec 6 08:50:45 1982
+Date: 6-Dec-82 08:50:45-PST (Mon)
+From: jkf (John Foderaro)
+Subject: opus 38.43
+Message-Id: <8211061650.12951@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA12951; 6-Dec-82 08:50:45-PST (Mon)
+To: local-lisp
+Status: O
+
+ The size of vectors is now recorded in bytes rather than longwords.
+ We've imported a few more commands to deal with fclosures.
+ (symeval-in-fclosure 'fclosure 'symbol)
+ (set-in-fclosure 'fclosure 'symbol 'value)
+
+ (let-fclosed vars function)
+
+
+
+
+From jkf Mon Dec 13 10:35:43 1982
+Date: 13-Dec-82 10:35:43-PST (Mon)
+From: jkf (John Foderaro)
+Subject: enhancemants to trace
+Message-Id: <8211131835.12160@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA12160; 13-Dec-82 10:35:43-PST (Mon)
+To: local-lisp
+Status: O
+
+ The function 'retrace' will insure that all functions which should be
+traced are indeed traced. This will solve the problem of reloading
+a file whose functions are traced. After you load a file, you can
+type (retrace) and those functions which became untraced during the loading
+process, will be traced again.
+
+ The top-level-print and top-level-read variables will now take effect
+within a trace break.
+
+
+
+
+
+From jkf Tue Dec 14 12:40:41 1982
+Date: 14-Dec-82 12:40:41-PST (Tue)
+From: jkf (John Foderaro)
+Subject: Re: #!, exec and lisp
+Message-Id: <8211142040.10379@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA10379; 14-Dec-82 12:40:41-PST (Tue)
+To: lime!burdvax!puder
+Cc: franz-friends
+In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon)
+Status: O
+
+ It is easy to make #! do a zapline. If you have a recent version of
+lisp, just execute:
+
+(defsharp ! (x) (zapline))
+
+(this could be put in your .lisprc, if you don't want to affect other
+people). The problem with adding this to Franz by default is that the
+sharpsign macro is shared by a number of lisps and few of them run under
+Unix. Therefore, few other lisps are going to want #! to be zapline.
+
+
+ Regarding the -f switch: The -f switch is used to communicate between the
+bootstrap at the beginning of a fasl file and the lisp interpreter. It
+wasn't meant as a general 'fasl this file' switch for users to make use of.
+The choice of '-f' was bad, it should have been something more unique like
+'-- autorun' so that a user would be unlikely to type it. We have avoided
+assigning meanings to switches on lisp's command line because we want to give
+each user the opportunity to assign whatever meaning he wants to whatever
+switch he wants. It isn't difficult to write a program to scan the command
+line.
+
+Re:
+ The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be
+ necessary, because the exec syscall supplies the full path name, because
+ the shell has already done the path searching on the command name. The
+ only place that might have to be searched is the current directory.
+
+This isn't true. (argv 0) is the command that you typed, not the full path
+name to the command. Only by prepending all the directories in the
+search list can you find the location of the command.
+
+
+ ---john foderaro
+
+
+
+From jkf Mon Jan 10 15:04:02 1983
+Date: 10-Jan-83 15:04:02-PST (Mon)
+From: jkf (John Foderaro)
+Subject: opus 38.45
+Message-Id: <8300102304.19240@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA19240; 10-Jan-83 15:04:02-PST (Mon)
+To: local-lisp
+Status: O
+
+ showstack will again report correctly for compiled calls if the
+transfer tables are unlinked (status translink nil).
+
+
+
+From jkf Mon Jan 10 19:46:06 1983
+Date: 10-Jan-83 19:46:06-PST (Mon)
+From: jkf (John Foderaro)
+Subject: opus 38.46
+Message-Id: <8300110346.24831@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA24831; 10-Jan-83 19:46:06-PST (Mon)
+To: local-lisp
+Status: O
+
+ This version incorporates some fixes from mit. You shouldn't notice
+any differences but if you do, let me know.
+
+
+
+
+
+From jkf Wed Jan 12 09:03:32 1983
+Date: 12-Jan-83 09:03:32-PST (Wed)
+From: jkf (John Foderaro)
+Subject: opus38.47
+Message-Id: <8300121703.1981@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA01981; 12-Jan-83 09:03:32-PST (Wed)
+To: local-lisp
+Status: O
+
+ The setf macro will now handle all car and cdr forms (i.e. c{ad}+r).
+ Thanks to peter norvig for this.
+
+ There is a new macro called 'defvar'. It is used to declare special
+variables and optionally to give them an initial value. It is used
+at top level in a file (outside of defuns).
+
+forms:
+(defvar foo) ; declares foo to be special
+(defvar bar 3) ; declares bar to be special and when this file is read in
+ ; bar will be given the value 3 if it is unbound.
+An advantage of '(defvar foo)' over '(declare (special foo))' is that if
+a file containing defvars is loaded (or fasl'ed) in during compilation,
+the variables mentioned in the defvar's will be declared special. The only
+way to have that effect with '(declare (special foo))' is to 'include'
+the file.
+
+ There is a new macro, 'environment', which can be used at the beginning of
+a file to specify what sort of environment this file needs in order to be
+compiled or run. For example:
+(environment (compile eval) (files mymacros othermacros)
+ (compile) (syntax maclisp))
+
+says that when compiling or loading into the interpreter, the files
+mymacros and othermacros should be loaded (if they aren't loaded already).
+When compiling, the maclisp syntax should be used.
+The general form of 'environment' is:
+ (environment when1 what1
+ when2 what2
+ ... ...
+ whenN whatN)
+the when's are a subset of (eval compile load), and the symbols have the
+same meaning as they do in 'eval-when'.
+The what's are either
+ (files file1 file2 ... fileN)
+ insure that the named files are loaded. To see if fileX
+ is loaded, it looks for a 'version' property under
+ fileX's property list. Thus to prevent multiple loading,
+ you should put
+ (putprop 'myfile t 'version) at the end of myfile.l
+ (syntax type)
+ type is either maclisp, intlisp, ucilisp, franzlisp
+ This sets the syntax correctly.
+
+There are additional macros to set of standard environments:
+(environment-maclisp) sets up the maclisp environment. This is what
+ you would get by using the -m switch to liszt.
+
+(environment-lmlisp) sets up the lisp machine environment. This is like
+ maclisp but it has additional macros.
+
+
+It is possible to add when's and what's to the specialized environments,
+e.g.
+ (environment-maclisp (compile eval) (files foo bar))
+
+
+
+
+
+
+
+From norvig Wed Jan 12 13:12:45 1983
+To: jkf local-lisp
+Subject: defvar
+Status: O
+
+Shouldn't defvar take any number of arguments, like setq? As it is,
+(defvar a 1 b 2) sets a to 1, but ignores the other arguments.
+
+From fateman Wed Jan 12 13:23:08 1983
+To: jkf local-lisp norvig
+Subject: Re: defvar
+Status: O
+
+I suspect the extra arguments to defvar are used in other systems for
+storage of documentation strings in appropriate places. E.g.
+(defvar dozen 12 "initially 12 except in the baker system when it is 13")
+causes some association with defvar and documentation should be put on
+a file.
+
+
+From jkf Wed Jan 12 14:25:02 1983
+Date: 12-Jan-83 14:25:02-PST (Wed)
+From: jkf (John Foderaro)
+Subject: Re: defvar
+Message-Id: <8300122225.13079@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA13079; 12-Jan-83 14:25:02-PST (Wed)
+To: norvig, local-lisp
+In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday)
+Status: O
+
+ fateman is correct that there is an optional third argument for
+documentation. We don't want to add multiple arguments because defvar
+it will mean that code we write here can't be transported to
+other lisp which only expect one defvar argument.
+
+
+
+From jkf Thu Jan 13 09:49:13 1983
+Date: 13-Jan-83 09:49:13-PST (Thu)
+From: jkf (John Foderaro)
+Subject: liszt 8.17
+Message-Id: <8300131749.331@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00331; 13-Jan-83 09:49:13-PST (Thu)
+To: local-lisp
+Status: O
+
+ The vector reference functions are open coded. These are
+ vref, vrefi-byte, vrefi-word, vrefi-long
+
+
+
+From G:alpines Thu Jan 13 20:31:34 1983
+Date: 13 Jan 1983 20:24-PST
+From: alpines@G (Harry Weeks at Vax-Populi)
+Subject: Franz on 68000's
+Message-Id: <83/01/13 2024.733@Vax-Populi>
+Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
+ id AA12970; 13-Jan-83 20:28:37-PST (Thu)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA14908; 13-Jan-83 20:31:34-PST (Thu)
+To: franz@BERKELEY
+Cc: franz-friends@BERKELEY
+Status: O
+
+>Date: 13 Jan 1983 20:01-PST
+From: G.alpines at Berkeley (Harry Weeks at Vax-Populi)
+Subject: Franz on 68000's.
+To: franz-friends-request@Berkeley
+Message-Id: <83/01/13 2001.733@Vax-Populi>
+
+Please put me on your mailing list for information concerning
+implementation of Franz, esp. on 68000's, but I'd like to keep
+informed generally as well. Thanks.
+
+ Harry Weeks
+ Bytek
+ 1730 Solano Avenue
+ Berkeley, CA 94707
+
+ (415) 527-1157
+
+
+From jkf Sun Jan 16 21:22:54 1983
+Date: 16-Jan-83 21:22:54-PST (Sun)
+From: jkf (John Foderaro)
+Subject: change to lisptags program
+Message-Id: <8300170522.23656@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA23656; 16-Jan-83 21:22:54-PST (Sun)
+To: local-lisp
+Status: O
+
+ lisptags will now surround the search string with /'s instead of ?'s
+in order to be compatible with ctags. Both types should work with vi,
+emacs people will probably have to make a minor modification to their
+tags.ml file.
+ My version in ~jkf/elib/tags.ml.
+
+
+
+
+
+
+From jkf Tue Jan 18 16:43:23 1983
+Date: 18-Jan-83 16:43:23-PST (Tue)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.48, liszt 8.19
+Message-Id: <8300190043.10935@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA10935; 18-Jan-83 16:43:23-PST (Tue)
+To: local-lisp
+Status: O
+
+ This is a long message so I'll put the most important thing first, in case
+you choose not to read the rest of the message:
+ *** object files generated by liszt 8.19 will not run in any lisp
+ *** older than 38.48. Object files which were generated by
+ *** liszt's before 8.19 will continue to work in the new lisp.
+
+
+There were two major changes to lisp and liszt:
+ 1) compiled functions will test at runtime to make sure that they
+ are passed the correct number of arguments.
+
+ 2) the lambda list keywords &optional, &rest and &aux are open compiled
+ in an efficient manner.
+
+I'll refresh your memory on what the possible forms are for the & keywords:
+
+ the formal parameter list of a def has this form
+ ( required-args
+ [ &optional optional-arguments ]
+ [ &rest rest-argument ]
+ [ &aux aux-arguments ])
+
+ as in this example which shows all possible forms:
+
+ (def foo
+ (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g)
+ (compute)))
+
+
+ the meaning and forms of the various parts of the formal parameter list are:
+
+ required-args: a sequence of n (zero or more) symbols which will be bound
+ to the first n actual arguments.
+
+ optional-args: a sequence of m (zero or more) symbols which will be
+ bound to the next m actual arguments if they are present, or
+ to default values.
+ the forms of an optional argument are:
+
+ foo - bind foo to the argument if it present, otherwise bind it
+ to nil
+ (foo (expr)) - bind foo to the argument if it is present, otherwise
+ evaluate (expr) and bind foo to the result.
+
+ (foo (expr) foo-p) - bind foo to the argument if it is present,
+ otherwise evaluate (expr) and bind foo to the result.
+ Also, bind foo-p to t if the argument is present, otherwise
+ bind foo-p to nil. foo-p will be treated like an &aux
+ variable (see below) but it should NOT be declared in the
+ &aux list!
+
+ rest-arg : a single symbol which will be bound to a list of the rest of the
+ arguments. This list is cons'ed up each time the function is called.
+
+ aux-args : these args are just like arguments to let or prog within the
+ function body so this & keyword isn't really necessary (but there
+ are few things in lisp that really are necessary).
+
+ the forms of the aux arg are:
+
+ foo - bind foo to nil
+ (foo (expr)) - evaluate (expr) and bind foo to the result.
+
+
+
+The compiler understands the &keywords but the interpreter does not. 'def'
+will convert a form with &keywords to a lexpr which is almost equivalent.
+The differences are:
+ The interpreted form, being a lexpr, is allowed to use the 'arg'
+ function. The compiled form, even with optional args,
+ is not a lexpr and thus 'arg' is illegal.
+
+ The order that &aux variables are lambda bound is slightly different
+ between interpreted and compiled code. As long as default
+ expressions reference no formal parameters after them in the
+ formal parameter list, there should be no problems.
+
+ The interpreted version will not check for the correct number of
+ arguments.
+
+Local functions cannot have &keywords.
+
+If you have any questions on this, send me mail. This change should
+only break functions which expect a variable number of argument and
+which don't declare the fact using &optional programs. There may be,
+of course, implementation errors. If you notice anything unusual
+please let me know right away. The old compiler will be
+in /usr/ucb/oliszt for a while.
+
+
+
+
+
+
+
+
+
+From layer Thu Jan 20 01:55:55 1983
+Date: 20-Jan-83 01:55:55-PST (Thu)
+From: layer (Kevin Layer)
+Subject: liszt 8.20
+Message-Id: <8300200955.17788@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA17788; 20-Jan-83 01:55:55-PST (Thu)
+To: local-lisp
+Phone: (415) 652-2405
+Status: O
+
+ There are now three new command line features for liszt:
+
+ 1. -E <s-expr>, where <s-expr> will be evaluated before compilation
+ starts. For example, the setting of constants can be done in this way:
+
+ liszt -E '(setq foobar "***foobar-string***")' foobar.l
+
+ and in the file being compiled, foobar is accessed as '#.foobar.
+
+ 2. -I <include-file>, where <include-file> will be loaded (via load)
+ before compilation starts.
+
+ 3. A combination of the -S and -o switches will set the .s file, as in:
+
+ liszt -S -o foo.vax.s foo.l
+
+ where previously, the -S determined the name of the .s file (foo.s in
+ the above example).
+
+
+
+From jkf Thu Jan 20 19:42:38 1983
+Date: 20-Jan-83 19:42:38-PST (Thu)
+From: jkf (John Foderaro)
+Subject: some mods to liszt 8.20
+Message-Id: <8300210342.7334@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA07334; 20-Jan-83 19:42:38-PST (Thu)
+To: local-lisp
+Status: O
+
+ the -E and -I flags are now -e and -i
+ there may be more than one -i flag given on the command line.
+
+
+
+From fateman Thu Jan 20 20:20:31 1983
+To: local-lisp
+Subject: fame, if not fortune
+Status: RO
+
+In the latest Scientific American, Feb. 1983, Hofstader's column
+is the first of several on the programming language "lisp". He
+mentions the particular dialect he is using .... Franz !
+
+From wilensky Thu Jan 20 20:57:27 1983
+Date: 20-Jan-83 20:57:27-PST (Thu)
+From: wilensky (Robert Wilensky)
+Subject: Re: fame, if not fortune
+Message-Id: <8300210457.8824@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA08824; 20-Jan-83 20:57:27-PST (Thu)
+To: fateman, local-lisp
+In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday)
+Status: RO
+
+
+On the other hand, being referenced by Hofstader is a dubious honor.
+
+
+From UCBKIM:jkf Fri Jan 21 08:15:04 1983
+Date: 21-Jan-83 08:11:01-PST (Fri)
+From: UCBKIM:jkf (John Foderaro)
+Subject: test message, ignore
+Message-Id: <8300211611.18650@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA18650; 21-Jan-83 08:11:01-PST (Fri)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA24887; 21 Jan 83 08:09:27 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA18766; 21-Jan-83 08:15:04-PST (Fri)
+To: franz-friends@BERKELEY
+Status: O
+
+ This will give our mailer a chance to tell me how many of our franz friends
+are no longer reachable.
+
+
+
+From JTSCHUDY@USC-ISIE Sat Jan 22 16:42:19 1983
+Date: 22 Jan 1983 1634-PST
+From: JTSCHUDY@USC-ISIE
+Subject: MAILINGLIST ADDITION
+Message-Id: <8300230037.1747@UCBVAX.BERKELEY.ARPA>
+Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA01747; 22 Jan 83 16:37:17 PST (Sat)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA18903; 22-Jan-83 16:42:19-PST (Sat)
+To: franz-friends@BERKELEY
+Status: O
+
+Hi! My name is Jim. I am presently attending the Naval Post Graduate
+School in Monterey California. I am in the Air Force enrolled in a
+DOD sponsored graduate degree in Command Control and Communications
+Systems Technology.
+
+i would like to be added to your mailing list. My net address is
+JTSCHUDY at ISIE.
+
+Thanks - Jim.
+-------
+
+
+From jkf Sat Jan 22 17:38:41 1983
+Date: 22-Jan-83 17:38:41-PST (Sat)
+From: jkf (John Foderaro)
+Subject: opus 38.49
+Message-Id: <8300230138.20020@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA20020; 22-Jan-83 17:38:41-PST (Sat)
+To: local-lisp
+Status: O
+
+ A longstanding bug in the determination of the number of free dtpr objects
+has been found and fixed. The effect of this bug was that the function
+which is responsible for allocating more memory pages didn't allocate
+enough dtpr pages because it thought that there were a large number of
+cells free.
+
+
+
+From MCLINDEN@RUTGERS Mon Jan 24 10:33:14 1983
+Date: 24 Jan 1983 1324-EST
+From: Sean McLinden <MCLINDEN@RUTGERS>
+Subject: Franz Lisp and floating point accelerator
+Message-Id: <8300241825.19602@UCBVAX.BERKELEY.ARPA>
+Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA19602; 24 Jan 83 10:25:06 PST (Mon)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA27143; 24-Jan-83 10:33:14-PST (Mon)
+To: franz-friends@UCBVAX
+Status: O
+
+
+ Has anyone determined if a floating point accelerator speeds up
+ Vax Franz Lisp jobs in any significant fashion?
+
+ Pointers would be appreciated.
+
+ Sean McLinden
+ Decision Systems Lab
+-------
+
+From mike@rand-unix Mon Jan 24 18:47:03 1983
+Date: Monday, 24 Jan 1983 15:34-PST
+From: mike@RAND-UNIX
+Subject: emacs interface to franz?
+Message-Id: <8300250008.58@UCBVAX.BERKELEY.ARPA>
+Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00058; 24 Jan 83 16:08:36 PST (Mon)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00921; 24-Jan-83 18:47:03-PST (Mon)
+To: franz-friends@BERKELEY
+Status: O
+
+
+Does anyone have a snazzy interface to emacs for franz?
+
+Thanks,
+ Michael
+
+
+From @udel-relay.ARPA,@UDel-Relay:Tim@UPenn.UPenn Tue Jan 25 16:29:19 1983
+Date: 25 Jan 1983 9:58-EST
+From: Tim Finin <Tim.UPenn@UDel-Relay>
+Subject: emacs interface to franz?
+Message-Id: <8300260022.29320@UCBVAX.BERKELEY.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA29320; 25 Jan 83 16:22:57 PST (Tue)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA01561; 25-Jan-83 16:29:19-PST (Tue)
+Return-Path: <Tim@UPenn.UPenn@UDel-Relay>
+To: mike@Rand-Unix
+Cc: franz-friends@BERKELEY
+Via: UPenn; 25 Jan 83 19:21-EST
+Status: O
+
+
+We have a simple interface from Franz to Emacs, but I much prefer to go the
+other way, i.e. run Franz as a inferior job under Emacs. I believe there
+are several Emacs packages which allow one to run inferior jobs in an Emacs
+window (I have my own which is, unfortunately totally undocumented). Some of
+the benefits of this set up include:
+
+ - one has all of the text editing functions available in Emacs
+ - one has many lisp-based editing functions available in Emacs
+ (thru mock-lisp packages like electriclisp)
+ - one has a history of the session in the editing buffer
+ - one has an environment which supports multiple concurrent
+ processes running in seperate windows.
+ - it is very easy to experiment with new interface features such as
+ symbol completion and re-evaluation of previously issued commands
+
+Tim
+
+
+From CARR@UTAH-20 Fri Jan 28 08:19:08 1983
+Date: 28 Jan 1983 0912-MST
+From: Harold Carr <CARR@UTAH-20>
+Subject: franz distribution
+Message-Id: <8300281615.20646@UCBVAX.BERKELEY.ARPA>
+Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA20646; 28 Jan 83 08:15:18 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA16991; 28-Jan-83 08:19:08-PST (Fri)
+To: franz-friends@UCBVAX
+Status: O
+
+What is the distribution policy?
+
+I work for a company that has opus 36 and is now currently running opus 37.
+Here at the University of Utah we are running opus 38.04. Is it OK to
+make a tape of the University's 38.04 to bring my company more up to
+date? Do I have to make it more formal by signing a transfer agreement
+or by obtaining the release directly from Berkeley?
+
+ Thanks in advance,
+ Harold Carr
+ CARR@UTAH-20
+-------
+
+From UCBKIM:jkf Fri Jan 28 15:09:32 1983
+Date: 28-Jan-83 08:34:33-PST (Fri)
+From: UCBKIM:jkf
+Subject: Re: franz distribution
+Message-Id: <8300281634.17319@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA17319; 28-Jan-83 08:34:33-PST (Fri)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA02275; 28 Jan 83 14:58:37 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00402; 28-Jan-83 15:09:32-PST (Fri)
+To: CARR@UTAH-20
+Cc: franz-friends@UCBVAX
+In-Reply-To: Your message of 28 Jan 1983 0912-MST
+Status: O
+
+ Here is our current distribution policy. This differs a bit from
+the one sent out a month ago [in particular, we now have anonymous ftp]
+
+ -[Fri Jan 28 08:31:45 1983 by jkf]-
+ Franz Lisp Distribution
+
+ This note describes our distribution policy for Franz Lisp.
+
+What is being distributed:
+ We distribute only source code in order to keep the distribution
+ small and relatively Unix independent. Makefiles are provided to
+ build the entire lisp system from source, even if you don't have
+ a version of lisp running already. This process takes about 3 cpu
+ hours on a Vax 780. [This version for the Vax only, a 68000 version
+ is being worked on. Contact ucbkim.sklower@berkeley or
+ ucbkim.layer@berkeley]
+
+ The following source is provided:
+ lisp interpreter,
+ compiler (liszt),
+ cross reference program (lxref),
+ lisp manual,
+ and other utility programs:
+ trace, step, debug, cmu library functions, (and other minor ones),
+ and these packages from the MIT lisp library:
+ defstruct, loop.
+ [These programs are provided as a convenience to those who can't
+ access the arpanet and copy them. There is no documentation for
+ them in the Franz Lisp manual. The best source of documentation
+ is the Lisp Machine manual (available from MIT, Symbolics
+ or LMI)]
+
+ Regarding Flavors: there are two implementations of flavors for
+ Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
+ and one from the University of Maryland (contact person
+ Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
+ exactly like flavors on the Lisp Machine (due to differences between
+ Lisp Machine lisp and Franz Lisp), and the implementations differ
+ from each other. The MIT version cannot be distributed by
+ us (yet) due to licensing problems. If you have a Lisp Machine
+ Source license from Symbolics, you should be able to get a copy
+ from MIT.
+ For a Tech Report on Maryland flavors, write to Liz Allen.
+
+What is the form of the distribution:
+ The files are packaged in a giant (2.1Mbyte) shell script. Running this
+shell script through 'sh' will result in a directory tree. A ReadMe file
+in the current directory will contain instructions on building the lisp
+system. The shell script is broken into a number of smaller files.
+The current distribution looks like:
+
+total 2089
+ 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
+ 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
+ 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
+ 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
+ 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
+
+The '38.50' means Opus 38, minor version 50. These numbers may be different
+by the time you get your distribution. In order to extract the lisp
+files from this shell script, you need only type:
+ cat * | sh
+
+
+To get a copy of the distribution:
+ The distribution may be obtained either using FTP from an arpanet site,
+or on a magnetic tape through the U.S Mail.
+
+ Arpanet:
+ The files are stored on the arpanet host 'ucb-vax' [ if you have an out
+ of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
+ internet number is 10.2.0.78].
+ You can login as 'anonymous'. Use your name as the password.
+ The files are in the subdirectory pub/lisp.
+
+ For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
+
+ Mag Tape:
+ In order to get a copy of the distribution mailed to you, send a check to
+ cover our tape copying and mailing costs (fees are listed below). We will
+ purchase the mag tape and you are free to keep it. Please do NOT
+ send us a tape.
+
+ Fees:
+ $50 - distribution tape mailed 3rd class
+ add $10 - a copy of the Lisp Manual (we will only
+ send one copy, you are free to photocopy it)
+ add $7 - send tape via 1st class mail.
+
+ -or-
+ $15 - for just a copy of the Lisp Manual
+
+ The address to send checks to is
+
+ Keith Sklower
+ EECS/Computer Science Division
+ 524 Evans Hall
+ University of California
+ Berkeley, CA 94720
+
+ All checks should be made out to "Regents, University of California."
+ We require pre-payment. We will not invoice or process purchase orders.
+
+
+
+Disclaimers:
+ This distribution works on the latest versions of Unix running at
+ Berkeley (4.1a). We can't guarantee that it will work on older
+ versions (although, if you are running 4.1, it is almost certain
+ that it will work, but we have not verified it).
+ VMS users who are using a typical Unix compatibility package will
+ probably not be able to build a lisp from this distribution unless they
+ know a great deal about VMS and their compatibility package.
+ At least one package (Eunice) supports Franz at this time.
+
+Redistribution:
+ If you get a copy of the distribution, you are free to give it to
+ other people. We appreciate being informed of new sites so they
+ can be put on a mailing list (electronic and conventional). This
+ list is used to announce new releases. To be put on this list,
+ send U.S. Mail to Keith Sklower (address above) or to
+ franz-friends-request@berkeley or ucbvax!franz-friends-request
+
+
+
+From Kim:fateman Sun Jan 30 02:12:28 1983
+Date: 28 Jan 83 08:32:08 PST (Fri)
+From: Kim:fateman (Richard Fateman)
+Subject: Re: franz distribution
+Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
+Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA21039; 28 Jan 83 08:31:58 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA10132; 30-Jan-83 02:12:28-PST (Sun)
+To: CARR@UTAH-20
+Cc: franz-friends@ucbvax
+Status: O
+
+Our policy is that you may move copies of Franz elsewhere
+without notifying us. We continue to be interested in sharing anything
+you or your company wish to provide us, in suggestions, programs, etc.
+
+
+From UCBCAD:pettengi Sun Jan 30 02:33:52 1983
+Date: 28-Jan-83 10:54:51-PST (Fri)
+From: UCBCAD:pettengi (Rob Pettengill)
+Subject: emacs interface to franz?
+Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
+Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA26156; 28-Jan-83 10:54:51-PST (Fri)
+Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00374; 28 Jan 83 12:53:44 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA10578; 30-Jan-83 02:33:52-PST (Sun)
+To: mike@rand-unix, franz-friends@ucbvax
+Cc: pettengi@UCBCAD
+Status: O
+
+ While I was at TI I used a very nice interface that let one start up
+a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
+under our VMS. Try Kashtan@SRI-AI.
+
+Rob Pettengill
+E-Systems, Dallas, Tx.
+
+From UCBKIM:jkf Sun Jan 30 02:44:27 1983
+Date: 28-Jan-83 08:34:33-PST (Fri)
+From: UCBKIM:jkf (John Foderaro)
+Subject: Re: franz distribution
+Message-Id: <8300281634.17319@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA17319; 28-Jan-83 08:34:33-PST (Fri)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA02275; 28 Jan 83 14:58:37 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA10772; 30-Jan-83 02:44:27-PST (Sun)
+To: CARR@UTAH-20
+Cc: franz-friends@UCBVAX
+In-Reply-To: Your message of 28 Jan 1983 0912-MST
+Status: RO
+
+ Here is our current distribution policy. This differs a bit from
+the one sent out a month ago [in particular, we now have anonymous ftp]
+
+ -[Fri Jan 28 08:31:45 1983 by jkf]-
+ Franz Lisp Distribution
+
+ This note describes our distribution policy for Franz Lisp.
+
+What is being distributed:
+ We distribute only source code in order to keep the distribution
+ small and relatively Unix independent. Makefiles are provided to
+ build the entire lisp system from source, even if you don't have
+ a version of lisp running already. This process takes about 3 cpu
+ hours on a Vax 780. [This version for the Vax only, a 68000 version
+ is being worked on. Contact ucbkim.sklower@berkeley or
+ ucbkim.layer@berkeley]
+
+ The following source is provided:
+ lisp interpreter,
+ compiler (liszt),
+ cross reference program (lxref),
+ lisp manual,
+ and other utility programs:
+ trace, step, debug, cmu library functions, (and other minor ones),
+ and these packages from the MIT lisp library:
+ defstruct, loop.
+ [These programs are provided as a convenience to those who can't
+ access the arpanet and copy them. There is no documentation for
+ them in the Franz Lisp manual. The best source of documentation
+ is the Lisp Machine manual (available from MIT, Symbolics
+ or LMI)]
+
+ Regarding Flavors: there are two implementations of flavors for
+ Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
+ and one from the University of Maryland (contact person
+ Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
+ exactly like flavors on the Lisp Machine (due to differences between
+ Lisp Machine lisp and Franz Lisp), and the implementations differ
+ from each other. The MIT version cannot be distributed by
+ us (yet) due to licensing problems. If you have a Lisp Machine
+ Source license from Symbolics, you should be able to get a copy
+ from MIT.
+ For a Tech Report on Maryland flavors, write to Liz Allen.
+
+What is the form of the distribution:
+ The files are packaged in a giant (2.1Mbyte) shell script. Running this
+shell script through 'sh' will result in a directory tree. A ReadMe file
+in the current directory will contain instructions on building the lisp
+system. The shell script is broken into a number of smaller files.
+The current distribution looks like:
+
+total 2089
+ 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
+ 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
+ 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
+ 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
+ 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
+
+The '38.50' means Opus 38, minor version 50. These numbers may be different
+by the time you get your distribution. In order to extract the lisp
+files from this shell script, you need only type:
+ cat * | sh
+
+
+To get a copy of the distribution:
+ The distribution may be obtained either using FTP from an arpanet site,
+or on a magnetic tape through the U.S Mail.
+
+ Arpanet:
+ The files are stored on the arpanet host 'ucb-vax' [ if you have an out
+ of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
+ internet number is 10.2.0.78].
+ You can login as 'anonymous'. Use your name as the password.
+ The files are in the subdirectory pub/lisp.
+
+ For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
+
+ Mag Tape:
+ In order to get a copy of the distribution mailed to you, send a check to
+ cover our tape copying and mailing costs (fees are listed below). We will
+ purchase the mag tape and you are free to keep it. Please do NOT
+ send us a tape.
+
+ Fees:
+ $50 - distribution tape mailed 3rd class
+ add $10 - a copy of the Lisp Manual (we will only
+ send one copy, you are free to photocopy it)
+ add $7 - send tape via 1st class mail.
+
+ -or-
+ $15 - for just a copy of the Lisp Manual
+
+ The address to send checks to is
+
+ Keith Sklower
+ EECS/Computer Science Division
+ 524 Evans Hall
+ University of California
+ Berkeley, CA 94720
+
+ All checks should be made out to "Regents, University of California."
+ We require pre-payment. We will not invoice or process purchase orders.
+
+
+
+Disclaimers:
+ This distribution works on the latest versions of Unix running at
+ Berkeley (4.1a). We can't guarantee that it will work on older
+ versions (although, if you are running 4.1, it is almost certain
+ that it will work, but we have not verified it).
+ VMS users who are using a typical Unix compatibility package will
+ probably not be able to build a lisp from this distribution unless they
+ know a great deal about VMS and their compatibility package.
+ At least one package (Eunice) supports Franz at this time.
+
+Redistribution:
+ If you get a copy of the distribution, you are free to give it to
+ other people. We appreciate being informed of new sites so they
+ can be put on a mailing list (electronic and conventional). This
+ list is used to announce new releases. To be put on this list,
+ send U.S. Mail to Keith Sklower (address above) or to
+ franz-friends-request@berkeley or ucbvax!franz-friends-request
+
+
+
+From Kim:fateman Mon Jan 31 19:30:20 1983
+Date: 28 Jan 83 08:32:08 PST (Fri)
+From: Kim:fateman (Richard Fateman)
+Subject: Re: franz distribution
+Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
+Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA21039; 28 Jan 83 08:31:58 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA03502; 31-Jan-83 19:30:20-PST (Mon)
+To: CARR@UTAH-20
+Cc: franz-friends@ucbvax
+Status: O
+
+Our policy is that you may move copies of Franz elsewhere
+without notifying us. We continue to be interested in sharing anything
+you or your company wish to provide us, in suggestions, programs, etc.
+
+
+From UCBCAD:pettengi Mon Jan 31 19:55:02 1983
+Date: 28-Jan-83 10:54:51-PST (Fri)
+From: UCBCAD:pettengi (Rob Pettengill)
+Subject: emacs interface to franz?
+Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
+Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA26156; 28-Jan-83 10:54:51-PST (Fri)
+Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00374; 28 Jan 83 12:53:44 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA03987; 31-Jan-83 19:55:02-PST (Mon)
+To: mike@rand-unix, franz-friends@ucbvax
+Cc: pettengi@UCBCAD
+Status: O
+
+ While I was at TI I used a very nice interface that let one start up
+a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
+under our VMS. Try Kashtan@SRI-AI.
+
+Rob Pettengill
+E-Systems, Dallas, Tx.
+
+From Kim:fateman Mon Jan 31 21:34:44 1983
+Date: 28 Jan 83 08:32:08 PST (Fri)
+From: Kim:fateman (Richard Fateman)
+Subject: Re: franz distribution
+Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
+Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA21039; 28 Jan 83 08:31:58 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00642; 31-Jan-83 21:34:44-PST (Mon)
+To: CARR@UTAH-20
+Cc: franz-friends@ucbvax
+Status: RO
+
+Our policy is that you may move copies of Franz elsewhere
+without notifying us. We continue to be interested in sharing anything
+you or your company wish to provide us, in suggestions, programs, etc.
+
+
+From UCBCAD:pettengi Mon Jan 31 22:12:30 1983
+Date: 28-Jan-83 10:54:51-PST (Fri)
+From: UCBCAD:pettengi (Rob Pettengill)
+Subject: emacs interface to franz?
+Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
+Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA26156; 28-Jan-83 10:54:51-PST (Fri)
+Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00374; 28 Jan 83 12:53:44 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA01266; 31-Jan-83 22:12:30-PST (Mon)
+To: mike@rand-unix, franz-friends@ucbvax
+Cc: pettengi@UCBCAD
+Status: O
+
+ While I was at TI I used a very nice interface that let one start up
+a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
+under our VMS. Try Kashtan@SRI-AI.
+
+Rob Pettengill
+E-Systems, Dallas, Tx.
+
+From UCBKIM:jkf Tue Feb 1 10:35:21 1983
+Date: 1-Feb-83 10:32:24-PST (Tue)
+From: UCBKIM:jkf (John Foderaro)
+Subject: multiple messages
+Message-Id: <8301011832.599@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00599; 1-Feb-83 10:32:24-PST (Tue)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00473; 1 Feb 83 10:32:35 PST (Tue)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA00644; 1-Feb-83 10:35:21-PST (Tue)
+To: franz-friends@ucbvax
+Status: RO
+
+ I'm sorry for the multiple messages. The franz-friends mailing list is
+huge and the machine which does the mailing is crashing often. Our local
+mail wizard informs me that if it crashes while in the middle of sending
+mail it will not have a record of who it sent to before the crash.
+ I hope you don't get too many copies of this message.
+
+
+
+
+
+From mike@rand-unix Wed Feb 2 05:33:01 1983
+Date: Tuesday, 1 Feb 1983 15:06-PST
+From: mike@RAND-UNIX
+Subject: response to "emacs interface to franz?"
+Message-Id: <8301021325.221@UCBVAX.BERKELEY.ARPA>
+Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00221; 2 Feb 83 05:25:50 PST (Wed)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA24463; 2-Feb-83 05:33:01-PST (Wed)
+To: franz-friends@BERKELEY
+Cc: mike@RAND-UNIX
+Status: RO
+
+
+Here are the responses that I received to my question "What's out
+there for emacs?"
+
+
+------- Forwarded Messages
+
+Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983
+Date: Mon 24 Jan 83 22:43:01-PST
+From: Jay Lark <CSD.LARK@SU-SCORE.ARPA>
+Subject: Re: emacs interface to franz?
+To: mike@RAND-UNIX.ARPA
+In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST
+
+I'm sure you've probably received several messages similar to this one,
+but just in case...
+
+There exists the capability in Unix Emacs to run a process in its own
+buffer. Typein can be directed to the process, and output is just sent
+right to the buffer. This is an excellent way of running Lisp, because
+you get all of the nice Emacs features (paren balancing, local sexpr
+editing) at essentially no cost. I have been largely unsuccessful with
+trying to run Emacs under Lisp.
+
+The process package is part of the standard Unix Emacs distribution.
+
+Jay Lark
+-------
+
+
+------- Message 2
+
+Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983
+Date: 25 Jan 1983 7:20-MST
+From: Russ Fish <utah-gr!fish@UTAH-CS> (host 10.0.0.4)
+Subject: Re: emacs interface to franz?
+To: mike@RAND-UNIX
+Cc: utah-gr!galway@UTAH-CS
+In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST
+
+We have been running our PSL (Portable Standard Lisp) in gemacs
+(Gosling's emacs) windows for some time. I suspect it would be a minor
+hack to convert it to Franz, but haven't done it and am not a Franz
+user. I could mail you our .ml code if you wanted to undertake
+converting it to Franz (or just using it for inspiration and hacking
+your own) and distributing it to Franz folks.
+
+It works like this: The lisp process is associated with a gemacs
+buffer/window. In that window you can carry on a normal line-by-line
+conversation, if you wish. <CR> sends the current line, (back to mark,
+which is left after the prompt) into the lisp. We mostly use the PSL
+in Rlisp syntax, which is algol-like, but this part of the code is just
+a wrapping for the new-shell function in process.ml with appropriate
+editting syntax set, so you could do the same with no work for any
+Lisp.
+
+You can send an expression, fn def, etc. from any other lisp-mode
+window with a single keypress. Echoing as input in the dialog window
+is inhibited if a prefix arg is provided, so you don't have to look at
+long exprs or fn defs again, just the lisp response.
+
+Sending multiple line exprs in response to a single prompt depends on
+the fact that PSL numbers the prompts for history, like the c-shell. A
+gemacs mlisp output filter process monitors the output for toploop
+prompts and feeds another line of input if the same prompt number comes
+back, instead of printing the prompt.
+
+The result is pretty classy. You get the full many-window gemacs
+editing environment with tags, etc. for random-access navigation and
+just send chunks of code as you change them. The extreme of usage is
+"menu" like windows which contain debugging code in clusters rather
+than sequences. You select exprs with the cursor and send them in any
+order.
+
+We also provide key fns for the common case of sending single lines to
+the toploop or single-character commands to the break-loop without
+editting them into a buffer.
+
+Best respond directly to me, since I am not on Franz-Friends.
+
+-Russ Fish (Fish@Utah-20, utah-cs!fish)
+
+
+
+------- Message 3
+
+Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983
+Return-Path: <israel.umcp-cs@UDel-Relay>
+Date: 25 Jan 83 15:13:51 EST (Tue)
+From: Bruce Israel <israel.umcp-cs@UDel-Relay>
+Subject: Re: emacs interface to franz?
+To: mike@RAND-UNIX
+In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX
+ <8300250008.58@UCBVAX.BERKELEY.ARPA>
+Via: UMCP-CS; 25 Jan 83 20:45-EST
+
+We have a few franz<->emacs interfaces, but I'm not sure what you mean.
+One is the process.ml package that comes with gosling's emacs (the emacs
+that I assume you are talking about). With this package, you can run
+franz inside a window from within emacs and have the facilities of an
+editor along with lisp. The other thing we have is a local Franz
+package called the load1 package. This package was written for
+compiling flavors (like in the lisp machine; another local package)
+and has a function called vi. (vi 'lisp-function) will call the
+editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the
+file which contains the definition of the lisp function, positioning
+the editor at the point in the file where the function is defined. Upon
+exiting the editor, it asks you if you want to reload the modified file.
+To edit a function from a file this way, the file must have been load1'ed
+previously so that the info on where the function is stored and what type
+it is will have been saved. Load1 will distinguish between different
+types of functions, ie. defflavors, defmethods, defmacros, defuns etc.
+and will search for the correct definition in the file. Is this what
+you mean? If you like I can send you the four or five files necessary.
+- Bruce
+
+
+------- Message 4
+
+Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983
+Date: 27 Jan 1983 09:44-EST
+From: Carl.Ebeling@CMU-CS-VLSI
+Subject: Re: emacs interface to franz?
+To: mike@RAND-UNIX
+Message-Id: <412526661/ce@CMU-CS-VLSI>
+In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14
+
+I have an electric lisp package and process package for emacs. It
+includes 'zap-function-to-lisp' among other things. It is for
+Gosling's emacs and uses the subprocess facility. I can mail them to
+you if you like.
+ Carl
+
+
+------- End of Forwarded Messages
+
+From UCBKIM:jkf Wed Feb 2 08:19:19 1983
+Date: 2-Feb-83 08:14:21-PST (Wed)
+From: UCBKIM:jkf (John Foderaro)
+Subject: multiple messages fixed?
+Message-Id: <8301021614.25937@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA25937; 2-Feb-83 08:14:21-PST (Wed)
+Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00384; 2 Feb 83 08:10:26 PST (Wed)
+Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA00477; 2 Feb 83 08:14:35 PST (Wed)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA26020; 2-Feb-83 08:19:19-PST (Wed)
+To: franz-friends@ucbvax
+Status: RO
+
+ I've broken the franz-friends mailing list over two machines. I hope that
+this will fix the problem of mail to franz-friends crashing ucbvax every
+thirty minutes. If you get multiple copies of this message, please do not
+tell me about it, I will already know.
+
+
+
+
+From jkf Thu Feb 10 21:45:17 1983
+Date: 10-Feb-83 21:45:17-PST (Thu)
+From: jkf (John Foderaro)
+Subject: liszt 8.21
+Message-Id: <8301110545.16021@UCBKIM.BERKELEY.ARPA>
+Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA16021; 10-Feb-83 21:45:17-PST (Thu)
+To: local-lisp
+Status: O
+
+ more functions open coded: vsize, vsize-byte, vsize-word,
+ vectorp, vectorip
+
+
+
+From PSI.KROHNFELDT@UTAH-20 Fri Feb 11 15:09:11 1983
+Date: 11 Feb 1983 1601-MST
+From: Jed Krohnfeldt <PSI.KROHNFELDT@UTAH-20>
+Subject: cfasl
+Message-Id: <8301112302.7475@UCBVAX.BERKELEY.ARPA>
+Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA07475; 11 Feb 83 15:02:05 PST (Fri)
+Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA07565; 11 Feb 83 15:06:37 PST (Fri)
+Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
+ id AA14422; 11-Feb-83 15:09:11-PST (Fri)
+To: Franz-friends@UCBVAX
+Status: O
+
+I am having trouble using cfasl in franz 38.04. I keep getting the
+message "ld: /usr/ucb/lisp : no namelist". Can anyone decipher this
+for me? Thanks...
+-------
+
+From apm@cmu-ri-isl Mon Feb 14 07:31:54 1983
+Date: 14 Feb 1983 10:24:21-EST
+From: Andrew.Mendler@CMU-RI-ISL
+Subject: franz lisp under5 vms 3.0
+Message-Id: <8302141531.27879@UCBVAX.ARPA>
+Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3)
+ id AA27879; 14 Feb 83 07:31:54 PST (Mon)
+Received: by UCBKIM.ARPA (3.310/3.3)
+ id AA01172; 14 Feb 83 15:50:41 PST (Mon)
+To: franz-friends@BERKELEY.ARPA
+Status: O
+
+Does anyone have a copy of Franz Lisp and the compiler that works under
+VMS version 3.0?
+
+From @udel-relay:tim.unc@UDel-Relay Mon Feb 14 02:52:18 1983
+Date: 13 Feb 83 14:34:48 EST (Sun)
+From: Tim Maroney <tim.unc@UDel-Relay>
+Subject: cfasl: no namelist
+Return-Path: <tim.unc@UDel-Relay>
+Message-Id: <8302141052.25792@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3)
+ id AA25792; 14 Feb 83 02:52:18 PST (Mon)
+Received: by UCBKIM.ARPA (3.310/3.3)
+ id AA02234; 14 Feb 83 16:18:42 PST (Mon)
+To: franz-friends@BERKELEY.ARPA
+Via: UNC; 14 Feb 83 5:43-EST
+Status: O
+
+I don't seem to be able to write Jed Krohnfeldt, and this
+answer is probably of general interest anyway. The message
+"ld: no namelist" means that some well-meaning system admin
+has stripped the lisp executable file to save space;
+unfortunately, this makes the dynamic loading used by cfasl
+impossible. Lisp will have to be recompiled (groan). No Franz
+Lisp executable file should EVER be stripped.
+
+Tim Maroney
+tim.unc@udel-relay
+decvax!duke!unc!tim
+
+From Mark.Sherman@CMU-CS-A Sat Feb 12 21:38:46 1983
+Date: 13 February 1983 0034-EST (Sunday)
+From: Mark.Sherman@CMU-CS-A
+Subject: Space and Leakage
+Message-Id: <13Feb83 003422 MS40@CMU-CS-A>
+Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
+ id AA07842; 12 Feb 83 21:38:46 PST (Sat)
+Received: by UCBKIM.ARPA (3.310/3.3)
+ id AA02341; 14 Feb 83 16:21:29 PST (Mon)
+To: franz-friends@UCB-VAX
+Status: O
+
+Can someone tell me how the maximum amount of storage that franz
+lisp uses is decided? I can force the size up to (about) 3050
+pages (according to "ps") and then get the message "storage exhausted".
+I have been told (and have seen) other jobs get substantially more
+space; can franz get more pages as well? (I am using the cshell
+and have already used the limit command to raise my process
+size up to 32 megabytes, or so I think.)
+
+I have also been told that the garbage collector leaks, that is,
+not all of the garbage is really collected. Does anyone have good
+ideas about how much (or fast) this happens, or if there is some way
+to minimize the lost space?
+
+(Please send responses directly to me as I am not on this list.)
+ -Mark Sherman (Sherman@CMU-CS-A)
+
+From @udel-relay:Mac.uvacs.Virginia@UDel-Relay Fri Feb 18 21:04:31 1983
+Date: 18 Feb 83 12:42:40-EST (Fri)
+From: Mac.uvacs@UDel-Relay
+Subject: global nonspecial variables
+Return-Path: <Mac.uvacs.Virginia@UDel-Relay>
+Message-Id: <8302190504.26020@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5)
+ id AA26020; 18 Feb 83 21:04:31 PST (Fri)
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA00656; 21 Feb 83 01:59:26 PST (Mon)
+To: FRANZ-FRIENDS@BERKELEY.ARPA
+Via: Virginia; 18 Feb 83 23:58-EST
+Status: O
+
+Does the Liszt compiler have any notion of global variables --
+free variables with fast access, without any rebinding?
+
+I think the MACLISP compiler has something like this for variables
+beginning "**".
+
+ Alex Colvin
+
+ uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac
+ csnet:mac@virginia
+ arpa: mac.uvacs@udel-relay
+
+From jkf@UCBKIM Mon Feb 21 09:19:56 1983
+Date: 21 Feb 83 09:19:43 PST (Mon)
+From: jkf@UCBKIM (John Foderaro)
+Subject: Re: global nonspecial variables
+Message-Id: <8302211719.2798@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA02798; 21 Feb 83 09:19:43 PST (Mon)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
+ id AA13982; 21 Feb 83 09:11:52 PST (Mon)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA02805; 21 Feb 83 09:19:56 PST (Mon)
+To: Mac.uvacs@UDel-Relay, FRANZ-FRIENDS@BERKELEY.ARPA
+In-Reply-To: Your message of 18 Feb 83 12:42:40-EST (Fri)
+Status: O
+
+ I don't understand the distinction between what you call a global variable
+and a special variable. A special variable in Franz Lisp (and any other
+shallow bound lisp) can be accessed rapidly and is only rebound if you
+put it in a lambda, prog or do variable list.
+
+
+
+From jkf@UCBKIM Fri Feb 25 08:29:01 1983
+Date: 25 Feb 83 08:28:45 PST (Fri)
+From: jkf@UCBKIM (John Foderaro)
+Subject: research position at edinburgh
+Message-Id: <8302251628.528@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA00528; 25 Feb 83 08:28:45 PST (Fri)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
+ id AA00867; 25 Feb 83 08:18:48 PST (Fri)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA00537; 25 Feb 83 08:29:01 PST (Fri)
+To: franz-friends@BERKELEY.ARPA
+Status: O
+
+
+ DEPARTMENT OF ARTIFICIAL INTELLIGENCE
+ UNIVERSITY OF EDINBURGH
+
+ RESEARCH FELLOW
+
+A Research Fellowship is available within the Programming Systems Development
+Group. The post has been created specifically to provide a modern LISP system
+for the Perq computer running under ICL MicroCode UNIX, and is funded by the
+Science and Engineering Research Council.
+
+Experience in implementing systems would be advantageous, as would be a
+knowledge of LISP and C. Access will be available to an SERC DECsystem-10
+running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as
+to Perqs.
+
+The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds
+sterling, according to age and experience. The post is funded for a period of
+two years from the date of appointment.
+
+Further particulars of the post can be obtained from:
+
+ Administrative Assistant
+ Department of Artificial Intelligence
+ University of Edinburgh
+ Forrest Hill
+ Edinburgh EH1 2QL
+ SCOTLAND
+phone
+ 031-667-1011 x2554
+
+or by contacting
+
+ RAE%EDXA%UCL-CS@ISID (Networks permitting)
+
+Applications should be made by March 17th, 1983.
+
+
+
+
+From layer Sat Mar 5 20:12:57 1983
+Date: 5 Mar 83 20:12:57 PST (Sat)
+From: layer (Kevin Layer)
+Subject: process function
+Message-Id: <8303060412.18927@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA18927; 5 Mar 83 20:12:57 PST (Sat)
+Phone: (415) 652-2405
+To: local-lisp
+Status: O
+
+The process function now looks in the environment at the SHELL variable.
+If present, it will use this as the default shell to execute your command.
+If not present, csh and then sh are tried (in that order).
+
+
+From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay Tue Mar 8 06:04:10 1983
+Date: 8 Mar 1983 2:32-EST
+From: Susan Pintzuk <Pintzuk.UPenn@UDel-Relay>
+Subject: lisp statistical packages
+Return-Path: <Pintzuk.UPenn.UPenn@UDel-Relay>
+Message-Id: <8303081401.AA13004@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14)
+ id AA13004; 8 Mar 83 06:01:54 PST (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA08297; 8 Mar 83 06:04:10 PST (Tue)
+To: franz-friends@BERKELEY.ARPA
+Via: UPenn; 8 Mar 83 3:49-EST
+Status: O
+
+do any franz-lisp packages exist which calculate mean, standard deviation,
+%n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.? if so, how
+do i obtain a copy?
+
+From jkf Tue Mar 8 09:10:46 1983
+Date: 8 Mar 83 09:10:46 PST (Tue)
+From: jkf (John Foderaro)
+Subject: opus38.56
+Message-Id: <8303081710.9423@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA09423; 8 Mar 83 09:10:46 PST (Tue)
+To: local-lisp
+Status: O
+
+ If $gcprint is set to a non nil value, then just before a garbage
+collection is begun, the message 'gc:' will be printed on the tty.
+As before, after the garbage collection is finished, the statistics
+message in square brackets will be printed.
+
+
+
+From fateman Wed Mar 9 09:54:31 1983
+Date: 9 Mar 83 09:54:31 PST (Wed)
+From: fateman (Richard Fateman)
+Subject: need a job
+Message-Id: <8303091754.14754@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA14754; 9 Mar 83 09:54:31 PST (Wed)
+To: local-lisp
+Status: O
+
+porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP
+computer? Wanna live in Denver? There is a recruiter in
+town from Denelcor at Marriot Inn, Jim Holly. There is an
+ad posted on 5th floor bulletin board.
+
+From jkf Sat Mar 19 17:44:33 1983
+Date: 19 Mar 83 17:44:33 PST (Sat)
+From: jkf (John Foderaro)
+Subject: liszt 8.24
+Message-Id: <8303200144.25091@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA25091; 19 Mar 83 17:44:33 PST (Sat)
+To: local-lisp
+Status: O
+
+ The vax and 68k versions of liszt have been combined into one set of
+source files. This is mainly a textual change, but some functions
+in the compiler have been modified in reduce the machine dependent code.
+Be on the lookout for strange errors.
+
+
+
+From fateman Tue Mar 22 20:52:11 1983
+Date: 22 Mar 83 20:52:11 PST (Tue)
+From: fateman (Richard Fateman)
+Subject: T Lisp
+Message-Id: <8303230452.5935@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA05935; 22 Mar 83 20:52:11 PST (Tue)
+To: local-lisp
+Status: RO
+
+I have a preliminary manual for the T dialect of Lisp, created
+at Yale. It is being offered for sale by Cognitive Systems, Inc.
+for $1000/CPU (educational price). It offers features from Lisp
+and Scheme. It runs on VAX and Apollo 68000 systems.
+
+From jkf Thu Mar 24 08:29:31 1983
+Date: 24 Mar 83 08:29:31 PST (Thu)
+From: jkf (John Foderaro)
+Subject: liszt 8.25
+Message-Id: <8303241629.6735@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA06735; 24 Mar 83 08:29:31 PST (Thu)
+To: local-lisp
+Status: O
+
+
+ If you do this:
+
+ liszt -x a/b/c.l -o x/y/z.o
+
+ then the cross reference file will be put in x/y/z.x
+ Before this version, it would have gone into a/b/c.x
+
+
+
+From jkf Thu Mar 24 15:00:37 1983
+Date: 24 Mar 83 15:00:37 PST (Thu)
+From: jkf (John Foderaro)
+Subject: liszt 8.26
+Message-Id: <8303242300.11144@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA11144; 24 Mar 83 15:00:37 PST (Thu)
+To: local-lisp
+Status: O
+
+ liszt will now pass the assembler the -V switch. This tells the assembler
+to keep its intermediate file in core rather than putting it in /tmp.
+This should make assembly slightly faster and also permit large lisp files to
+be compiled on systems with small /tmp's.
+
+
+
+From @udel-relay.ARPA:tim.unc@UDel-Relay Sat Mar 26 03:41:05 1983
+Date: 25 Mar 83 15:03:29 EST (Fri)
+From: Tim Maroney <tim.unc@UDel-Relay>
+Subject: open coding of (function (lambda ...))
+Return-Path: <tim.unc@UDel-Relay>
+Message-Id: <8303261137.AB02371@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17)
+ id AB02371; 26 Mar 83 03:37:13 PST (Sat)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA00854; 26 Mar 83 03:41:05 PST (Sat)
+To: franz-friends@BERKELEY.ARPA
+Via: UNC; 25 Mar 83 19:43-EST
+Status: O
+
+This doesn't seem to work. I'm using Liszt version 8.10, University
+of Maryland distribution. The documentation in the file "lispnews"
+is sketchy, but it seems that compiling and loading the file:
+
+(setq appsum (function (lambda (x) (apply 'sum x))))
+
+should leave a bcd object in appsum's value, but it doesn't. It
+leaves the uncompiled lambda. Am I doing something wrong?
+
+Tim Maroney
+decvax!duke!unc!tim
+tim.unc@udel-relay
+
+From jkf@UCBKIM Sat Mar 26 08:46:44 1983
+Date: 26 Mar 83 08:46:28 PST (Sat)
+From: jkf@UCBKIM (John Foderaro)
+Subject: Re: open coding of (function (lambda ...))
+Message-Id: <8303261646.2453@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA02453; 26 Mar 83 08:46:28 PST (Sat)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17)
+ id AA05012; 26 Mar 83 08:42:50 PST (Sat)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA02462; 26 Mar 83 08:46:44 PST (Sat)
+To: tim.unc@UDel-Relay
+Cc: franz-friends@BERKELEY.ARPA
+In-Reply-To: Your message of 25 Mar 83 15:03:29 EST (Fri)
+Status: O
+
+
+ Liszt only compiles functions, not literals it finds in files.
+To make this statement be compiled:
+(setq appsum (function (lambda (x) (apply 'sum x))))
+
+you should surround it with a function defintion:
+(defun junk ()
+ (setq appsum (function (lambda (x) (apply 'sum x)))))
+
+
+
+From CARR@UTAH-20 Mon Apr 4 14:53:09 1983
+Date: 4 Apr 1983 0922-MST
+From: Harold Carr <CARR@UTAH-20>
+Subject: Franz/Common lisp
+Message-Id: <8304041711.AA07020@UCBVAX.ARPA>
+Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20)
+ id AA07020; 4 Apr 83 09:11:40 PST (Mon)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA01683; 4 Apr 83 14:53:09 PST (Mon)
+To: franz-friends@BERKELEY.ARPA
+Cc: KROHNFELDT@UTAH-20
+Status: O
+
+Does anyone have any sort of Common Lisp compatibility package for Franz?
+If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20).
+-------
+
+From jeff@aids-unix Tue Apr 5 12:42:46 1983
+Date: 4 Apr 1983 11:06:49 PST (Monday)
+From: Jeff Dean <jeff@aids-unix>
+Subject: knowledge representation language
+Message-Id: <8304052042.AA26557@UCBVAX.ARPA>
+Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20)
+ id AA26557; 5 Apr 83 12:42:11 PST (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA16443; 5 Apr 83 12:42:46 PST (Tue)
+To: franz-friends@BERKELEY.ARPA
+Status: O
+
+Does anyone have a knowledge representation language (such as FRL or
+KL-ONE) available under Franz Lisp?
+
+ Jeff Dean
+ arpa: jeff@aids-unix
+ uucp: ...ucbvax!jeff@aids-unix
+
+
+From jkf Tue Apr 5 13:08:06 1983
+Date: 5 Apr 83 13:08:06 PST (Tue)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.57
+Message-Id: <8304052108.16969@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA16969; 5 Apr 83 13:08:06 PST (Tue)
+To: local-lisp
+Status: RO
+
+ This version has a number of internal changes to make it compilable
+on 68k. If you notice it acting abnormally, let me know.
+
+
+
+From FAHLMAN@CMU-CS-C Thu Apr 7 07:50:06 1983
+Date: Thu, 7 Apr 1983 10:46 EST
+From: Scott E. Fahlman <Fahlman@CMU-CS-C>
+Subject: Franz/Common lisp
+Message-Id: <8304071549.AA13873@UCBVAX.ARPA>
+Received: ID <FAHLMAN@CMU-CS-C>; 7 Apr 83 10:46:59 EST
+Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20)
+ id AA13873; 7 Apr 83 07:49:42 PST (Thu)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA18082; 7 Apr 83 07:50:06 PST (Thu)
+To: Harold Carr <CARR@UTAH-20>
+Cc: franz-friends@BERKELEY.ARPA
+In-Reply-To: Msg of 4 Apr 1983 11:22-EST from Harold Carr <CARR at UTAH-20>
+Status: RO
+
+
+Harold,
+
+A couple of things make it seem unlikely that anyone would have such a
+package right now. First, we don't even have a final Common Lisp manual
+yet -- Guy's next draft is due very soon, but there will be some tuning
+and hassling after that. Second, there are things in Common Lisp that
+would be very tough to fake on Franz: lexical binding, generic
+sequences, some of the hairy number types, character objects, etc.
+Common Lisp is pretty close to being a superset of Franz, so I would
+expect to see Franz compatibility packages in Common Lisp, but not vice
+versa. Third, if anyone were writing such a package, they would be
+crazy not to have arranged for access to our code that implements all of
+the hairy functions, and nobody has done this to my knowledge.
+
+My standard advice is for people to continue to code in Franz with the
+knowledge that they can easily convert their code to Common Lisp
+whenever the DEC Common Lisp is available to them. This should be a
+one-time conversion, since moving the other way after "going native" in
+Common Lisp would be very tough.
+
+If someone does pop up with a compatibility package -- even a partial
+one -- I would be interested in hearing about it.
+
+-- Scott
+
+From fateman@UCBKIM Sun Apr 10 19:52:14 1983
+Date: 10 Apr 83 19:50:59 PST (Sun)
+From: fateman@UCBKIM (Richard Fateman)
+Subject: Re: Franz/Common lisp
+Message-Id: <8304110350.6176@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA06176; 10 Apr 83 19:50:59 PST (Sun)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
+ id AA10019; 10 Apr 83 19:49:55 PST (Sun)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA06192; 10 Apr 83 19:52:14 PST (Sun)
+To: carr@utah-20, fahlman@cmu-cs-c
+Cc: franz-friends@BERKELEY.ARPA
+Status: RO
+
+I think that a common-lisp-compatibility package written
+in Franz would not be as difficult as all that.
+
+If Common Lisp (TM of DEC?) were available on all the same
+machines at the same price, (appx. $0.) and CL were
+in fact a superset of Franz for all practical purposes, and
+with similar or better efficiency, etc. Why would anyone bother?
+
+Of course if CL does not meet all of the objectives (e.g. price, machines),
+then a CL-to-Franz "translator" might make sense.
+
+With that in mind,
+I would like to officially request a copy of the Common Lisp
+language (as implemented in CL, presumably), as soon as it
+becomes available (i.e. no later than when it is a "product"
+of DEC, and probably at "beta" test time).
+I agree fully with Scott that trying to do this with an incomplete
+language specification is unwise.
+
+I am also not making any commitment to do anything with CL at
+Berkeley, but since we are building tools for our own applications,
+and CL might be useful, we might consider an efficient merge of
+ideas.
+
+From jkf@UCBKIM Mon Apr 11 08:07:39 1983
+Date: 11 Apr 83 06:42:43 PST (Mon)
+From: jkf@UCBKIM (John Foderaro)
+Subject: mail to this mailing list
+Message-Id: <8304111442.11378@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA11378; 11 Apr 83 06:42:43 PST (Mon)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
+ id AA07288; 11 Apr 83 08:05:32 PST (Mon)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
+ id AA11949; 11 Apr 83 08:07:39 PST (Mon)
+To: franz-friends@BERKELEY.ARPA
+Status: RO
+
+ I'm sorry that people who mail to this mailing list must put up with lots
+ of mail errors from our local mailer. The problem is not that we have a
+ lot of illegal addresses, but that over the three day period that the
+ mailer tries to deliver the mail, some of the destination sites never
+ respond. I think that this is due primarily to the fact that many sites
+ are running new mail and networking software. Hopefully this will
+ improve over time.
+ john foderaro
+
+
+
+
+From jkf Fri Apr 22 09:59:09 1983
+Date: 22 Apr 83 09:59:09 PST (Fri)
+From: jkf (John Foderaro)
+Subject: lisp opus 38.59
+Message-Id: <8304221759.20996@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA20996; 22 Apr 83 09:59:09 PST (Fri)
+To: local-lisp
+Status: RO
+
+ Input like 1.2.3 and 1..2 will now be read as single symbols rather
+than two consecutive numbers.
+
+
+
+From jkf Sun May 8 00:02:54 1983
+Date: 8 May 83 00:02:54 PDT (Sun)
+From: jkf (John Foderaro)
+Subject: opus 38.60
+Message-Id: <8305080702.22344@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.310/3.5)
+ id AA22344; 8 May 83 00:02:54 PDT (Sun)
+To: local-lisp
+Cc: rms
+Status: RO
+
+ Thanks to some suggestions from rms we are now one step closer to
+full closures. fclosures will now work if called recursively.
+It is still true that the only way to make fclosures share variables
+is to use fclosure-list.
+
+ symeval-in-fclosure may return the wrong value if the closure is
+'active'. This will be fixed eventually.
+
+
+
+From mbr@nprdc Sat May 21 07:37:23 1983
+Date: 20 May 1983 14:57:55-PDT
+From: mbr@NPRDC
+Subject: lam9.c and curses
+Message-Id: <8305211434.AA16172@UCBVAX.ARPA>
+Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29)
+ id AA16172; 21 May 83 07:34:43 PDT (Sat)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA08856; 21 May 83 07:37:23 PDT (Sat)
+Reply-To: mbr <mbr@NPRDC>
+To: franz-friends@BERKELEY.ARPA
+Cc: mbr@NPRDC
+Status: O
+
+When we attempted to cfasl a file that used the curses package
+of screen control routines into Franz 38.40, we got the message
+_ospeed: /usr/libcurses.a (cr_tty.o) multiply defined.
+The apparent cause of this cryptic remark is that in lam9.c
+there is an extern variable ospeed. There are a number of
+tantalizing routines in this source file dealing with termcaps that
+are apparently not called by anyone. Are there plans for these
+routines? Does anyone use them (heaven forbid they should be
+documented!). Our current fix is to just change ospeed to ospiid
+which so far has had no dire effects, but I am interested in others
+experience. The curses stuff seems to work fine after this
+modification.
+ Mark Rosenstein
+
+
+From jkf Wed May 25 12:15:54 1983
+Date: 25 May 83 12:15:54 PDT (Wed)
+From: jkf (John Foderaro)
+Subject: opus 38.61
+Message-Id: <8305251915.1144@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA01144; 25 May 83 12:15:54 PDT (Wed)
+To: local-lisp
+Status: O
+
+ symeval-in-fclosure and set-in-fclosure now work (thanks to keith).
+
+ selectq is now a part of standard franz. selectq is just like
+ caseq except it allows 'otherwise' as well as 't' for the
+ key which means 'if nothing else matches, use this clause'.
+
+
+
+
+From cornwell@nrl-css Wed May 25 12:51:17 1983
+Date: Wed, 25 May 83 15:14:19 EDT
+From: Mark Cornwell <cornwell@NRL-CSS>
+Subject: Franz on the Sun
+Message-Id: <8305251950.AA02600@UCBVAX.ARPA>
+Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29)
+ id AA02600; 25 May 83 12:50:26 PDT (Wed)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA01878; 25 May 83 12:51:17 PDT (Wed)
+To: franz-friends@BERKELEY.ARPA
+Cc: cornwell@NRL-CSS
+Status: O
+
+
+ Our group at NRL is planning to purchase Sun workstations. I
+currently have a substantial amount of code written in Franz Lisp that
+I want to run on the Sun.
+
+ What is the status of the Berkeley group porting Franz to the Sun?
+How do I get a copy?
+
+ Also, I have a few concerns about configuring a Sun to run Franz well.
+The basic desktop Sun workstation provides 1 Mbyte of physical memory.
+This can be extended to 2 Mbyte or one can add an Ethernet interface
+*but not both*. Since I am unwilling to give up my Ethernet
+interface I may be forced to run Franz in 1 Mbyte and contend with
+the added paging overhead (using a 68010 running 4.2bsd and a local disk).
+
+ Has anyone out there had experience running Franz Lisp on a Sun in
+such a configuration? Can I get away without the 2 Mbyte extension?
+I think your answers would be of general interest.
+
+-- Mark (caught between a rock and a hard place?) Cornwell
+
+
+
+From baden@UCBKIM Wed May 25 13:51:39 1983
+Date: 25 May 83 13:32:01 PDT (Wed)
+From: baden@UCBKIM (Scott B. Baden)
+Subject: Re: Franz on the Sun
+Message-Id: <8305252032.2716@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA02716; 25 May 83 13:32:01 PDT (Wed)
+Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29)
+ id AA03753; 25 May 83 13:50:52 PDT (Wed)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA03002; 25 May 83 13:51:39 PDT (Wed)
+To: franz-friends@BERKELEY.ARPA
+Cc: cornwell@NRL-CSS
+Status: O
+
+Which sun are you using? My office mate says that
+he has seen a sun configured with 2MB of memory AND
+an Ethernet board.
+
+From mike%Rice.Rice@Rand-Relay Fri May 27 19:51:33 1983
+Date: Fri, 27 May 83 18:18:47 CDT
+From: Mike.Caplinger <mike.rice@Rand-Relay>
+Subject: Re: Franz on the Sun
+Return-Path: <mike%Rice.Rice@Rand-Relay>
+Message-Id: <1983.05.27.18.18.47.150.08942@dione.rice>
+Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29)
+ id AA19088; 27 May 83 19:50:15 PDT (Fri)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA02221; 27 May 83 19:51:33 PDT (Fri)
+To: franz-friends@BERKELEY.ARPA
+In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed)
+Via: Rice; 27 May 83 19:14-PDT
+Status: RO
+
+As I type I'm bringing up the 68K version of Opus 38 (now FTPable from
+UCB-VAX) on a SUN running 4.1c. There don't seem to be any major
+problems so far, but the compiler doesn't run on a system with all the
+net servers on it because it runs out of memory. I've been told this
+is because there's a bug in 4.1c that forces it to only use 1/2 of the
+swap partition. I'm having to run standalone to compile the compiler;
+I don't yet know whether I'll be able to compile other stuff without
+this rather extreme fix.
+
+As I use the system more I will post more info to this group.
+
+From narain@rand-unix Tue May 31 10:49:00 1983
+Date: Tuesday, 31 May 1983 10:45-PDT
+From: narain@rand-unix
+Subject: Interrupt question
+Message-Id: <8305311747.AA10893@UCBVAX.ARPA>
+Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29)
+ id AA10893; 31 May 83 10:47:26 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA13428; 31 May 83 10:49:00 PDT (Tue)
+To: franz-friends@BERKELEY.ARPA
+Cc: narain@rand-unix
+Status: O
+
+
+Hi, I would be grateful if you could tell me what is the equivalent of
+Interlisp's control-h (followed by OK) in Franzlisp. In other words, I
+wish to interrupt a Franzlisp program, from time to time, examine its state
+and allow it to continue from the interrupted point.
+
+-- Sanjai
+
+From lbl-csam!steve@ssc-vax.UUCP Tue May 31 19:31:04 1983
+Date: 31 May 83 17:28:35 PDT (Tue)
+From: ssc-vax!steve@lbl-csam.UUCP
+Subject: packages
+Message-Id: <8306010028.AA16451@LBL-CSAM.ARPA>
+Received: by LBL-CSAM.ARPA (3.320/3.21)
+ id AA16451; 31 May 83 17:28:35 PDT (Tue)
+Received: by UCBVAX.ARPA (3.341/3.31)
+ id AA02877; 31 May 83 19:30:00 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA22745; 31 May 83 19:31:04 PDT (Tue)
+To: ucbvax!franz-friends@lbl-csam.UUCP
+Status: O
+
+
+Does a version of LispMachine ``packages'' or some similar oblist partitioning
+scheme exist for franz? Having just integrated several independently coded
+modules, I think something like that would be very useful.
+ -thanks
+ Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve
+
+
+From fateman Tue Jun 14 11:48:32 1983
+Date: 14 Jun 83 11:48:32 PDT (Tue)
+From: fateman (Richard Fateman)
+Subject: "macsyma on a chip?"
+Message-Id: <8306141848.6756@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA06756; 14 Jun 83 11:48:32 PDT (Tue)
+To: macsyma-i@mit-mc
+Cc: franz-friends
+Status: O
+
+Well, sort of. We now have Macsyma running on a Motorola 68000 - based
+system with 6 megabytes of real memory. The operating system is a
+Unisoft UNIX system, which has been ported to some large number (>65) boxes.
+The Pixel people were kind enough to lend us a machine with enough
+real memory to make virtual memory unnecessary.
+
+It takes a long time to load up, but once running, it is quite responsive,
+and appears to be about 60% of a VAX 11/780 in terms of CPU time.
+
+We have not shaken down everything, but since the source code is unchanged
+from the VAX, we expect the bugs to be limited to lisp compilation
+glitches, or differences between versions of the UNIX system.
+
+
+From jkf Wed Jun 15 10:42:05 1983
+Date: 15 Jun 83 10:42:05 PDT (Wed)
+From: jkf (John Foderaro)
+Subject: Opus 38.62
+Message-Id: <8306151742.20591@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA20591; 15 Jun 83 10:42:05 PDT (Wed)
+To: local-lisp
+Status: O
+
+ There is no longer a limit on the size of bignums, strings or
+symbol names which can be read by the reader [other than the size of
+virtual memory].
+
+ The value of lisp-library-directory will determine where cfasl finds
+its private version of the loader.
+
+ (changes by sklower)
+
+
+From @CMU-CS-C:UI.TYJ@CU20D Wed Jun 15 18:22:55 1983
+Date: 14 Jun 1983 1812-EDT
+From: Tai Jin <UI.TYJ@CU20D>
+Subject: franz mailing liszt
+Message-Id: <8306142214.AA16599@UCBVAX.ARPA>
+Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
+ id AA16599; 14 Jun 83 15:14:36 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA28806; 15 Jun 83 18:22:55 PDT (Wed)
+To: franz-friends%berkeley@CMCSC
+Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC
+Status: O
+
+
+Hi, we would like to be added to your mailing list.
+
+We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS)
+running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center
+for Computing Activities).
+
+Is anyone out there working on an UTS/IBM implementation? Any information will
+be greatly appreciated.
+
+
+Thanks,
+
+Tai Jin <UI.TYJ%CU20D@CMCSC>
+Travis Winfrey <UI.TRAVIS%CU20D@CMCSC>
+-------
+
+From @CMU-CS-C:Ui.Travis@CU20D Thu Jun 16 09:47:39 1983
+Date: 16 Jun 1983 1243-EDT
+From: Travis Lee Winfrey <Ui.Travis@CU20D>
+Subject: Porting Franz lisp to Amdahl Unix
+Message-Id: <8306161646.AA25470@UCBVAX.ARPA>
+Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
+ id AA25470; 16 Jun 83 09:46:15 PDT (Thu)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA06352; 16 Jun 83 09:47:39 PDT (Thu)
+To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC
+Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D,
+ kim.fateman%berkeley@CMCSC
+Status: O
+
+Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's
+Unix running on a IBM 4341. We are working from a copy that runs on the VAX.
+
+We would be very interested in seeing any versions that runs both on the VAX
+and some other machine, such as the 68000. We are also interested in seeing
+any documentation on other porting efforts, regardless of what machine.
+
+Thanks,
+
+Tai Jin <ui.tyj%cu20d@cmu-cs-c>
+Travis Winfrey <ui.travis%cu20d@cmu-cs-c>
+-------
+
+From jkf Sun Jun 19 15:43:34 1983
+Date: 19 Jun 83 15:43:34 PDT (Sun)
+From: jkf (John Foderaro)
+Subject: opus 38.63
+Message-Id: <8306192243.19626@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA19626; 19 Jun 83 15:43:34 PDT (Sun)
+To: local-lisp
+Status: O
+
+ Added functions:
+ (vputprop 'Vv_vector 'g_value 'g_indicator)
+ (vget 'Vv_vector 'g_indicator)
+
+ work just like putprop and get, but modify the vector property list.
+
+ Also:
+ you can determine which function is called by lisp to print a vector
+ by placing the function to call on the vector's property list under
+ indicator 'print'. The print function is called with two arguments:
+ the vector and the port.
+
+ For example:
+=> (defun printv (v port)
+ (patom "A vector of size " port)
+ (print (vsize v) port))
+printv
+=> (setq xx (new-vector 10))
+vector[40]
+=> (vputprop xx 'printv 'print)
+printv
+=> xx
+A vector of size 10
+=>
+
+
+
+From jkf Sun Jun 19 22:47:42 1983
+Date: 19 Jun 83 22:47:42 PDT (Sun)
+From: jkf (John Foderaro)
+Subject: opus 38.64
+Message-Id: <8306200547.23164@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA23164; 19 Jun 83 22:47:42 PDT (Sun)
+To: local-lisp
+Cc: jpg@Mit-mc
+Status: O
+
+
+ added the function (^ 'x_a 'x_b) which computes x_a to the x_b
+power and always returns a fixnum result (it currently wraps around
+on overflow).
+
+
+
+From JPG@MIT-MC Sun Jun 19 22:54:00 1983
+Date: 20 June 1983 01:53 EDT
+From: Jeffrey P. Golden <JPG@MIT-MC>
+Subject: ^
+Message-Id: <8306200553.AA15160@UCBVAX.ARPA>
+Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33)
+ id AA15160; 19 Jun 83 22:53:57 PDT (Sun)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA23228; 19 Jun 83 22:54:00 PDT (Sun)
+To: jkf@UCBKIM
+Cc: JPG@MIT-MC, local-lisp@UCBKIM
+Status: O
+
+ Date: 19 Jun 83 22:47:42 PDT
+ From: jkf%UCBKIM@Berkeley
+ Subject: opus 38.64
+ To: local-lisp%UCBKIM@Berkeley
+ Cc: jpg@Mit-mc
+ added the function (^ 'x_a 'x_b) which computes x_a to the x_b
+ power and always returns a fixnum result (it currently wraps around
+ on overflow).
+The Maclisp ^ errors out in this case with the message:
+;RESULT LARGER THAN FIXNUM - ^
+
+
+From narain@rand-unix Mon Jun 20 22:09:31 1983
+Date: Monday, 20 Jun 1983 22:00-PDT
+From: narain@rand-unix
+Subject: Re: Interrrupt question
+Message-Id: <8306210509.AA00276@UCBVAX.ARPA>
+Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
+ id AA00276; 20 Jun 83 22:09:20 PDT (Mon)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA09633; 20 Jun 83 22:09:31 PDT (Mon)
+To: franz-friends@BERKELEY.ARPA
+Cc: narain@rand-unix
+Status: O
+
+
+ TWIMC
+ -----
+
+Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp:
+i.e. if you wish to interrupt a Franzlisp computation, browse around the state
+and resume computation:
+
+Hit DEL;
+Browse;
+(return t)
+
+This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay).
+
+-- Sanjai
+
+From Tim%UPenn.UPenn@UDel-Relay Tue Jun 21 14:52:53 1983
+Date: Tue, 21 Jun 83 10:33 EDT
+From: Tim Finin <Tim.UPenn@UDel-Relay>
+Subject: interrupting Franz
+Return-Path: <Tim%UPenn.UPenn@UDel-Relay>
+Message-Id: <8306212152.AA12930@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
+ id AA12930; 21 Jun 83 14:52:36 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA21097; 21 Jun 83 14:52:53 PDT (Tue)
+To: franz-friends@BERKELEY.ARPA
+Via: UPenn; 21 Jun 83 17:40-EDT
+Status: O
+
+
+Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.
+
+From jkf Sat Jun 25 13:49:37 1983
+Date: 25 Jun 83 13:49:37 PDT (Sat)
+From: jkf (John Foderaro)
+Subject: opus 38.65
+Message-Id: <8306252049.25527@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA25527; 25 Jun 83 13:49:37 PDT (Sat)
+To: local-lisp
+Status: O
+
+ If you have automatic case conversion set (i.e. (sstatus uctolc t)),
+then symbols with lower case letters will be escaped by print.
+
+
+
+From layer Tue Jul 5 00:26:29 1983
+Date: 5 Jul 1983 0026-PDT (Tuesday)
+From: layer (Kevin Layer)
+Subject: lisp opus 38.67
+Message-Id: <5390.30.426237985@ucbkim>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA05911; 5 Jul 83 00:26:29 PDT (Tue)
+Phone: (415) 652-2405
+To: local-lisp
+Cc: layer
+Status: O
+
+ The function 'sortcar' has been slightly changed: if the second
+arg is nil, then the ordering function 'alphalessp' is assumed
+('sort' does it this way).
+
+ Kevin
+
+From layer Wed Jul 6 00:02:33 1983
+Date: 6 Jul 83 00:02:33 PDT (Wed)
+From: layer (Kevin Layer)
+Subject: liszt opus 8.30
+Message-Id: <8307060702.24776@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA24776; 6 Jul 83 00:02:33 PDT (Wed)
+Phone: (415) 652-2405
+To: local-lisp
+Cc: sklower, jkf
+Status: O
+
+ All modifications should be transparent, but if there are problems
+relating to the autorun feature (-r flag), please let me know.
+
+ Kevin
+
+
+
+From sklower Thu Jul 7 00:27:52 1983
+Date: 7 Jul 83 00:27:52 PDT (Thu)
+From: sklower (Keith Sklower)
+Subject: Franz, opus38.68
+Message-Id: <8307070727.10697@UCBKIM.ARPA>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA10697; 7 Jul 83 00:27:52 PDT (Thu)
+To: local-lisp
+Status: O
+
+Franz now escapes UPPER case letters instead of lower case letters when
+(status uctolc) is enabled, so that (read (print x)) is an identity operation
+on atom printnames. Also, we made (explode) conform to what maclisp does
+with opposite-than-normal character-cases.
+
+From Ira%UPenn.UPenn@UDel-Relay Fri Jul 8 01:46:25 1983
+Date: Thu, 7 Jul 83 22:13 EDT
+From: Ira Winston <Ira.UPenn@UDel-Relay>
+Subject: Eliza
+Return-Path: <Ira%UPenn.UPenn@UDel-Relay>
+Message-Id: <8307080845.AA16294@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
+ id AA16294; 8 Jul 83 01:45:43 PDT (Fri)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA01687; 8 Jul 83 01:46:25 PDT (Fri)
+To: franz-friends@BERKELEY.ARPA
+Via: UPenn; 8 Jul 83 3:07-EDT
+Status: O
+
+Does anyone have a version of Eliza that runs under Franz Lisp?
+
+From layer Fri Jul 8 18:04:10 1983
+Date: 8 Jul 1983 1804-PDT (Friday)
+From: layer (Kevin Layer)
+Subject: lisp opus 38.69
+Message-Id: <7031.30.426560643@ucbkim>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA07142; 8 Jul 83 18:04:10 PDT (Fri)
+Phone: (415) 652-2405
+To: local-lisp
+Cc: layer
+Status: O
+
+ 'setf' now knows about 'nthelem', and there are two new functions:
+
+ (readdir 's_direct)
+ returns a list of the contents of the directory s_direct.
+
+ (dirp 's_name)
+ returns s_name if s_name is a directory. This doesn't
+ insure that you can read the directory, though (only
+ uses stat(2)).
+
+ Kevin
+
+From layer Fri Jul 8 20:57:13 1983
+Date: 8 Jul 1983 2057-PDT (Friday)
+From: layer (Kevin Layer)
+Subject: new function readdir
+Message-Id: <465.30.426571029@ucbkim>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA00480; 8 Jul 83 20:57:13 PDT (Fri)
+Phone: (415) 652-2405
+To: local-lisp
+Fcc: record
+Status: O
+
+ The function 'readdir' and 'dirp' should not be relied on yet, since
+they are provisional, because they are implemented with C library
+functions only available on 4.1+ systems.
+
+ Kevin
+
+From Pwh%GaTech.GATech@UDel-Relay Tue Jul 12 18:08:46 1983
+Date: 11 Jul 83 20:36:32-EDT (Mon)
+From: <pwh.gatech@UDel-Relay>
+Subject: Franz flavors?
+Return-Path: <Pwh%GaTech.GATech@UDel-Relay>
+Message-Id: <8307130107.AA03336@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
+ id AA03336; 12 Jul 83 18:07:40 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA20140; 12 Jul 83 18:08:46 PDT (Tue)
+To: franz-friends@BERKELEY.ARPA
+Cc: jlk.Gatech@UDel-Relay
+Via: GATech; 12 Jul 83 2:43-EDT
+Status: O
+
+We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our
+long awaited Symbolics Lisp Machine up and running and are trying to establish
+some measure of compatability between Franz and Zeta Lisp (as appropriate).
+Janet seems to recall some mention of a flavor package for Franz. Is this
+Berkley based or can anyone provide some clues as to where to check next?
+
+Also, when is the next release of Franz scheduled and what features will it
+incorporate?
+
+If the flavor package is non-existent, we will probably be forced to develop
+one here and will, of course, be glad to pass anything useful along.
+
+phil hutto
+
+From narain@rand-unix Tue Jul 12 20:10:42 1983
+Date: Tuesday, 12 Jul 1983 19:49-PDT
+From: narain@rand-unix
+Subject: Re: Franz flavors?
+Message-Id: <8307130309.AA05908@UCBVAX.ARPA>
+Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
+ id AA05908; 12 Jul 83 20:09:41 PDT (Tue)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA21387; 12 Jul 83 20:10:42 PDT (Tue)
+To: <pwh.gatech@UDEL-RELAY>
+Cc: franz-friends@BERKELEY.ARPA, jlk.Gatech@UDEL-RELAY
+In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon).
+ <8307130107.AA03336@UCBVAX.ARPA>
+Status: O
+
+
+We at Rand are interested in developing a set of guidelines for writing
+code that will be compatible with each of Zeta- Franz- and PSL Lisps. I
+would be grateful if you could tell us of what your experiences have been with
+making Franzlisp code work on the Symbolics machine. We would gladly share
+our own with you if you wish; incidentally we also have an IJCAI paper on a
+related issue.
+
+-- Sanjai Narain
+
+From liz.umcp-cs@UDel-Relay Wed Jul 13 00:55:26 1983
+Date: 13 Jul 83 03:09:39 EDT (Wed)
+From: Liz Allen <liz.umcp-cs@UDel-Relay>
+Subject: Re: Franz flavors?
+Return-Path: <liz.umcp-cs@UDel-Relay>
+Message-Id: <8307130754.AA10367@UCBVAX.ARPA>
+Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
+ id AA10367; 13 Jul 83 00:54:32 PDT (Wed)
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA24477; 13 Jul 83 00:55:26 PDT (Wed)
+To: pwh.gatech@UDel-Relay, franz-friends@BERKELEY.ARPA
+Cc: jlk.Gatech@UDel-Relay
+Via: UMCP-CS; 13 Jul 83 3:23-EDT
+Status: O
+
+Here at the Univ of Maryland, we do have an implementation of
+flavors in Franz Lisp and have used it successfully in several
+large systems. It doesn't contain all the features of the Lisp
+Machine Flavors, but it does implement all the major ones. It is
+also different in a few ways that are necessitated by the limitations
+of Franz Lisp (shallow binding without invisible pointers or true
+closures -- though closures may be in the very newest versions of
+Franz -- we have opus 38.26). The package uses a hashing scheme
+for looking up methods, and the function <- which is used to send
+a message to an object is written in C. Together, this makes it
+an efficient implementation.
+
+We are currently working on a new policy for distributing flavors,
+our other lisp packages and our window package. When we have worked
+it out, I will announce the details here.
+
+ -Liz
+
+From @MIT-MC:mdm@cmu-ri-isl Thu Jul 14 11:07:57 1983
+Date: 14 Jul 1983 14:03:01-EDT
+From: Malcolm.McRoberts@CMU-RI-ISL
+Subject: random numbers
+Message-Id: <8307141806.AA05735@UCBVAX.ARPA>
+Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35)
+ id AA05735; Thu, 14 Jul 83 11:06:45 PDT
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA13687; 14 Jul 83 11:07:57 PDT (Thu)
+Apparently-To: <franz-friends@UCB-VAX>
+Status: O
+
+I am interested in obtaining a GOOD random number generator that is callable
+from Franz. My only real requirements are that it accept a seed (so that I
+can duplicate the same series), is fairly good (try doing several (random
+4)'s in Franz and see what you get), and is of intermediate speed. If you
+know of such an animal please send me mail telling me how to get it.
+ thanks
+
+
+From kanderso@bbn-vax Thu Jul 14 12:49:58 1983
+Date: 14 Jul 1983 15:47:19 EDT (Thursday)
+From: Ken Anderson <kanderso@bbn-vax>
+Subject: Random numbers
+Message-Id: <8307141948.AA06936@UCBVAX.ARPA>
+Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35)
+ id AA06936; Thu, 14 Jul 83 12:48:49 PDT
+Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
+ id AA15607; 14 Jul 83 12:49:58 PDT (Thu)
+To: franz-friends@BERKELEY.ARPA
+Cc: Malcolm.McRoberts@CMU-RI-ISL
+Status: O
+
+Here is a random number generator i use. It seems to work fairly well, but i have
+not looked to closely at the statistics. Since it will occasionally require
+bignums, it is probably not the fastest either. I was just looking for something
+that was likely to be portable between LISP's.
+I would be very interested in hearing your evaluation of it.
+
+k
+
+;;; RANDOM NUMBERS
+(declare (macros t))
+(include math.h)
+
+(defvar $uniform-a 16807) ; = 7^5
+(defvar $mersenne-prime 2147483647) ; = 2^31 - 1
+(defvar $mersenne-prime-1 (- $mersenne-prime 1))
+
+(defmacro with-seed (s-newseed . body)
+ ; evaluates body with the seed of the random numbers set to s-newseed.
+ ; the value of s-newseed is updated. Thus this is a way of
+ ; Keepining several sequences of random numbers with their own seeds
+ `(let (($uniform-seed ,s-newseed))
+ (prog1 (progn ,@body)
+ (setq ,s-newseed $uniform-seed))))
+
+(defun uniform-basic (previous-fixnum)
+ ; -> a fixnum 0 < fixnum < 2^31 - 1
+ ; Repeated calls will generate fixnums in the range
+ ; 1 -> 2^31 - 2.
+
+ ; The basic idea is new = A^k * old (mod p)
+ ; where A is a primitive root of p, k is not a factor of p-1
+ ; and p is a large prime.
+
+ ; This is a good random number generator but is not be the fastest!
+ ; On FRANZ LISP, and LISP MACHINE it will require bignums since
+ ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder
+ ; can be done more efficiently.
+ ; See: Linus Schrage, A More Portable Fortran Random Number Generator,
+ ; ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979.
+ (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime))
+
+(defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1
+
+(defun uniform ()
+ ; -> the next uniform random number in the sequence
+ ; To have your own sequence, rebind $uniform-seed.
+ (setq $uniform-seed (uniform-basic $uniform-seed)))
+
+(defun uniform-between (low-num high-num)
+ ; -> a uniform random number, x, low-num <= x <= high-num
+ ; If low-num and high-num are fixnums, a fixnum is returned.
+ (cond ((not (and (fixp low-num) (fixp high-num)))
+ (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1))
+ (-$ high-num low-num))))
+ (t (+ low-num (// (uniform)
+ (// $mersenne-prime-1 (max 1 (- high-num low-num -1))))))))
+
+(defun gaussian-random-1 ()
+ ; -> a gaussian random variable with mean 0.0 and
+ ; standard deviation 1.0.
+ ; Good tails.
+ (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0))))
+ (sin (*$ $2pi (uniform-between 0.0 1.0)))))
+
+(defun gaussian-random (mean standard-deviation)
+ (+$ mean (*$ (gaussian-random-1) standard-deviation)))
+
+;;(defun gaussian (x)
+;; (* (sqrt $2pi)
+;; (exp (minus (// (square x) 2.0)))))
+
+(defun random-yes-no (fraction-yes)
+ (<= (uniform-between 0.0 1.0) fraction-yes))
+
+
+From layer Sat Jul 30 15:46:42 1983
+Date: 30 Jul 1983 1546-PDT (Saturday)
+From: layer (Kevin Layer)
+Subject: liszt opus 8.33
+Message-Id: <19472.30.428453197@ucbkim>
+Received: by UCBKIM.ARPA (3.340/3.5)
+ id AA19498; 30 Jul 83 15:46:42 PDT (Sat)
+Phone: (415) 652-2405
+To: local-lisp
+Status: O
+
+ Vset is now open coded. There should be no visible change in the
+behaviour of vectors, except in speed (greater, that is), and
+vsize-{byte,word} work properly now.
+
+ Bugs to me.
+
+ Kevin
+
+From jkf Mon Aug 1 14:41:28 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA03743; Mon, 1 Aug 83 14:41:28 PDT
+Date: Mon, 1 Aug 83 14:41:28 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308012141.AA03743@ucbkim.ARPA>
+To: local-lisp
+Subject: defstruct
+Status: O
+
+ defstruct now understands two more types of structures:
+ :vector
+ :named-vector
+
+ A named vector has the defstruct structure name on the vector property
+list, thus an instance of the foo structure would print as 'foo[8]'.
+
+
+ :named-vector is now the default structure type (instead of :hunk).
+
+
+
+
+From jkf Tue Aug 2 15:20:04 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA26686; Tue, 2 Aug 83 15:20:04 PDT
+Date: Tue, 2 Aug 83 15:20:04 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308022220.AA26686@ucbkim.ARPA>
+To: local-lisp
+Subject: lisp opus 38.70
+Status: RO
+
+ When a vector is printed, the size in square brackets will be the number
+of entries (not the number of bytes). The size printed for vectori
+objects will continue to be the number of bytes.
+
+ Also, if the property of a vector is a list with the car being a non nil
+symbol, and if that list doesn't have a print property, then that
+symbol will be printed rather than 'vector' or 'vectori'.
+
+
+
+From layer Thu Aug 4 02:10:12 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA11660; Thu, 4 Aug 83 02:10:12 PDT
+From: layer (Kevin Layer)
+Phone: (415) 652-2405
+Date: 4 Aug 1983 0210-PDT (Thursday)
+Message-Id: <11649.30.428836207@ucbkim>
+To: local-lisp
+Subject: liszt opus 8.34
+Status: RO
+
+ I just installed a new compiler. For the vax, there shouldn't be
+any visible changes, though a couple of vector bugs were fixed. For
+the 68000, the vector access functions are now open coded, and the
+new one was installed on mike, rob, and chip in /usr/ucb.
+
+ Kevin
+
+From FRD@SU-AI Fri Aug 5 15:57:17 1983
+Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
+ id AA10610; Fri, 5 Aug 83 15:57:17 PDT
+Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
+ id AA10357; Fri, 5 Aug 83 15:54:22 PDT
+Message-Id: <8308052254.AA10357@UCBVAX.ARPA>
+Date: 05 Aug 83 1353 PDT
+From: Fred Lakin <FRD@SU-AI>
+Subject: Franz & SUNs
+To: franz-friends@BERKELEY
+Status: RO
+
+I am interested in connectons between Franz and SUN workstations.
+Like how far along is Franz on the SUN? Is there some package
+which allows Franz on a VAX to use a SUN as a display device?
+
+Any info on this matter would be appreciated.
+Thnaks, Fred Lakin
+
+
+From tektronix!ogcvax!metheus!tombl Sat Aug 6 09:49:57 1983
+Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
+ id AA21229; Sat, 6 Aug 83 09:49:57 PDT
+Received: by UCBVAX.ARPA (3.347/3.35)
+ id AA13549; Sat, 6 Aug 83 09:40:11 PDT
+Message-Id: <8308061640.AA13549@UCBVAX.ARPA>
+From: ogcvax!metheus!tombl
+To: ogcvax!tektronix!ucbvax!franz-friends
+Cc: ogcvax!tektronix!ucbvax!sklower
+Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT
+Subject: bug in Opus 38.66
+Date: Fri Aug 5 20:46:56 1983
+Status: O
+
+
+A bug present in previous versions is also present in 38.66 of Franz.
+cfasl fails (in most cases) to close the file it reads from.
+Consequently, mysterious events occur when the maximum number of open
+file descriptors is reached.
+
+The fix is made in the file ffasl.c. "close(fildes)" should be
+prepended to the two return sequences from (the Unix code for)
+Lcfasl:
+
+------------------------------------------------------------------
+Old: 146c146
+ < {Restorestack(); return(nil);}
+ ---
+Fixed: > {close(fildes); Restorestack(); return(nil);}
+ 149a150
+ > close(fildes);
+------------------------------------------------------------------
+
+
+ Tom Blenko
+ Metheus Corp.
+ ucbvax!tektronix!ogcvax!metheus!tombl
+ allegra!ogcvax!metheus!tombl
+
+
+
+From FRD@SU-AI Sun Aug 7 12:34:43 1983
+Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
+ id AA10610; Fri, 5 Aug 83 15:57:17 PDT
+Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
+ id AA10357; Fri, 5 Aug 83 15:54:22 PDT
+Message-Id: <8308052254.AA10357@UCBVAX.ARPA>
+Date: 05 Aug 83 1353 PDT
+From: Fred Lakin <FRD@SU-AI>
+Subject: Franz & SUNs
+To: franz-friends@BERKELEY
+Status: O
+
+I am interested in connectons between Franz and SUN workstations.
+Like how far along is Franz on the SUN? Is there some package
+which allows Franz on a VAX to use a SUN as a display device?
+
+Any info on this matter would be appreciated.
+Thnaks, Fred Lakin
+
+
+From jkf Mon Aug 8 09:06:49 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA06584; Mon, 8 Aug 83 09:06:49 PDT
+Date: Mon, 8 Aug 83 09:06:49 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308081606.AA06584@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.72
+Status: O
+
+ A bug was fixed in defmacro which caused the &protect option and
+displace-macros to interact poorly.
+
+
+
+From jkf Fri Aug 12 22:11:13 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA25610; Fri, 12 Aug 83 22:11:13 PDT
+Date: Fri, 12 Aug 83 22:11:13 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308130511.AA25610@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.73
+Status: O
+
+ 'equal' will now compare all types of vectors for equality.
+
+ 'copy' will now copy all types of vectors.
+
+
+
+
+From layer Mon Aug 15 20:03:53 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA03597; Mon, 15 Aug 83 20:03:53 PDT
+From: layer (Kevin Layer)
+Phone: (415) 652-2405
+Date: 15 Aug 1983 2003-PDT (Monday)
+Message-Id: <3556.30.429851029@ucbkim>
+To: local-lisp
+Subject: liszt opus 8.35
+Fcc: record
+Status: RO
+
+ Several things have changed:
+
+1) Bugs in the open coding of vectors have been fixed.
+
+2) Minor re-organization of the compiler source code.
+
+3) The routine to determine whether or not tail merging is
+ possible underwent major modification.
+
+4) Lexpr's are compiled differently, or rather the way lexpr args
+ are accessed has changed. For those that want to know, here is
+ the nitty gritty:
+
+ Consider a the following lexpr: (defun test nargs ...).
+ The arguments to the lexpr are stacked on the name stack
+ (low to high number), and then nargs is stacked. The user
+ is allowed to change the binding of 'nargs' to anything
+ he likes, so we have to have another way to access the arguments
+ on the name stack (i.e., other than an offset from nargs).
+ Before, a pointer to the argument base was pushed on the
+ C stack, so that indexing could be done from there.
+ The addressing modes used to do this are not available
+ on the MC68000 (something like *n(fp)[Rx]), so now
+ nargs is pushed on the name stack twice, and the location
+ of an argument can be easily calculated as an offset from nargs.
+
+In short, lots of thing changed. The SUN's should be updated
+in the next couple of days (after I test it out). Bugs to me...
+
+ Kevin
+
+From jkf Mon Aug 15 23:11:08 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA05928; Mon, 15 Aug 83 23:11:08 PDT
+Date: Mon, 15 Aug 83 23:11:08 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308160611.AA05928@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.74
+Status: O
+
+
+ If a vector has a 'unique' property on it's property list, then it will
+not be copied by 'copy'.
+
+ 'untrace' will now autoload /usr/lib/lisp/trace.
+
+ A number of functions and macros were contributed by the bair group:
+
+
+
+
+
+
+
+
+(<= 'fx_arg1 'fx_arg2 ...)
+(<=& 'x_arg1 'x_arg2)
+
+ RETURNS: t iff (> 'fx_arg1 'fx_arg2) [or (>& 'x_arg1
+ 'x_arg2)] is nil, otherwise nil. The general
+ function, <=, can take more than two argu-
+ ments.
+
+(>= 'fx_arg1 'fx_arg2)
+(>=& 'x_arg1 'x_arg2)
+
+ RETURNS: t iff (< 'fx_arg1 'fx_arg2 ...) [or (<&
+ 'x_arg1 'x_arg2)] is nil, otherwise nil.
+
+ NOTE: The general function, >=, can take more than two
+ arguments.
+
+(litatom 'g_arg)
+
+ RETURNS: t iff g_arg is an atom, but not a number.
+
+(nequal 'g_x 'g_y)
+
+ RETURNS: t iff g_x is not equal to g_y, otherwise nil.
+
+(lineread [['p_port] ['s_flag]])
+
+ RETURNS: a list consisting of s-expressions on a line
+ from the port p_port (or piport if p_port is
+ not given). If an s-expression (e.g., a list)
+ takes more than one line, or a line terminates
+ in a space or tab, then lineread continues
+ reading until an expression ends at the end of
+ a line.
+
+ NOTE: If s_flag is t, then if the first character on a
+ line is a newline, lineread performs a tyi and
+ returns nil. If s_flag is nil or not present,
+ lineread does a read skipping over any blank
+ lines to make sure that an s-expression is actu-
+ ally read.
+
+ SIDE EFFECT: lineread uses read, advancing the port
+ character pointer.
+
+
+
+
+
+
+
+
+\e9
+
+\e9
+
+
+
+
+
+
+
+
+
+
+(defv g_arg1 g_arg2)
+
+ EQUIVALENT TO: (set g_arg1 g_arg2)
+
+(pp-form 'g_form ['p_port] ['n_lmar])
+
+ RETURNS: nil
+
+ SIDE EFFECT: g_form is pretty-printed to the port
+ p_port (or poport if p_port is not given).
+ If pp-form is also supplied with an
+ integer (n_lmar), that integer will be
+ used as a left margin setting (0 is the
+ default). This is the function which pp
+ uses (n_lmar = 0). pp-form does not look
+ for function definitions or values of
+ variables, it just prints out the form it
+ is given.
+
+ NOTE: This is useful as a top-level-printer, c.f. top-
+ level in Chapter 6.
+
+(sload 's_file1 ...)
+
+ SIDE EFFECT: The files named are opened for reading and
+ each form is read, optionally printed, and
+ evaluated.
+
+ NOTE: What sload prints is controlled by the special
+ atom $sldprint. If $sldprint is t (default),
+ then if a form is recognizable as a function
+ definition, only the function name is printed,
+ otherwise the whole form is printed. If
+ $sldprint is eq to value, then the result of each
+ form's evaluation will also be printed. Printing
+ the forms' values can be controlled by setting
+ sload-print equal to the name of the function to
+ be called. sload recognizes named functions by
+ looking at the sloadprintarg property of the
+ function name. The value of the sloadprintarg
+ property should be the argument number of the
+ function name. For the standard Franz Lisp func-
+ tions, the properties are already set.
+
+ EXAMPLE: (defprop def 1 sloadprintarg) ; This is the
+ default--declaring that
+ ; the name of
+ the function definition is the
+ ; first argu-
+ ment.
+
+
+\e9
+
+\e9
+
+
+
+
+
+
+
+
+
+
+ The functions described below are an alternative
+ to the gensym facility. They generate new symbols by
+ attaching counter numbers to the ends of the symbols'
+ names. An example follows of how the functions are
+ used.
+
+
+ ____________________________________________________
+
+ -> (initsym joe (john 5)) ; initializing new symbol counters
+ (joe0 john5)
+ -> (newsym john) ; create a new symbol
+ john6
+ -> (newsym chuck) ; symbol need not be initsym'ed
+ chuck0
+ -> (oldsym john) ; get current symbol
+ john6
+ -> (allsym john) ; get all symbols between 0 and counter
+ (john0 john1 john2 john3 john4 john5 john6)
+ -> (allsym (john 5)) ; get all symbols between 5 and counter
+ (john5 john6)
+ -> (remsym joe (john 4)) ; remob all interned symbols
+ ; associated with joe and from
+ ; john4 to the current john
+ ; symbol--returns symbols with symbol counters
+ ; before doing remsym
+ (joe0 john6)
+ -> (symstat joe john)
+ ((joe nil) (john 3))
+ ____________________________________________________
+
+
+
+
+(initsym g_arg1 ...)
+
+ WHERE: g_argi is a list (n_counteri s_argi) or a
+ string s_argi (which is equivalent to (0
+ s_argi)).
+
+ RETURNS: a list of interned identifiers using the sym-
+ bol counters n_counteri, i.e., the result of
+ concatenating s_argi to n_counteri.
+
+ EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5)
+
+ NOTE: See also newsym, oldsym, allsym, remsym, and sym-
+ stat functions.
+
+
+
+
+\e9
+
+\e9
+
+
+
+
+
+
+
+
+
+
+(newsym s_arg)
+
+ RETURNS: an interned identifier formed by concatenating
+ the name s_arg to the symbol counter for
+ s_arg. The symbol counter is stored on the
+ property list of s_arg under symctr. If there
+ is no counter, a counter of 0 is used and
+ added to the property list. Thus, a symbol
+ need not be initsymed.
+
+ EXAMPLE: (initsym joe (john5)) ==> (joe0 john5)
+ (newsym john) ==> john6
+ (newsym joe) ==> joe1
+
+ NOTE: See also initsym, oldsym, allsym, remsym, and
+ symstat functions.
+
+(oldsym s_arg)
+
+ RETURNS: the identifier using the current symbol
+ counter for s_arg, rather than creating a new
+ identifier. If no symbol counter exists for
+ s_arg, then s_arg is returned.
+
+ NOTE: See also initsym, newsym, allsym, remsym, and
+ symstat functions.
+
+(allsym g_arg)
+
+ WHERE: g_arg is a list (s_arg n_counter) or a string
+ s_arg (equivalent to (s_arg 0)).
+
+ RETURNS: a list of all the created identifiers between
+ n_counter and the current symbol counter for
+ s_arg.
+
+ EXAMPLE: (allsym john) ==> (john0 john1 john2)
+
+ NOTE: See also initsym, newsym, oldsym, remsym, and
+ symstat functions.
+
+(remsym g_arg1 ...)
+
+ WHERE: g_argi is a list (s_argi n_counteri) or a
+ string s_argi (which is equivalent to (s_argi
+ 0)).
+
+ RETURNS: a list of symbols s_argi with the current sym-
+ bol counters.
+
+ SIDE EFFECT: remsym remob's all the created identifiers
+ between zero and the current symbol
+ counter for s_argi.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ NOTE: See also initsym, newsym oldsym, allsym, and sym-
+ stat functions.
+
+(symstat s_arg1 ...)
+
+ RETURNS: a list of pairs consisting of (s_argi symctri)
+ where symctri is s_argi's current symbol
+ counter.
+
+ NOTE: See also initsym, newsym, oldsym, allsym, and
+ remsym functions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+\e9
+
+\e9
+
+
+
+
+
+
+From jkf Thu Aug 18 19:25:45 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA09885; Thu, 18 Aug 83 19:25:45 PDT
+Date: Thu, 18 Aug 83 19:25:45 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308190225.AA09885@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.75
+
+ evalhook and funcallhook can now be executed without setting (*rset t)
+and (sstatus evalhook t). Although they can be executed, they won't
+have any effect unless and until (*rset t) and (sstatus evalhook t) are
+done.
+ The reason for this change is that now one can turn off stepping
+by (sstatus evalhook nil) and then continue the evaluation with
+evalhook and funcallhook.
+
+ Those who use the new top-level 'tpl' will notice a few new commands
+dealing with stepping when you type '?help'. These new commands
+are ?step, ?soff, and ?sc. Details of the commands are available
+using the help mechanism (e.g. '?help step').
+
+
+
+
+From jkf Fri Aug 19 13:54:26 1983
+Received: by ucbkim.ARPA (4.2/4.2)
+ id AA20017; Fri, 19 Aug 83 13:54:26 PDT
+Date: Fri, 19 Aug 83 13:54:26 PDT
+From: jkf (John Foderaro)
+Message-Id: <8308192054.AA20017@ucbkim.ARPA>
+To: local-lisp
+Subject: liszt 8.36
+
+ The compiler will now compile the form
+ (*no-macroexpand* <form>)
+ in a special way: if <form> is a function call, e.g. (name arg1 ...),
+ then any macro properties of 'name' will be ignored for this
+ invocation. This permits one to write macros which attempt
+ an optimization, and if that fails, then call the standard
+ function. *no-macroexpand* is not a function that can be called,
+ thus forms with *no-macroexpand* are likely to be 'cmacros'.
+ Here is an example:
+
+ (defcmacro length (x &protect (x))
+ `(if (null ,x)
+ then 0
+ elseif (null (cdr ,x))
+ then 1
+ else (*no-macroexpand* (length ,x))))
+
+
+ [in case you are wondering, the `&protect (x)' means that
+ should the actual argument to 'length' be a non atom, defcmacro
+ will lambda bind the value, insuring that it is only evaluated
+ once]
+
+
+
+
+From layer Wed Aug 24 22:18:34 1983
+Received: by ucbkim.ARPA (4.6/4.2)
+ id AA12256; Wed, 24 Aug 83 22:18:34 PDT
+From: layer (Kevin Layer)
+Phone: (415) 652-2405
+Date: 24 Aug 1983 2218-PDT (Wednesday)
+Message-Id: <12219.30.430636709@ucbkim>
+To: local-lisp
+Subject: liszt on kim
+
+ The liszt that I installed on kim yesterday, compiled eq's wrong
+in some rare cases. I installed a new one this evening that fixes
+this, but if you compiled any programs with the bad one, you might
+consider re-compiling them...
+
+ Kevin
+
+From fateman Thu Aug 25 13:58:59 1983
+Received: by ucbkim.ARPA (4.6/4.2)
+ id AA21033; Thu, 25 Aug 83 13:58:59 PDT
+Date: Thu, 25 Aug 83 13:58:59 PDT
+From: fateman (Richard Fateman)
+Message-Id: <8308252058.AA21033@ucbkim.ARPA>
+To: local-lisp
+
+I have a copy of the latest Common Lisp manual... the Excelsior Edition.
+
+From patel@UCLA-LOCUS Tue Aug 30 21:58:38 1983
+Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
+ id AA29417; Tue, 30 Aug 83 21:58:38 PDT
+Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4)
+ id AA06203; Tue, 30 Aug 83 21:50:26 PDT
+Message-Id: <8308310450.AA06203@ucbvax.ARPA>
+Date: Tue, 30 Aug 83 21:44:13 PDT
+From: Dorab Patel <patel@UCLA-LOCUS>
+To: franz-friends@BERKELEY
+Subject: bug fix for 'insert' in opus 38.50
+
+The function 'insert' in Opus 38.50 does not perform as advertised in
+the manual if the last argument is non-nil (i.e. if no duplicates are allowed.
+It still insists on putting the duplicate element into the list. The
+fix is in /usr/lib/lisp/common2.l. Just change the default setting
+of the 'comparefn' to that given below instead of
+(function alphalessp). Here is an excerpt from the modified file.
+
+
+ [.....]
+(def insert
+ (lambda (x l comparefn nodups)
+ (cond ((null l) (list x))
+ ((atom l)
+ (error "an atom, can't be inserted into" l))
+ (t (cond
+ ((null comparefn) (setq comparefn
+ (function
+ (lambda (x y)
+ (or (alphalessp x y)
+ (equal x y)))))))
+ (prog (l1 n n1 y)
+ (setq l1 l)
+ (setq n (length l))
+ a (setq n1 (/ (add1 n) 2))
+ (setq y (Cnth l1 n1))
+ [..........]
+
+From jkf Sun Sep 4 09:59:01 1983
+Received: by ucbkim.ARPA (4.6/4.2)
+ id AA03721; Sun, 4 Sep 83 09:59:01 PDT
+Date: Sun, 4 Sep 83 09:59:01 PDT
+From: jkf (John Foderaro)
+Message-Id: <8309041659.AA03721@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.77
+
+ The 'error' function used to print its arguments and then call 'err' to
+cause the familar 'call to err' error. The problem with this is that
+even if you wrap your compuatation with (errset ... nil), the error message
+will still be printed. In opus 38.77, this problem has been fixed.
+
+A new function was added:
+ (err-with-message 'st_message ['g_value])
+ This causes an error to be signaled with the given message. The message
+will only be printed if an '(errset ... nil)' isn't being executed.
+Normally nil is returned from an errset if an error occured. If you provide
+g_value, then it will be returned from the errset.
+[Not surprisingly, 'error' now uses 'err-with-message']
+
+
+Also, 'error' now takes any number of arguments. In concatenates them,
+separated by spaces, and this is the error message passed to
+err-with-message.
+
+
+
+
+From narain@rand-unix Fri Sep 9 13:32:24 1983
+Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
+ id AA16481; Fri, 9 Sep 83 13:32:24 PDT
+Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7)
+ id AA11010; Fri, 9 Sep 83 13:31:58 PDT
+Message-Id: <8309092031.AA11010@ucbvax.ARPA>
+Date: Friday, 9 Sep 1983 10:55-PDT
+To: franz-friends@BERKELEY
+Cc: narain@rand-unix
+Subject: Franzlisp Question
+From: narain@rand-unix
+
+
+Hello all:
+
+I would be grateful if you could answer another question regarding Franzlisp.
+How does one make Franzlisp continue from an error? For example when Lisp
+gives an error message like "x unbound variable", is it possible to
+bind x to a value and make Lisp continue from that point? Right now we have
+to start over again and it is very time consuming.
+
+-- Sanjai
+
+From AUSTIN@DEC-MARLBORO.ARPA Fri Sep 9 13:46:45 1983
+Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
+ id AA16843; Fri, 9 Sep 83 13:46:45 PDT
+Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7)
+ id AA11248; Fri, 9 Sep 83 13:46:26 PDT
+Date: 9 Sep 1983 1427-EDT
+From: AUSTIN@DEC-MARLBORO
+To: FRANZ-FRIENDS@BERKELEY
+Subject: LIST MEMBERSHIP
+Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO>
+
+PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION.
+
+MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO.
+
+THANKS!
+ --------
+
+From jkf Sat Sep 10 12:34:14 1983
+Received: by ucbkim.ARPA (4.6/4.2)
+ id AA28421; Sat, 10 Sep 83 12:34:14 PDT
+Date: Sat, 10 Sep 83 12:34:14 PDT
+From: jkf (John Foderaro)
+Message-Id: <8309101934.AA28421@ucbkim.ARPA>
+To: local-lisp
+Subject: opus 38.78
+
+ The new functions contributed by the bair group dealing with symbol
+creation have been changed from fexprs to exprs (lambdas) and lexprs.
+
+The new documentation follows:
+
+
+
+
+
+
+
+ The functions described below are an alternative to the
+gensym facility. They generate new symbols by attaching
+counter numbers to the ends of the symbols' names. An exam-
+ple follows of how the functions are used.
+
+
+ ____________________________________________________
+
+ -> (initsym 'joe '(john 5)) ; initializing new symbol counters
+ (joe0 john5)
+ -> (newsym 'john) ; create a new symbol
+ john6
+ -> (newsym 'chuck) ; symbol need not be initsym'ed
+ chuck0
+ -> (oldsym 'john) ; get current symbol
+ john6
+ -> (allsym 'john) ; get all symbols between 0 and counter
+ (john0 john1 john2 john3 john4 john5 john6)
+ -> (allsym '(john 5)) ; get all symbols between 5 and counter
+ (john5 john6)
+ -> (remsym 'joe '(john 4)) ; remob all interned symbols
+ ; associated with joe and from
+ ; john4 to the current john
+ ; symbol--returns symbols with symbol counters
+ ; before doing remsym
+ (joe0 john6)
+ -> (symstat 'joe 'john)
+ ((joe nil) (john 3))
+ ____________________________________________________
+
+
+
+
+(initsym 'g_arg1 ...)
+
+ WHERE: g_argi is a list (n_counteri s_argi) or a
+ string s_argi (which is equivalent to (0
+ s_argi)).
+
+ RETURNS: a list of interned identifiers using the sym-
+ bol counters n_counteri, i.e., the result of
+ concatenating s_argi to n_counteri.
+
+ EXAMPLE: (initsym 'joe '(john 5)) ==> (joe0 john5)
+
+ NOTE: See also newsym, oldsym, allsym, remsym, and sym-
+ stat functions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+(newsym 's_arg)
+
+ RETURNS: an interned identifier formed by concatenating
+ the name s_arg to the symbol counter for
+ s_arg. The symbol counter is stored on the
+ property list of s_arg under symctr. If there
+ is no counter, a counter of 0 is used and
+ added to the property list. Thus, a symbol
+ need not be initsymed.
+
+ EXAMPLE: (initsym 'joe '(john5)) ==> (joe0 john5)
+ (newsym 'john) ==> john6
+ (newsym 'joe) ==> joe1
+
+ NOTE: See also initsym, oldsym, allsym, remsym, and
+ symstat functions.
+
+(oldsym 's_arg)
+
+ RETURNS: the identifier using the current symbol
+ counter for s_arg, rather than creating a new
+ identifier. If no symbol counter exists for
+ s_arg, then s_arg is returned.
+
+ NOTE: See also initsym, newsym, allsym, remsym, and
+ symstat functions.
+
+(allsym 'g_arg)
+
+ WHERE: g_arg is a list (s_arg n_counter) or a string
+ s_arg (equivalent to (s_arg 0)).
+
+ RETURNS: a list of all the created identifiers between
+ n_counter and the current symbol counter for
+ s_arg.
+
+ EXAMPLE: (allsym 'john) ==> (john0 john1 john2)
+
+ NOTE: See also initsym, newsym, oldsym, remsym, and
+ symstat functions.
+
+(remsym 'g_arg1 ...)
+
+ WHERE: g_argi is a list (s_argi n_counteri) or a
+ string s_argi (which is equivalent to (s_argi
+ 0)).
+
+ RETURNS: a list of symbols s_argi with the current sym-
+ bol counters.
+
+ SIDE EFFECT: remsym remob's all the created identifiers
+ between zero and the current symbol
+ counter for s_argi.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ NOTE: See also initsym, newsym oldsym, allsym, and sym-
+ stat functions.
+
+(symstat 's_arg1 ...)
+
+ RETURNS: a list of pairs consisting of (s_argi symctri)
+ where symctri is s_argi's current symbol
+ counter.
+
+ NOTE: See also initsym, newsym, oldsym, allsym, and
+ remsym functions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
projects / unix-history / commitdiff