[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

                        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

_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.


newsletters. In particular, we hope to  see  information  on
Interlisp,  NIL,  T,  Ylisp,  PSL, and "Common Lisp" for the

_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.


(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-

(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"

(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

_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.

     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

(2)  The _d_o function will properly  handle  the  _g_o  pseudo-

(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

(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.


(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

(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-

(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.



_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.