4.1cBSD/usr/src/ucb/lisp/lispnews
From jkf Tue Apr 13 00:12:22 1982
To: /na/doe/jkf/lispnews
Subject: new features
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
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
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
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
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
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
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
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
$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
a minor modification: 'makhunk' is now more efficient.
From jkf Wed May 5 20:56:40 1982
To: local-lisp
Subject: Opus 38.16
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
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
... 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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,
____________________
9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
SRI Int'l, and Univ. of Calif.
9
"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.
9
9
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 Tue Nov 2 00:39:57 1982
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
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
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
[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
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:53:39 1982
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
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
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
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
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)
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:17:12 1982
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
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
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
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
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)
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
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
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
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
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
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)
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
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
>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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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 Mon Jan 31 20:29:51 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 AA04834; 31-Jan-83 20:29:51-PST (Mon)
To: CARR@UTAH-20
Cc: franz-friends@UCBVAX
In-Reply-To: Your message of 28 Jan 1983 0912-MST
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 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
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
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 Mon Jan 31 22:44:43 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 AA01976; 31-Jan-83 22:44:43-PST (Mon)
To: CARR@UTAH-20
Cc: franz-friends@UCBVAX
In-Reply-To: Your message of 28 Jan 1983 0912-MST
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 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
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 UCBKIM:jkf Tue Feb 1 11:34:04 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 AA02111; 1-Feb-83 11:34:04-PST (Tue)
To: franz-friends@ucbvax
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 UCBKIM:jkf Tue Feb 1 12:05:33 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 AA02854; 1-Feb-83 12:05:33-PST (Tue)
To: franz-friends@ucbvax
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 UCBKIM:jkf Tue Feb 1 12:26:37 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 AA03162; 1-Feb-83 12:26:37-PST (Tue)
To: franz-friends@ucbvax
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 UCBKIM:jkf Tue Feb 1 12:53:16 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 AA03661; 1-Feb-83 12:53:16-PST (Tue)
To: franz-friends@ucbvax
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 UCBKIM:jkf Tue Feb 1 13:52:06 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 AA05054; 1-Feb-83 13:52:06-PST (Tue)
To: franz-friends@ucbvax
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
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 mike@rand-unix Wed Feb 2 06:07:11 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 AA24743; 2-Feb-83 06:07:11-PST (Wed)
To: franz-friends@BERKELEY
Cc: mike@RAND-UNIX
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 mike@rand-unix Wed Feb 2 06:42:41 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 AA25024; 2-Feb-83 06:42:41-PST (Wed)
To: franz-friends@BERKELEY
Cc: mike@RAND-UNIX
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 mike@rand-unix Wed Feb 2 07:09:17 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 AA25231; 2-Feb-83 07:09:17-PST (Wed)
To: franz-friends@BERKELEY
Cc: mike@RAND-UNIX
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 mike@rand-unix Wed Feb 2 07:38:51 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 AA25505; 2-Feb-83 07:38:51-PST (Wed)
To: franz-friends@BERKELEY
Cc: mike@RAND-UNIX
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
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
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
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
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
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
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
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)
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
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.