[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: franz-friends@mit-mc
- From: Kim.fateman at Berkeley
- Date: Fri, 19 Feb 82 20:25:11 GMT
- Original-date: 19 Feb 1982 12:25:11-PST
FUGUE Notes
An occasional publication of the
Franz Lisp User Group under Unix and Eunice (FUGUE)
Number 1 (March, 1982)
edited by Richard J. Fateman
University of California
Berkeley CA 94720
USA
fateman@berkeley
_1. _W_e_l_c_o_m_e!
It seemed about time to publish the first of these
newsletters, since we have accumulated a suite of short com-
positions, and moved on to Opus 38. We would also like to
relay to others such information as has been forwarded to
us. The reports of projects at Berkeley (and elsewhere) may
strike sympathetic chords with other research.
_1._1. _H_o_w _m_a_n_y _p_l_a_y_e_r_s _a_r_e _w_e?
It is hard for us to know how many people are using
Franz Lisp. Franz Lisp has been distributed to at least 250
UNIX 4.1BSD sites, many of which have multiple CPUs. There
are an estimated 750 VAX 11/780 and 11/750 systems capable
of running Franz Lisp under UNIX. There are probably a few
dozen sites using Franz under Eunice, a UNIX simulation
package developed by David Kashtan at SRI. Judging from the
FUGUE mailing lists there are at least 150 people interested
in Franz News. (There are 100 non-Berkeley names on the
Arpanet list "franz-friends@mit-mc" and some of those names
are in fact mailing lists on other machines. There are about
40 additional sites requiring postal service.) Some are
undoubtedly intent on cheering or jeering from the side-
lines, and some may be mail junkies, but many users (includ-
ing the students who must write programs in Franz Lisp for
class work) are not represented directly.
While we at Berkeley can afford active communication
with only a handful of sites, we know of a few dozen users
who have various application programs running in Franz.
_1._2. _A_n _i_n_v_i_t_a_t_i_o_n
We invite our colleagues who are designing alternative
Lisp or Lisp-like systems to provide comments in future
____________________
9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
SRI Int'l, and Univ. of Calif.
9
newsletters. In particular, we hope to see information on
Interlisp, NIL, T, Ylisp, PSL, and "Common Lisp" for the
VAX.
_1._3. _T_h_e _s_t_r_u_c_t_u_r_e _o_f _t_h_i_s _n_e_w_s_l_e_t_t_e_r
We have no particular format in mind for this
newsletter, although we suspect the headings (e.g. bugs,
fixes) will re-appear in the future. For this issue, we
mention some of the applications written on top of Franz in
sections below. Future editions of this newsletter, will,
we hope, describe other applications, or perhaps highlight
one already mentioned.
_2. _W_h_a_t'_s _N_e_w?
Since the earliest release of Franz, there have been
several additional chapters added to the manual, and possi-
bly interesting new reports of Lisp applications. These are
(1) _C_M_U_e_d_i_t, _C_M_U_t_o_p_l_e_v_e_l, _C_M_U_d_e_b_u_g_g_i_n_g: Is this new? It was
in 4.1BSD, but may not be known to you all. Included
are a somewhat streamlined version of the Interlisp
structure editor, a history-keeping top-level, and some
front-end to the debugging system.
(2) _F_P: An implementation of John Backus' Functional Pro-
gramming notation. Written by Scott Baden at Berkeley,
it is described in a mostly machine-reproducible memo
available with the code.
(3) _P_E_A_R_L: A simple and efficient data base system for
artificial intelligence natural language programs, from
the school of Prof. Robert Wilensky at Berkeley. It is
up and running at Fairchild. Watch this space for
PHRAN, a phrase analysis program.
(4) _C_G_O_L: This is a replacement for the lisp reader which
provides an infix syntax for arithmetic, iteration,
(etc), an extensible parser for whatever was left out,
and for the fun of it, a fierce lesson in software
bootstrapping technology. CGOL is, of course, written
in CGOL. Vaughn Pratt is the author, although John
Foderaro at Berkeley did the bootstrap. The documenta-
tion is available in a separate memo (and in machine
readable form with the code.)
(5) _F_R_L: Frame Representation Language: (Roberts and Gold-
stein, MIT), was moved from Maclisp to Franz Lisp by
Steve Rosenberg and Douglas Lanam, working at Lawrence
Berkeley Laboratory, and refined since then at Hewlett
Packard Research Center, where they now work.
9
9
(6) _M_a_c_s_y_m_a: Macsyma is an algebraic manipulation system,
originating primarily with the work done by the Mathlab
Group at MIT, and transported to the VAX by Richard
Fateman, Keith Sklower, and John Foderaro. It is
available currently by first signing a test-site agree-
ment with MIT, and then obtaining a tape (from Berke-
ley).
(7) _A_I _P_r_o_g_r_a_m_m_i_n_g A package of programs providing compa-
tibility with the Lisp dialect used in the text "Artif-
icial Intelligence Programming" by Charniak, Riesbeck,
and McDermott, has been developed by Brown University
(under the baton of Matt Kaplan). A revised and illus-
trated manual "Franz Lisp ... The Manual" describing
the Brown variations is being maintained by Graeme
Hirst. Many features seem to be in the style of UCI
lisp, which is also supplied by a library file of func-
tions. (DE took the FUN out of DEFUN).
(8) _A_d_v_i_s_e: The advice-taking system from Interlisp has
been converted to run under Franz by Lisa Rau at Berke-
ley. Advise uses the CMU version of the Interlisp edi-
tor, and thus is slightly different in its "location"
performance.
(9) _P_r_o_l_o_g: There appear to be several places working on
Prolog interpreters or Prolog-to-Lisp translators. We
do not yet have one on hand, but would consider adopt-
ing one.
(10) _I_n_t_e_r_l_i_s_p _C_o_m_p_a_t_i_b_i_l_i_t_y: There seem to be a number of
people working on translation aids. We have as a
starting point, a number of functions which can be read
into the compiler to help it gobble DEFINEQ's, for
example. We hope others working in this area will
volunteer more code.
_3. _A_v_a_i_l_a_b_i_l_i_t_y
Some readers may be curious as to how changes to Franz
will be promulgated. We are attempting to set up an Arpanet
site, perhaps at Berkeley, which will support anonymous
login for file transfer. Then persons able to tap into the
Arpanet or Csnet can obtain fresh copies of source, and
perhaps even binary code. If you receive this note via com-
puter network, you will hear of progress. Most people
"off-net" should get periodic new releases as the Berkeley
Software Distribution progresses from 4.1 to 4.2. For peo-
ple who cannot wait (We expect the successor to 4.1BSD to
appear in September, 1982) or others, typically Eunice
sites, who do not get "nBSD" we will continue to make mag-
netic tapes as needed. As in the past we will charge $200 as
a tape copying fee, including one hard-copy of the
documentation. This charge is for the copying service, not
the software, and we have no objection to a recipient making
further copies and redistributing. In particular, we have no
objection to SRI giving out versions of Franz in combination
with Eunice. If others would care to distribute tapes at
lower cost, we would be pleased to cooperate.
So far as possible, we will attempt to distribute work-
ing versions of programs which appear to be generally use-
ful, which are given to us in machine readable format along
with documentation, and without restriction as to further
distribution.
_4. _P_r_o_j_e_c_t_s _a_t _B_e_r_k_e_l_e_y
This section mentions a few of the continuing projects
at Berkeley. This is not intended to be complete.
(1) James Larus is working on a version of Masterscope for
Franz with the essential difference that the Ingres
relational data base system is being used instead of an
ad-hoc lisp system. This may make it possible to deal
with much larger program profiles, or it may be unac-
ceptably slow. A side effect will be a set of routines
for interfacing to Ingres.
(2) Various students are working on graphics interfaces for
Franz. While an "Alto Terminal" system was constructed
at CMU, very few others (perhaps no others) can make
use of it because of the hardware requirements. We
have two BBN BitGraph terminals (768 by 1024 bits)
which can be used for line or raster graphics,audio
output, etc. While there may be, at the moment, even
fewer BitGraphs than Altos, at least we have them at
Berkeley. We expect to try out a few other
workstation/graphics systems (SUN) in the near future.
(3) Work being done by Scott Morrison will provide a super-
set of the "Common Lisp" specifications for numeric
data types. This will be based on the IEEE floating
point standard, currently software simulated on the VAX
via C programs.
(4) A group of students (David R. Barton, John Foderaro
and Neil Soiffer) are designing and implementing a pro-
gramming language which provides data abstraction in a
mathematical setting. This may be the basis for a
future algebraic manipulation system, and should have
other uses.
(5) Along with investigators at Lawrence Livermore Lab,
interactive systems for combined algebraic and numeric
manipulation are being set up. For example, minimiza-
tion via MINPACK numerical routines, and solution of
systems of ordinary differential equations, are being
studied. (people: D.C. Halbert, J.D. Halpern, T.
Einwohner).
A variety of programs for CAD and VLSI are being used,
in some cases, quite heavily, at Berkeley, but their authors
are not yet ready to distribute them. We understand that
Franz is being used for VLSI work at MIT and other loca-
tions. We hope to have more information prepared for a
later newsletter.
Similarly, there may be versions of AI programs
described later.
_5. _M_o_d_i_f_i_c_a_t_i_o_n_s _a_n_d _B_u_g _F_i_x_e_s
For Opus 38, there are some changes have been made to
setsyntax, the reader, the compiler, "format" These are
described in this section, written by John Foderaro.
_5._1. _B_u_g _F_i_x_e_s
The following bug fixes and new features are in the
latest Lisp system, Opus 38:
(1) If _s_y_s_c_a_l_l returns a small integer, it will do so from
the small integer table rather than allocating a new
integer.
(2) The _d_o function will properly handle the _g_o pseudo-
function.
(3) We added new functions <&, =& and >& which are like <,
= and > except their arguments must be fixnums. The
compiler can use this information to generate better
code.
(4) The function which handles &rest, &aux and &optional
forms within the formal variable list of a _d_e_f_u_n was
rewritten to recognize cases where it can avoid gen-
erating an lexpr.
(5) Two bugs in error handlers were found and fixed. One
was in the _e_r_r function itself, the other in the inter-
nal function _I-_t_h_r_o_w-_e_r_r which prevented _u_n_w_i_n_d-_p_r_o_t_e_c_t
from working correctly.
(6) It was discovered that any non local transfer through
an _u_n_w_i_n_d-_p_r_o_t_e_c_t would be continued as a *_t_h_r_o_w. This
was fixed.
9
9
(7) Some users didn't like the fact that the compiler
_p_u_r_c_o_p_y's literals. Thus there is a new symbol, $_p_u_r_-
_c_o_p_y_l_i_t_s which if nil will prevent the _p_u_r_c_o_p_y.
(8) _l_o_a_d will no longer disable garbage collection during a
load. The problem we ran into was that if a _d_u_m_p_l_i_s_p
was done during a load, the garbage collector would
remain disabled in the _d_u_m_p_l_i_s_ped file.
(9) We have improved the reader's error messages when it
read an incorrect period or right parenthesis.
(10) When allocating a large amount of space, the system no
longer tries to clear all of it with one movc5 instruc-
tion, because the hardware limits the range of that
instruction.
(11) The sharp-sign macro is now user extensible via the
_d_e_f_s_h_a_r_p function.
(12) We fixed a bug in _r_e_a_d_l_i_s_t so that if an error occurs
during the readlist, the file descriptor will be deal-
located.
(13) We fixed a bug in the internal character macro reader,
so that if the macro switches the port it is reading
from, this will not confuse the function which called
the macro.
(14) We fixed a bug in _f_a_s_l which caused the message "File
not in new fasl format" to occur when _f_a_s_ling in large
files. The problem was that the number of functions in
a large file would overflow the fixed sized table in
the _f_a_s_l function. The table size was increased, and a
more appropriate error message is printed should that
table overflow.
(15) We fixed a bug in bignum division which would rarely
occur when the leading bigit of the quotient and divi-
sor were the same.
(16) We fixed a bug in eval so that eval now protects the
definition of an interpreted function before starting
to execute it.
(17) We changed the lisp reader to treat each part of the
syntax code independently, thus allowing for more user
control over the reader and printer. This is explained
further below.
9
9
_5._2. _R_e_a_d_e_r _C_h_a_n_g_e
The most visible difference between Opus 37 and Opus 38
is the lisp reader. The syntax code for each character is
now viewed as a triple: character class, escape requirement,
and separatorness. The character class describes the syn-
tactic category to which the character belongs. The escape
requirement describes in which cases the character should be
escaped when printed. The separatorness says whether this
character separates symbols. To reduce user confusion, and
to make it easy to extend the reader at a future time, the
user describes a syntax class with a name rather than a
number. The user is free to add syntax classes if the
built-in ones are not sufficient. The _g_e_t_s_y_n_t_a_x function
will return the syntax code of a character as a name. The
function (_s_t_a_t_u_s _s_y_n_t_a_x _c) is now an error, because we want
to prevent the user from ever seeing the number associated
with the syntax name. Also, the actual numbers were forced
to change, so that the result of (_s_t_a_t_u_s _s_y_n_t_a_x _c) in Opus
38 is probably not what an existing program expects, and
rather than return a strange value, we felt it was better to
signal an error.
For compatibility, the _s_e_t_s_y_n_t_a_x function will accept
Opus 37 syntax code numbers as the syntax class, and will
convert them to the proper name; however we encourage all
code which uses numbers to convert to names.
_5._3. _N_e_w _p_a_c_k_a_g_e_s
The _f_o_r_m_a_t, _l_o_o_p, _C_G_O_L, and _d_e_f_s_t_r_u_c_t packages have
been moved to Franz from the Maclisp world.
_5._4. _O_t_h_e_r _m_o_d_i_f_i_c_a_t_i_o_n_s
(1) The garbage collector will now collect string space on
a page by page basis. It is possible to disable the
string garbage collection with a call to _s_s_t_a_t_u_s.
(2) The -a switch has be added to the lisp compiler. When
a file compiled with -a is _f_a_s_led into lisp, a property
is added to each function defined which describes the
source file of that function, when it was compiled and
how many arguments it expects.
_6. _O_t_h_e_r _m_a_c_h_i_n_e_s
A Motorola 68000 implementation of Franz is being
worked on by Keith Sklower. We expect that it will appear
first on a system supporting the UNIX operating system, and
that it may not support more than a 2 megabyte address space
unless memory mapping is available. There have been are
occasional flirts with the IBM world, especially UNIX sys-
tems such as supported by Amdahl, but there are no definite
plans at this time.
_7. _C_o_m_m_o_n _L_i_s_p
A new Lisp named "Common Lisp" based loosely on
MacLisp, MIT Lisp Machine Lisp("Zetalisp"), NIL, and SCHEME,
but incorporating yet newer features is a topic of study of
a group lead by Guy Steele Jr. at CMU. Guy has assembled a
voluminous draft manual, and several subgroups seem to be
working on (getting funding for) implementations for
machines as diverse as the IBM 4341, DEC20, MC68000, Perq1A
and of course the VAX. We expect that many, if not all, of
the features of Common Lisp, will be supported in Franz,
either by work at Berkeley, or elsewhere. We are however,
waiting until the manual is more settled and funding ques-
tions are resolved, to say more than this.
9
9