lispnews

From jkf Tue Apr 13 00:12:22 1982
To: /na/doe/jkf/lispnews
Subject: new features
Status: RO

 In response to requests from franz users, these enhancements have been
made:

In Lisp 38.07,  if the lisp variable 'displace-macros' is set to non-nil,
then when a macro expansion is done by the evaluator, the resulting
expansion replaces the original call.  This means that macro expansion
is only done once.  

In Liszt 8.03, the 'function' function is open coded.  If you have
	(function (lambda ....))
in your code then the lambda expression is compiled as a separate function
and the result of the function call is a 'bcd' object which points
to that compiled lambda.



From jkf Sun Apr 18 13:16:46 1982
To: local-lisp
Subject: opus 38.09
Status: RO

 The new features of this version are:
	If the load function ends up fasl'ing in a file, then load will
  do what is necessary to insure that the new functions are linked in
  correctly. Previously, if you turned on the transfer tables with
  (sstatus translink on) or (sstatus translink t) and then fasl'ed in
  functions which already existed, the old versions of the functions
  would still be used, unless you did (sstatus translink on) yourself.
  Now this is done automatically.

      tyi now accepts a second argument which is the object to return
  upon eof.  -1 is the default.

     (pp-form 'g_obj ['p_port]) should be used instead of $prpr
 for pretty printing a form.

     The storage allocator and collector has been modified to add
 two new data types: vector and vector immediate.  They are not in
 their final form so I suggest that you not try to use them. 
 However, be on the lookout for garbage collection bugs.



From jkf Wed Apr 21 07:45:54 1982
To: local-lisp
Subject: liszt 8.04
Status: RO

  the new features of liszt 8.04 are:

1) init files:
    Before liszt begins compiling, it looks for an init file to load in.
    It first searches in the current directory, and then it searches
    your home directory (getenv 'HOME).
    It looks for file names:
	.lisztrc.o  .lisztrc.l  lisztrc.o lisztrc.l
    It loads only the first one it finds.

2) interrupt handling
    If you interrupt liszt  (with ^C typically), it will remove its
    temporary file and exit.

3) preallocation of space
    It preallocates space in order to reduce the number of gc's done
    during compiling.

	
	


From jkf Wed Apr 21 13:47:50 1982
To: local-lisp
Subject: lisp opus 38.10
Status: RO

 lisp will now look for a lisprc in a way similar to liszt.

 It will first search in . and then in $HOME
 It will look for the file .lisprc or lisprc ending with .o, .l and then
just .lisprc or lisprc.

 Shortly, it will only look for files ending in .l and .o since we don't
want to encourage files with non-standard filename extensions.


 


From jkf Wed Apr 21 23:40:59 1982
To: local-lisp
Subject: lisp opus 38.11
Status: RO

 I finally got sick of showstack and baktrace and rewrote them in lisp,
rincorporating some of the features people have been requesting.
Showstack now works as follows:
	(showstack) : show all interesting forms.  Forms resulting from
		      the trace package are not printed as well as 
		      extraneous calls to eval.  In the form printed,
		      the special form <**> means 'the previous expression
		      printed'.  prinlevel and prinlength are set to 
		      reasonable values to prevent the expression from
		      getting too large
	(showstack t) : same as above but print all expressions.
	(showstack 5) : print only the first 5 expressions. of course, 5
		      is not the only possible numeric argument.
	(showstack lev 3) : set prinlevel to 3 before printing
	(showstack len 4) : set prinlength to 4 before printing
 the above arguments can be used in combination.

The default value of prinlevel is showstack-prinlevel, that of prinlength
is showstack-prinlength.  the default showstack printer is the
value of showstack-printer (default is 'print').

baktrace accepts the same arguments as showstack, but it ignores the
prinlevel and prinlength arguments.




From jkf Sat Apr 24 08:55:18 1982
To: local-lisp
Subject: lisp opus 38.12, liszt 8.05
Status: RO

  these changes and enhancements were made:

1) the function 'function' in the interpreter acts just like 'quote'
   In the compiler, 'function' will act like 'quote' unless the
   argument is a lambda expression, in which case liszt will replace
   the lambda expression with a unique symbol.  That unique symbol's
   function cell will contain a compiled version of the lambda 
   expression.   These changes will make Franz compatible with Maclisp
   type lisps, as far as the treatment of 'function'

2) Mechanisms were added to permit user written C or Fortran code to call 
   lisp code. Everything isn't quite ready yet.

3) Signal was fixed so that if you ask for a signal to be ignored, the
   operating system will be notified.  The correct way to fork a lisp
   is now:
	(cond ((fork) (signal 2 (prog1 (signal 2) (wait)))))

4) You can select the default function trace uses to print the arguments and
   results.  Just lambda bind trace-printer to the name of the function
   you want it to use.  The standard trace-printer sets prinlevel and
   prinlength to the values of trace-prinlevel and trace-prinlength before
   printing.  By default, trace-prinlevel is 4, and trace-prinlength is 5


   


From jkf Sun Apr 25 23:46:16 1982
To: local-lisp
Subject: lisp opus 38.13
Status: RO

  Functions 1+ and 1- are now part of the interpreter, rather than
being made equivalent to add1 and sub1.



From jkf Wed Apr 28 09:52:43 1982
To: local-lisp
Subject: Opus 38.14
Status: RO

  Has these new features:
	1) the message [load filename] will appear before load
	   reads in a lisp source file.  This can be disabled by
	   setting $ldprint to nil.
	2) a function 'truename' as been added.  It takes a port
	   and returns the name of the file associated with that port.
	   It returns a string if there is a file associated with
	   the port, otherwise it returns nil.



From jkf Wed Apr 28 10:36:34 1982
To: local-lisp
Subject: more on opus 38.14
Status: RO

 $ldprint is lambda bound to nil during the loading of the lisprc file.




From jkf Wed May  5 08:30:00 1982
To: local-lisp
Subject: opus 38.15
Status: RO

 a minor modification: 'makhunk' is now more efficient.


From jkf Wed May  5 20:56:40 1982
To: local-lisp
Subject: Opus 38.16
Status: RO

 A new function was added:
	(hunk-to-list 'h_hunk) 
	returns the elements of h_hunk as a list.

 Also, the error message printed when an oversized print name is encountered
has been improved.



From jkf Fri May  7 20:03:40 1982
To: local-lisp
Subject: Liszt version 8.06
Status: RO


 Local declarations are now supported.  You can say:
(defun foo (a b)
   (declare (special a))
   ... body ...)

and the special declaration for 'a' will affect the body of function
foo only.  The 'a' which is an argument to foo will also be special
in this case.    Declarations may be 
 1) at the top level, not within a function body.
 2) at the beginning of a  'lambda' body.
 3) at the beginning of a 'prog' body
 4) at the beginning of a 'do' body.

'the beginning' means either the first, second or third form in the body.
When the compiler is searching for declarations, it will not macroexpand.


 Fixnum declarations now have meaning.  If you do
	(declare (fixnum i j))
then
	(greaterp i  j)  will be converted to (>& i j)

 The declare function is now defined in the compiler.  Previously,
the only way to declare something was for the compiler to 'compile'
the declaration form.  Now, if you load or fasl in a file with
a declare statement in it, the declare statement will have the
proper effect in the compiler.


 (function (lambda () ...)), (function (nlambda () ...)) and
 (function (lexpr () ...))  are all supported.



From jkf Wed May 12 08:15:37 1982
To: local-lisp
Subject: Lisp Opus 38.17
Status: RO

 ... has a minor bug fix:  The port returned by 'fileopen' will now print
correctly.



From jkf  Tue May 25 06:18:04 1982
Date: 25-May-82 06:17:51-PDT (Tue)
From: jkf
Subject: opus 38.18
Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue)
To: local-lisp
Status: RO

  The msg macro will now evaluate all atom arguments except the ones 
for carriage control (N B).  Thus if you used (msg foo) you should
now use (msg "foo").



From jkf Thu May 27 08:29:29 1982
To: local-lisp
Subject: liszt 8.08
Status: RO

 Fixes a bug in the code which converts generic arithmetic to fixnum only
arithmetic.   Liszt was converting from generic to fixnum operators based on
the first argument only due to a typo in the code.

 


From jkf Wed Jun  9 07:25:19 1982
To: local-lisp
Subject: lisp Opus 38.20
Status: RO

  There is now a character macro for reading hexadecimal.
  #x1f = #X1f = #X1F = 31
  #x-1f = -31
  


From jkf Thu Jun 17 15:42:54 1982
To: local-lisp
Subject: Lisp Opus 38.21
Status: RO

  Has two routines for interfacing with termcap.  These routines were
written by morris djavaher and are meant to be called by lisp programs
which have yet to be installed.




From jkf  Tue Jun 22 09:09:25 1982
Date: 22-Jun-82 09:09:13-PDT (Tue)
From: jkf
Subject: opus 38.22
Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue)
To: local-lisp
Status: RO

  setq with no arguments will now return nil.
  


From jkf  Wed Jun 30 19:05:54 1982
Date: 30-Jun-82 19:05:32-PDT (Wed)
From: jkf (John Foderaro)
Subject: liszt 8.09
Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed)
To: local-lisp
Status: RO

  liszt will now look in 12 places for an init file when it starts up.
It will load in the first one it comes to only.
The files it looks for are:

  { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , }

 


From jkf  Tue Sep 14 08:53:03 1982
Date: 14-Sep-82 08:52:44-PDT (Tue)
From: jkf (John Foderaro)
Subject: lisp opus 38.26
Message-Id: <8208141553.9999@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999;
	14-Sep-82 08:53:03-PDT (Tue)
To: local-lisp
Status: RO

  Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx.  Now it reads
them (and other similar symbols) correctly.




From jkf  Sat Oct  2 15:15:48 1982
Date: 2-Oct-82 15:15:32-PDT (Sat)
From: jkf (John Foderaro)
Subject: lisp opus 38.27
Message-Id: <8209022215.10796@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796;
	2-Oct-82 15:15:48-PDT (Sat)
To: local-lisp
Status: RO

  If you set the variable top-level-print to a non nil value, then that
value will be used by the top-level to print out the result of the
evaluation.  This has effect in break loops too.
  For example, if you want the pretty printer to print out the top level
values, type  (setq top-level-print 'pp-form).


  


From jkf  Sun Oct  3 19:28:45 1982
Date: 3-Oct-82 19:28:29-PDT (Sun)
From: jkf (John Foderaro)
Subject: lisp opus 38.28
Message-Id: <8209040228.9829@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829;
	3-Oct-82 19:28:45-PDT (Sun)
To: local-lisp
Status: RO

 A modification has been made to the load function.
   Normally if you type (load 'x), the load function will first try to fasl
the file x.o and failing that it will try to load x.l
   If you (setq load-most-recent t),  and if x.l and x.o both exist, then
load will fasl or load the most recently modified file.
   The load-most-recent flag only has an effect if you type the filename
without a trailing .l or .o.




From jkf  Tue Oct  5 21:01:55 1982
Date: 5-Oct-82 21:01:33-PDT (Tue)
From: jkf (John Foderaro)
Subject: liszt 8.12, lisp 38.29
Message-Id: <8209060401.6358@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358;
	5-Oct-82 21:01:55-PDT (Tue)
To: local-lisp
Status: RO

  Liszt will now check that you are passing the correct number of arguments
to functions.   As a result, some files which have compiled without
complaint in the past may compile now with warnings or errors.  In this
note, I'll explain what the compiler knows, what it looks for in your
program, and how you can help the compiler understand your program.

  For each function, liszt either knows nothing about the the number of
arguments to a function, or it knows the minimum number of arguments, or the
maximum number of arguments, or both the minimum and maximum number of
arguments.   This information comes about in one of three ways:
  1) it is known when liszt starts (by virtue of a value stored under the
     fcn-info indicator on a function's property list)
  2) it is declared by the user, either via (declare (*arginfo ...))
     or (declare (*args ...)) [see below]
  3) it is determined when a (lambda) function is compiled.
     When a lambda is compiled, the compiler can easily figure out the
       minimum and maximum number of arguments.
     When an nlambda or lexpr function is compiled, the compiler doesn't
     make a guess as to how many arguments are expected.  The user should
     use the (declare (*args ...)) form to tell the compiler how many
     arguments are expected.
     For lexpr's generated via 'defun' using &optional and &rest keywords,
     the correct declaration is generated automatically.
Once liszt determines the number of arguments to a function, it uses that
information to check that the function is called with the correct number of
arguments.  It does not check calls to the function that occured before it
determined the correct number of arguments.  [This backward checking will
be added sometime in the future.]

  If liszt finds that a function is called with the wrong number of
arguments, it prints an informative message.  That message is a error if the
function being called is one which is open coded by the compiler. The
message is a warning otherwise.  The reason for the distinction is that
you are free to redefine functions not open coded by the compiler. If the
number of arguments is not correct, it may just be that the compiler's
database and your code are refering to two different functions.
If you redefine system functions, you should use the
(declare (*arginfo ...)) form to let the compiler know about the number
of arguments expected by your version of the functions.

  You can declare the number of arguments to functions using this form

(declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...))
  where each min or max is either a fixnum or nil (meaning "I don't know")
  
for example, here are some `correct' declarations:

(declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil)))
  
 explanation:
   (read 0 2) means that the function read expects between 0 and 2
   	arguments (inclusive).
   (cons 2 2) means that cons expects 2 arguments.
   (boole 3 nil) means that boole expects at least 3 arguments.
   (append nil nil) means that append expects any number of arguments,
      this is equivalent to (append 0 nil).
      

The *arginfo declaration is usually made at the top level of a file.

To declare the argument characteristics of the current function being
compiled use the '*args' declaration. It looks somewhat like the
*arginfo declaration.

It is best explained with examples

(def read
   (lexpr (n)
       (declare (*args 0 2))
       ... code for read
       ))

(def process
  (nlambda (x)
      (declare (*args 1 3))
      ... code for process
      ))

Note: the *args declaration is not needed for lambda's.



  If you get an error or warning which you believe is incorrect, it is
probably due to an incorrect database entry.  Please let me know and I will
fix it immediately.   I expect that there will be quite a few of these
errors because much of the database was built by hand.


     



From jkf  Fri Oct  8 12:55:45 1982
Date: 8-Oct-82 12:55:31-PDT (Fri)
From: jkf (John Foderaro)
Subject: lisp 38.30, liszt 8.13
Message-Id: <8209081955.4140@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140;
	8-Oct-82 12:55:45-PDT (Fri)
To: local-lisp
Status: RO

There are now three new functions for dealing with processes:
  *process
  *process-send
  *process-receive

 These functions are designed to replace the 'process' function, which, due
to its nlambda'ness, was difficult to use.  All of the above functions
are lambda's or lexpr's.

  See chapter 6 of the manual (its on-line) for the details of these
functions.  This is a quick summary:

  (*process-send 'st_command)
  tells the shell to run the command st_command concurrently, and returns
  a write-only port.  Characters written to this port will appear at
  the standard input of st_command.
  example:
     (setq p (*process-send "mail jkf"))
     (print 'HiThere p)
     (close p)

     
  (*process-receive 'st_command)
  tells the shell to run st_command concurrently, and returns a
  read-only port.  Characters written to the standard output by
  st_command will be available by reading from the given port.
  Characters written on the standard error by st_command will
  appear on lisp's the standard error (the terminal most likely).
  example:
    ; to see if foo is logged in:
    (setq p (*process-receive "u"))
    (do ((user (read p '**eof**) (read p '**eof**)))
        ((eq '**eof** user) (print 'Not-Logged-In))
	(cond ((eq 'foo user) (print 'Is-Logged-In))))
    (close p)


  (*process 'st_command ['g_readp ['g_writep]])
  this is the general function which process, *process-send and
  *process-receive call.  If called with one argument it
  starts the new process and waits for it to end, e.g:
  (*process (concat "vi " filename))
  In this case *process return the exit code of the process.

  The g_readp and g_writep arguments, if given, tell *process to
  run the process concurrently.  If g_read is non nil then
  *process will return a port just like *process-receive.
  If g_writep is non-nil, then *process will set up a pipe like
  *process-send.
  *process will return a list of the form
    (readport writeport process-id)
    where readport and writeport will only be a port if g_readp
    or g_writep are non nil.


 A little know fact about processes is that  a process, once started,
cannot die and disappear until its parent asks about its status.
Take the mail example given above:
     (setq p (*process-send "mail jkf"))
     (print 'HiThere p)
     (close p)
after the mail process finishes it work, it will attempt to die, returning
an integer called the 'exit status'.  However until the lisp program
asks about its status the mail process will remain in existence
in a Zombie state, somewhere between life and death. ps will show this:

  PID TT STAT  TIME COMMAND
 3876 p0 Z     0:01 <exiting>

A user is only allowed a small number of processes, so if you continue
to generate processes and leave them around as Zombies, you will eventually
run out of processes.  The way to let the Zombie die is to call
the wait function, e.g.
    -> (wait)
    (3876 . 0)
    -> 
this says that process 3876 died with exit status 0.

Also, when you exit lisp the shell will clean up the Zombies.

If you start a  process with (*process "vi foo") then lisp will wait
for it to complete before continuing, so you don't have to worry about
Zombies.  You only have to worry if you run a process concurrently,
such as when you use *process-send or *process-receive.

      
       
      



From jkf  Tue Oct 12 10:44:22 1982
Date: 12-Oct-82 10:43:52-PDT (Tue)
From: jkf (John Foderaro)
Subject: lisp opus 38.31
Message-Id: <8209121744.29800@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
	id A29800; 12-Oct-82 10:44:22-PDT (Tue)
To: local-lisp
Status: RO

  new function:  (time-string ['x_time])
    if given no arguments, it returns the current time as a string.

    if given an argument, x_time, then it converts that argument to
      a time string and returns that string.
      The argument should represent the number of seconds since
      Jan 1, 1970 (GMT).

  note that this makes (status ctime) obsolete.
 


From jkf  Tue Oct 12 14:35:26 1982
Date: 12-Oct-82 14:34:10-PDT (Tue)
From: jkf (John Foderaro)
Subject: also in opus 38.31
Message-Id: <8209122135.5086@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
	id A05086; 12-Oct-82 14:35:26-PDT (Tue)
To: local-lisp
Status: RO

  If top-level-read is set to a non nil value, then the lisp
top level will funcall it to read a form for evaluation.
It will be funcalled with two arguments, a port and an eof marker.
top-level-read will be used in break levels too.
  Be very careful when setting top-level-read because if you set it
to an illegal value, there is no way to correct it.





From jkf  Tue Oct 19 18:54:18 1982
Date: 19-Oct-82 18:54:02-PDT (Tue)
From: jkf (John Foderaro)
Subject: lisp tags
Message-Id: <8209200154.195@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A00195; 19-Oct-82 18:54:18-PDT (Tue)
To: franz-friends
Status: RO

  We also use vi style tags so emacs users and vi users can share the same
tags file.  Rather than modify ctags, we use this shell script:

#!/bin/csh 
# make a tags file for lisp source files.
# use:
#	lisptags foo.l bar.l baz.l ... bof.l
# generate the file 'tags'
#
awk -f /usr/local/lib/ltags $* | sort > tags


where the file /usr/local/lib/ltags is

/^\(DEF/	{ print $2 "	" FILENAME "	?^" $0 "$?" }
/^\(def/	{ print $2 "	" FILENAME "	?^" $0 "$?" }



From jkf  Tue Oct 19 22:50:40 1982
Date: 19-Oct-82 22:50:29-PDT (Tue)
From: jkf (John Foderaro)
Subject: Lisp Opus 38.32, Liszt 8.14
Message-Id: <8209200550.3968@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A03968; 19-Oct-82 22:50:40-PDT (Tue)
To: local-lisp
Status: RO


Topic 1:
    liszt can now autoload macros.   If liszt encounters a symbol without
    a function definition but with a macro-autoload indicator on the
    property list, then the value of the indicator is a file to load which
    should define the macro.

    The interpreter's undefined function handler will also look for
    macro-autoload properties, thus you needn't give a symbol both an
    autoload and a macro-autoload property.

    The default lisp contains macro-autoload properties for the macros
    defstruct, loop and defflavor.

Topic 2:
    It is now possible to define 'compiler only macros' or cmacros.
    A cmacro acts like a normal macro, but will only be used by the
    compiler.   A cmacro is stored on the property list of a
    symbol under the indicator 'cmacro'.    Thus a function can
    have a normal definition and a cmacro definition.
    The macro 'defcmacro' has a syntax identical to 'defmacro' and
    creates cmacros instead of macros.
    For an example of the use of cmacros, see the definitions
    of nthcdr and nth in /usr/lib/lisp/common2.l

 Topic 3:
    If the form (foo ...) is macro expanded and the result also begins
    with the symbol foo, then liszt will stop macro expanding (previously
    it got into an infinite loop).
    
 Topic 4:
    The function nth has been added to Franz.
    (nth 'x_index 'l_list)
    returns the nth element of l_list, where the car of the list
    is accessed with (nth 0 'l_list)

    The macros (push 'g_value 'g_stack), and
    	       (pop 'g_stack ['g_into])
    have been added to franz.
    typical uses
      (setq foo nil)
      (push 'xxx foo)
      (push 123 foo)
      now foo = (123 xxx)
      (pop foo) returns 123
      now foo = (xxx)
      (pop foo yyy) returns xxx and sets yyy to xxx

      
 Topic 5:
    The version of Flavors written at Mit for Franz have been transported
    here.  Flavors is a system for doing object oriented programming in
    lisp.  The documentation for flavors in the Lisp Machine manual
    from Mit.  Since Lisp Machine manuals are rather scarce around here,
    perhaps we can find someone to make copies of the flavor chapter for
    those interested in it.  There is a description of the unique
    features of the Franz Flavors in /usr/lib/lisp/flavors.usage.
    As mentioned above, the flavors code will be autoloaded
    when you call 'defflavor' for the first time.
    Our local flavors expert is Eric Cooper (r.ecc).
 
    
    
    



From jkf  Fri Oct 22 15:46:51 1982
Date: 22-Oct-82 15:46:32-PDT (Fri)
From: jkf (John Foderaro)
Subject: lisp opus 38.34
Message-Id: <8209222246.5610@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A05610; 22-Oct-82 15:46:51-PDT (Fri)
To: local-lisp
Status: RO


  Franz lisp now has a form of closure called an fclosure.  A fclosure is a
compromise between a funarg and the type of functional object that we
currently have in Franz. In this short note, I'll explain through examples
what fclosures are and where you might use them, and finally describe the new
functions.  The fclosure system was designed to be compatible with the Lisp
Machine closures, so you may want to look at a Lisp Machine manual for more
information.  fclosure are related to closures in this way:
   (fclosure '(a b) 'foo) <==> (let ((a a) (b b)) (closure '(a b) 'foo))

A example of the use of fclosures:

->(setq counter 0)
0
->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
fclosure[1]

The function 'fclosure' creates a new type of object called a fclosure.
A fclosure object contains a functional object, and a set of symbols and
values for the symbols.  In the above example, the fclosure functional
object is (lambda (val) (setq counter (+ val counter)))
and the set of symbols and values just contains the symbol 'counter' and
zero, the value of counter when the fclosure was created.

When  a fclosure is funcall'ed:
  1) the lisp system lambda binds the symbols in the fclosure to their
     values in the fclosure.
  2) it continues the funcall on the functional object of the fclosure
  3) finally it un-lambda binds the symbols in the fclosure and at the
     same time stores the current values of the symbols in the fclosure.

To see what that means, let us continue the example:
-> (funcall x 32)
32
-> (funcall x 21)
53

Notice that the fclosure is saving the value of the symbol 'counter'.
Each time a fclosure is created, new space is allocated for saving
the values of the symbols.
If we executed the same fclosure function:
->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
fclosure[1]

We now have two independent counters:
-> (funcall y 2)
2
-> (funcall y 12)
14
-> (funcall x 3)
56

To summarize:

(fclosure 'l_vars 'g_funcobj)
 l_vars is a list of symbols (not containing nil)
 g_funcobj is lambda expression or a symbol or another fclosure

  examples: (fclosure '(foo bar baz) 'plus)
            (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #'
	   		which will make the compiler compile the
			lambda expression.


There are time when you want to share variables between fclosures.
This can be done if the fclosures are created at the time times using
fclosure-list:

(fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...])
  This creates a list of closures such that if a symbol appears in
  l_varsN and l_varsM then its value will be shared between the
  closures associated with g_funcobjN and g_funcobjM.

  example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y))
			             '(c a) '(lambda () (setq c a))))
	    (fclosure[4] fclosure[7])
	   -> (funcall (car x) 123)   ; set the value of a in the 1st fclosure
	   123
	   -> (funcall (cadr x))     ; read the same value in the 2nd fclosure
	   123


Other fclosure functions:

(fclosure-alist 'c_fclosure)
  returns an assoc list giving the symbols and values in the fclosure

(fclosurep 'g_obj)
  returns t iff g_obj is a fclosure

(fclosure-function 'c_fclosure)
  returns the functional object of the fclosure



Note: If a throw (or error) occurs during the evaluation of a fclosure,
 which passes control out of the fclosure, then current values of the
 symbols will not be stored.   This may be a bug.  We could set up
 an unwind-protect, but it would then take longer to funcall
 a fclosure.  If you think an unwind protect is important, let me know.

Note 2: you can also 'apply' a fclosure.



  


From jkf  Sat Oct 23 08:58:07 1982
Date: 23-Oct-82 08:57:53-PDT (Sat)
From: jkf (John Foderaro)
Subject: more on closures
Message-Id: <8209231558.21572@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A21572; 23-Oct-82 08:58:07-PDT (Sat)
To: local-lisp
Status: RO

  I sent the maryland people the flavors.usage file from mit so that they
could compare their implementation with mit's.   What follows is their
analysis.   Some of the differences between the two versions is due to
different schemes for getting around the fact that franz didn't have a form
of closure.   RZ has indicated that now that franz has fclosures, it may be
possible to use more of the 'official' lisp machine flavor code.  fclosures
will probably affect the maryland implementation too:
Date:     22 Oct 82 15:39:18 EDT  (Fri)
From:     Liz Allen <liz.umcp-cs@UDel-Relay>
Subject:  flavors
To:       jkf at Ucb-C70
Via:  UMCP-CS; 23 Oct 82 9:09-EDT

Wow, implementing closure in one day is amazing.  We had thought
about writing some kind of closure...  We've been discussing how
having closures would affect our code.  It might make it easier to
read and modify, but it might be less efficient.  Can you tell us
how your implementation works and what it looks like to a user?

About the MIT implementation.  Ours is probably better in a couple
of respects but probably loses a couple of places, too.  Pros:

	1.  With ours, there is no need to discard instances when
	redefining a flavor.  The only time this would be necessary
	is if the instance variables change which rarely happens
	since methods change much more often than the instance
	variables.  Without a structure editor, you tend to reload the
	file containing flavors in order to change a method.

	2.  We can compile files with flavors (he didn't say if you
	can compile MIT's Franz flavors) and when they are compiled
	they run *fast*.  Most of the overhead occurs at combine
	time and compiled flavors shouldn't have to be recombined.

	3.  We use hunks to store instance variables (actually, an
	instance is a hunk whose cxr 0 is the name of the flavor and
	whose cxr n (> 0) are the values of instance variables).  We
	pay a price at combine time since instance variable references
	in method code are replaced with cxr and rplacx calls (but MIT
	pays the same price in putting hash calls in the methods), but
	we win over MIT since the cxr calls are much faster than the
	hash table calls.  We do have to have "ghost" methods which
	are copies of methods containing different cxr calls when the
	referenced variables of a method don't align in flavors
	which inherit the method.  This, however, happens only
	rarely.

	4.  We handle getting and setting instance variables better
	than the MIT implementation -- we don't need to send a message
	and the syntax is much better.  We recently added the
	functions << and >> which get and set instance variables, eg:

		(<< foo 'instance-var)
	and
		(>> foo 'instance-var 'value)

	where foo is a flavor instance.

	5.  Our describe function has a hook which (if the variable
	*debugging-flavors* is set to non-nil) allows the user to
	follow pointers to any instances referenced in the describe.
	This is done by assigning to a variable (made from its unique
	id) the value of the instance.

Cons:

	1.  They implement more things from Lisp Machine flavors
	(like wrappers/whoppers, init-keywords), but we really haven't
	found the need for them.  We implement less closely to LM
	flavors, but in a way that's better suited to Franz Lisp.

	2.  We didn't implement the method table as a hash table, but
	there's no reason why we couldn't.

	3.  Things we don't have, but could easily implement include:
	describe-method, defun-method/declare-flavor-instance-variables,
	and storing flavor information in hunks instead of on the
	property lists.

	4.  We don't handle method types like :and and :or.  We just
	have primary/untyped methods and :before and :after daemons.

We have people reading our documentation.  After we get some feedback
from them, we'll send the tape and docs to you.  That should be early
next week.

				-Liz Allen and Randy Trigg







From jkf  Mon Oct 25 12:56:59 1982
Date: 25-Oct-82 12:55:44-PDT (Mon)
From: jkf (John Foderaro)
Subject: lisp Opus 38.35, liszt 8.15
Message-Id: <8209251956.17542@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A17542; 25-Oct-82 12:56:59-PDT (Mon)
To: local-lisp
Status: RO


New features:
 1) tilde-expansion:  franz will now expand filenames which begin with ~
	just like csh does.  It will only do the expansion if
	the symbol tilde-expansion has a non-nil value.  The default
	value for tilde-expansion is t.
	These functions do tilde expansion: If I've left any out, let
	me know:
	 load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir
	 sys:access, sys:unlink [these are new functions, see below]

 2) liszt will remove its temporary file if given a SIGTERM signal
    (SIGTERM is sent by default when you give the kill command from the shell)

 3) load will now print a helpful message if an read error occurs when it
    is reading a file.
    
 4) new functions:

     (lexpr-funcall 'function 'arg1 ... 'argn)
        This is a cross between funcall and apply.
	The last argument, argn, must be a list (possibly empty).
	The element of list argn are stacked and then the function is
	funcalled.
	For example:
	(lexpr-funcall 'list 'a 'b 'c '(d e f))
	is the same as
	(funcall 'list 'a 'b 'c 'd 'e 'f)
	
	Also
	(lexpr-funcall 'list 'a 'b 'c nil)
	is the same as
	(funcall 'list 'a 'b 'c)
 	
     (tilde-expand 'st_filename)
     returns: symbol whose pname is the filename, with a leading tilde
     	     expanded.  if st_filename doesn't begin with a tilde, it
	     just returns st_filename

     (username-to-dir 'st_name)
     returns: the home directory of the given user, if that user exists.
     	      Saves old information so doesn't have to keep searching
	      the passwd file.

     Some low level system functions.  These are listed here for completeness.
     The perform a function from the unix library (see the unix manual
      for details).
     (sys:getpwnam 'st_username)
       return passwd file info.
     (sys:access 'st_file 'x_mode)
     (sys:unlink 'st_file)


Bug fixes:
  1) patom will handle prinlevel and prinlength correctly.
  2) it is now safe for an interpreted function to redefine itself.
  3) the information return by 'evalframe' about a funcall'ed function
     is now correct.

  
  



From jkf  Mon Oct 25 14:57:00 1982
Date: 25-Oct-82 14:56:25-PDT (Mon)
From: jkf (John Foderaro)
Subject: 'if' macro: request for comments
Message-Id: <8209252157.21567@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A21567; 25-Oct-82 14:57:00-PDT (Mon)
To: local-lisp
Status: RO

  Would anyone object if we added a macro called 'if' to the default franz
system?   'if' is a common name and I want to make sure that it doesn't
break any existing code before I add it.

Some background:
 At mit the 'if' macro is used all over the place.
 Its form is
 	(if <predicate> <then-expr> [ <else-expr>])
	
 I've always felt that macros should make the code more readable and
 that the 'if' macro makes code more obscure because it isn't easy
 to tell in complicated 'if' expressions where the <then-expr>
 and <else-expr>'s begin.  Also, there is no provision for
 an 'elseif' expression.

 I wrote a macro called 'If' which uses keywords to separate clauses.
 (If <pred> 
    then <then-expr> 
  [elseif <pred> then <then-expr>]* 
  [else <else-expr>])

 These two macros are not incompatible.  one macro could do the job
 of both.  There is an ambigous case:
	(if p then x) could be (cond (p then) (t x))
			or (cond (p x))
 but it isn't likely that 'if' macro users would write something like
 that.

Thus I propose that we add a macro, if, which act's like 'If' if
its second arg is 'then' or like 'if' it the second arg is not 'then'
and there are two or three arguments.  Other cases would cause
an error.


	


From jkf  Mon Oct 25 22:37:24 1982
Date: 25-Oct-82 22:37:09-PDT (Mon)
From: jkf (John Foderaro)
Subject: opus 38.36
Message-Id: <8209260537.1666@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A01666; 25-Oct-82 22:37:24-PDT (Mon)
To: local-lisp
Status: RO

  I've added the 'if' macro to franz.  If you have any objections, it is still
not too late to voice them.
  I've also defined 'If' to be the same as 'if'.

  As I mentioned in my earlier request for comments, the 'if' macro is a
cross between the mit version and a locally written version using keywords.
The following documentation describes the various forms.
As you know, you can test out the 'if' macro by using apply. for example:

=> (apply 'if '(if a then b c  elseif d thenret else e))
(cond (a b c) (d) (t e))


;
;  This macro is compatible with both the crufty mit-version and
; the keyword version at ucb.
;
;  simple summary:
;   non-keyword use:
;	(if a b) ==> (cond (a b))
;	(if a b c d e ...) ==> (cond (a b) (t c d e ...))
;   with keywords:
;	(if a then b) ==> (cond (a b))
;	(if a thenret) ==> (cond (a))
;	(if a then b c d e) ==> (cond (a b c d e))
;	(if a then b c  else d) ==> (cond (a b c) (t d))
;	(if a then b c  elseif d  thenret  else g)
;		==> (cond (a b c) (d) (t g))
;
;   
;
;
; In the syntax description below,
;    optional parts are surrounded by [ and ],
;    + means one or more instances.
;    | means 'or'
;    <expr> is an lisp expression which isn't a keyword
;       The keywords are:  then, thenret, else, elseif.
;    <pred> is also a lisp expression which isn't a keyword.
; 
; <if-stmt> ::=  <simple-if-stmt>
; 	       | <keyword-if-stmt>
; 
; <simple-if-stmt> ::=  (if <pred> <expr>)
; 		      | (if <pred> <expr> <expr>)
; 
; <keyword-if-stmt> ::= (if <pred> <then-clause> [ <else-clause> ] )
; 
; <then-clause> ::=  then <expr>+
; 		   | thenret
; 
; <else-clause> ::=  else <expr>+
; 		   | elseif <pred> <then-clause> [ <else-clause> ]



  


From jkf  Tue Oct 26 09:20:25 1982
Date: 26-Oct-82 09:20:04-PDT (Tue)
From: jkf (John Foderaro)
Subject: no more jkfmacs
Message-Id: <8209261620.11552@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A11552; 26-Oct-82 09:20:25-PDT (Tue)
To: local-lisp
Status: RO


  Since Franz now has the push, pop, if and msg macros, there is no
reason for jkfmacs to exist.  I've removed the code in jkfmacs and
replaced it with a warning message which will be printed if you load it.
  If you used the jkfmacs version of 'push' you will have to go through
your code and switch the order of arguments.  The Franz version is
	(push value stack)
Also, the unpush macro, defined in jkfmacs, no longer exists: just use
pop with one argument.



From jkf  Wed Oct 27 20:35:07 1982
Date: 27-Oct-82 20:34:25-PDT (Wed)
From: jkf (John Foderaro)
Subject: liszt 8.16
Message-Id: <8209280335.27561@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A27561; 27-Oct-82 20:35:07-PDT (Wed)
To: local-lisp
Status: RO

  Back on May 6, a modification to liszt was made which turned 'declare'
into a user callable function which provided information to the compiler.
The purpose of the change was to permit one to 'load' a file containing
declarations, instead of 'include'ing it.  It turns out that this was a bad
idea since if the compiler were to evaluate an interpreted function with
local declarations, it would assume that those local declarations were
describing the current file being compiled.
   Thus declare has it old meaning: it is a no-op unless the compiler is
compiling the form.  If one really wants to actively declare something,
we've added the function 'liszt-declare', which looks just like declare
but can be evaluated within the compiler.

  If you are confused by all this, don't worry.  There is very little chance
that it will affect you.



From jkf  Fri Oct 29 09:34:11 1982
Date: 29-Oct-82 09:33:59-PDT (Fri)
From: jkf (John Foderaro)
Subject: cmacros
Message-Id: <8209291634.8411@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A08411; 29-Oct-82 09:34:11-PDT (Fri)
To: local-lisp
Status: RO

  A week ago, Joe Faletti mentioned that one problem with cmacros is that if
you redefine a function, the cmacro property stays around and thus the
redefinition of the function isn't communicate to the compiler.
  He suggested that whenever a function is defined (via 'def' or when fasl'ed
in) any cmacro properties should be remprop'ed.   I've been trying to think
of an alternative to this, but I can't think of one.  Unless someone
has a better idea, I'll implement his suggestion.
  This means that if you want to define the function 'foo' and a cmacro for
'foo', the cmacro definition must appear later in the file than 'foo's
definition.




From jkf  Fri Oct 29 10:11:36 1982
Date: 29-Oct-82 10:10:54-PDT (Fri)
From: jkf (John Foderaro)
Subject: LetS: An Expressional Loop Notation
Message-Id: <8209291711.9176@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A09176; 29-Oct-82 10:11:36-PDT (Fri)
To: local-lisp
Status: RO

  I've got a copy of a paper by Richard Waters (at mit) describing a system
for writing loops in lisp (and other languages).  Basically you describe the
loop in functional programming terms (similar to Backus's FP, or apl) and
the LetS package converts it into an iterative form for efficient execution
in lisp.
  We don't have the LetS code here to play with, and we probably won't be
able to get it for a while since our arpanet connection is hopelessly
clogged for anything but tiny messages.   However you might be interested in
stopping by my office and looking at the paper.




From jkf  Fri Oct 29 12:06:47 1982
Date: 29-Oct-82 12:06:08-PDT (Fri)
From: jkf (John Foderaro)
Subject: Re:  cmacros
Message-Id: <8209291906.12141@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A12141; 29-Oct-82 12:06:47-PDT (Fri)
To: baden, local-lisp
In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday)
Status: RO

  I could make it a 'Note'.  I would prefer not to make it a warning because
such redefinition is guaranteed to occur when the compiler compiles itself
and the lisp code part of the lisp system.



From fateman Sat Oct 30 09:17:49 1982
To: franz-friends
Subject: fugue # 2
Status: RO

                        FUGUE Notes

               An occasional publication of the
    Franz Lisp User Group under Unix and Eunice (FUGUE)

                  Number 2 (October, 1982)
                edited by Richard J. Fateman
                  University of California
                     Berkeley CA 94720
                            USA
                      fateman@berkeley

1.  Welcome!

     It seems  about time to publish  the  second  of  these
newsletters,  since  we  have  accumulated  a  number of new
items.  We would also like to relay to others such  informa-
tion as has been forwarded to us. The reports of projects at
Berkeley (and elsewhere) may strike sympathetic chords  with
other research.

2.  New programs

2.1.  OPS-5

     OPS-5 is a "production system" written by Charles Forgy
of  CMU.   It  appears to work just fine in Franz, and is in
wide use.  Interested persons may obtain copies of  documen-
tation and the program from Charles.Forgy@CMU-10A. ( Charles
Forgy, Computer Science Department, Carnegie-Mellon  Univer-
sity, Pittsburgh, PA  15213)

It is their policy to send it to anyone who wants it free of
charge.

2.2.  GLISP

     GLISP is a system which provides interesting linguistic
features for generic operations and data abstraction.  Writ-
ten by Gordon Novak at Stanford University,  it  was  origi-
nally  developed for Interlisp, but has been ported to other
lisps, including Franz.

2.3.  Flavors

     There are now two distinct implementations,  apparently
with  identical  functionally,  of "flavors" as appearing in
the MIT Lisp Machine software.  One is described in TR-1174,
____________________
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 Mon Nov  1 17:43:52 1982
Date:     29 Oct 82 12:04:24 EDT  (Fri)
From:     Liz Allen <liz.umcp-cs@UDel-Relay>
Subject:  Re:  Flavor system
To:       ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc
Cc:       randy.umcp-cs at UDel-Relay
In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley
Via:  UMCP-CS; 30 Oct 82 5:40-EDT
Status: RO

	Date: 25 October 1982 16:29-EDT
	From: ECC@MIT-MC@Berkeley
	Subject:  Flavor system
	To: FRANZ-FRIENDS at MIT-MC

	Can someone give me a pointer to the Franz flavor system
	developed by U. Maryland?  I am looking for information on how to
	FTP the files -- what machine, whether public, what files, etc.

Since the U. of Maryland is not (yet) an Arpanet host, you can't
FTP files directly from here.  We are right now completing some
documentation for all of our hacks -- including documentation for
some recent improvements for our flavors system.  When that
documentation is complete, we will be ready to distribute the
packages developed here.  Besides flavors, this includes a top
level called userexec which is based on INTERLISP's top level and
a production system called YAPS similar to but more flexible than
OPS5.

We are supposed to become an Arpanet host in a few months...  (Read
open ended period of time.)  Meanwhile, if you would like to get
our code, mail me a tape, and I will mail it back with the code and
documentation on it.  I'd appreciate it if someone would volunteer
to let other folks FTP the files from their machine until we do
become an Arpanet host.  My address is:

	Liz Allen
	Univ of Maryland
	Dept of Computer Science
	College Park MD 20783
	(301) 454-4247
	liz.umcp-cs@udel-relay

				-Liz



From jkf  Wed Nov  3 15:49:29 1982
Date: 3-Nov-82 15:48:50-PST (Wed)
From: jkf (John Foderaro)
Subject: lisp opus 38.40
Message-Id: <8210032349.16460@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A16460; 3-Nov-82 15:49:29-PST (Wed)
To: local-lisp
Status: RO

  putprop will now put new properties at the head of the property list.
  
  


From ecc@UCBARPA  Thu Nov  4 10:28:49 1982
Date: 4-Nov-82 10:19:26-PST (Thu)
From: ecc@UCBARPA (Eric C. Cooper)
Subject: Lisp song
Message-Id: <8210041819.24539@UCBARPA.BERKELEY.ARPA>
Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82])
	id A24537; 4-Nov-82 10:19:28-PST (Thu)
Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A00305; 4-Nov-82 10:28:49-PST (Thu)
To: local-lisp@kim
Status: O

[This has been forwarded from uucp through Xerox through info-lispm.]

>From decvax!utzoo!utcsrgv!roderick Mon Nov  1 14:24:35 1982

Another Glitch in the Call
------- ------ -- --- ----
   (Sung to the tune of a recent Pink Floyd song.)


We don't need no indirection
We don't need no flow control
No data typing or declarations
   Hey! Did you leave the lists alone?

Chorus:
   All in all, it's just a pure-LISP function call.

We don't need no side effect-ing
We don't need no scope control
No global variables for execution
   Hey! Did you leave those args alone?

(Chorus)

We don't need no allocation
We don't need no special nodes
No dark bit-flipping in the functions
   Hey! Did you leave the bits alone?

(Chorus)

We don't need no compilation
We don't need no load control
No link edit for external bindings
   Hey! Did you leave that source alone?

(Chorus, and repeat)

From jkf  Sat Nov 13 20:53:41 1982
Date: 13-Nov-82 20:53:16-PST (Sat)
From: jkf (John Foderaro)
Subject: lisp opus 38.41
Message-Id: <8210140453.490@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
	id A00490; 13-Nov-82 20:53:41-PST (Sat)
To: local-lisp
Status: O

  added functions:
  	(remq 'g_val 'l_list) - just like remove but uses eq instead of equal
	(command-line-args) - returns a list of the command line arguments
		when lisp was started.  This function will return
		only those arguments typed by the user, even if the
		lisp was started with the autorun feature (liszt -r).
	(sys:gethostname) - returns the name of the machine.
	(status domain) - returns 'ucb' here.



From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982
Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST
Date: 28 Nov 1982 11:47:28-EST
From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A
Subject: (random) problems
Status: RO

I am having two problems using (random) in Franz lisp.  The first problem is
that I can't find any way to set the seed.  Every time I enter lisp, the
generator is in the same state.  I have had to resort to cfasling a c
procedure that calls srand() (as (random) seems to be defined in c by a call
on rand()).  Is there a way to do this within lisp?  The other problem is
more serious.  The generator seems to generate tight cycles for (at least)
arguments that are small powers of 2.  For example, repeatedly executing
(random 2) yields the sequence 01010101..., and (random 4) yields
01230123....  These sequences apparently occur no matter to what value I set
the seed.  Does anyone one know what I could be doing wrong, or have a
working random number generator?


From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982
Status: O

From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982
Date:     28 Nov 82 22:40:14 EST  (Sun)
From:     Tim Maroney <tim.unc@UDel-Relay>
Subject:  rng
To:       franz-friends at Ucb-C70
Via:  UNC; 28 Nov 82 23:38-EST
Status: O

To the person who asked about random number generators and deficiencies
in (random) [I can't write mail to you for some reason]:

You're not doing anything wrong; that's the way the sucker works.
One good way to get random numbers is to do the syscall that gets
you the number of seconds since whenever-it-is, and use the mod
function. This is especially good for getting a random one or zero,
by using the evenp function.

					Tim Maroney
					tim@unc@udel-relay


From jkf  Tue Nov 30 09:21:10 1982
Date: 30-Nov-82 09:21:10-PST (Tue)
From: jkf (John Foderaro)
Subject: opus 38.42
Message-Id: <8210301721.11699@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
	id AA11699; 30-Nov-82 09:21:10-PST (Tue)
To: local-lisp
Status: O

  added: (sys:link 'oldname 'newname) that what the ln program does.

  changed: the order of arguments to the vset functions is now:
  	(vset 'vector 'index 'value).
	
	[This shouldn't affect anyone since vectors haven't been officially
	 released yet and won't be until I make one more major modification]

	setf now knows about vectors.  You can say
		(setf (vref 'vector 'index) 'value)
	and not have to worry about the order of arguments to vset.



From jkf  Tue Nov 30 10:42:00 1982
Date: 30-Nov-82 10:42:00-PST (Tue)
From: jkf (John Foderaro)
Subject: Re: opus 38.42
Message-Id: <8210301842.13143@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
	id AA13143; 30-Nov-82 10:42:00-PST (Tue)
To: jeffc, local-lisp
In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday)
Status: O

  It can't do symbolic links (I've only been adding system calls that I had
a use for).

  setf is a generalized setq.  The target can be an expression which locates
a value.  setf figures out how to store in the target.
for example:

  (setf x 3)        ==  (setq x 3)
  (setf (car x) 3)  == (rplaca x 3)
  (setf (get foo 'bar) 3) == (putprop foo 3 'bar)

the target must be something it has been 'taught' to understand, or it can
be a macro, in which case setf macro-expands it and takes another look.

The setf macro (and a list of targets it knows about is in
/usr/lib/lisp/common2.l)




From jkf@UCBKIM  Wed Dec  1 09:13:23 1982
Date: 1-Dec-82 09:13:03-PST (Wed)
From: jkf@UCBKIM (John Foderaro)
Subject: Random Numbers in Franz
Message-Id: <8211011713.3615@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
	id AA03615; 1-Dec-82 09:13:03-PST (Wed)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82])
	id A18406; 1-Dec-82 09:13:23-PST (Wed)
To: franz-friends@berkeley
Status: RO

Date: 29-Nov-82 15:56:09-PST (Mon)
From: alice!sola!mitch
Subject: Random Numbers in Franz
To: alice!ucbvax!franz-friends

In general, it is very bad practice to compute a random number between 0
and n by any expression such as (mod (random) n).  In fact, Franz's
random function does exactly that, returning the number generated by the
C function rand(3) modulo n.  This technique uses only the rightmost 
bits of successive calls to rand, and the righmost n bits of congruential
sequences (like that returned by rand(3)) have a period of AT MOST 2**n
(See Knuth vol.2 p. 12).  So using the rightmost two bits will indeed give
you sequences of at most period 4.  (If your lisp doesn't have this 
behavior, you're not using the standard rand.)

A better way to do it is to use the high order bits, by dividing the entire
range up into n pieces and then seeing where you fall.  (This method is
biased if n is of the same order as the range, though.)

The code I use is:


(or (getd '$old-random) (putd '$old-random (getd 'random)))

(defun random n
  (cond ((eq n 0) ($old-random))
	((fix (quotient (boole 1 ($old-random) #o 7777777777)
			(quotient #o 7777777777 (arg 1)))))))

		Mitch Marcus





From jkf  Thu Dec  2 08:04:37 1982
Date: 2-Dec-82 08:04:37-PST (Thu)
From: jkf (John Foderaro)
Subject: Franz Lisp distribution
Message-Id: <8211021604.14414@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
	id AA14414; 2-Dec-82 08:04:37-PST (Thu)
To: franz-friends, net-lang-lisp@k
Status: O


	Franz Lisp Distribution
	
  This note describes our distribution policy for Franz Lisp.

What is being distributed:
  We distribute only source code in order to keep the distribution
  small and relatively Unix independent.   Makefiles are provided to
  build the entire lisp system from source, even if you don't have
  a version of lisp running already.  This process takes about 3 cpu
  hours on a Vax 780.  [This version for the Vax only, a 68000 version
  is being worked on.  Contact ucbkim.sklower@berkeley or 
  ucbkim.layer@berkeley]

  The following source is provided:
    lisp interpreter, 
    compiler (liszt),
    cross reference program (lxref),
    lisp manual,
    and other utility programs:
       trace, step, debug, cmu library functions, (and other minor ones),
       and these packages from the MIT lisp library:
	    defstruct, loop, flavors. 
   	    [These programs are provided as a convenience to those who can't
	     access the arpanet and copy them.  There is no documentation for
	     them in the Franz Lisp manual.  The best source of documentation
	     is the Lisp Machine manual (available from MIT, Symbolics
	     or LMI)]

   Regarding Flavors:  there are two implementations of flavors for
	Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
	and one from the University of Maryland (contact person
	Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
	exactly like flavors on the Lisp Machine (due to differences between
	Lisp Machine lisp and Franz Lisp), and the implementations differ
	from each other.    We incorporated the Mit version into the
	standard distribution because the high bandwidth between here and
	MIT will insure that it keeps up to date with the current Franz.
	This is not to imply that it is the better implementation.
	We haven't had enough experience with flavors to judge.
	Those seriously interested in Flavors should contact Liz
	Allen and ask for the Tech Report on the Univ Of Maryland Flavors
	system.

What is the form of the distribution:
  The files are packaged in a giant (2.1Mbyte) shell script.  Running this
shell script through 'sh' will result in a directory tree.  A ReadMe file
in the current directory will contain instructions on building the lisp
system.  The shell script is broken into a number of smaller files.
The current distribution looks like:
% ls
total 2092
 195 opus38.40.aa	 195 opus38.40.ae	 195 opus38.40.ai
 195 opus38.40.ab	 195 opus38.40.af	 195 opus38.40.aj
 195 opus38.40.ac	 195 opus38.40.ag	 142 opus38.40.ak
 195 opus38.40.ad	 195 opus38.40.ah

The '38.40' means Opus 38, minor version 40.  These numbers may be different
by the time you get your distribution.  In order to extract the lisp
files from this shell script, you need only type:
	cat * | sh


To get a copy of the distribution:
  The distribution may be obtained either using FTP from an arpanet site,
or on a magnetic tape through the U.S Mail.

 Arpanet:
   The files are stored on the ucb-c70 (NCP) arpanet host in the
   directory /users/lisp/lispuser.  If you have an account on the ucb-c70,
   you are free to take FTP a copy of these files.
   If you do not have an account on the ucb-c70, send me (jkf@berkeley) a
   message and I will set up a temporary account for you.
   If you are on a TCP host, write me and we will set up an account on one
   of our Vax's for you to FTP the files.  Eventually we will have an
   anonymous login on a TCP machine.

 Mag Tape:
   In order to get a copy of the distribution mailed to you, send a check to
 cover our tape copying and mailing costs (fees are listed below).  We will
 purchase the mag tape and you are free to keep it.  Please do NOT
 send us a tape.

     Fees:
     		$50	- distribution tape mailed 3rd class
	    add $10	- a copy of the Lisp Manual (we will only
	       		  send one copy, you are free to photocopy it)
  	    add $7	- send tape via 1st class mail.

	     -or-
	     	$15	- for just a copy of the Lisp Manual

 The address to send checks to is 

	Keith Sklower
	EECS/Computer Science Division
	524 Evans Hall
	University of California
	Berkeley, CA  94720

 All checks should be made out to "Regents, University of California."
 We require pre-payment.  We will not invoice or process purchase orders.



Disclaimers:
    This distribution works on the latest versions of Unix running at
    Berkeley (4.1a).  We can't guarantee that it will work on older
    versions (although, if you are running 4.1, it is almost certain
    that it will work, but we have not verified it).
    VMS users who are using a typical Unix compatibility package will 
    probably not be able to build a lisp from this distribution unless they
    know a great deal about VMS and their compatibility package.
    At least one package (Eunice) supports Franz at this time.
    
Redistribution:
    If you get a copy of the distribution, you are free to give it to
    other people.  We appreciate being informed of new sites so they
    can be put on a mailing list (electronic and conventional).  This
    list is used to announce new releases.  To be put on this list,
    send U.S. Mail to Keith Sklower (address above) or to 
    franz-friends-request@berkeley or ucbvax!franz-friends-request



From jkf  Mon Dec  6 08:50:45 1982
Date: 6-Dec-82 08:50:45-PST (Mon)
From: jkf (John Foderaro)
Subject: opus 38.43
Message-Id: <8211061650.12951@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA12951; 6-Dec-82 08:50:45-PST (Mon)
To: local-lisp
Status: O

  The size of vectors is now recorded in bytes rather than longwords.
  We've imported a few more commands to deal with fclosures.
  (symeval-in-fclosure 'fclosure 'symbol)
  (set-in-fclosure 'fclosure 'symbol 'value)

  (let-fclosed vars function)
  



From jkf  Mon Dec 13 10:35:43 1982
Date: 13-Dec-82 10:35:43-PST (Mon)
From: jkf (John Foderaro)
Subject: enhancemants to trace
Message-Id: <8211131835.12160@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA12160; 13-Dec-82 10:35:43-PST (Mon)
To: local-lisp
Status: O

  The function 'retrace' will insure that all functions which should be
traced are indeed traced.   This will solve the problem of reloading
a file whose functions are traced.  After you load a file, you can
type (retrace) and those functions which became untraced during the loading
process, will be traced again.

  The top-level-print and top-level-read variables will now take effect
within a trace break.





From jkf  Tue Dec 14 12:40:41 1982
Date: 14-Dec-82 12:40:41-PST (Tue)
From: jkf (John Foderaro)
Subject: Re: #!, exec and lisp
Message-Id: <8211142040.10379@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA10379; 14-Dec-82 12:40:41-PST (Tue)
To: lime!burdvax!puder
Cc: franz-friends
In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon)
Status: O

   It is easy to make #! do a zapline.   If you have a recent version of
lisp, just execute:

(defsharp ! (x) (zapline))

(this could be put in your .lisprc, if you don't want to affect other 
people).    The problem with adding this to Franz by default is that the
sharpsign macro is shared by a number of lisps and few of them run under
Unix.   Therefore, few other lisps are going to want #! to be zapline.


  Regarding the -f switch:  The -f switch is used to communicate between the
bootstrap at the beginning of a fasl file and the lisp interpreter.  It
wasn't meant as a general 'fasl this file' switch for users to make use of.
The choice of '-f' was bad, it should have been something more unique like
'-- autorun' so that a user would be unlikely to type it.   We have avoided
assigning meanings to switches on lisp's command line because we want to give
each user the opportunity to assign whatever meaning he wants to whatever
switch he wants.   It isn't difficult to write a program to scan the command
line.

Re:
    The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be
    necessary, because the exec syscall supplies the full path name, because
    the shell has already done the path searching on the command name.  The
    only place that might have to be searched is the current directory.

This isn't true.  (argv 0) is the command that you typed, not the full path
name to the command.  Only by prepending all the directories in the
search list can you find the location of the command.


				---john foderaro
				


From jkf  Mon Jan 10 15:04:02 1983
Date: 10-Jan-83 15:04:02-PST (Mon)
From: jkf (John Foderaro)
Subject: opus 38.45
Message-Id: <8300102304.19240@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA19240; 10-Jan-83 15:04:02-PST (Mon)
To: local-lisp
Status: O

  showstack will again report correctly for compiled calls if the
transfer tables are unlinked (status translink nil).



From jkf  Mon Jan 10 19:46:06 1983
Date: 10-Jan-83 19:46:06-PST (Mon)
From: jkf (John Foderaro)
Subject: opus 38.46
Message-Id: <8300110346.24831@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA24831; 10-Jan-83 19:46:06-PST (Mon)
To: local-lisp
Status: O

 This version incorporates some fixes from mit.  You shouldn't notice
any differences but if you do, let me know.





From jkf  Wed Jan 12 09:03:32 1983
Date: 12-Jan-83 09:03:32-PST (Wed)
From: jkf (John Foderaro)
Subject: opus38.47
Message-Id: <8300121703.1981@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA01981; 12-Jan-83 09:03:32-PST (Wed)
To: local-lisp
Status: O

  The setf macro will now handle all car and cdr forms (i.e. c{ad}+r).
  Thanks to peter norvig for this.

  There is a new macro called 'defvar'.  It is used to declare special
variables and optionally to give them an initial value.  It is used
at top level in a file (outside of defuns).

forms:
(defvar foo)	; declares foo to be special
(defvar bar 3)	; declares bar to be special and when this file is read in
		; bar will be given the value 3 if it is unbound.
An advantage of '(defvar foo)' over '(declare (special foo))' is that if
a file containing defvars is loaded (or fasl'ed) in during compilation,
the variables mentioned in the defvar's will be declared special.  The only
way to have that effect with '(declare (special foo))' is to 'include'
the file.  

 There is a new macro, 'environment', which can be used at the beginning of
a file to specify what sort of environment this file needs in order to be
compiled or run.  For example:
(environment (compile eval) (files mymacros othermacros)
	     (compile) (syntax maclisp))

says that when compiling or loading into the interpreter, the files
mymacros and othermacros should be loaded (if they aren't loaded already).
When compiling, the maclisp syntax should be used.
The general form of 'environment' is:
   (environment when1 what1
   	        when2 what2
		...    ...
		whenN whatN)
the when's are a subset of (eval compile load), and the symbols have the
same meaning as they do in 'eval-when'.
The what's are either
	(files file1 file2 ... fileN)
		insure that the named files are loaded.  To see if fileX
		is loaded, it looks for a 'version' property under
		fileX's property list.  Thus to prevent multiple loading,
		you should put
		(putprop 'myfile t 'version) at the end of myfile.l
	(syntax type)
		type is either maclisp, intlisp, ucilisp, franzlisp
		This sets the syntax correctly.

There are additional macros to set of standard environments:
(environment-maclisp)  sets up the maclisp environment.  This is what
	you would get by using the -m switch to liszt.

(environment-lmlisp)  sets up the lisp machine environment. This is like
	maclisp but it has additional macros.

	
It is possible to add when's and what's to the specialized environments,
e.g.
 (environment-maclisp (compile eval) (files foo bar))



  



From norvig Wed Jan 12 13:12:45 1983
To: jkf local-lisp
Subject: defvar
Status: O

Shouldn't defvar take any number of arguments, like setq?  As it is,
(defvar a 1 b 2) sets a to 1, but ignores the other arguments.

From fateman Wed Jan 12 13:23:08 1983
To: jkf local-lisp norvig
Subject: Re:  defvar
Status: O

I suspect the extra arguments to defvar are used in other systems for
storage of documentation strings in appropriate places.  E.g.
(defvar dozen 12 "initially 12 except in the baker system when it is 13")
causes some association with defvar and documentation should be put on
a file.


From jkf  Wed Jan 12 14:25:02 1983
Date: 12-Jan-83 14:25:02-PST (Wed)
From: jkf (John Foderaro)
Subject: Re: defvar
Message-Id: <8300122225.13079@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA13079; 12-Jan-83 14:25:02-PST (Wed)
To: norvig, local-lisp
In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday)
Status: O

 fateman is correct that there is an optional third argument for
documentation.   We don't want to add multiple arguments because defvar
it will mean that code we write here can't be transported to
other lisp which only expect one defvar argument.



From jkf  Thu Jan 13 09:49:13 1983
Date: 13-Jan-83 09:49:13-PST (Thu)
From: jkf (John Foderaro)
Subject: liszt 8.17
Message-Id: <8300131749.331@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00331; 13-Jan-83 09:49:13-PST (Thu)
To: local-lisp
Status: O

 The vector reference functions are open coded.  These are
 	vref, vrefi-byte, vrefi-word, vrefi-long



From G:alpines  Thu Jan 13 20:31:34 1983
Date: 13 Jan 1983 20:24-PST
From: alpines@G   (Harry Weeks at Vax-Populi)
Subject: Franz on 68000's
Message-Id: <83/01/13 2024.733@Vax-Populi>
Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
	id AA12970; 13-Jan-83 20:28:37-PST (Thu)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA14908; 13-Jan-83 20:31:34-PST (Thu)
To: franz@BERKELEY
Cc: franz-friends@BERKELEY
Status: O

>Date: 13 Jan 1983 20:01-PST
From: G.alpines at Berkeley (Harry Weeks at Vax-Populi)
Subject: Franz on 68000's.
To: franz-friends-request@Berkeley
Message-Id: <83/01/13 2001.733@Vax-Populi>

Please put me on your mailing list for information concerning
implementation of Franz, esp. on 68000's, but I'd like to keep
informed generally as well.  Thanks.

					Harry Weeks
					Bytek
					1730 Solano Avenue
					Berkeley, CA 94707
					
					(415) 527-1157


From jkf  Sun Jan 16 21:22:54 1983
Date: 16-Jan-83 21:22:54-PST (Sun)
From: jkf (John Foderaro)
Subject: change to lisptags program
Message-Id: <8300170522.23656@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA23656; 16-Jan-83 21:22:54-PST (Sun)
To: local-lisp
Status: O

 lisptags will now surround the search string with /'s instead of ?'s
in order to be compatible with ctags.   Both types should work with vi,
emacs people will probably have to make a minor modification to their
tags.ml file.
  My version in ~jkf/elib/tags.ml.
 





From jkf  Tue Jan 18 16:43:23 1983
Date: 18-Jan-83 16:43:23-PST (Tue)
From: jkf (John Foderaro)
Subject: lisp opus 38.48, liszt 8.19
Message-Id: <8300190043.10935@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA10935; 18-Jan-83 16:43:23-PST (Tue)
To: local-lisp
Status: O

  This is a long message so I'll put the most important thing first, in case
you choose not to read the rest of the message:
  *** object files generated by liszt 8.19 will not run in any lisp
  *** older than 38.48.    Object files which were generated by
  *** liszt's before 8.19 will continue to work in the new lisp.


There were two major changes to lisp and liszt:
 1) compiled functions will test at runtime to make sure that they
    are passed the correct number of arguments.

 2) the lambda list keywords &optional, &rest and &aux are open compiled
    in an efficient manner.

I'll refresh your memory on what the possible forms are for the & keywords:

  the formal parameter list of a def has this form
  ( required-args
    [ &optional optional-arguments ]
    [ &rest rest-argument ]
    [ &aux  aux-arguments ])

 as in this example which shows all possible forms:

 (def foo 
   (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g)
    	(compute)))

   
 the meaning and forms of the various parts of the formal parameter list are:

 required-args: a sequence of n (zero or more) symbols which will be bound
 	to the first n actual arguments.

 optional-args:	a sequence of m (zero or more) symbols which will be
 	bound to the next m actual arguments if they are present, or
	to default values.
	the forms of an optional argument are:
	
	foo	- bind foo to the argument if it present, otherwise bind it
		  to nil
	(foo (expr)) - bind foo to the argument if it is present, otherwise
		evaluate (expr) and bind foo to the result.

	(foo (expr) foo-p)  - bind foo to the argument if it is present, 
		otherwise evaluate (expr) and bind foo to the result.
		Also, bind foo-p to t if the argument is present, otherwise
		bind foo-p to nil.  foo-p will be treated like an &aux
		variable (see below) but it should NOT be declared in the
		&aux list!

  rest-arg : a single symbol which will be bound to a list of the rest of the
  	arguments.  This list is cons'ed up each time the function is called.

  aux-args : these args are just like arguments to let or prog within the
  	function body so this & keyword isn't really necessary (but there
	are few things in lisp that really are necessary).

	the forms of the aux arg are:

	foo - bind foo to nil
	(foo (expr))  - evaluate (expr) and bind foo to the result.



The compiler understands the &keywords but the interpreter does not.  'def'
will convert a form with &keywords to a lexpr which is almost equivalent.
The differences are:
    The interpreted form, being a lexpr, is allowed to use the 'arg'
	function.  The compiled form, even with optional args,
	is not a lexpr and thus 'arg' is illegal.

    The order that &aux variables are lambda bound is slightly different
        between interpreted and compiled code.  As long as default
	expressions reference no formal parameters after them in the
	formal parameter list, there should be no problems.

    The interpreted version will not check for the correct number of
        arguments.

Local functions cannot have &keywords.	

If you have any questions on this, send me mail.  This change should
only break functions which expect a variable number of argument and
which don't declare the fact using &optional programs.  There may be,
of course, implementation errors.  If you notice anything unusual
please let me know right away.  The old compiler will be
in /usr/ucb/oliszt for a while.



	
    
	



From layer  Thu Jan 20 01:55:55 1983
Date: 20-Jan-83 01:55:55-PST (Thu)
From: layer (Kevin Layer)
Subject: liszt 8.20
Message-Id: <8300200955.17788@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA17788; 20-Jan-83 01:55:55-PST (Thu)
To: local-lisp
Phone: (415) 652-2405
Status: O

    There are now three new command line features for liszt:

    1. -E <s-expr>, where <s-expr> will be evaluated before compilation
       starts.  For example, the setting of constants can be done in this way:

	   liszt -E '(setq foobar "***foobar-string***")' foobar.l

       and in the file being compiled, foobar is accessed as '#.foobar.

    2. -I <include-file>, where <include-file> will be loaded (via load)
       before compilation starts.

    3. A combination of the -S and -o switches will set the .s file, as in:

        liszt -S -o foo.vax.s foo.l

      where previously, the -S determined the name of the .s file (foo.s in
      the above example).
      


From jkf  Thu Jan 20 19:42:38 1983
Date: 20-Jan-83 19:42:38-PST (Thu)
From: jkf (John Foderaro)
Subject: some mods to liszt 8.20
Message-Id: <8300210342.7334@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA07334; 20-Jan-83 19:42:38-PST (Thu)
To: local-lisp
Status: O

 the -E and -I flags are now -e and -i
 there may be more than one -i flag given on the command line.
 


From fateman Thu Jan 20 20:20:31 1983
To: local-lisp
Subject: fame, if not fortune
Status: RO

In the latest Scientific American, Feb. 1983, Hofstader's column
is the first of several on the programming language "lisp".  He
mentions the particular dialect he is using .... Franz !

From wilensky  Thu Jan 20 20:57:27 1983
Date: 20-Jan-83 20:57:27-PST (Thu)
From: wilensky (Robert Wilensky)
Subject: Re: fame, if not fortune
Message-Id: <8300210457.8824@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA08824; 20-Jan-83 20:57:27-PST (Thu)
To: fateman, local-lisp
In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday)
Status: RO


On the other hand, being referenced by Hofstader is a dubious honor.


From UCBKIM:jkf  Fri Jan 21 08:15:04 1983
Date: 21-Jan-83 08:11:01-PST (Fri)
From: UCBKIM:jkf (John Foderaro)
Subject: test message, ignore
Message-Id: <8300211611.18650@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA18650; 21-Jan-83 08:11:01-PST (Fri)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA24887; 21 Jan 83 08:09:27 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA18766; 21-Jan-83 08:15:04-PST (Fri)
To: franz-friends@BERKELEY
Status: O

 This will give our mailer a chance to tell me how many of our franz friends
are no longer reachable.



From JTSCHUDY@USC-ISIE  Sat Jan 22 16:42:19 1983
Date: 22 Jan 1983 1634-PST
From: JTSCHUDY@USC-ISIE
Subject: MAILINGLIST ADDITION
Message-Id: <8300230037.1747@UCBVAX.BERKELEY.ARPA>
Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA01747; 22 Jan 83 16:37:17 PST (Sat)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA18903; 22-Jan-83 16:42:19-PST (Sat)
To: franz-friends@BERKELEY
Status: O

Hi!  My name is Jim.  I am presently attending the Naval Post Graduate
School in Monterey California.  I am in the Air Force  enrolled  in  a
DOD  sponsored  graduate  degree in Command Control and Communications
Systems Technology.

i  would  like  to  be  added to your mailing list.  My net address is
JTSCHUDY at ISIE.

Thanks - Jim.
-------


From jkf  Sat Jan 22 17:38:41 1983
Date: 22-Jan-83 17:38:41-PST (Sat)
From: jkf (John Foderaro)
Subject: opus 38.49
Message-Id: <8300230138.20020@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA20020; 22-Jan-83 17:38:41-PST (Sat)
To: local-lisp
Status: O

  A longstanding bug in the determination of the number of free dtpr objects
has been found and fixed.  The effect of this bug was that the function
which is responsible for allocating more memory pages didn't allocate
enough dtpr pages because it thought that there were a large number of
cells free.



From MCLINDEN@RUTGERS  Mon Jan 24 10:33:14 1983
Date: 24 Jan 1983 1324-EST
From: Sean McLinden  <MCLINDEN@RUTGERS>
Subject: Franz Lisp and floating point accelerator
Message-Id: <8300241825.19602@UCBVAX.BERKELEY.ARPA>
Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA19602; 24 Jan 83 10:25:06 PST (Mon)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA27143; 24-Jan-83 10:33:14-PST (Mon)
To: franz-friends@UCBVAX
Status: O


  Has anyone determined if a floating point accelerator speeds up
 Vax Franz Lisp jobs in any significant fashion?

  Pointers would be appreciated.

  Sean McLinden
  Decision Systems Lab
-------

From mike@rand-unix  Mon Jan 24 18:47:03 1983
Date: Monday, 24 Jan 1983 15:34-PST
From: mike@RAND-UNIX
Subject: emacs interface to franz?
Message-Id: <8300250008.58@UCBVAX.BERKELEY.ARPA>
Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00058; 24 Jan 83 16:08:36 PST (Mon)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00921; 24-Jan-83 18:47:03-PST (Mon)
To: franz-friends@BERKELEY
Status: O


Does anyone have a snazzy interface to emacs for franz?  

Thanks,
  Michael


From @udel-relay.ARPA,@UDel-Relay:Tim@UPenn.UPenn  Tue Jan 25 16:29:19 1983
Date: 25 Jan 1983  9:58-EST
From: Tim Finin <Tim.UPenn@UDel-Relay>
Subject: emacs interface to franz?
Message-Id: <8300260022.29320@UCBVAX.BERKELEY.ARPA>
Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA29320; 25 Jan 83 16:22:57 PST (Tue)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA01561; 25-Jan-83 16:29:19-PST (Tue)
Return-Path: <Tim@UPenn.UPenn@UDel-Relay>
To: mike@Rand-Unix
Cc: franz-friends@BERKELEY
Via:  UPenn; 25 Jan 83 19:21-EST
Status: O


We have a simple interface from Franz to Emacs, but I much prefer to go the
other way, i.e. run Franz as a inferior job under Emacs.  I believe there
are several Emacs packages which allow one to run inferior jobs in an Emacs
window (I have my own which is, unfortunately totally undocumented). Some of
the benefits of this set up include:

    - one has all of the text editing functions available in Emacs
    - one has many lisp-based editing functions available in Emacs
      (thru mock-lisp packages like electriclisp)
    - one has a history of the session in the editing buffer
    - one has an environment which supports multiple concurrent
      processes running in seperate windows.
    - it is very easy to experiment with new interface features such as
      symbol completion and re-evaluation of previously issued commands
    
Tim
    

From CARR@UTAH-20  Fri Jan 28 08:19:08 1983
Date: 28 Jan 1983 0912-MST
From: Harold Carr <CARR@UTAH-20>
Subject: franz distribution
Message-Id: <8300281615.20646@UCBVAX.BERKELEY.ARPA>
Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA20646; 28 Jan 83 08:15:18 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA16991; 28-Jan-83 08:19:08-PST (Fri)
To: franz-friends@UCBVAX
Status: O

What is the distribution policy?

I work for a company that has opus 36 and is now currently running opus 37.
Here at the University of Utah we are running opus 38.04. Is it OK to
make a tape of the University's 38.04 to bring my company more up to
date? Do I have to make it more formal by signing a transfer agreement
or by obtaining the release directly from Berkeley?

                              Thanks in advance,
                                 Harold Carr
                                CARR@UTAH-20
-------

From UCBKIM:jkf  Fri Jan 28 15:09:32 1983
Date: 28-Jan-83 08:34:33-PST (Fri)
From: UCBKIM:jkf
Subject: Re: franz distribution
Message-Id: <8300281634.17319@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA17319; 28-Jan-83 08:34:33-PST (Fri)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA02275; 28 Jan 83 14:58:37 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00402; 28-Jan-83 15:09:32-PST (Fri)
To: CARR@UTAH-20
Cc: franz-friends@UCBVAX
In-Reply-To: Your message of 28 Jan 1983 0912-MST
Status: O

  Here is our current distribution policy.  This differs a bit from
the one sent out a month ago [in particular, we now have anonymous ftp]

				    -[Fri Jan 28 08:31:45 1983 by jkf]-
	Franz Lisp Distribution
	
  This note describes our distribution policy for Franz Lisp.

What is being distributed:
  We distribute only source code in order to keep the distribution
  small and relatively Unix independent.   Makefiles are provided to
  build the entire lisp system from source, even if you don't have
  a version of lisp running already.  This process takes about 3 cpu
  hours on a Vax 780.  [This version for the Vax only, a 68000 version
  is being worked on.  Contact ucbkim.sklower@berkeley or 
  ucbkim.layer@berkeley]

  The following source is provided:
    lisp interpreter, 
    compiler (liszt),
    cross reference program (lxref),
    lisp manual,
    and other utility programs:
       trace, step, debug, cmu library functions, (and other minor ones),
       and these packages from the MIT lisp library:
	    defstruct, loop. 
   	    [These programs are provided as a convenience to those who can't
	     access the arpanet and copy them.  There is no documentation for
	     them in the Franz Lisp manual.  The best source of documentation
	     is the Lisp Machine manual (available from MIT, Symbolics
	     or LMI)]

   Regarding Flavors:  there are two implementations of flavors for
	Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
	and one from the University of Maryland (contact person
	Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
	exactly like flavors on the Lisp Machine (due to differences between
	Lisp Machine lisp and Franz Lisp), and the implementations differ
	from each other.    The MIT version cannot be distributed by 
	us (yet) due to licensing problems.   If you have a Lisp Machine
	Source license from Symbolics, you should be able to get a copy
	from MIT.
	For a Tech Report on Maryland flavors, write to Liz Allen.

What is the form of the distribution:
  The files are packaged in a giant (2.1Mbyte) shell script.  Running this
shell script through 'sh' will result in a directory tree.  A ReadMe file
in the current directory will contain instructions on building the lisp
system.  The shell script is broken into a number of smaller files.
The current distribution looks like:

total 2089
 489 -rw-r--r--  1 jkf        500003 Jan 26 11:33 opus38.50.aa
 489 -rw-r--r--  1 jkf        500002 Jan 26 11:35 opus38.50.ab
 489 -rw-r--r--  1 jkf        500047 Jan 26 11:37 opus38.50.ac
 489 -rw-r--r--  1 jkf        500007 Jan 26 11:38 opus38.50.ad
 133 -rw-r--r--  1 jkf        136038 Jan 26 11:39 opus38.50.ae

The '38.50' means Opus 38, minor version 50.  These numbers may be different
by the time you get your distribution.  In order to extract the lisp
files from this shell script, you need only type:
	cat * | sh


To get a copy of the distribution:
  The distribution may be obtained either using FTP from an arpanet site,
or on a magnetic tape through the U.S Mail.

 Arpanet:
   The files are stored on the arpanet host 'ucb-vax' [ if you have an out
   of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
   internet number is 10.2.0.78].
   You can login as 'anonymous'.   Use your name as the password.
   The files are in the subdirectory pub/lisp.
   
   For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.

 Mag Tape:
   In order to get a copy of the distribution mailed to you, send a check to
 cover our tape copying and mailing costs (fees are listed below).  We will
 purchase the mag tape and you are free to keep it.  Please do NOT
 send us a tape.

     Fees:
     		$50	- distribution tape mailed 3rd class
	    add $10	- a copy of the Lisp Manual (we will only
	       		  send one copy, you are free to photocopy it)
  	    add $7	- send tape via 1st class mail.

	     -or-
	     	$15	- for just a copy of the Lisp Manual

 The address to send checks to is 

	Keith Sklower
	EECS/Computer Science Division
	524 Evans Hall
	University of California
	Berkeley, CA  94720

 All checks should be made out to "Regents, University of California."
 We require pre-payment.  We will not invoice or process purchase orders.



Disclaimers:
    This distribution works on the latest versions of Unix running at
    Berkeley (4.1a).  We can't guarantee that it will work on older
    versions (although, if you are running 4.1, it is almost certain
    that it will work, but we have not verified it).
    VMS users who are using a typical Unix compatibility package will 
    probably not be able to build a lisp from this distribution unless they
    know a great deal about VMS and their compatibility package.
    At least one package (Eunice) supports Franz at this time.
    
Redistribution:
    If you get a copy of the distribution, you are free to give it to
    other people.  We appreciate being informed of new sites so they
    can be put on a mailing list (electronic and conventional).  This
    list is used to announce new releases.  To be put on this list,
    send U.S. Mail to Keith Sklower (address above) or to 
    franz-friends-request@berkeley or ucbvax!franz-friends-request



From Kim:fateman  Sun Jan 30 02:12:28 1983
Date: 28 Jan 83 08:32:08 PST (Fri)
From: Kim:fateman (Richard Fateman)
Subject: Re:  franz distribution
Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA21039; 28 Jan 83 08:31:58 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA10132; 30-Jan-83 02:12:28-PST (Sun)
To: CARR@UTAH-20
Cc: franz-friends@ucbvax
Status: O

Our policy is that you may move copies of Franz elsewhere
without notifying us.  We continue to be interested in sharing anything
you or your company wish to provide us, in suggestions, programs, etc.


From UCBCAD:pettengi  Sun Jan 30 02:33:52 1983
Date: 28-Jan-83 10:54:51-PST (Fri)
From: UCBCAD:pettengi (Rob Pettengill)
Subject: emacs interface to franz?
Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
	id AA26156; 28-Jan-83 10:54:51-PST (Fri)
Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00374; 28 Jan 83 12:53:44 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA10578; 30-Jan-83 02:33:52-PST (Sun)
To: mike@rand-unix, franz-friends@ucbvax
Cc: pettengi@UCBCAD
Status: O

	While I was at TI I used a very nice interface that let one start up
a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
under our VMS.  Try Kashtan@SRI-AI.

Rob Pettengill
E-Systems, Dallas, Tx.

From UCBKIM:jkf  Sun Jan 30 02:44:27 1983
Date: 28-Jan-83 08:34:33-PST (Fri)
From: UCBKIM:jkf (John Foderaro)
Subject: Re: franz distribution
Message-Id: <8300281634.17319@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA17319; 28-Jan-83 08:34:33-PST (Fri)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA02275; 28 Jan 83 14:58:37 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA10772; 30-Jan-83 02:44:27-PST (Sun)
To: CARR@UTAH-20
Cc: franz-friends@UCBVAX
In-Reply-To: Your message of 28 Jan 1983 0912-MST
Status: RO

  Here is our current distribution policy.  This differs a bit from
the one sent out a month ago [in particular, we now have anonymous ftp]

				    -[Fri Jan 28 08:31:45 1983 by jkf]-
	Franz Lisp Distribution
	
  This note describes our distribution policy for Franz Lisp.

What is being distributed:
  We distribute only source code in order to keep the distribution
  small and relatively Unix independent.   Makefiles are provided to
  build the entire lisp system from source, even if you don't have
  a version of lisp running already.  This process takes about 3 cpu
  hours on a Vax 780.  [This version for the Vax only, a 68000 version
  is being worked on.  Contact ucbkim.sklower@berkeley or 
  ucbkim.layer@berkeley]

  The following source is provided:
    lisp interpreter, 
    compiler (liszt),
    cross reference program (lxref),
    lisp manual,
    and other utility programs:
       trace, step, debug, cmu library functions, (and other minor ones),
       and these packages from the MIT lisp library:
	    defstruct, loop. 
   	    [These programs are provided as a convenience to those who can't
	     access the arpanet and copy them.  There is no documentation for
	     them in the Franz Lisp manual.  The best source of documentation
	     is the Lisp Machine manual (available from MIT, Symbolics
	     or LMI)]

   Regarding Flavors:  there are two implementations of flavors for
	Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
	and one from the University of Maryland (contact person
	Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
	exactly like flavors on the Lisp Machine (due to differences between
	Lisp Machine lisp and Franz Lisp), and the implementations differ
	from each other.    The MIT version cannot be distributed by 
	us (yet) due to licensing problems.   If you have a Lisp Machine
	Source license from Symbolics, you should be able to get a copy
	from MIT.
	For a Tech Report on Maryland flavors, write to Liz Allen.

What is the form of the distribution:
  The files are packaged in a giant (2.1Mbyte) shell script.  Running this
shell script through 'sh' will result in a directory tree.  A ReadMe file
in the current directory will contain instructions on building the lisp
system.  The shell script is broken into a number of smaller files.
The current distribution looks like:

total 2089
 489 -rw-r--r--  1 jkf        500003 Jan 26 11:33 opus38.50.aa
 489 -rw-r--r--  1 jkf        500002 Jan 26 11:35 opus38.50.ab
 489 -rw-r--r--  1 jkf        500047 Jan 26 11:37 opus38.50.ac
 489 -rw-r--r--  1 jkf        500007 Jan 26 11:38 opus38.50.ad
 133 -rw-r--r--  1 jkf        136038 Jan 26 11:39 opus38.50.ae

The '38.50' means Opus 38, minor version 50.  These numbers may be different
by the time you get your distribution.  In order to extract the lisp
files from this shell script, you need only type:
	cat * | sh


To get a copy of the distribution:
  The distribution may be obtained either using FTP from an arpanet site,
or on a magnetic tape through the U.S Mail.

 Arpanet:
   The files are stored on the arpanet host 'ucb-vax' [ if you have an out
   of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
   internet number is 10.2.0.78].
   You can login as 'anonymous'.   Use your name as the password.
   The files are in the subdirectory pub/lisp.
   
   For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.

 Mag Tape:
   In order to get a copy of the distribution mailed to you, send a check to
 cover our tape copying and mailing costs (fees are listed below).  We will
 purchase the mag tape and you are free to keep it.  Please do NOT
 send us a tape.

     Fees:
     		$50	- distribution tape mailed 3rd class
	    add $10	- a copy of the Lisp Manual (we will only
	       		  send one copy, you are free to photocopy it)
  	    add $7	- send tape via 1st class mail.

	     -or-
	     	$15	- for just a copy of the Lisp Manual

 The address to send checks to is 

	Keith Sklower
	EECS/Computer Science Division
	524 Evans Hall
	University of California
	Berkeley, CA  94720

 All checks should be made out to "Regents, University of California."
 We require pre-payment.  We will not invoice or process purchase orders.



Disclaimers:
    This distribution works on the latest versions of Unix running at
    Berkeley (4.1a).  We can't guarantee that it will work on older
    versions (although, if you are running 4.1, it is almost certain
    that it will work, but we have not verified it).
    VMS users who are using a typical Unix compatibility package will 
    probably not be able to build a lisp from this distribution unless they
    know a great deal about VMS and their compatibility package.
    At least one package (Eunice) supports Franz at this time.
    
Redistribution:
    If you get a copy of the distribution, you are free to give it to
    other people.  We appreciate being informed of new sites so they
    can be put on a mailing list (electronic and conventional).  This
    list is used to announce new releases.  To be put on this list,
    send U.S. Mail to Keith Sklower (address above) or to 
    franz-friends-request@berkeley or ucbvax!franz-friends-request



From Kim:fateman  Mon Jan 31 19:30:20 1983
Date: 28 Jan 83 08:32:08 PST (Fri)
From: Kim:fateman (Richard Fateman)
Subject: Re:  franz distribution
Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA21039; 28 Jan 83 08:31:58 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA03502; 31-Jan-83 19:30:20-PST (Mon)
To: CARR@UTAH-20
Cc: franz-friends@ucbvax
Status: O

Our policy is that you may move copies of Franz elsewhere
without notifying us.  We continue to be interested in sharing anything
you or your company wish to provide us, in suggestions, programs, etc.


From UCBCAD:pettengi  Mon Jan 31 19:55:02 1983
Date: 28-Jan-83 10:54:51-PST (Fri)
From: UCBCAD:pettengi (Rob Pettengill)
Subject: emacs interface to franz?
Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
	id AA26156; 28-Jan-83 10:54:51-PST (Fri)
Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00374; 28 Jan 83 12:53:44 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA03987; 31-Jan-83 19:55:02-PST (Mon)
To: mike@rand-unix, franz-friends@ucbvax
Cc: pettengi@UCBCAD
Status: O

	While I was at TI I used a very nice interface that let one start up
a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
under our VMS.  Try Kashtan@SRI-AI.

Rob Pettengill
E-Systems, Dallas, Tx.

From Kim:fateman  Mon Jan 31 21:34:44 1983
Date: 28 Jan 83 08:32:08 PST (Fri)
From: Kim:fateman (Richard Fateman)
Subject: Re:  franz distribution
Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA>
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA21039; 28 Jan 83 08:31:58 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00642; 31-Jan-83 21:34:44-PST (Mon)
To: CARR@UTAH-20
Cc: franz-friends@ucbvax
Status: RO

Our policy is that you may move copies of Franz elsewhere
without notifying us.  We continue to be interested in sharing anything
you or your company wish to provide us, in suggestions, programs, etc.


From UCBCAD:pettengi  Mon Jan 31 22:12:30 1983
Date: 28-Jan-83 10:54:51-PST (Fri)
From: UCBCAD:pettengi (Rob Pettengill)
Subject: emacs interface to franz?
Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA>
Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
	id AA26156; 28-Jan-83 10:54:51-PST (Fri)
Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00374; 28 Jan 83 12:53:44 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA01266; 31-Jan-83 22:12:30-PST (Mon)
To: mike@rand-unix, franz-friends@ucbvax
Cc: pettengi@UCBCAD
Status: O

	While I was at TI I used a very nice interface that let one start up
a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
under our VMS.  Try Kashtan@SRI-AI.

Rob Pettengill
E-Systems, Dallas, Tx.

From UCBKIM:jkf  Tue Feb  1 10:35:21 1983
Date: 1-Feb-83 10:32:24-PST (Tue)
From: UCBKIM:jkf (John Foderaro)
Subject: multiple messages
Message-Id: <8301011832.599@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00599; 1-Feb-83 10:32:24-PST (Tue)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00473; 1 Feb 83 10:32:35 PST (Tue)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA00644; 1-Feb-83 10:35:21-PST (Tue)
To: franz-friends@ucbvax
Status: RO

  I'm sorry for the multiple messages.  The franz-friends mailing list is
huge and the machine which does the mailing is crashing often.  Our local
mail wizard informs me that if it crashes while in the middle of sending
mail it will not have a record of who it sent to before the crash.
  I hope you don't get too many copies of this message.
  
  



From mike@rand-unix  Wed Feb  2 05:33:01 1983
Date: Tuesday,  1 Feb 1983 15:06-PST
From: mike@RAND-UNIX
Subject: response to "emacs interface to franz?"
Message-Id: <8301021325.221@UCBVAX.BERKELEY.ARPA>
Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00221; 2 Feb 83 05:25:50 PST (Wed)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA24463; 2-Feb-83 05:33:01-PST (Wed)
To: franz-friends@BERKELEY
Cc: mike@RAND-UNIX
Status: RO


Here are the responses that I received to my question "What's out
there for emacs?"  


------- Forwarded Messages

Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983
Date: Mon 24 Jan 83 22:43:01-PST
From: Jay Lark <CSD.LARK@SU-SCORE.ARPA>
Subject: Re: emacs interface to franz?
To: mike@RAND-UNIX.ARPA
In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST

I'm sure you've probably received several messages similar to this one,
but just in case...

There exists the capability in Unix Emacs to run a process in its own
buffer.  Typein can be directed to the process, and output is just sent
right to the buffer.  This is an excellent way of running Lisp, because 
you get all of the nice Emacs features (paren balancing, local sexpr
editing) at essentially no cost.  I have been largely unsuccessful with
trying to run Emacs under Lisp.

The process package is part of the standard Unix Emacs distribution.

Jay Lark
-------


------- Message 2

Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983
Date: 25 Jan 1983 7:20-MST
From: Russ Fish <utah-gr!fish@UTAH-CS> (host 10.0.0.4)
Subject: Re: emacs interface to franz?
To: mike@RAND-UNIX
Cc: utah-gr!galway@UTAH-CS
In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST

We have been running our PSL (Portable Standard Lisp) in gemacs
(Gosling's emacs) windows for some time.  I suspect it would be a minor
hack to convert it to Franz, but haven't done it and am not a Franz
user.  I could mail you our .ml code if you wanted to undertake
converting it to Franz (or just using it for inspiration and hacking
your own) and distributing it to Franz folks.

It works like this:  The lisp process is associated with a gemacs
buffer/window.  In that window you can carry on a normal line-by-line
conversation, if you wish.  <CR> sends the current line, (back to mark,
which is left after the prompt) into the lisp.  We mostly use the PSL
in Rlisp syntax, which is algol-like, but this part of the code is just
a wrapping for the new-shell function in process.ml with appropriate
editting syntax set, so you could do the same with no work for any
Lisp.

You can send an expression, fn def, etc. from any other lisp-mode
window with a single keypress.  Echoing as input in the dialog window
is inhibited if a prefix arg is provided, so you don't have to look at
long exprs or fn defs again, just the lisp response.  

Sending multiple line exprs in response to a single prompt depends on
the fact that PSL numbers the prompts for history, like the c-shell.  A
gemacs mlisp output filter process monitors the output for toploop
prompts and feeds another line of input if the same prompt number comes
back, instead of printing the prompt.

The result is pretty classy.  You get the full many-window gemacs
editing environment with tags, etc. for random-access navigation and
just send chunks of code as you change them.  The extreme of usage is
"menu" like windows which contain debugging code in clusters rather
than sequences.  You select exprs with the cursor and send them in any
order.

We also provide key fns for the common case of sending single lines to
the toploop or single-character commands to the break-loop without
editting them into a buffer.

Best respond directly to me, since I am not on Franz-Friends.

-Russ Fish  (Fish@Utah-20, utah-cs!fish)



------- Message 3

Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983
Return-Path: <israel.umcp-cs@UDel-Relay>
Date:     25 Jan 83 15:13:51 EST  (Tue)
From: Bruce Israel <israel.umcp-cs@UDel-Relay>
Subject:  Re:  emacs interface to franz?
To: mike@RAND-UNIX
In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX
		<8300250008.58@UCBVAX.BERKELEY.ARPA>
Via:  UMCP-CS; 25 Jan 83 20:45-EST

We have a few franz<->emacs interfaces, but I'm not sure what you mean.
One is the process.ml package that comes with gosling's emacs (the emacs
that I assume you are talking about).  With this package, you can run
franz inside a window from within emacs and have the facilities of an
editor along with lisp.  The other thing we have is a local Franz
package called the load1 package.  This package was written for
compiling flavors (like in the lisp machine; another local package)
and has a function called vi.  (vi 'lisp-function) will call the
editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the
file which contains the definition of the lisp function, positioning
the editor at the point in the file where the function is defined.  Upon
exiting the editor, it asks you if you want to reload the modified file.
To edit a function from a file this way, the file must have been load1'ed
previously so that the info on where the function is stored and what type
it is will have been saved.  Load1 will distinguish between different
types of functions, ie. defflavors, defmethods, defmacros, defuns etc.
and will search for the correct definition in the file.  Is this what
you mean?  If you like I can send you the four or five files necessary.
- Bruce


------- Message 4

Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983
Date: 27 Jan 1983 09:44-EST
From: Carl.Ebeling@CMU-CS-VLSI
Subject: Re: emacs interface to franz?
To: mike@RAND-UNIX
Message-Id: <412526661/ce@CMU-CS-VLSI>
In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14    

I have an electric lisp package and process package for emacs.  It
includes 'zap-function-to-lisp' among other things.  It is for
Gosling's emacs and uses the subprocess facility.  I can mail them to
you if you like.
	Carl


------- End of Forwarded Messages

From UCBKIM:jkf  Wed Feb  2 08:19:19 1983
Date: 2-Feb-83 08:14:21-PST (Wed)
From: UCBKIM:jkf (John Foderaro)
Subject: multiple messages fixed?
Message-Id: <8301021614.25937@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA25937; 2-Feb-83 08:14:21-PST (Wed)
Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00384; 2 Feb 83 08:10:26 PST (Wed)
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA00477; 2 Feb 83 08:14:35 PST (Wed)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA26020; 2-Feb-83 08:19:19-PST (Wed)
To: franz-friends@ucbvax
Status: RO

 I've broken the franz-friends mailing list over two machines.  I hope that
this will fix the problem of mail to franz-friends crashing ucbvax every
thirty minutes.   If you get multiple copies of this message, please do not
tell me about it, I will already know.




From jkf  Thu Feb 10 21:45:17 1983
Date: 10-Feb-83 21:45:17-PST (Thu)
From: jkf (John Foderaro)
Subject: liszt 8.21
Message-Id: <8301110545.16021@UCBKIM.BERKELEY.ARPA>
Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA16021; 10-Feb-83 21:45:17-PST (Thu)
To: local-lisp
Status: O

  more functions open coded: vsize, vsize-byte, vsize-word,
  	vectorp, vectorip
	


From PSI.KROHNFELDT@UTAH-20  Fri Feb 11 15:09:11 1983
Date: 11 Feb 1983 1601-MST
From: Jed Krohnfeldt <PSI.KROHNFELDT@UTAH-20>
Subject: cfasl
Message-Id: <8301112302.7475@UCBVAX.BERKELEY.ARPA>
Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA07475; 11 Feb 83 15:02:05 PST (Fri)
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA07565; 11 Feb 83 15:06:37 PST (Fri)
Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
	id AA14422; 11-Feb-83 15:09:11-PST (Fri)
To: Franz-friends@UCBVAX
Status: O

I am having trouble using cfasl in franz 38.04.  I keep getting the
message "ld: /usr/ucb/lisp : no namelist".  Can anyone decipher this
for me?  Thanks...
-------

From apm@cmu-ri-isl  Mon Feb 14 07:31:54 1983
Date: 14 Feb 1983 10:24:21-EST
From: Andrew.Mendler@CMU-RI-ISL
Subject: franz lisp under5 vms 3.0
Message-Id: <8302141531.27879@UCBVAX.ARPA>
Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3)
	id AA27879; 14 Feb 83 07:31:54 PST (Mon)
Received: by UCBKIM.ARPA (3.310/3.3)
	id AA01172; 14 Feb 83 15:50:41 PST (Mon)
To: franz-friends@BERKELEY.ARPA
Status: O

Does anyone have a copy of Franz Lisp and the compiler that works under
VMS version 3.0?  

From @udel-relay:tim.unc@UDel-Relay  Mon Feb 14 02:52:18 1983
Date:     13 Feb 83 14:34:48 EST  (Sun)
From: Tim Maroney <tim.unc@UDel-Relay>
Subject:  cfasl: no namelist
Return-Path: <tim.unc@UDel-Relay>
Message-Id: <8302141052.25792@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3)
	id AA25792; 14 Feb 83 02:52:18 PST (Mon)
Received: by UCBKIM.ARPA (3.310/3.3)
	id AA02234; 14 Feb 83 16:18:42 PST (Mon)
To: franz-friends@BERKELEY.ARPA
Via:  UNC; 14 Feb 83 5:43-EST
Status: O

I don't seem to be able to write Jed Krohnfeldt, and this
answer is probably of general interest anyway. The message
"ld: no namelist" means that some well-meaning system admin
has stripped the lisp executable file to save space;
unfortunately, this makes the dynamic loading used by cfasl
impossible. Lisp will have to be recompiled (groan). No Franz
Lisp executable file should EVER be stripped.

Tim Maroney
tim.unc@udel-relay
decvax!duke!unc!tim

From Mark.Sherman@CMU-CS-A  Sat Feb 12 21:38:46 1983
Date: 13 February 1983 0034-EST (Sunday)
From: Mark.Sherman@CMU-CS-A
Subject: Space and Leakage
Message-Id: <13Feb83 003422 MS40@CMU-CS-A>
Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
	id AA07842; 12 Feb 83 21:38:46 PST (Sat)
Received: by UCBKIM.ARPA (3.310/3.3)
	id AA02341; 14 Feb 83 16:21:29 PST (Mon)
To: franz-friends@UCB-VAX
Status: O

Can someone tell me how the maximum amount of storage that franz
lisp uses is decided? I can force the size up to (about) 3050
pages (according to "ps") and then get the message "storage exhausted".
I have been told (and have seen) other jobs get substantially more
space; can franz get more pages as well? (I am using the cshell
and have already used the limit command to raise my process
size up to 32 megabytes, or so I think.)
 
I have also been told that the garbage collector leaks, that is,
not all of the garbage is really collected. Does anyone have good
ideas about how much (or fast) this happens, or if there is some way
to minimize the lost space?
 
(Please send responses directly to me as I am not on this list.)
                        -Mark Sherman (Sherman@CMU-CS-A)

From @udel-relay:Mac.uvacs.Virginia@UDel-Relay  Fri Feb 18 21:04:31 1983
Date:     18 Feb 83 12:42:40-EST (Fri)
From: Mac.uvacs@UDel-Relay
Subject:  global nonspecial variables
Return-Path: <Mac.uvacs.Virginia@UDel-Relay>
Message-Id: <8302190504.26020@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5)
	id AA26020; 18 Feb 83 21:04:31 PST (Fri)
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA00656; 21 Feb 83 01:59:26 PST (Mon)
To: FRANZ-FRIENDS@BERKELEY.ARPA
Via:  Virginia; 18 Feb 83 23:58-EST
Status: O

Does the Liszt compiler have any notion of global variables --
free variables with fast access, without any rebinding?

I think the MACLISP compiler has something like this for variables
beginning "**".

				Alex Colvin

				uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac
				csnet:mac@virginia
				arpa: mac.uvacs@udel-relay

From jkf@UCBKIM  Mon Feb 21 09:19:56 1983
Date: 21 Feb 83 09:19:43 PST (Mon)
From: jkf@UCBKIM (John Foderaro)
Subject: Re:  global nonspecial variables
Message-Id: <8302211719.2798@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA02798; 21 Feb 83 09:19:43 PST (Mon)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
	id AA13982; 21 Feb 83 09:11:52 PST (Mon)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA02805; 21 Feb 83 09:19:56 PST (Mon)
To: Mac.uvacs@UDel-Relay, FRANZ-FRIENDS@BERKELEY.ARPA
In-Reply-To: Your message of     18 Feb 83 12:42:40-EST (Fri)
Status: O

  I don't understand the distinction between what you call a global variable
and a special variable.   A special variable in Franz Lisp (and any other
shallow bound lisp) can be accessed rapidly and is only rebound if you
put it in a lambda, prog or do variable list.



From jkf@UCBKIM  Fri Feb 25 08:29:01 1983
Date: 25 Feb 83 08:28:45 PST (Fri)
From: jkf@UCBKIM (John Foderaro)
Subject: research position at edinburgh
Message-Id: <8302251628.528@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA00528; 25 Feb 83 08:28:45 PST (Fri)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
	id AA00867; 25 Feb 83 08:18:48 PST (Fri)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA00537; 25 Feb 83 08:29:01 PST (Fri)
To: franz-friends@BERKELEY.ARPA
Status: O


                    DEPARTMENT OF ARTIFICIAL INTELLIGENCE
                           UNIVERSITY OF EDINBURGH

                              RESEARCH FELLOW

A Research Fellowship is available within the Programming Systems Development
Group.  The post has been created specifically to provide a modern LISP system
for the Perq computer running under ICL MicroCode UNIX, and is funded by the
Science and Engineering Research Council.

Experience in implementing systems would be advantageous, as would be a
knowledge of LISP and C.  Access will be available to an SERC DECsystem-10
running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as
to Perqs.

The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds
sterling, according to age and experience.  The post is funded for a period of
two years from the date of appointment.

Further particulars of the post can be obtained from:

	Administrative Assistant
	Department of Artificial Intelligence
	University of Edinburgh
	Forrest Hill
	Edinburgh  EH1 2QL
	SCOTLAND
phone
	031-667-1011 x2554

or by contacting

	RAE%EDXA%UCL-CS@ISID		(Networks permitting)

Applications should be made by March 17th, 1983.




From layer  Sat Mar  5 20:12:57 1983
Date: 5 Mar 83 20:12:57 PST (Sat)
From: layer (Kevin Layer)
Subject: process function
Message-Id: <8303060412.18927@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA18927; 5 Mar 83 20:12:57 PST (Sat)
Phone: (415) 652-2405
To: local-lisp
Status: O

The process function now looks in the environment at the SHELL variable.
If present, it will use this as the default shell to execute your command.
If not present, csh and then sh are tried (in that order).


From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay  Tue Mar  8 06:04:10 1983
Date:  8 Mar 1983  2:32-EST
From: Susan Pintzuk <Pintzuk.UPenn@UDel-Relay>
Subject: lisp statistical packages
Return-Path: <Pintzuk.UPenn.UPenn@UDel-Relay>
Message-Id: <8303081401.AA13004@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14)
	id AA13004; 8 Mar 83 06:01:54 PST (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA08297; 8 Mar 83 06:04:10 PST (Tue)
To: franz-friends@BERKELEY.ARPA
Via:  UPenn; 8 Mar 83 3:49-EST
Status: O

do any franz-lisp packages exist which calculate mean, standard deviation,
%n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.?  if so, how
do i obtain a copy?

From jkf  Tue Mar  8 09:10:46 1983
Date: 8 Mar 83 09:10:46 PST (Tue)
From: jkf (John Foderaro)
Subject: opus38.56
Message-Id: <8303081710.9423@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA09423; 8 Mar 83 09:10:46 PST (Tue)
To: local-lisp
Status: O

  If $gcprint is set to a non nil value, then just before a garbage
collection is begun, the message 'gc:' will be printed on the tty.
As before, after the garbage collection is finished, the statistics
message in square brackets will be printed.



From fateman  Wed Mar  9 09:54:31 1983
Date: 9 Mar 83 09:54:31 PST (Wed)
From: fateman (Richard Fateman)
Subject: need a job 
Message-Id: <8303091754.14754@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA14754; 9 Mar 83 09:54:31 PST (Wed)
To: local-lisp
Status: O

porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP
computer?  Wanna live in Denver?  There is a recruiter in
town from Denelcor at Marriot Inn, Jim Holly.  There is an
ad posted on 5th floor bulletin board.

From jkf  Sat Mar 19 17:44:33 1983
Date: 19 Mar 83 17:44:33 PST (Sat)
From: jkf (John Foderaro)
Subject: liszt 8.24
Message-Id: <8303200144.25091@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA25091; 19 Mar 83 17:44:33 PST (Sat)
To: local-lisp
Status: O

  The vax and 68k versions of liszt have been combined into one set of
source files.  This is mainly a textual change, but some functions
in the compiler have been modified in reduce the machine dependent code.
Be on the lookout for strange errors.



From fateman  Tue Mar 22 20:52:11 1983
Date: 22 Mar 83 20:52:11 PST (Tue)
From: fateman (Richard Fateman)
Subject: T Lisp
Message-Id: <8303230452.5935@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA05935; 22 Mar 83 20:52:11 PST (Tue)
To: local-lisp
Status: RO

I have a preliminary manual for the T dialect of Lisp, created
at Yale.  It is being offered for sale by Cognitive Systems, Inc.
for $1000/CPU (educational price).  It offers features from Lisp
and Scheme.  It runs on VAX and Apollo 68000 systems.  

From jkf  Thu Mar 24 08:29:31 1983
Date: 24 Mar 83 08:29:31 PST (Thu)
From: jkf (John Foderaro)
Subject: liszt 8.25
Message-Id: <8303241629.6735@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA06735; 24 Mar 83 08:29:31 PST (Thu)
To: local-lisp
Status: O


  If you do this:

  liszt -x a/b/c.l -o x/y/z.o

  then the cross reference file will be put in x/y/z.x 
  Before this version, it would have gone into a/b/c.x
  


From jkf  Thu Mar 24 15:00:37 1983
Date: 24 Mar 83 15:00:37 PST (Thu)
From: jkf (John Foderaro)
Subject: liszt 8.26
Message-Id: <8303242300.11144@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA11144; 24 Mar 83 15:00:37 PST (Thu)
To: local-lisp
Status: O

  liszt will now pass the assembler the -V switch.  This tells the assembler
to keep its intermediate file in core rather than putting it in /tmp.
This should make assembly slightly faster and also permit large lisp files to
be compiled on systems with small /tmp's.



From @udel-relay.ARPA:tim.unc@UDel-Relay  Sat Mar 26 03:41:05 1983
Date:     25 Mar 83 15:03:29 EST  (Fri)
From: Tim Maroney <tim.unc@UDel-Relay>
Subject:  open coding of (function (lambda ...))
Return-Path: <tim.unc@UDel-Relay>
Message-Id: <8303261137.AB02371@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17)
	id AB02371; 26 Mar 83 03:37:13 PST (Sat)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA00854; 26 Mar 83 03:41:05 PST (Sat)
To: franz-friends@BERKELEY.ARPA
Via:  UNC; 25 Mar 83 19:43-EST
Status: O

This doesn't seem to work. I'm using Liszt version 8.10, University
of Maryland distribution. The documentation in the file "lispnews"
is sketchy, but it seems that compiling and loading the file:

(setq appsum (function (lambda (x) (apply 'sum x))))

should leave a bcd object in appsum's value, but it doesn't. It
leaves the uncompiled lambda. Am I doing something wrong? 

Tim Maroney
decvax!duke!unc!tim
tim.unc@udel-relay

From jkf@UCBKIM  Sat Mar 26 08:46:44 1983
Date: 26 Mar 83 08:46:28 PST (Sat)
From: jkf@UCBKIM (John Foderaro)
Subject: Re:  open coding of (function (lambda ...))
Message-Id: <8303261646.2453@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA02453; 26 Mar 83 08:46:28 PST (Sat)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17)
	id AA05012; 26 Mar 83 08:42:50 PST (Sat)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA02462; 26 Mar 83 08:46:44 PST (Sat)
To: tim.unc@UDel-Relay
Cc: franz-friends@BERKELEY.ARPA
In-Reply-To: Your message of     25 Mar 83 15:03:29 EST  (Fri)
Status: O


   Liszt only compiles functions, not literals it finds in files.
To make this statement be compiled:
(setq appsum (function (lambda (x) (apply 'sum x))))

you should surround it with a function defintion:
(defun junk ()
	(setq appsum (function (lambda (x) (apply 'sum x)))))



From CARR@UTAH-20  Mon Apr  4 14:53:09 1983
Date:  4 Apr 1983 0922-MST
From: Harold Carr <CARR@UTAH-20>
Subject: Franz/Common lisp
Message-Id: <8304041711.AA07020@UCBVAX.ARPA>
Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20)
	id AA07020; 4 Apr 83 09:11:40 PST (Mon)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA01683; 4 Apr 83 14:53:09 PST (Mon)
To: franz-friends@BERKELEY.ARPA
Cc: KROHNFELDT@UTAH-20
Status: O

Does anyone have any sort of Common Lisp compatibility package for Franz?
If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20).
-------

From jeff@aids-unix  Tue Apr  5 12:42:46 1983
Date:  4 Apr 1983 11:06:49 PST (Monday)
From: Jeff Dean <jeff@aids-unix>
Subject: knowledge representation language
Message-Id: <8304052042.AA26557@UCBVAX.ARPA>
Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20)
	id AA26557; 5 Apr 83 12:42:11 PST (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA16443; 5 Apr 83 12:42:46 PST (Tue)
To: franz-friends@BERKELEY.ARPA
Status: O

Does anyone have a knowledge representation language (such as FRL or
KL-ONE) available under Franz Lisp?

	Jeff Dean
	arpa: jeff@aids-unix
	uucp: ...ucbvax!jeff@aids-unix


From jkf  Tue Apr  5 13:08:06 1983
Date: 5 Apr 83 13:08:06 PST (Tue)
From: jkf (John Foderaro)
Subject: lisp opus 38.57
Message-Id: <8304052108.16969@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA16969; 5 Apr 83 13:08:06 PST (Tue)
To: local-lisp
Status: RO

  This version has a number of internal changes to make it compilable
on 68k.  If you notice it acting abnormally, let me know.



From FAHLMAN@CMU-CS-C  Thu Apr  7 07:50:06 1983
Date: Thu, 7 Apr 1983  10:46 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Franz/Common lisp
Message-Id: <8304071549.AA13873@UCBVAX.ARPA>
Received: ID <FAHLMAN@CMU-CS-C>; 7 Apr 83 10:46:59 EST
Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20)
	id AA13873; 7 Apr 83 07:49:42 PST (Thu)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA18082; 7 Apr 83 07:50:06 PST (Thu)
To: Harold Carr <CARR@UTAH-20>
Cc: franz-friends@BERKELEY.ARPA
In-Reply-To: Msg of 4 Apr 1983  11:22-EST from Harold Carr <CARR at UTAH-20>
Status: RO


Harold,

A couple of things make it seem unlikely that anyone would have such a
package right now.  First, we don't even have a final Common Lisp manual
yet -- Guy's next draft is due very soon, but there will be some tuning
and hassling after that.  Second, there are things in Common Lisp that
would be very tough to fake on Franz: lexical binding, generic
sequences, some of the hairy number types, character objects, etc.
Common Lisp is pretty close to being a superset of Franz, so I would
expect to see Franz compatibility packages in Common Lisp, but not vice
versa.  Third, if anyone were writing such a package, they would be
crazy not to have arranged for access to our code that implements all of
the hairy functions, and nobody has done this to my knowledge.

My standard advice is for people to continue to code in Franz with the
knowledge that they can easily convert their code to Common Lisp
whenever the DEC Common Lisp is available to them.  This should be a
one-time conversion, since moving the other way after "going native" in
Common Lisp would be very tough.

If someone does pop up with a compatibility package -- even a partial
one -- I would be interested in hearing about it.

-- Scott

From fateman@UCBKIM  Sun Apr 10 19:52:14 1983
Date: 10 Apr 83 19:50:59 PST (Sun)
From: fateman@UCBKIM (Richard Fateman)
Subject: Re:  Franz/Common lisp
Message-Id: <8304110350.6176@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA06176; 10 Apr 83 19:50:59 PST (Sun)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
	id AA10019; 10 Apr 83 19:49:55 PST (Sun)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA06192; 10 Apr 83 19:52:14 PST (Sun)
To: carr@utah-20, fahlman@cmu-cs-c
Cc: franz-friends@BERKELEY.ARPA
Status: RO

I think that a common-lisp-compatibility package written
in Franz would not be as difficult as all that. 

If Common Lisp (TM of DEC?) were available on all the same
machines at the same price, (appx. $0.) and CL were
in fact a superset of Franz for all practical purposes, and
with similar or better efficiency, etc. Why would anyone bother?

Of course if CL does not meet all of the objectives (e.g. price, machines),
then a CL-to-Franz "translator" might make sense.

With that in mind,
I would like to officially request a copy of the Common Lisp
language (as implemented in CL, presumably), as soon as it
becomes available (i.e. no later than when it is a "product"
of DEC, and probably at "beta" test time).
I agree fully with Scott that trying to do this with an incomplete
language specification is unwise.

I am also not making any commitment to do anything with CL at
Berkeley, but since we are building tools for our own applications,
and CL might be useful, we might consider an efficient merge of
ideas.

From jkf@UCBKIM  Mon Apr 11 08:07:39 1983
Date: 11 Apr 83 06:42:43 PST (Mon)
From: jkf@UCBKIM (John Foderaro)
Subject: mail to this mailing list
Message-Id: <8304111442.11378@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA11378; 11 Apr 83 06:42:43 PST (Mon)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
	id AA07288; 11 Apr 83 08:05:32 PST (Mon)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
	id AA11949; 11 Apr 83 08:07:39 PST (Mon)
To: franz-friends@BERKELEY.ARPA
Status: RO

  I'm sorry that people who mail to this mailing list must put up with lots
 of mail errors from our local mailer.   The problem is not that we have a
 lot of illegal addresses, but that over the three day period that the
 mailer tries to deliver the mail, some of the destination sites never
 respond.  I think that this is due primarily to the fact that many sites
 are running new mail and networking software.   Hopefully this will
 improve over time.
 					john foderaro
					



From jkf  Fri Apr 22 09:59:09 1983
Date: 22 Apr 83 09:59:09 PST (Fri)
From: jkf (John Foderaro)
Subject: lisp opus 38.59
Message-Id: <8304221759.20996@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA20996; 22 Apr 83 09:59:09 PST (Fri)
To: local-lisp
Status: RO

  Input like 1.2.3 and 1..2  will now be read as single symbols rather
than two consecutive numbers.



From jkf  Sun May  8 00:02:54 1983
Date: 8 May 83 00:02:54 PDT (Sun)
From: jkf (John Foderaro)
Subject: opus 38.60
Message-Id: <8305080702.22344@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.310/3.5)
	id AA22344; 8 May 83 00:02:54 PDT (Sun)
To: local-lisp
Cc: rms
Status: RO

 Thanks to some suggestions from rms we are now one step closer to
full closures.   fclosures will now work if called recursively.
It is still true that the only way to make fclosures share variables
is to use fclosure-list.

 symeval-in-fclosure may return the wrong value if the closure is 
'active'.  This will be fixed eventually.



From mbr@nprdc  Sat May 21 07:37:23 1983
Date: 20 May 1983 14:57:55-PDT
From: mbr@NPRDC
Subject: lam9.c and curses
Message-Id: <8305211434.AA16172@UCBVAX.ARPA>
Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29)
	id AA16172; 21 May 83 07:34:43 PDT (Sat)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA08856; 21 May 83 07:37:23 PDT (Sat)
Reply-To: mbr <mbr@NPRDC>
To: franz-friends@BERKELEY.ARPA
Cc: mbr@NPRDC
Status: O

When we attempted to cfasl a file that used the curses package
of screen control routines into Franz 38.40, we got the message
_ospeed: /usr/libcurses.a (cr_tty.o) multiply defined.
The apparent cause of this cryptic remark is that in lam9.c
there is an extern variable ospeed. There are a number of
tantalizing routines in this source file dealing with termcaps that
are apparently not called by anyone. Are there plans for these
routines? Does anyone use them (heaven forbid they should be
documented!). Our current fix is to just change ospeed to ospiid
which so far has had no dire effects, but I am interested in others
experience. The curses stuff seems to work fine after this
modification.
			Mark Rosenstein


From jkf  Wed May 25 12:15:54 1983
Date: 25 May 83 12:15:54 PDT (Wed)
From: jkf (John Foderaro)
Subject: opus 38.61
Message-Id: <8305251915.1144@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA01144; 25 May 83 12:15:54 PDT (Wed)
To: local-lisp
Status: O

  symeval-in-fclosure and set-in-fclosure now work (thanks to keith).

  selectq is now a part of standard franz.  selectq is just like
 caseq except it allows 'otherwise' as well as 't' for the
 key which means 'if nothing else matches, use this clause'.
 
 


From cornwell@nrl-css  Wed May 25 12:51:17 1983
Date: Wed, 25 May 83 15:14:19 EDT
From: Mark Cornwell <cornwell@NRL-CSS>
Subject: Franz on the Sun
Message-Id: <8305251950.AA02600@UCBVAX.ARPA>
Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29)
	id AA02600; 25 May 83 12:50:26 PDT (Wed)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA01878; 25 May 83 12:51:17 PDT (Wed)
To: franz-friends@BERKELEY.ARPA
Cc: cornwell@NRL-CSS
Status: O


  Our group at NRL is planning to purchase Sun workstations. I
currently have a substantial amount of code written in Franz Lisp that
I want to run on the Sun. 
 
  What is the status of the Berkeley group porting Franz to the Sun?   
How do I get a copy?

  Also, I have a few concerns about configuring a Sun to run Franz well.  
The basic desktop Sun workstation provides 1 Mbyte of physical memory.   
This can be extended to 2 Mbyte or one can add an Ethernet interface
*but not both*.  Since I am unwilling to give up my Ethernet
interface I may be forced to run Franz in 1 Mbyte and contend with
the added paging overhead (using a 68010 running 4.2bsd and a local disk).

  Has anyone out there had experience running Franz Lisp on a Sun in
such a configuration?  Can I get away without the 2 Mbyte extension?
I think your answers would be of general interest. 

-- Mark (caught between a rock and a hard place?) Cornwell

 

From baden@UCBKIM  Wed May 25 13:51:39 1983
Date: 25 May 83 13:32:01 PDT (Wed)
From: baden@UCBKIM (Scott B. Baden)
Subject: Re:  Franz on the Sun
Message-Id: <8305252032.2716@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA02716; 25 May 83 13:32:01 PDT (Wed)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29)
	id AA03753; 25 May 83 13:50:52 PDT (Wed)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA03002; 25 May 83 13:51:39 PDT (Wed)
To: franz-friends@BERKELEY.ARPA
Cc: cornwell@NRL-CSS
Status: O

Which sun are you using?  My office mate says that
he has seen a sun configured with 2MB of memory AND
an Ethernet board.

From mike%Rice.Rice@Rand-Relay  Fri May 27 19:51:33 1983
Date:     Fri, 27 May 83 18:18:47 CDT
From: Mike.Caplinger <mike.rice@Rand-Relay>
Subject:  Re:  Franz on the Sun
Return-Path: <mike%Rice.Rice@Rand-Relay>
Message-Id:  <1983.05.27.18.18.47.150.08942@dione.rice>
Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29)
	id AA19088; 27 May 83 19:50:15 PDT (Fri)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA02221; 27 May 83 19:51:33 PDT (Fri)
To: franz-friends@BERKELEY.ARPA
In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed)
Via:  Rice; 27 May 83 19:14-PDT
Status: RO

As I type I'm bringing up the 68K version of Opus 38 (now FTPable from
UCB-VAX) on a SUN running 4.1c.  There don't seem to be any major
problems so far, but the compiler doesn't run on a system with all the
net servers on it because it runs out of memory.  I've been told this
is because there's a bug in 4.1c that forces it to only use 1/2 of the
swap partition.  I'm having to run standalone to compile the compiler;
I don't yet know whether I'll be able to compile other stuff without
this rather extreme fix.

As I use the system more I will post more info to this group.

From narain@rand-unix  Tue May 31 10:49:00 1983
Date: Tuesday, 31 May 1983 10:45-PDT
From: narain@rand-unix
Subject: Interrupt question
Message-Id: <8305311747.AA10893@UCBVAX.ARPA>
Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29)
	id AA10893; 31 May 83 10:47:26 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA13428; 31 May 83 10:49:00 PDT (Tue)
To: franz-friends@BERKELEY.ARPA
Cc: narain@rand-unix
Status: O


Hi, I would be grateful if you could tell me  what  is  the  equivalent  of
Interlisp's  control-h  (followed  by  OK) in Franzlisp.  In other words, I
wish to interrupt a Franzlisp program, from time to time, examine its state
and allow it to continue from the interrupted point.

-- Sanjai

From lbl-csam!steve@ssc-vax.UUCP  Tue May 31 19:31:04 1983
Date: 31 May 83 17:28:35 PDT (Tue)
From: ssc-vax!steve@lbl-csam.UUCP
Subject: packages
Message-Id: <8306010028.AA16451@LBL-CSAM.ARPA>
Received: by LBL-CSAM.ARPA (3.320/3.21)
	id AA16451; 31 May 83 17:28:35 PDT (Tue)
Received: by UCBVAX.ARPA (3.341/3.31)
	id AA02877; 31 May 83 19:30:00 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA22745; 31 May 83 19:31:04 PDT (Tue)
To: ucbvax!franz-friends@lbl-csam.UUCP
Status: O


Does a version of LispMachine ``packages'' or some similar oblist partitioning
scheme exist for franz?  Having just integrated several independently coded
modules, I think something like that would be very useful.
					-thanks
	Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve


From fateman  Tue Jun 14 11:48:32 1983
Date: 14 Jun 83 11:48:32 PDT (Tue)
From: fateman (Richard Fateman)
Subject: "macsyma on a chip?"
Message-Id: <8306141848.6756@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA06756; 14 Jun 83 11:48:32 PDT (Tue)
To: macsyma-i@mit-mc
Cc: franz-friends
Status: O

Well, sort of. We now have Macsyma running on a Motorola 68000 - based
system with 6 megabytes of real memory. The operating system is a 
Unisoft UNIX system, which has been ported to some large number (>65) boxes.  
The Pixel people were kind enough to lend us a machine with enough 
real memory to make virtual memory unnecessary.

It takes a long time to load up, but once running, it is quite responsive,
and appears to be about 60% of a VAX 11/780 in terms of CPU time. 

We have not shaken down everything, but since the source code is unchanged
from the VAX, we expect the bugs to be limited to lisp compilation
glitches, or differences between versions of the UNIX system.


From jkf  Wed Jun 15 10:42:05 1983
Date: 15 Jun 83 10:42:05 PDT (Wed)
From: jkf (John Foderaro)
Subject: Opus 38.62
Message-Id: <8306151742.20591@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA20591; 15 Jun 83 10:42:05 PDT (Wed)
To: local-lisp
Status: O

  There is no longer a limit on the size of bignums, strings or
symbol names which can be read by the reader [other than the size of
virtual memory].

  The value of lisp-library-directory will determine where cfasl finds
its private version of the loader.

 (changes by sklower)


From @CMU-CS-C:UI.TYJ@CU20D  Wed Jun 15 18:22:55 1983
Date: 14 Jun 1983 1812-EDT
From: Tai Jin <UI.TYJ@CU20D>
Subject: franz mailing liszt
Message-Id: <8306142214.AA16599@UCBVAX.ARPA>
Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
	id AA16599; 14 Jun 83 15:14:36 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA28806; 15 Jun 83 18:22:55 PDT (Wed)
To: franz-friends%berkeley@CMCSC
Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC
Status: O


Hi, we would like to be added to your mailing list.

We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS)
running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center
for Computing Activities).

Is anyone out there working on an UTS/IBM implementation?  Any information will
be greatly appreciated.


Thanks,

Tai Jin <UI.TYJ%CU20D@CMCSC>
Travis Winfrey <UI.TRAVIS%CU20D@CMCSC>
-------

From @CMU-CS-C:Ui.Travis@CU20D  Thu Jun 16 09:47:39 1983
Date: 16 Jun 1983 1243-EDT
From: Travis Lee Winfrey <Ui.Travis@CU20D>
Subject: Porting Franz lisp to Amdahl Unix
Message-Id: <8306161646.AA25470@UCBVAX.ARPA>
Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
	id AA25470; 16 Jun 83 09:46:15 PDT (Thu)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA06352; 16 Jun 83 09:47:39 PDT (Thu)
To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC
Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D,
        kim.fateman%berkeley@CMCSC
Status: O

Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's
Unix running on a IBM 4341.  We are working from a copy that runs on the VAX.

We would be very interested in seeing any versions that runs both on the VAX
and some other machine, such as the 68000.  We are also interested in seeing
any documentation on other porting efforts, regardless of what machine.

Thanks,

Tai Jin  <ui.tyj%cu20d@cmu-cs-c>
Travis Winfrey <ui.travis%cu20d@cmu-cs-c>
-------

From jkf  Sun Jun 19 15:43:34 1983
Date: 19 Jun 83 15:43:34 PDT (Sun)
From: jkf (John Foderaro)
Subject: opus 38.63
Message-Id: <8306192243.19626@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA19626; 19 Jun 83 15:43:34 PDT (Sun)
To: local-lisp
Status: O

 Added functions:
   (vputprop 'Vv_vector 'g_value 'g_indicator)
   (vget  'Vv_vector 'g_indicator)

  work just like putprop and get, but modify the vector property list.

 Also:
   you can determine which function is called by lisp to print a vector
 by placing the function to call on the vector's property list under
 indicator 'print'.  The  print function is called with two arguments:
 the vector and the port.
 
 For example:
=> (defun printv (v port)
      (patom "A vector of size " port)
      (print (vsize v) port))
printv
=> (setq xx (new-vector 10))
vector[40]
=> (vputprop xx 'printv 'print)
printv
=> xx
A vector of size 10
=>



From jkf  Sun Jun 19 22:47:42 1983
Date: 19 Jun 83 22:47:42 PDT (Sun)
From: jkf (John Foderaro)
Subject: opus 38.64
Message-Id: <8306200547.23164@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA23164; 19 Jun 83 22:47:42 PDT (Sun)
To: local-lisp
Cc: jpg@Mit-mc
Status: O


  added the function (^ 'x_a 'x_b)  which computes  x_a to the x_b
power and always returns a fixnum result (it currently wraps around
on overflow).



From JPG@MIT-MC  Sun Jun 19 22:54:00 1983
Date: 20 June 1983 01:53 EDT
From: Jeffrey P. Golden <JPG@MIT-MC>
Subject: ^
Message-Id: <8306200553.AA15160@UCBVAX.ARPA>
Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33)
	id AA15160; 19 Jun 83 22:53:57 PDT (Sun)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA23228; 19 Jun 83 22:54:00 PDT (Sun)
To: jkf@UCBKIM
Cc: JPG@MIT-MC, local-lisp@UCBKIM
Status: O

   Date: 19 Jun 83 22:47:42 PDT 
   From: jkf%UCBKIM@Berkeley 
   Subject: opus 38.64
   To: local-lisp%UCBKIM@Berkeley
   Cc: jpg@Mit-mc
   added the function (^ 'x_a 'x_b)  which computes  x_a to the x_b
   power and always returns a fixnum result (it currently wraps around
   on overflow).
The Maclisp ^ errors out in this case with the message:
;RESULT LARGER THAN FIXNUM - ^


From narain@rand-unix  Mon Jun 20 22:09:31 1983
Date: Monday, 20 Jun 1983 22:00-PDT
From: narain@rand-unix
Subject: Re: Interrrupt question
Message-Id: <8306210509.AA00276@UCBVAX.ARPA>
Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
	id AA00276; 20 Jun 83 22:09:20 PDT (Mon)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA09633; 20 Jun 83 22:09:31 PDT (Mon)
To: franz-friends@BERKELEY.ARPA
Cc: narain@rand-unix
Status: O


				   TWIMC
				   -----

Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp:
i.e. if you wish to interrupt a Franzlisp computation, browse around the state
and resume computation:

Hit DEL;
Browse;
(return t)

This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay).

-- Sanjai

From Tim%UPenn.UPenn@UDel-Relay  Tue Jun 21 14:52:53 1983
Date: Tue, 21 Jun 83 10:33 EDT
From: Tim Finin <Tim.UPenn@UDel-Relay>
Subject: interrupting Franz
Return-Path: <Tim%UPenn.UPenn@UDel-Relay>
Message-Id: <8306212152.AA12930@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
	id AA12930; 21 Jun 83 14:52:36 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA21097; 21 Jun 83 14:52:53 PDT (Tue)
To: franz-friends@BERKELEY.ARPA
Via:  UPenn; 21 Jun 83 17:40-EDT
Status: O


Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.

From jkf  Sat Jun 25 13:49:37 1983
Date: 25 Jun 83 13:49:37 PDT (Sat)
From: jkf (John Foderaro)
Subject: opus 38.65
Message-Id: <8306252049.25527@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA25527; 25 Jun 83 13:49:37 PDT (Sat)
To: local-lisp
Status: O

  If you have automatic case conversion set (i.e. (sstatus uctolc t)),
then symbols with lower case letters will be escaped by print.



From layer  Tue Jul  5 00:26:29 1983
Date:  5 Jul 1983 0026-PDT (Tuesday)
From: layer (Kevin Layer)
Subject: lisp opus 38.67
Message-Id: <5390.30.426237985@ucbkim>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA05911; 5 Jul 83 00:26:29 PDT (Tue)
Phone: (415) 652-2405
To: local-lisp
Cc: layer
Status: O

  The function 'sortcar' has been slightly changed: if the second
arg is nil, then the ordering function 'alphalessp' is assumed
('sort' does it this way).

	Kevin

From layer  Wed Jul  6 00:02:33 1983
Date: 6 Jul 83 00:02:33 PDT (Wed)
From: layer (Kevin Layer)
Subject: liszt opus 8.30
Message-Id: <8307060702.24776@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA24776; 6 Jul 83 00:02:33 PDT (Wed)
Phone: (415) 652-2405
To: local-lisp
Cc: sklower, jkf
Status: O

  All modifications should be transparent, but if there are problems
relating to the autorun feature (-r flag), please let me know.

	Kevin



From sklower  Thu Jul  7 00:27:52 1983
Date: 7 Jul 83 00:27:52 PDT (Thu)
From: sklower (Keith Sklower)
Subject: Franz, opus38.68
Message-Id: <8307070727.10697@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA10697; 7 Jul 83 00:27:52 PDT (Thu)
To: local-lisp
Status: O

Franz now escapes UPPER case letters instead of lower case letters when
(status uctolc) is enabled, so that (read (print x)) is an identity operation
on atom printnames.  Also, we made (explode) conform to what maclisp does
with opposite-than-normal character-cases.

From Ira%UPenn.UPenn@UDel-Relay  Fri Jul  8 01:46:25 1983
Date: Thu, 7 Jul 83 22:13 EDT
From: Ira Winston <Ira.UPenn@UDel-Relay>
Subject: Eliza
Return-Path: <Ira%UPenn.UPenn@UDel-Relay>
Message-Id: <8307080845.AA16294@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
	id AA16294; 8 Jul 83 01:45:43 PDT (Fri)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA01687; 8 Jul 83 01:46:25 PDT (Fri)
To: franz-friends@BERKELEY.ARPA
Via:  UPenn; 8 Jul 83 3:07-EDT
Status: O

Does anyone have a version of Eliza that runs under Franz Lisp?

From layer  Fri Jul  8 18:04:10 1983
Date:  8 Jul 1983 1804-PDT (Friday)
From: layer (Kevin Layer)
Subject: lisp opus 38.69
Message-Id: <7031.30.426560643@ucbkim>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA07142; 8 Jul 83 18:04:10 PDT (Fri)
Phone: (415) 652-2405
To: local-lisp
Cc: layer
Status: O

  'setf' now knows about 'nthelem', and there are two new functions:

	(readdir 's_direct)
		returns a list of the contents of the directory s_direct.

	(dirp 's_name)
		returns s_name if s_name is a directory.  This doesn't
		insure that you can read the directory, though (only
		uses stat(2)).

					Kevin

From layer  Fri Jul  8 20:57:13 1983
Date:  8 Jul 1983 2057-PDT (Friday)
From: layer (Kevin Layer)
Subject: new function readdir
Message-Id: <465.30.426571029@ucbkim>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA00480; 8 Jul 83 20:57:13 PDT (Fri)
Phone: (415) 652-2405
To: local-lisp
Fcc: record
Status: O

  The function 'readdir' and 'dirp' should not be relied on yet, since
they are provisional, because they are implemented with C library
functions only available on 4.1+ systems.

	Kevin

From Pwh%GaTech.GATech@UDel-Relay  Tue Jul 12 18:08:46 1983
Date:     11 Jul 83 20:36:32-EDT (Mon)
From: <pwh.gatech@UDel-Relay>
Subject:  Franz flavors?
Return-Path: <Pwh%GaTech.GATech@UDel-Relay>
Message-Id: <8307130107.AA03336@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
	id AA03336; 12 Jul 83 18:07:40 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA20140; 12 Jul 83 18:08:46 PDT (Tue)
To: franz-friends@BERKELEY.ARPA
Cc: jlk.Gatech@UDel-Relay
Via:  GATech; 12 Jul 83 2:43-EDT
Status: O

We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our
long awaited Symbolics Lisp Machine up and running and are trying to establish
some measure of compatability between Franz and Zeta Lisp (as appropriate).
Janet seems to recall some mention of a flavor package for Franz. Is this
Berkley based or can anyone provide some clues as to where to check next?

Also, when is the next release of Franz scheduled and what features will it
incorporate?

If the flavor package is non-existent, we will probably be forced to develop
one here and will, of course, be glad to pass anything useful along.

phil hutto

From narain@rand-unix  Tue Jul 12 20:10:42 1983
Date: Tuesday, 12 Jul 1983 19:49-PDT
From: narain@rand-unix
Subject: Re:  Franz flavors?
Message-Id: <8307130309.AA05908@UCBVAX.ARPA>
Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
	id AA05908; 12 Jul 83 20:09:41 PDT (Tue)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA21387; 12 Jul 83 20:10:42 PDT (Tue)
To: <pwh.gatech@UDEL-RELAY>
Cc: franz-friends@BERKELEY.ARPA, jlk.Gatech@UDEL-RELAY
In-Reply-To: Your message of     11 Jul 83 20:36:32-EDT (Mon).
             <8307130107.AA03336@UCBVAX.ARPA>
Status: O


We at Rand are interested in developing a set of guidelines for writing
code that will be compatible with each of Zeta- Franz- and PSL Lisps. I
would be grateful if you could tell us of what your experiences have been with
making Franzlisp code work on the Symbolics machine. We would gladly share
our own with you if you wish; incidentally we also have an IJCAI paper on a
related issue.

-- Sanjai Narain

From liz.umcp-cs@UDel-Relay  Wed Jul 13 00:55:26 1983
Date:     13 Jul 83 03:09:39 EDT  (Wed)
From: Liz Allen <liz.umcp-cs@UDel-Relay>
Subject:  Re:  Franz flavors?
Return-Path: <liz.umcp-cs@UDel-Relay>
Message-Id: <8307130754.AA10367@UCBVAX.ARPA>
Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
	id AA10367; 13 Jul 83 00:54:32 PDT (Wed)
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA24477; 13 Jul 83 00:55:26 PDT (Wed)
To: pwh.gatech@UDel-Relay, franz-friends@BERKELEY.ARPA
Cc: jlk.Gatech@UDel-Relay
Via:  UMCP-CS; 13 Jul 83 3:23-EDT
Status: O

Here at the Univ of Maryland, we do have an implementation of
flavors in Franz Lisp and have used it successfully in several
large systems.  It doesn't contain all the features of the Lisp
Machine Flavors, but it does implement all the major ones.  It is
also different in a few ways that are necessitated by the limitations
of Franz Lisp (shallow binding without invisible pointers or true
closures -- though closures may be in the very newest versions of
Franz -- we have opus 38.26).  The package uses a hashing scheme
for looking up methods, and the function <- which is used to send
a message to an object is written in C.  Together, this makes it
an efficient implementation.

We are currently working on a new policy for distributing flavors,
our other lisp packages and our window package.  When we have worked
it out, I will announce the details here.

				-Liz

From @MIT-MC:mdm@cmu-ri-isl  Thu Jul 14 11:07:57 1983
Date: 14 Jul 1983 14:03:01-EDT
From: Malcolm.McRoberts@CMU-RI-ISL
Subject: random numbers
Message-Id: <8307141806.AA05735@UCBVAX.ARPA>
Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35)
	id AA05735; Thu, 14 Jul 83 11:06:45 PDT
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA13687; 14 Jul 83 11:07:57 PDT (Thu)
Apparently-To: <franz-friends@UCB-VAX>
Status: O

I am interested in obtaining a GOOD random number generator that is callable
from Franz.  My only real requirements are that it accept a seed (so that I
can duplicate the same series), is fairly good (try doing several (random
4)'s in Franz and see what you get), and is of intermediate speed.  If you
know of such an animal please send me mail telling me how to get it.
							thanks


From kanderso@bbn-vax  Thu Jul 14 12:49:58 1983
Date: 14 Jul 1983 15:47:19 EDT (Thursday)
From: Ken Anderson <kanderso@bbn-vax>
Subject: Random numbers
Message-Id: <8307141948.AA06936@UCBVAX.ARPA>
Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35)
	id AA06936; Thu, 14 Jul 83 12:48:49 PDT
Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
	id AA15607; 14 Jul 83 12:49:58 PDT (Thu)
To: franz-friends@BERKELEY.ARPA
Cc: Malcolm.McRoberts@CMU-RI-ISL
Status: O

Here is a random number generator i use.  It seems to work fairly well, but i have
not looked to closely at the statistics.  Since it will occasionally require
bignums, it is probably not the fastest either.  I was just looking for something
that was likely to be portable between LISP's.
I would be very interested in hearing your evaluation of it.

k

;;; RANDOM NUMBERS
(declare (macros t))
(include math.h)

(defvar $uniform-a 16807) ; = 7^5
(defvar $mersenne-prime 2147483647) ; = 2^31 - 1
(defvar $mersenne-prime-1 (- $mersenne-prime 1))

(defmacro with-seed (s-newseed . body)
  ; evaluates body with the seed of the random numbers set to s-newseed.
  ; the value of s-newseed is updated.  Thus this is a way of
  ; Keepining several sequences of random numbers with their own seeds
  `(let (($uniform-seed ,s-newseed))
	(prog1 (progn ,@body) 
	       (setq ,s-newseed $uniform-seed))))

(defun uniform-basic (previous-fixnum)
  ; -> a fixnum 0 < fixnum < 2^31 - 1
  ; Repeated calls will generate fixnums in the range
  ; 1 -> 2^31 - 2.

  ; The basic idea is new = A^k * old (mod p)
  ; where A is a primitive root of p, k is not a factor of  p-1
  ; and p is a large prime.

  ; This is a good random number generator but is not be the fastest!
  ; On FRANZ LISP, and LISP MACHINE it will require bignums since
  ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder
  ; can be done more efficiently.
  ; See: Linus Schrage, A More Portable Fortran Random Number Generator,
  ;      ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979.
  (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime))

(defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1

(defun uniform ()
  ; -> the next uniform random number in the sequence
  ; To have your own sequence, rebind $uniform-seed.
  (setq $uniform-seed (uniform-basic $uniform-seed)))

(defun uniform-between (low-num high-num)
  ; -> a uniform random  number, x, low-num <= x <= high-num
  ; If low-num and high-num are fixnums, a fixnum is returned.
  (cond ((not (and (fixp low-num) (fixp high-num)))
	 (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1))
		       (-$ high-num low-num))))
	(t (+ low-num (// (uniform)
			  (// $mersenne-prime-1 (max 1 (- high-num low-num -1))))))))

(defun gaussian-random-1 ()
  ; -> a gaussian random variable with mean 0.0 and
  ; standard deviation 1.0.
  ; Good tails.
  (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0))))
     (sin (*$ $2pi (uniform-between 0.0 1.0)))))

(defun gaussian-random (mean standard-deviation)
  (+$ mean (*$ (gaussian-random-1) standard-deviation)))

;;(defun gaussian (x)
;;  (* (sqrt $2pi) 
;;     (exp (minus (// (square x) 2.0)))))

(defun random-yes-no (fraction-yes)
    (<= (uniform-between 0.0 1.0) fraction-yes))


From layer  Sat Jul 30 15:46:42 1983
Date: 30 Jul 1983 1546-PDT (Saturday)
From: layer (Kevin Layer)
Subject: liszt opus 8.33
Message-Id: <19472.30.428453197@ucbkim>
Received: by UCBKIM.ARPA (3.340/3.5)
	id AA19498; 30 Jul 83 15:46:42 PDT (Sat)
Phone: (415) 652-2405
To: local-lisp
Status: O

  Vset is now open coded.  There should be no visible change in the
behaviour of vectors, except in speed (greater, that is), and 
vsize-{byte,word} work properly now.

  Bugs to me.

	Kevin

From jkf  Mon Aug  1 14:41:28 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA03743; Mon, 1 Aug 83 14:41:28 PDT
Date: Mon, 1 Aug 83 14:41:28 PDT
From: jkf (John Foderaro)
Message-Id: <8308012141.AA03743@ucbkim.ARPA>
To: local-lisp
Subject: defstruct
Status: O

  defstruct now understands two more types of structures:
  	:vector
	:named-vector

  A named vector has the defstruct structure name on the vector property
list, thus an instance of the foo structure would print as 'foo[8]'.


  :named-vector is now the default structure type (instead of :hunk).




From jkf  Tue Aug  2 15:20:04 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA26686; Tue, 2 Aug 83 15:20:04 PDT
Date: Tue, 2 Aug 83 15:20:04 PDT
From: jkf (John Foderaro)
Message-Id: <8308022220.AA26686@ucbkim.ARPA>
To: local-lisp
Subject: lisp opus 38.70
Status: RO

  When a vector is printed, the size in square brackets will be the number
of entries (not the number of bytes).  The size printed for vectori
objects will continue to be the number of bytes.

  Also, if the property of a vector is a list with the car being a non nil
symbol, and if that list doesn't have a print property, then that
symbol will be printed rather than 'vector' or 'vectori'.



From layer  Thu Aug  4 02:10:12 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA11660; Thu, 4 Aug 83 02:10:12 PDT
From: layer (Kevin Layer)
Phone: (415) 652-2405
Date:  4 Aug 1983 0210-PDT (Thursday)
Message-Id: <11649.30.428836207@ucbkim>
To: local-lisp
Subject: liszt opus 8.34
Status: RO

  I just installed a new compiler.  For the vax, there shouldn't be
any visible changes, though a couple of vector bugs were fixed.  For
the 68000, the vector access functions are now open coded, and the
new one was installed on mike, rob, and chip in /usr/ucb.

	Kevin

From FRD@SU-AI  Fri Aug  5 15:57:17 1983
Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
	id AA10610; Fri, 5 Aug 83 15:57:17 PDT
Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
	id AA10357; Fri, 5 Aug 83 15:54:22 PDT
Message-Id: <8308052254.AA10357@UCBVAX.ARPA>
Date: 05 Aug 83  1353 PDT
From: Fred Lakin <FRD@SU-AI>
Subject: Franz & SUNs  
To: franz-friends@BERKELEY
Status: RO

I am interested in connectons between Franz and SUN workstations.
Like how far along is Franz on the SUN?  Is there some package
which allows Franz on a VAX to use a SUN as a display device?

Any info on this matter would be appreciated.
Thnaks, Fred Lakin


From tektronix!ogcvax!metheus!tombl  Sat Aug  6 09:49:57 1983
Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
	id AA21229; Sat, 6 Aug 83 09:49:57 PDT
Received: by UCBVAX.ARPA (3.347/3.35)
	id AA13549; Sat, 6 Aug 83 09:40:11 PDT
Message-Id: <8308061640.AA13549@UCBVAX.ARPA>
From: ogcvax!metheus!tombl
To: ogcvax!tektronix!ucbvax!franz-friends
Cc: ogcvax!tektronix!ucbvax!sklower
Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT
Subject: bug in Opus 38.66
Date: Fri Aug  5 20:46:56 1983
Status: O


A bug present in previous versions is also present in 38.66 of Franz.
cfasl fails (in most cases) to close the file it reads from.
Consequently, mysterious events occur when the maximum number of open
file descriptors is reached.

The fix is made in the file ffasl.c. "close(fildes)" should be
prepended to the two return sequences from (the Unix code for)
Lcfasl:

------------------------------------------------------------------
Old:	146c146
	< 		{Restorestack(); return(nil);}
	---
Fixed:	> 		{close(fildes); Restorestack(); return(nil);}
	149a150
	> 	close(fildes);
------------------------------------------------------------------


	Tom Blenko
	Metheus Corp.
	ucbvax!tektronix!ogcvax!metheus!tombl
	allegra!ogcvax!metheus!tombl



From FRD@SU-AI  Sun Aug  7 12:34:43 1983
Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
	id AA10610; Fri, 5 Aug 83 15:57:17 PDT
Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
	id AA10357; Fri, 5 Aug 83 15:54:22 PDT
Message-Id: <8308052254.AA10357@UCBVAX.ARPA>
Date: 05 Aug 83  1353 PDT
From: Fred Lakin <FRD@SU-AI>
Subject: Franz & SUNs  
To: franz-friends@BERKELEY
Status: O

I am interested in connectons between Franz and SUN workstations.
Like how far along is Franz on the SUN?  Is there some package
which allows Franz on a VAX to use a SUN as a display device?

Any info on this matter would be appreciated.
Thnaks, Fred Lakin


From jkf  Mon Aug  8 09:06:49 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA06584; Mon, 8 Aug 83 09:06:49 PDT
Date: Mon, 8 Aug 83 09:06:49 PDT
From: jkf (John Foderaro)
Message-Id: <8308081606.AA06584@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.72
Status: O

  A bug was fixed in defmacro which caused the &protect option and
displace-macros to interact poorly.



From jkf  Fri Aug 12 22:11:13 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA25610; Fri, 12 Aug 83 22:11:13 PDT
Date: Fri, 12 Aug 83 22:11:13 PDT
From: jkf (John Foderaro)
Message-Id: <8308130511.AA25610@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.73
Status: O

 'equal' will now compare all types of vectors for equality.

 'copy' will now copy all types of vectors.

 


From layer  Mon Aug 15 20:03:53 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA03597; Mon, 15 Aug 83 20:03:53 PDT
From: layer (Kevin Layer)
Phone: (415) 652-2405
Date: 15 Aug 1983 2003-PDT (Monday)
Message-Id: <3556.30.429851029@ucbkim>
To: local-lisp
Subject: liszt opus 8.35
Fcc: record
Status: RO

  Several things have changed:

1) Bugs in the open coding of vectors have been fixed.

2) Minor re-organization of the compiler source code.

3) The routine to determine whether or not tail merging is
   possible underwent major modification.

4) Lexpr's are compiled differently, or rather the way lexpr args
   are accessed has changed.  For those that want to know, here is
   the nitty gritty:

     Consider a the following lexpr: (defun test nargs ...).
     The arguments to the lexpr are stacked on the name stack
     (low to high number), and then nargs is stacked.  The user
     is allowed to change the binding of 'nargs' to anything
     he likes, so we have to have another way to access the arguments
     on the name stack (i.e., other than an offset from nargs).
     Before, a pointer to the argument base was pushed on the 
     C stack, so that indexing could be done from there.
     The addressing modes used to do this are not available
     on the MC68000 (something like *n(fp)[Rx]), so now
     nargs is pushed on the name stack twice, and the location
     of an argument can be easily calculated as an offset from nargs.

In short, lots of thing changed.  The SUN's should be updated
in the next couple of days (after I test it out).  Bugs to me...

	Kevin

From jkf  Mon Aug 15 23:11:08 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA05928; Mon, 15 Aug 83 23:11:08 PDT
Date: Mon, 15 Aug 83 23:11:08 PDT
From: jkf (John Foderaro)
Message-Id: <8308160611.AA05928@ucbkim.ARPA>
To: local-lisp
Subject:  opus 38.74
Status: O


  If a vector has a 'unique' property on it's property list, then it will
not be copied by 'copy'.

  'untrace' will now autoload /usr/lib/lisp/trace.

  A number of functions and macros were contributed by the bair group:

 






(<= 'fx_arg1 'fx_arg2 ...)
(<=& 'x_arg1 'x_arg2)

     RETURNS: t iff (> 'fx_arg1 'fx_arg2)  [or  (>&  'x_arg1
              'x_arg2)]  is nil, otherwise nil.  The general
              function, <=, can take  more  than  two  argu-
              ments.

(>= 'fx_arg1 'fx_arg2)
(>=& 'x_arg1 'x_arg2)

     RETURNS: t  iff  (<  'fx_arg1  'fx_arg2  ...)  [or  (<&
              'x_arg1 'x_arg2)] is nil, otherwise nil.

     NOTE: The general function, >=, can take more than  two
           arguments.

(litatom 'g_arg)

     RETURNS: t iff g_arg is an atom, but not a number.

(nequal 'g_x 'g_y)

     RETURNS: t iff g_x is not equal to g_y, otherwise nil.

(lineread [['p_port] ['s_flag]])

     RETURNS: a list consisting of s-expressions on  a  line
              from  the  port p_port (or piport if p_port is
              not given).  If an s-expression (e.g., a list)
              takes more than one line, or a line terminates
              in a space or  tab,  then  lineread  continues
              reading until an expression ends at the end of
              a line.

     NOTE: If s_flag is t, then if the first character on  a
           line  is  a  newline, lineread performs a tyi and
           returns nil.  If s_flag is nil  or  not  present,
           lineread  does  a  read  skipping  over any blank
           lines to make sure that an s-expression is  actu-
           ally read.

     SIDE EFFECT: lineread uses  read,  advancing  the  port
                  character pointer.








9

9










(defv g_arg1 g_arg2)

     EQUIVALENT TO: (set g_arg1 g_arg2)

(pp-form 'g_form ['p_port] ['n_lmar])

     RETURNS: nil

     SIDE EFFECT: g_form  is  pretty-printed  to  the   port
                  p_port (or poport if p_port is not given).
                  If  pp-form  is  also  supplied  with   an
                  integer  (n_lmar),  that  integer  will be
                  used as a left margin setting  (0  is  the
                  default).   This is the  function which pp
                  uses (n_lmar = 0). pp-form does  not  look
                  for  function  definitions  or  values  of
                  variables, it just prints out the form  it
                  is given.

     NOTE: This is useful as a top-level-printer, c.f.  top-
           level in Chapter 6.

(sload 's_file1 ...)

     SIDE EFFECT: The files named are opened for reading and
                  each form is read, optionally printed, and
                  evaluated.

     NOTE: What sload prints is controlled  by  the  special
           atom  $sldprint.   If  $sldprint  is t (default),
           then if a form  is  recognizable  as  a  function
           definition,  only  the  function name is printed,
           otherwise  the  whole  form   is   printed.    If
           $sldprint is eq to value, then the result of each
           form's evaluation will also be printed.  Printing
           the  forms'  values  can be controlled by setting
           sload-print equal to the name of the function  to
           be  called.   sload recognizes named functions by
           looking at  the  sloadprintarg  property  of  the
           function  name.   The  value of the sloadprintarg
           property should be the  argument  number  of  the
           function name.  For the standard Franz Lisp func-
           tions, the properties are already set.

     EXAMPLE: (defprop def 1 sloadprintarg)   ; This is  the
              default--declaring that
                                              ; the name  of
              the function definition is the
                                              ; first  argu-
              ment.


9

9










          The functions described below are  an  alternative
     to  the  gensym facility.  They generate new symbols by
     attaching counter numbers to the ends of  the  symbols'
     names.   An  example  follows  of how the functions are
     used.


    ____________________________________________________

    -> (initsym joe (john 5))       ; initializing new symbol counters
    (joe0 john5)
    -> (newsym john)                ; create a new symbol
    john6
    -> (newsym chuck)               ; symbol need not be initsym'ed
    chuck0
    -> (oldsym john)                ; get current symbol
    john6
    -> (allsym john)                ; get all symbols between 0 and counter
    (john0 john1 john2 john3 john4 john5 john6)
    -> (allsym (john 5))            ; get all symbols between 5 and counter
    (john5 john6)
    -> (remsym joe (john 4))        ; remob all interned symbols
                                    ; associated with joe and from
                                    ; john4 to the current john
                                    ; symbol--returns symbols with symbol counters
                                    ; before doing remsym
    (joe0 john6)
    -> (symstat joe john)
    ((joe nil) (john 3))
    ____________________________________________________




(initsym g_arg1 ...)

     WHERE:   g_argi is a  list  (n_counteri  s_argi)  or  a
              string  s_argi  (which  is  equivalent  to  (0
              s_argi)).

     RETURNS: a list of interned identifiers using the  sym-
              bol  counters  n_counteri, i.e., the result of
              concatenating s_argi to n_counteri.

     EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5)

     NOTE: See also newsym, oldsym, allsym, remsym, and sym-
           stat functions.




9

9










(newsym s_arg)

     RETURNS: an interned identifier formed by concatenating
              the  name  s_arg  to  the  symbol  counter for
              s_arg.  The symbol counter is  stored  on  the
              property list of s_arg under symctr.  If there
              is no counter, a counter  of  0  is  used  and
              added  to  the  property list.  Thus, a symbol
              need not be initsymed.

     EXAMPLE: (initsym joe (john5)) ==> (joe0 john5)
              (newsym john) ==> john6
              (newsym joe) ==> joe1

     NOTE: See also initsym,  oldsym,  allsym,  remsym,  and
           symstat functions.

(oldsym s_arg)

     RETURNS: the  identifier  using  the   current   symbol
              counter  for s_arg, rather than creating a new
              identifier.  If no symbol counter  exists  for
              s_arg, then s_arg is returned.

     NOTE: See also initsym,  newsym,  allsym,  remsym,  and
           symstat functions.

(allsym g_arg)

     WHERE:   g_arg is a list (s_arg n_counter) or a  string
              s_arg (equivalent to (s_arg 0)).

     RETURNS: a list of all the created identifiers  between
              n_counter  and  the current symbol counter for
              s_arg.

     EXAMPLE: (allsym john) ==> (john0 john1 john2)

     NOTE: See also initsym,  newsym,  oldsym,  remsym,  and
           symstat functions.

(remsym g_arg1 ...)

     WHERE:   g_argi is a  list  (s_argi  n_counteri)  or  a
              string  s_argi (which is equivalent to (s_argi
              0)).

     RETURNS: a list of symbols s_argi with the current sym-
              bol counters.

     SIDE EFFECT: remsym remob's all the created identifiers
                  between   zero   and  the  current  symbol
                  counter for s_argi.













     NOTE: See also initsym, newsym oldsym, allsym, and sym-
           stat functions.

(symstat s_arg1 ...)

     RETURNS: a list of pairs consisting of (s_argi symctri)
              where   symctri  is  s_argi's  current  symbol
              counter.

     NOTE: See also initsym,  newsym,  oldsym,  allsym,  and
           remsym functions.









































9

9






From jkf  Thu Aug 18 19:25:45 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA09885; Thu, 18 Aug 83 19:25:45 PDT
Date: Thu, 18 Aug 83 19:25:45 PDT
From: jkf (John Foderaro)
Message-Id: <8308190225.AA09885@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.75
Status: O

  evalhook and funcallhook can now be executed without setting (*rset t)
and (sstatus evalhook t).   Although they can be executed, they won't
have any effect unless and until (*rset t) and (sstatus evalhook t) are
done.
  The reason for this change is that now one can turn off stepping
by (sstatus evalhook nil) and then continue the evaluation with
evalhook and funcallhook.

  Those who use the new top-level 'tpl' will notice a few new commands
dealing with stepping when you type '?help'.   These new commands
are ?step, ?soff, and ?sc. Details of the commands are available
using the help mechanism (e.g. '?help step').




From jkf  Fri Aug 19 13:54:26 1983
Received: by ucbkim.ARPA (4.2/4.2)
	id AA20017; Fri, 19 Aug 83 13:54:26 PDT
Date: Fri, 19 Aug 83 13:54:26 PDT
From: jkf (John Foderaro)
Message-Id: <8308192054.AA20017@ucbkim.ARPA>
To: local-lisp
Subject: liszt 8.36
Status: O

 The compiler will now compile the form
       (*no-macroexpand* <form>)
 in a special way: if <form> is a function call, e.g. (name arg1 ...),
 then any macro properties of 'name' will be ignored for this
 invocation.  This permits one to write macros which attempt
 an optimization, and if that fails, then call the standard
 function.  *no-macroexpand* is not a function that can be called,
 thus forms with *no-macroexpand* are likely to be 'cmacros'.
 Here is an example:

   (defcmacro length (x &protect (x))
       `(if (null ,x)
          then 0
	 elseif (null (cdr ,x))
	  then 1
	 else (*no-macroexpand* (length ,x))))


 [in case you are wondering, the `&protect (x)' means that
  should the actual argument to 'length' be a non atom, defcmacro
  will lambda bind the value, insuring that it is only evaluated
  once]
 
 


From layer  Wed Aug 24 22:18:34 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA12256; Wed, 24 Aug 83 22:18:34 PDT
From: layer (Kevin Layer)
Phone: (415) 652-2405
Date: 24 Aug 1983 2218-PDT (Wednesday)
Message-Id: <12219.30.430636709@ucbkim>
To: local-lisp
Subject: liszt on kim
Status: O

  The liszt that I installed on kim yesterday, compiled eq's wrong
in some rare cases.  I installed a new one this evening that fixes
this, but if you compiled any programs with the bad one, you might
consider re-compiling them...

	Kevin

From fateman  Thu Aug 25 13:58:59 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA21033; Thu, 25 Aug 83 13:58:59 PDT
Date: Thu, 25 Aug 83 13:58:59 PDT
From: fateman (Richard Fateman)
Message-Id: <8308252058.AA21033@ucbkim.ARPA>
To: local-lisp
Status: O

I have a copy of the latest Common Lisp manual... the Excelsior Edition.

From patel@UCLA-LOCUS  Tue Aug 30 21:58:38 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA29417; Tue, 30 Aug 83 21:58:38 PDT
Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4)
	id AA06203; Tue, 30 Aug 83 21:50:26 PDT
Message-Id: <8308310450.AA06203@ucbvax.ARPA>
Date:           Tue, 30 Aug 83 21:44:13 PDT
From: Dorab Patel <patel@UCLA-LOCUS>
To: franz-friends@BERKELEY
Subject:        bug fix for 'insert' in opus 38.50
Status: O

The function 'insert' in Opus 38.50 does not perform as advertised in 
the manual if the last argument is non-nil (i.e. if no duplicates are allowed.
It still insists on putting the duplicate element into the list. The
fix is in /usr/lib/lisp/common2.l. Just change the default setting
of the 'comparefn' to that given below instead of 
(function alphalessp). Here is an excerpt from the modified file.


  [.....]
(def insert
     (lambda (x l comparefn nodups)
      (cond ((null l) (list x))
            ((atom l)
             (error "an atom, can't be inserted into" l))
            (t (cond
                ((null comparefn) (setq comparefn 
					(function
					 (lambda (x y) 
						 (or (alphalessp x y) 
						     (equal x y)))))))
               (prog (l1 n n1 y)
                     (setq l1 l)
                     (setq n (length l))
                a    (setq n1 (/ (add1 n) 2))
                     (setq y (Cnth l1 n1))
		     [..........]

From jkf  Sun Sep  4 09:59:01 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA03721; Sun, 4 Sep 83 09:59:01 PDT
Date: Sun, 4 Sep 83 09:59:01 PDT
From: jkf (John Foderaro)
Message-Id: <8309041659.AA03721@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.77
Status: O

  The 'error' function used to print its arguments and then call 'err' to
cause the familar 'call to err' error.  The problem with this is that
even if you wrap your compuatation with (errset ... nil), the error message
will still be printed.   In opus 38.77, this problem has been fixed.

A new function was added:
	(err-with-message 'st_message ['g_value])
 This causes an error to be signaled with the given message.   The message
will only be printed if an '(errset ... nil)' isn't being executed.
Normally nil is returned from an errset if an error occured.  If you provide
g_value, then it will be returned from the errset.
[Not surprisingly, 'error' now uses 'err-with-message']


Also, 'error' now takes any number of arguments.  In concatenates them,
separated by spaces, and this is the error message passed to
err-with-message.




From narain@rand-unix  Fri Sep  9 13:32:24 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA16481; Fri, 9 Sep 83 13:32:24 PDT
Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7)
	id AA11010; Fri, 9 Sep 83 13:31:58 PDT
Message-Id: <8309092031.AA11010@ucbvax.ARPA>
Date: Friday,  9 Sep 1983 10:55-PDT
To: franz-friends@BERKELEY
Cc: narain@rand-unix
Subject: Franzlisp Question
From: narain@rand-unix
Status: O


Hello all:

I would be grateful if you could answer another question regarding Franzlisp.
How does one make Franzlisp continue from an error? For example when Lisp
gives an error message like "x unbound variable", is it possible to
bind x to a value and make Lisp continue from that point? Right now we have
to start over again and it is very time consuming.

-- Sanjai

From AUSTIN@DEC-MARLBORO.ARPA  Fri Sep  9 13:46:45 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA16843; Fri, 9 Sep 83 13:46:45 PDT
Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA11248; Fri, 9 Sep 83 13:46:26 PDT
Date: 9 Sep 1983 1427-EDT
From: AUSTIN@DEC-MARLBORO
To: FRANZ-FRIENDS@BERKELEY
Subject: LIST MEMBERSHIP
Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO>
Status: O

PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION.

MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO.

THANKS!
   --------

From jkf  Sat Sep 10 12:34:14 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA28421; Sat, 10 Sep 83 12:34:14 PDT
Date: Sat, 10 Sep 83 12:34:14 PDT
From: jkf (John Foderaro)
Message-Id: <8309101934.AA28421@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.78
Status: O

 The new functions contributed by the bair group dealing with symbol
creation have been changed from fexprs to exprs (lambdas) and lexprs.

The new documentation follows:







     The functions described below are an alternative to the
gensym  facility.   They  generate  new symbols by attaching
counter numbers to the ends of the symbols' names.  An exam-
ple follows of how the functions are used.


    ____________________________________________________

    -> (initsym 'joe '(john 5))     ; initializing new symbol counters
    (joe0 john5)
    -> (newsym 'john)               ; create a new symbol
    john6
    -> (newsym 'chuck)              ; symbol need not be initsym'ed
    chuck0
    -> (oldsym 'john)               ; get current symbol
    john6
    -> (allsym 'john)               ; get all symbols between 0 and counter
    (john0 john1 john2 john3 john4 john5 john6)
    -> (allsym '(john 5))           ; get all symbols between 5 and counter
    (john5 john6)
    -> (remsym 'joe '(john 4))      ; remob all interned symbols
                                    ; associated with joe and from
                                    ; john4 to the current john
                                    ; symbol--returns symbols with symbol counters
                                    ; before doing remsym
    (joe0 john6)
    -> (symstat 'joe 'john)
    ((joe nil) (john 3))
    ____________________________________________________




(initsym 'g_arg1 ...)

     WHERE:   g_argi is a  list  (n_counteri  s_argi)  or  a
              string  s_argi  (which  is  equivalent  to  (0
              s_argi)).

     RETURNS: a list of interned identifiers using the  sym-
              bol  counters  n_counteri, i.e., the result of
              concatenating s_argi to n_counteri.

     EXAMPLE: (initsym 'joe '(john 5)) ==> (joe0 john5)

     NOTE: See also newsym, oldsym, allsym, remsym, and sym-
           stat functions.



















(newsym 's_arg)

     RETURNS: an interned identifier formed by concatenating
              the  name  s_arg  to  the  symbol  counter for
              s_arg.  The symbol counter is  stored  on  the
              property list of s_arg under symctr.  If there
              is no counter, a counter  of  0  is  used  and
              added  to  the  property list.  Thus, a symbol
              need not be initsymed.

     EXAMPLE: (initsym 'joe '(john5)) ==> (joe0 john5)
              (newsym 'john) ==> john6
              (newsym 'joe) ==> joe1

     NOTE: See also initsym,  oldsym,  allsym,  remsym,  and
           symstat functions.

(oldsym 's_arg)

     RETURNS: the  identifier  using  the   current   symbol
              counter  for s_arg, rather than creating a new
              identifier.  If no symbol counter  exists  for
              s_arg, then s_arg is returned.

     NOTE: See also initsym,  newsym,  allsym,  remsym,  and
           symstat functions.

(allsym 'g_arg)

     WHERE:   g_arg is a list (s_arg n_counter) or a  string
              s_arg (equivalent to (s_arg 0)).

     RETURNS: a list of all the created identifiers  between
              n_counter  and  the current symbol counter for
              s_arg.

     EXAMPLE: (allsym 'john) ==> (john0 john1 john2)

     NOTE: See also initsym,  newsym,  oldsym,  remsym,  and
           symstat functions.

(remsym 'g_arg1 ...)

     WHERE:   g_argi is a  list  (s_argi  n_counteri)  or  a
              string  s_argi (which is equivalent to (s_argi
              0)).

     RETURNS: a list of symbols s_argi with the current sym-
              bol counters.

     SIDE EFFECT: remsym remob's all the created identifiers
                  between   zero   and  the  current  symbol
                  counter for s_argi.













     NOTE: See also initsym, newsym oldsym, allsym, and sym-
           stat functions.

(symstat 's_arg1 ...)

     RETURNS: a list of pairs consisting of (s_argi symctri)
              where   symctri  is  s_argi's  current  symbol
              counter.

     NOTE: See also initsym,  newsym,  oldsym,  allsym,  and
           remsym functions.



















































From jkf@ucbkim  Wed Sep 14 08:04:14 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA14801; Wed, 14 Sep 83 08:04:14 PDT
Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA04212; Wed, 14 Sep 83 08:03:58 PDT
Received: by ucbkim.ARPA (4.6/4.2)
	id AA14786; Wed, 14 Sep 83 08:03:43 PDT
Date: Wed, 14 Sep 83 08:03:43 PDT
From: jkf@ucbkim (John Foderaro)
Message-Id: <8309141503.AA14786@ucbkim.ARPA>
To: franz-friends@BERKELEY
Subject: lisp distribution
Status: O

  A number of you have noticed that ftp'ing the lisp distribution from
ucb-vax can be slow at times.    As a result, we've made 'ucb-arpa' the
primary distribution machine.  You can ftp from ucb-arpa using an anonymous
login (with your name as password).   The files are in the pub/lisp
subdirectory.
					john foderaro
					



From liz%umcp-cs@UDel-Relay  Mon Sep 26 19:41:37 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA24055; Mon, 26 Sep 83 19:41:37 PDT
Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA07367; Mon, 26 Sep 83 16:28:58 PDT
Message-Id: <8309262328.AA07367@ucbvax.ARPA>
Date:     26 Sep 83 15:22:00 EDT  (Mon)
From: Liz Allen <liz%umcp-cs@UDel-Relay>
Return-Path: <liz%umcp-cs@UDel-Relay>
Subject:  Maryland software distribution
To: franz-friends@BERKELEY
Via:  UMCP-CS; 26 Sep 83 17:46-EDT
Status: O

This is to announce the availability of the Univ of Maryland software
distribution.  This includes source code for the following:

1.  The flavors package written in Franz Lisp.  This package has
    been used successfully in a number of large systems at Maryland,
    and while it does not implement all the features of Lisp Machine
    Flavors, the features present are as close to the Lisp Machine
    version as possible within the constraints of Franz Lisp.
    (Note that Maryland flavors code *can* be compiled.)
2.  Other Maryland Franz hacks including the INTERLISP-like top
    level, the lispbreak error handling package, the for macro and
    the new loader package.
3.  The YAPS production system written in Franz Lisp.  This is
    similar to OPS5 but more flexible in the kinds of lisp expressions
    that may appear as facts and patterns (sublists are allowed
    and flavor objects are treated atomically), the variety of
    tests that may appear in the left hand sides of rules and the
    kinds of actions may appear in the right hand sides of rules.
    In addition, YAPS allows multiple data bases which are flavor
    objects and may be sent messages such as "fact" and "goal".
4.  The windows package in the form of a C loadable library.  This
    flexible package allows convenient management of multiple
    contexts on the screen and runs on ordinary character display
    terminals as well as bit-mapped displays.  Included is a Franz
    lisp interface to the window library, a window shell for
    executing shell processes in windows, and a menu package (also
    a C loadable library).

You should be aware of the fact that the lisp software is based on
Franz Opus 38.26 and that we will be switching to the newer version
of lisp that comes with Berkeley 4.2 whenever that comes out.

---------------------------------------------------------------------

To obtain the Univ of Maryland distribution tape:

1.  Fill in the form below, make a hard copy of it and sign it.
2.  Make out a check to University of Maryland Foundation for $100,
    mail it and the form to:

		Liz Allen
		Univ of Maryland
		Dept of Computer Science
		College Park MD 20742

3.  If you need an invoice, send me mail, and I will get one to you.
    Don't forget to include your US Mail address.

Upon receipt of the money, we will mail you a tape containing our
software and the technical reports describing the software.  We
will also keep you informed of bug fixes via electronic mail.

---------------------------------------------------------------------

The form to mail to us is:


In exchange for the Maryland software tape, I certify to the
following:

a.  I will not use any of the Maryland software distribution in a
    commercial product without obtaining permission from Maryland
    first.
b.  I will keep the Maryland copyright notices in the source code,
    and acknowledge the source of the software in any use I make of
    it.
c.  I will not redistribute this software to anyone without permission
    from Maryland first.
d.  I will keep Maryland informed of any bug fixes.
e.  I am the appropriate person at my site who can make guarantees a-d.

				Your signature, name, position,
				phone number, U.S. and electronic
				mail addresses.

---------------------------------------------------------------------

If you have any questions, etc, send mail to me:

				-Liz Allen, U of Maryland, College Park MD
				 Usenet:   ...!seismo!umcp-cs!liz
				 Arpanet:  liz%umcp-cs@Udel-Relay


From fateman  Thu Sep 29 14:50:17 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA10806; Thu, 29 Sep 83 14:50:17 PDT
Date: Thu, 29 Sep 83 14:50:17 PDT
From: fateman (Richard Fateman)
Message-Id: <8309292150.AA10806@ucbkim.ARPA>
To: franz-friends
Subject: survey
Cc: fateman
Status: O

I am trying to collect some statistics on usage of Franz.
I would like to get answers to these questions:
(1) Your location:
(2) The number of computers at your location (actively) running Franz:
(3) Have you produced a locally modified manual? (y/n)
(4) Are other Lisps in use there? (names?)
(5) Do you use Franz for instruction? research?
(6) Are you distributing or selling packages "on top of" Franz?

(You may also send comments you wish; I will compile results and
redistribute, so please do not respond to "franz-friends", but to me.)
Thanks.

From jkf  Thu Sep 29 23:04:29 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA04355; Thu, 29 Sep 83 23:04:29 PDT
Date: Thu, 29 Sep 83 23:04:29 PDT
From: jkf (John Foderaro)
Message-Id: <8309300604.AA04355@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.80
Status: O

  Two new functions:

    (character-index 'st_string 'xst_char)

    returns the position of the character xst_char in the string
    st_string.  The position of the first character is '1'
    (1-based indexing was chosen because substring also uses
     1-based indexing).
    If the character is not in the string, nil is returned.

     xst_char, as its prefix implies, can either be the fixnum
     value of a character (commonly written #/x), or a symbol
     or string, in which case the first character is used.


  (sleep 'x_seconds)
    sleep for x_seconds.

  


From jkf  Sat Oct  1 21:42:29 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA16280; Sat, 1 Oct 83 21:42:29 PDT
Date: Sat, 1 Oct 83 21:42:29 PDT
From: jkf (John Foderaro)
Message-Id: <8310020442.AA16280@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.81
Status: O

 new function  (sys:nice 'x_delta-priority)
this increments your nice value (decrements your process priority)
by x_delta-priority.    x_delta-priority can only be negative
if you are root, of course.




From unmvax!gatech!pwh  Tue Oct  4 08:35:04 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA23488; Tue, 4 Oct 83 08:35:04 PDT
Received: by ucbvax.ARPA (4.12/4.7)
	id AA07616; Tue, 4 Oct 83 08:05:43 PDT
From: unmvax!gatech!pwh
Message-Id: <8310041505.AA07616@ucbvax.ARPA>
Date:     1 Oct 83 19:44:56-EDT (Sat)
Original-From:      <pwh@gatech>
To: franz-friends@BERKELEY
Subject:  why a HOLE (duck) ?
Status: RO


Could someone explain to me what HOLE is all about in the vax dependent 
Franz code? I've scrutinized the code and read the preliminary Franz 
implementation manual too many times and still can't figure it...

phil hutto




From mbr@nprdc  Sat Oct  8 15:59:38 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA08262; Sat, 8 Oct 83 15:59:38 PDT
Received: from nprdc (nprdc.ARPA) by ucbvax.ARPA (4.12/4.7)
	id AA23633; Sat, 8 Oct 83 15:58:02 PDT
Message-Id: <8310082258.AA23633@ucbvax.ARPA>
Date: 8 Oct 1983 15:52:17-PDT
From: Mark Rosenstein <mbr@NPRDC>
Reply-To: mbr@NPRDC
To: franz-friends@BERKELEY
Subject: bugs in liszt 8.36
Status: RO

Problem:
   -I flag doesn't work
Solution??
   in file tlev.l change 'i to 'I in line 127
   (notice that -i flag includes files and it is imposible to get
    into uci mode)

Problem:
   while compiling get message:
     Undefined function called from compiled code   e-sub2
Solution??
   in file tlev.l change e-sub2 to e-sub in line 298
   (I don't swear by this solution--my stuff seems to compile ok
    but no promises)

From jkf  Wed Oct 12 06:11:15 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA29652; Wed, 12 Oct 83 06:11:15 PDT
Date: Wed, 12 Oct 83 06:11:15 PDT
From: John Foderaro (on an h19-u) <jkf>
Message-Id: <8310121311.AA29652@ucbkim.ARPA>
To: local-lisp
Subject: New AI language in the works
Cc: 
Status: RO


From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

>From an article "Computing Women" in a shoddy little pseudo-magazine
called "Ampersand" that was stuck inside CMU's student newspaper this
week:

	Our final tip involves a different kind of research.  Is a
	breakthough in computing happening right on your own
	campus?  MIT and Carnegie-Mellon University, for example,
	are busy developing a brainchild called Lisp.  If
	successful, Lisp may become the standard language of
	``artificially intelligent'' computers that ``think''
	within a limited sphere on their own.  Imagine your
	marketability if you've worked with a poineer in this
	field.  Skip a football game some Saturday afternoon and
	see what the Prof is doing with HIS spare time.  It could
	be profitable to you.





From @MIT-MC:apm@cmu-ri-isl1  Fri Oct 14 09:27:56 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA14501; Fri, 14 Oct 83 09:27:56 PDT
Received: from MIT-MC (mit-mc.ARPA) by ucbvax.ARPA (4.12/4.7)
	id AA00195; Fri, 14 Oct 83 09:26:15 PDT
Message-Id: <8310141626.AA00195@ucbvax.ARPA>
Date: 14 Oct 1983 12:22:28-EDT
From: Andrew.Mendler@CMU-RI-ISL1
Subject: eunice version of franz
Apparently-To: <franz-friends@UCB-VAX>
Status: RO

What is the most recent version of franz lisp that is available under eunice?
In particular is opus38.55 available?

Thanks in advance.


From sklower  Fri Oct 14 09:45:15 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA14694; Fri, 14 Oct 83 09:45:15 PDT
Date: Fri, 14 Oct 83 09:45:15 PDT
From: sklower (Keith Sklower)
Message-Id: <8310141645.AA14694@ucbkim.ARPA>
To: franz-friends
Subject: eunice version of franz
Status: RO

We have opus38.79 working on David Kashtan's machine.  The source
is integrated with the vax-unix and 68000 versions, all available
by anonymous ftp, or as the regular tape distribution.  I have had
one report from a eunice user that the installation didn't get past
construction the kernel, but it could be due to insufficient quota.

From jkf  Sun Oct 16 16:39:35 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA03935; Sun, 16 Oct 83 16:39:35 PDT
Date: Sun, 16 Oct 83 16:39:35 PDT
From: John Foderaro (on an aaa-60-s) <jkf>
Message-Id: <8310162339.AA03935@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.82
Cc: 
Status: RO

  I'm working on a simple record (destruct-like) package. Consequently,
I've made 'defrecord' autoload my record package.  This will cause
problems if there are people who use the name 'defrecord' as a
non-macro function.   If this will cause you problems, please speak up.



From procter@UCBMIRO  Mon Oct 17 08:59:02 1983
Received: from UCBMIRO.ARPA by ucbkim.ARPA (4.6/4.2)
	id AA01206; Mon, 17 Oct 83 08:59:02 PDT
Date: 16 Oct 83 22:56:00 PDT (Sun)
From: procter@UCBMIRO (Steve Procter)
Subject: cfasl
Message-Id: <8310170556.AA01323@UCBMIRO.ARPA>
Received: by UCBMIRO.ARPA (3.340/3.29)
	id AA01323; 16 Oct 83 22:56:00 PDT (Sun)
To: local-lisp@ucbkim
Status: O

	How are arguements passed from lisp to the C routines?
I wrote a program which just printed the arguements passed to it, 
and when I cfasl'd it and used it, I got argc > 500000...

						steve procter
						procter@ucbmiro

From jkf  Mon Oct 17 10:08:37 1983
Received: by ucbkim.ARPA (4.6/4.2)
	id AA02418; Mon, 17 Oct 83 10:08:37 PDT
Date: Mon, 17 Oct 83 10:08:37 PDT
From: John Foderaro (on an h19-u) <jkf>
Message-Id: <8310171708.AA02418@ucbkim.ARPA>
To: procter@UCBMIRO
Subject: Re: cfasl
Cc: local-lisp
In-Reply-To: Your message of 16 Oct 83 22:56:00 PDT (Sun)
Status: O

  Arguments are passed to C functions in the normal C way (on the stack
not as strings on the command line).   There are examples in the
lisp manual (in the section on foreign functions).



From whm.Arizona@Rand-Relay  Fri Oct 28 05:44:39 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
	id AA20395; Fri, 28 Oct 83 05:44:39 pdt
Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
	id AA14289; Fri, 28 Oct 83 05:43:48 pdt
Message-Id: <8310281243.AA14289@ucbvax.ARPA>
Date: 28 Oct 1983 01:12:45-PST
From: whm.arizona@Rand-Relay
Return-Path: <whm.Arizona@Rand-Relay>
Subject:  Memory management in Franz
Date-Sent: 28 Oct 83 01:12:42 MST  (Fri)
To: franz-friends@BERKELEY
Via:  Arizona; 28 Oct 83 2:37-PDT
Status: O

I've got a couple of questions about Franz Lisp storage management that
I wondering if somebody "in the know" might be able to answer.  I tried
this on net.lang.lisp, but didn't get any answers.

First, Franz seems to support non-relocatable data objects such as
external functions.  Are such objects managed by having two logical
regions in managed memory, one for relocatable objects and one for
non-relocatable objects?  Such a scheme has been used in other systems
that require garbage collection and I was wondering if Franz uses
this or some other scheme.

Second, I've heard (but not tried) that Franz allows non-relocatable
data to be allocated via brk/sbrk.  Is this true?

(Actually, I suppose I'd like information on any storage management
implementations for any languages (w/ automatic storage management)
that allow non-relocatable data to be dynamically allocated that don't
use the aforementioned scheme.)

					Thanks,
					Bill Mitchell
					whm.arizona@rand-relay
p.s.
I'm not on the Franz-Friends list, so if you would, please mail me
any replies.

From whm.Arizona@Rand-Relay  Mon Oct 31 04:55:33 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
	id AA29912; Mon, 31 Oct 83 04:55:33 pst
Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
	id AA08771; Mon, 31 Oct 83 04:54:49 pst
Message-Id: <8310311254.AA08771@ucbvax.ARPA>
Date: 31 Oct 1983 00:41:38-PST
From: whm.arizona@Rand-Relay
Return-Path: <whm.Arizona@Rand-Relay>
Subject:  Memory management in Franz
Date-Sent: 31 Oct 83 00:41:36 MST  (Mon)
To: franz-friends@BERKELEY
Via:  Arizona; 31 Oct 83 1:36-PST
Status: O

[My apologies if this is a repeat; I got some very wierd messages back
from the Berkeley mailer on my first attempt to send this.]

I've got a couple of questions about Franz Lisp storage management that
I wondering if somebody "in the know" might be able to answer.  I tried
this on net.lang.lisp, but didn't get any answers.

First, Franz seems to support non-relocatable data objects such as
external functions.  Are such objects managed by having two logical
regions in managed memory, one for relocatable objects and one for
non-relocatable objects?  Such a scheme has been used in other systems
that require garbage collection and I was wondering if Franz uses
this or some other scheme.

Second, I've heard (but not tried) that Franz allows non-relocatable
data to be allocated via brk/sbrk.  Is this true?

(Actually, I suppose I'd like information on any storage management
implementations for any languages (w/ automatic storage management)
that allow non-relocatable data to be dynamically allocated that don't
use the aforementioned scheme.)

					Thanks,
					Bill Mitchell
					whm.arizona@rand-relay
p.s.
I'm not on the Franz-Friends list, so if you would, please mail me
any replies.

From pjt@brl-voc  Tue Nov  1 06:52:11 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
	id AA03145; Tue, 1 Nov 83 06:52:11 pst
Received: from BRL-VOC (brl-voc.ARPA) by ucbvax.ARPA (4.16/4.13)
	id AA01150; Tue, 1 Nov 83 06:51:14 pst
Message-Id: <8311011451.AA01150@ucbvax.ARPA>
Date:     Tue, 1 Nov 83 9:44:54 EST
From: Paul Tanenbaum <pjt@brl-voc>
To: Ailist-requests@sri-ai, Franz-Friends@BERKELEY
Cc: pjt@brl-voc
Subject:  mailing list
Status: O

Please cons me onto your mailing list
     Thanks,
     paul   <pjt@brl-voc>


From norvig  Fri Nov  4 14:14:16 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA20986; Fri, 4 Nov 83 14:14:16 pst
Date: Fri, 4 Nov 83 14:14:16 pst
From: norvig (Peter Norvig)
Message-Id: <8311042214.AA20986@ucbkim.ARPA>
To: mills@ernie
Subject: Graphics on Suns
Cc: local-lisp
Status: O

I want a lisp-callable package to display trees and graphs on the suns.
This is for showing semantic nets, and it would also be useful for showing
how procedures call each other, like Interlisp's masterscope. Does anyone
know of such a package?

From kanderso@bbn-vax  Fri Nov  4 19:55:59 1983
Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
	id AA26540; Fri, 4 Nov 83 19:55:59 pst
Received: from bbn-vax (bbn-vax.ARPA) by ucbvax.ARPA (4.16/4.13)
	id AA03738; Fri, 4 Nov 83 19:55:52 pst
Message-Id: <8311050355.AA03738@ucbvax.ARPA>
Date: Fri, 4 Nov 83 22:55 EST
From: Ken Anderson <kanderso@BBN-Vax>
Subject: Why no &keywords in local functions?
To: franz-friends@BERKELEY
Status: O

With liszt version 8.29 (Opus 38.66 of Franz) I get the following message:

?Error: save.l: save-install: local functions can't use &keyword's save-install

When compiling the function (declared as a localf):

(defun save-install (thing table &aux type handler)
    ; Install thing in hash table, and recursively install its parts.
    (cond ((memq (setq type (save-type thing))
		 '(symbol number)))	; Needn't install
	  (t (cond ((zerop (save-count++ thing))
		    ; Increment access count, and install parts of thing if it
		    ; is being installe
		    (cond ((setq handler (get type 'save-install-parts))
			   (funcall handler thing table))
			  (t (ferror "Don't Know how to save ~S~%" thing))))))))

This used to work in earlier Opuses (like 38.44).  Can you explain the
change.

From norvig  Tue Nov  8 01:51:03 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA20986; Fri, 4 Nov 83 14:14:16 pst
Date: Fri, 4 Nov 83 14:14:16 pst
From: norvig (Peter Norvig)
Message-Id: <8311042214.AA20986@ucbkim.ARPA>
To: mills@ernie
Subject: Graphics on Suns
Cc: local-lisp
Status: O

I want a lisp-callable package to display trees and graphs on the suns.
This is for showing semantic nets, and it would also be useful for showing
how procedures call each other, like Interlisp's masterscope. Does anyone
know of such a package?

From norvig  Tue Nov  8 02:03:27 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA20986; Fri, 4 Nov 83 14:14:16 pst
Date: Fri, 4 Nov 83 14:14:16 pst
From: norvig (Peter Norvig)
Message-Id: <8311042214.AA20986@ucbkim.ARPA>
To: mills@ernie
Subject: Graphics on Suns
Cc: local-lisp
Status: O

I want a lisp-callable package to display trees and graphs on the suns.
This is for showing semantic nets, and it would also be useful for showing
how procedures call each other, like Interlisp's masterscope. Does anyone
know of such a package?

From sklower  Thu Nov 17 17:03:27 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA01897; Thu, 17 Nov 83 17:03:27 pst
Date: Thu, 17 Nov 83 17:03:27 pst
From: sklower (Keith Sklower)
Message-Id: <8311180103.AA01897@ucbkim.ARPA>
To: local-lisp
Subject: lisp sources
Status: O

Franz now resides in /usr/franz.

From jkf  Tue Nov 22 09:33:32 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA15675; Tue, 22 Nov 83 09:33:32 pst
Date: Tue, 22 Nov 83 09:33:32 pst
From: John Foderaro (on an h19-u) <jkf>
Message-Id: <8311221733.AA15675@ucbkim.ARPA>
To: local-lisp
Subject: liszt 8.39
Cc: 
Status: O

  The -W switch has been added to liszt.  When specified, if a compilation
causes any warning messages to given (such as a symbol declared special),
then the compiler will not perform the assembly and will return a non-zero
exit status (for 'make's benefit).   Liszt will continue to compile after it
has seen a warning, even if -W is given, to permit as many warnings as
possible to be made in each compile.




From barry%umcp-cs@CSNet-Relay  Tue Nov 22 17:14:09 1983
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA23508; Tue, 22 Nov 83 17:14:09 pst
Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.21/4.15)
	id AA06655; Tue, 22 Nov 83 17:13:29 pst
Message-Id: <8311230113.AA06655@UCB-VAX.ARPA>
Date:     22 Nov 83 12:48:01 EST  (Tue)
From: Barry Perricone <barry%umcp-cs@CSNet-Relay>
Return-Path: <barry%umcp-cs@CSNet-Relay>
Subject:  Franz for VMS
To: franz-friends@BERKELEY
Via:  UMCP-CS; 22 Nov 83 19:25-EST
Status: O


  I need to know if anybody has a version of Franz for the Vax series
under VMS which includes 'liszt'.  Also one which when a 'dumplisp'
is performed will output a file which can execute as a stand-alone
(i.e., does not need to be "restored").  I would appreciate
any information on this matter, and if one exists information
on how I could obtain a copy of it.

Thanks in advance,
Barry P.

From alfred.ct@Rand-Relay  Sat Dec  3 22:40:07 1983
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA12594; Sat, 3 Dec 83 22:40:07 pst
Received: from rand-relay.ARPA by UCB-VAX.ARPA (4.22/4.16)
	id AA06631; Sat, 3 Dec 83 21:43:27 pst
Message-Id: <8312040543.AA06631@UCB-VAX.ARPA>
Date: 3 Dec 1983 11:58:11-PST
From: alfred.ct@Rand-Relay
Return-Path: <alfred.ct@Rand-Relay>
Subject: Deficiency in Franz GC
To: franz-friends@BERKELEY
Via:  ct; 3 Dec 83 12:46-PST
Status: RO

This really isn't a bug so much as a deficiency
in the code.  We are running Opus 38.26 and recently
had need to increase the constant TTSIZE (in config.h)
above the default 10216.  It turns out that this
breaks the garbage collector which will fail
to completely clear the array bitmapi
if given a TTSIZE greater 10216 (during the
clearing out of bit maps).  The offending code
is in Talloc.c (or alloc.c, depending on your Opus).
The old code is:

	/* try the movc5 to clear the bit maps */
	/* the maximum number of bytes we can clear in one sweep is
	 * 2^16 (or 1<<16 in the C lingo)
	 */
	bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; 
	if(bytestoclear > MAXCLEAR)
	{ 
	   blzero(((int) &bitmapi[((int)beginsweep>>7)]) + MAXCLEAR, 
			    bytestoclear - MAXCLEAR);
	   bytestoclear = MAXCLEAR;
	}
	blzero((int)&bitmapi[((int)beginsweep)>>7],bytestoclear);

and the fixed version that we have been running for several weeks
now is:

	/* try the movc5 to clear the bit maps */
	/* the maximum number of bytes we can clear in one sweep is
	 * 2^16 (or 1<<16 in the C lingo)
	 */
	bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16;
	{int count = 0; 
    	while (bytestoclear > 0) {
	    if(bytestoclear > MAXCLEAR)
	    { 
	   	blzero(((int) &bitmapi[((int)beginsweep>>7)])+count*MAXCLEAR, 
			    MAXCLEAR);
	   	++count;
	    }
	    else
	    	blzero(((int)&bitmapi[((int)beginsweep)>>7]+count*MAXCLEAR),
			bytestoclear);
   	    bytestoclear -= MAXCLEAR;
	    }
	}

The old code is still present in Opus 38.56.

Alfred Correira
Paul Robertson
...ucbvax!nbires!ctvax!alfred (UUCP)
alfred.ct@Rand-Relay (CSNET)

From fateman  Tue Dec 13 09:11:00 1983
Received: by ucbkim.ARPA (4.16/4.13)
	id AA03666; Tue, 13 Dec 83 08:31:30 pst
Date: Tue, 13 Dec 83 08:31:30 pst
From: fateman (Richard Fateman)
Message-Id: <8312131631.AA03666@ucbkim.ARPA>
To: local-lisp
Cc: pattrsn
Status: O

I have just received a copy of the new Common Lisp Reference Manual
(The Mary Poppins Edition ... Practically Perfect in Every Way)
... it is 385 pages long.

From hoey@nrl-aic  Wed Jan 11 12:58:53 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA06395; Wed, 11 Jan 84 12:58:53 pst
Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
	id AA03955; Wed, 11 Jan 84 12:58:55 pst
Message-Id: <8401112058.AA03955@UCB-VAX.ARPA>
Date: 11 Jan 1984 14:43-EST
From: Dan Hoey <hoey@NRL-AIC>
Subject: Problems with arrays in Franz
Apparently-To: <FRANZ-FRIENDS@berkeley>
Status: O



From hoey@nrl-aic  Wed Jan 11 13:10:01 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA06529; Wed, 11 Jan 84 13:10:01 pst
Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
	id AA04150; Wed, 11 Jan 84 13:09:46 pst
Message-Id: <8401112109.AA04150@UCB-VAX.ARPA>
Date: 11 Jan 1984 14:43-EST
From: Dan Hoey <hoey@NRL-AIC>
Subject: Problems with arrays in Franz
To: FRANZ-FRIENDS@BERKELEY
Status: O

Hard to believe but it was less than two and a half years ago that
someone was having trouble using Franz arrays...

    Date: 17 Jul 1981 17:06:22-PDT
    From: CSVAX.jkf at Berkeley
    To: FININ@WHARTON-10
    cc: franz-friends at MIT-MC
    Subject: Re: ... the maclisp-style array package.
    In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday).

        From: FININ@WHARTON-10
        Subject: ... the maclisp-style array package.

        ...
        [3] We've been having problems with the MacLisp compatable array
            package - it doesn't work!  Does anyone have a debugged version?

    Can you be more specific? We use it in Vax Macsyma without any problems.
    Personally I feel that Maclisp arrays were invented by a madman and no new
    code should be written using them.  

    -- john foderaro

Well, I used the Maclisp array package because I didn't want to waste
time writing my own.  Instead I spent hours looking for the bug in this
code:

    -> (let ((factorial (*array () () 100.)))
            (store (factorial 0) 1)
	    (do ((i 1 (1+ i)))
	        ((= i 100.))
                (store (factorial i) (times i (factorial (1- i)))))
            (factorial 10.))
    285656

To make a long story short, this lossage is because the second argument
to *array being nil tells the garbage collector not to scan the
array.  The factorial of ten gets tossed in the bit bucket, where it
unfortunately looks like a fixnum.  To fix the example, change the
first line of the example to

    -> (let ((factorial (*array () t 100.)))

To save someone else from excruciatingly wrong answers, change the
documentation in Section 2.

    (*array 's_name 's_type 'x_dim1 ... 'x_dimn)
    (array s_name s_type x_dim1 ... x_dimn)

         WHERE:   s_type may be one of t, nil,  fixnum,  flonum,
                  fixnum-block and flonum-block.
           ...
<                  In FRANZ LISP arrays of type t, nil, fix-
<          num and flonum are equivalent and the elements of
<          these  arrays  can  be  any  type of lisp object.
---
>                  In  FRANZ  LISP arrays of type t, fixnum,
>          and  flonum  are  equivalent  and the elements of
>          these arrays can  be  any  type  of  lisp object.
>          Type nil arrays may also contain any type of lisp
>          object,  but  they are not marked  by the garbage
>          collector  (see 9.2.2)  and can lose data if used
>          incorrectly.
           Fixnum-block and  flonum-block  arrays  are  res-
           tricted  to  fixnums and flonums respectively and
           are used mainly to communicate with foreign func-
           tions (see 8.4).

Dan

From hoey@nrl-aic  Wed Jan 11 16:23:56 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA06395; Wed, 11 Jan 84 12:58:53 pst
Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
	id AA03955; Wed, 11 Jan 84 12:58:55 pst
Message-Id: <8401112058.AA03955@UCB-VAX.ARPA>
Date: 11 Jan 1984 14:43-EST
From: Dan Hoey <hoey@NRL-AIC>
Subject: Problems with arrays in Franz
Apparently-To: <FRANZ-FRIENDS@berkeley>
Status: O



From fateman@ucbdali  Sun Jan 15 14:58:17 1984
Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13)
	id AA00458; Sun, 15 Jan 84 14:58:17 pst
Received: by ucbdali.ARPA (4.22/4.18)
	id AA02865; Sun, 15 Jan 84 14:58:51 pst
Date: Sun, 15 Jan 84 14:58:51 pst
From: fateman@ucbdali (Richard Fateman)
Message-Id: <8401152258.AA02865@ucbdali.ARPA>
To: franz-friends@ucbdali
Subject: FUGUE.3
Status: O








                        FUGUE Notes

               An occasional publication of the
    Franz Lisp User Group under Unix and Eunice (FUGUE)

                  Number 3 (January, 1984)
                edited by Richard J. Fateman
                  University of California
                     Berkeley CA 94720
                            USA
                      fateman@berkeley

_1.  _W_e_l_c_o_m_e!

     It seems about time  to  publish  the  third  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.  _N_e_w _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s

     Franz now runs on a number of Motorola 68000 and  68010
systems,  including  DUAL,  PIXEL,  Apple-LISA  (UNIX),  and
undoubtedly a large number of other UNISOFT Inc. UNIX ports.
(The  LISA  has  only  a 1 megabyte address space, and hence
cannot run the compiler.  It can  load  cross-compiled  pro-
grams.)  Non-UNISOFT  UNIX  systems we have Franz running on
include the 4.2BSD" Sun Microsystems operating system.

     Some work is beginning on  high-speed  VLSI  chips  for
Lisp, using the reduced instruction set technology which has
been successfully used at UCB in the past.  More information
on this will be available in the near future.

_3.  _N_e_w _p_r_o_g_r_a_m_s

_3._1.  _V_a_x_i_m_a _a_n_d _A_l_g_e_b_r_a_i_c _M_a_n_i_p_u_l_a_t_i_o_n

     Macsyma runs on the 68000 workstations with  sufficient
memory  both virtual and real.  At least 4 megabytes of vir-
tual is needed, but benchmarks suggest  that  anything  less
than  2 megabytes of real memory is painful.  We recommend 4
or more real megabytes.  The PIXEL machine with 6  megabytes
(unpaged) is our fastest real-time Macsyma system, (CPU-time
is about 25% longer than reported VAX-780 CPU time, but more
to the point, CPU-time is equal to real-time).  Distribution
____________________
9   UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
SRI Int'l, and Univ. of Calif.



9










of 68000 Macsyma will presumably be done by Symbolics, (con-
tact  RP@mit-mc,  with  a  cc to fateman@berkeley if you are
interested).

     Development of a new algebra system and  user  applica-
tion  modules  is  proceeding,  and  a  programming language
called Newspeak, initially implemented on top of  Franz,  is
the  principal vehicle. This is described in John Foderaro's
PhD dissertation, available from the  CS  Division  at  UCB.
(Newspeak  is  hierarchical,  object-oriented,  and strongly
typed;  is  compiler-based,  and  should  provide  efficient
access  to  machine  resources).   While the algebra code is
progressing well, we are not yet ready to set a release date
for the user-end of the system, tentatively named Xi.

_4.  _N_e_w _f_e_a_t_u_r_e_s

     As usual,  various  performance  enhancements  and  bug
fixes  have  been  incorporated in versions of Franz (now on
Opus 38.87 and the compiler, Liszt 8.39) Most  changes  made
it  into  the  recent Berkeley 4.2BSD UNIX distribution, and
reported alterations will not be repeated here.

_5.  _O_t_h_e_r _L_i_s_p_s

     We understand that a version of PSL will  be  supported
by  Hewlett  Packard,  on  its workstations, and that Common
Lisp, from DEC will  have  initial  field-test  in  January,
1984.   We  believe  PSL  should be available from Utah in a
form for running on 4.2BSD VAX UNIX; similarly for "T"  from
Cognitive  Systems.   We  believe that a Common-Lisp support
package for Franz may be constructed, but probably not at UC
under current funding. (see Business news below, though).

_6.  _W_o_r_k _i_n _P_r_o_g_r_e_s_s

_6._1.  _G_r_a_p_h_i_c_s

     Gregg Foster has  constructed  a  graphics  Franz  Lisp
which  includes  the  full Sun Microsystems Graphics package
for Sun-2 systems, and Keith Sklower has  constructed  a  C-
structure  package  in  Franz  to enable programmers to more
easily construct arbitrary C-structures in Lisp, to pass  to
C.  Various  demonstration  programs  have  been  written to
access the smooth-curve plotting capabilities, variable-size
fonts, etc.

_6._2.  _I_B_M _F_r_a_n_z

     Still more nibbles on this one, but not yet. We heard a
rumor  of  work  at  Columbia University. (also see the next
item.)
9

9










_7.  _B_u_s_i_n_e_s_s _N_e_w_s

_7._1.  _F_r_a_n_z _I_n_c

     A new software company has been formed to support Franz
and  application  programs,  and  is  seeking customers in 3
categories: (a) manufacturers of hardware wishing to  obtain
a  Lisp  system  and/or Lisp support; (b) software producers
who wish to have reliable access to experts  in  Franz,  for
enhancement,  support, training or porting of existing code.
(c) end-users who are using Franz or applications written in
Franz and need help in customizing, debugging, conversion to
or from other dialects, etc.

     The University of California will continue  to  distri-
bute  Franz  Lisp  on  its current basis, but your questions
about support in any of these categories,  or  about  future
plans,  can be directed to Franz Inc. Most of the principals
at UC will be participating in this venture.  Contact  Franz
Inc. via fkunze@berkeley, or (to avoid abuse of various net-
work privileges), Fritz Kunze, President, Franz  Inc.,  6321
Thornhill Drive, Oakland, Ca 94611 (415) 339-1481.






























9

9




From cowan@AEROSPACE  Thu Jan 19 09:56:25 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA14836; Thu, 19 Jan 84 09:56:25 pst
Received: from aerospace.ARPA by UCB-VAX.ARPA (4.22/4.19)
	id AA02684; Thu, 19 Jan 84 09:55:33 pst
Message-Id: <8401191755.AA02684@UCB-VAX.ARPA>
Date:           Thu, 19 Jan 84 09:55:01 PST
From: Ric Cowan <cowan@AEROSPACE>
To: franz-friends@BERKELEY
Subject:        Help
Status: O

Hi, 

I'm starting a new project and would like to use Franz lisp. It is a large
application that needs to:

	(1) Run on a VAX 11/780 under VMS.
	(2) Interface with INGRESS.
	(3) Support a menu driven interface with VT100 type terminals.

Is Franz lisp a viable language to use? 

Thanks in advance,

Ric Cowan

From levitt@aids-unix  Thu Jan 26 17:44:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA10074; Thu, 26 Jan 84 17:44:03 pst
Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.19)
	id AA02121; Thu, 26 Jan 84 17:01:25 pst
Message-Id: <8401270101.AA02121@UCB-VAX.ARPA>
Date: 26 Jan 1984 16:25:55-PST
From: Tod Levitt <levitt@aids-unix>
To: franz-friends@BERKELEY
Subject: report PAM 124, "Parlez vous Franz..." by James Larus
Cc: levitt@aids-unix
Status: O

I am trying to obtain a copy of PAM report 124 which discusses
interfacing foreign functions to Franzlisp. Can someone please
point me at a source for this document? Thanks...
                            Tod Levitt (levitt@aids-unix)

From jkf@ucbmike  Fri Jan 27 08:44:54 1984
Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
	id AA15308; Fri, 27 Jan 84 08:44:54 pst
Date: Fri, 27 Jan 84 08:44:40 pst
From: John Foderaro (on an h19-u) <jkf@ucbmike>
Message-Id: <8401271644.2469@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.17/3.5)
	id AA02469; Fri, 27 Jan 84 08:44:40 pst
To: local-lisp@kim
Subject: lisp 38.88
Cc: 
Status: O

 The 'msg' macro now accepts the special form (T 'x_column), and it
spaces over to that column (plus 1).

-> (msg "foo" (T 10) "bar" N "baz" (T 11) "bof" N)
foo       bar
baz        bof
nil
->

Note that the method used to locate the column only works if nothing
has yet been actually written on the line.  Problems will occur if you drain
the port in the middle of the line.

For example:
-> (msg "foo" D (T 10) "bar" N		<< here we drain after "foo"
        "foo"   (T 10) "bar" N)
foo          bar		<< thus column 11 turns out to be column 14
foo       bar
nil
->


From jkf@ucbmike  Tue Jan 31 10:55:51 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
	id AA20759; Tue, 31 Jan 84 10:55:51 pst
Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21)
	id AA12296; Tue, 31 Jan 84 10:51:34 pst
Date: Tue, 31 Jan 84 10:51:33 pst
From: John Foderaro (on an sun-e) <jkf@ucbmike>
Message-Id: <8401311851.1218@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.17/3.5)
	id AA01218; Tue, 31 Jan 84 10:51:33 pst
To: franz-friends@BERKELEY
Subject: LISPcraft, a book on Lisp and Franz.
Cc: 
Status: O

  A new Lisp book is due out March 23rd which may be especially interesting 
to Franz Lisp users or potential Franz Lisp users.   The title
is `LISPcraft' and it was written by Robert Wilensky, a Computer Science
professor at Berkeley who teaches AI programming courses.
  The book starts at first principles and teaches Lisp programming, and then 
goes on to Franz-specific topics such as debugging, read macros, error 
handling, and compilation.   Then there are chapters on Lisp 
applications: pattern matching and databases.  Finally it contains 
a complete description of all Franz functions.

details:
LISPcraft, by Robert Wilensky    385 pages, $19.95
publisher: W. W. Norton, 500 5th Avenue, N.Y. N.Y.  10110
           800-223-2584




From jkf@ucbmike  Fri Feb  3 08:03:58 1984
Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
	id AA19272; Fri, 3 Feb 84 08:03:58 pst
Date: Fri, 3 Feb 84 08:04:17 pst
From: John Foderaro (on an h19-u) <jkf@ucbmike>
Message-Id: <8402031604.2117@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.17/3.5)
	id AA02117; Fri, 3 Feb 84 08:04:17 pst
To: local-lisp@kim
Subject: opus 38.89
Cc: 
Status: O

 In opus 38.88 the msg macro was extended to make (T n) put the cursor
on column n+1.   Others had extended the msg macro in a conflicting way,
so we decided to convert over to their extensions.  So forget what
you read in the opus38.88 message, and remember this:
	(C n)	go to column n.  The first column on the line is column 1.
	        If the cursor is beyond column n, then go to the next line
		and go to column n.
	(T m)   print m tab characters
	
	
	


From jkf  Thu Feb 16 10:32:03 1984
Received: by ucbkim.ARPA (4.16/4.22)
	id AA16308; Thu, 16 Feb 84 10:32:03 pst
Date: Thu, 16 Feb 84 10:32:03 pst
From: John Foderaro (on an sun-e) <jkf>
Message-Id: <8402161832.AA16308@ucbkim.ARPA>
To: local-lisp
Subject: opus 38.90
Cc: 
Status: O

 For those of you using the 'tpl' toplevel, the new command ?fast
will set all switches for maximum speed:
	(*rset nil)
	(sstatus translink on)
	(setq displace-macros t)
 	


From wilensky@ucbdali  Wed Feb 22 09:58:43 1984
Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22)
	id AA16486; Wed, 22 Feb 84 09:58:43 pst
Received: by ucbdali.ARPA (4.22/4.22)
	id AA06784; Wed, 22 Feb 84 09:57:21 pst
Date: Wed, 22 Feb 84 09:57:21 pst
From: wilensky@ucbdali (Robert Wilensky)
Message-Id: <8402221757.AA06784@ucbdali.ARPA>
To: andy@aids-unix, franz-friends@ucbdali
Subject: Re: Franz Flavors & software copyright
In-Reply-To: Your message of 21 Feb 1984 16:29-PST
Status: O


Thanks for your clarification.  Everything you said is consistent with my
understanding of the situation.  And you are correct in emphasizing the
complexity of the issue.  But I want to stress my main point.  This is
that the ``author'' holds the copyright.  It may be unclear who the author
is, but it is clearly NOT the university. 

In addition, many pieces of ``university-developed'' software have
contributions by unfunded students, and by faculty, whose salary is not paid
by the gov't (except maybe during the summer).  Furthermore, it would seem
to be unclear who the author is if it is, say, a student working as a gov't
sponsored r. a.  For example, the student's thesis is presumably his to
copyright, even if the student were paid by the gov't because it was not
part of what he was paid to do.  One could argue that a concommitant program
has the same status unless it were specifically contracted for.

Let me state that my main purpose was not to promote people selling their
code, but rather, to stop the universities from impeding its distribution.
As far as I know, the gov't hasn't tried to prevent us from giving each
other our software, but many universities have.  Therefore, we are better
off leaving them out of the picture entirely - legally this seems to be a
sound position.


From jkf@ucbmike  Wed Mar 14 09:04:55 1984
Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
	id AA00884; Wed, 14 Mar 84 09:04:55 pst
Date: Wed, 14 Mar 84 08:58:51 pst
From: John Foderaro (on an h19-u) <jkf@ucbmike>
Message-Id: <8403141658.3782@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.17/3.5)
	id AA03782; Wed, 14 Mar 84 08:58:51 pst
To: fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
Subject: lisps running wild 
Cc: local-lisp@kim
In-Reply-To: Your message of Tue, 13 Mar 84 21:45:25 pst
Status: O

re:	
	From: chris@ucbcory (Chris Guthrie)
	We are having a good deal
	of trouble with them being left running instead of dying and killing
	the load here.

The problem is that people are setting a flag in their lisp init files
which instruct lisp to ignore 'end of file' (much like the c shell).
If a connection is broken (ipc connection breaks or modem hangs up), then
lisp is sent a hangup signal (which it ignores) and then a continuous
sequence of 'end of files' which it ignores after a bit of processing.
The solution is this:
  If you have something in your init file which instructs lisp to ignore
end of files  (such as (sstatus ignoreeof t)), then you should also
have   (signal 1 'exit)   in the init file so lisp will exit upon a hangup.




From mcgeer  Wed Mar 14 09:37:45 1984
Received: by ucbkim.ARPA (4.16/4.22)
	id AA01437; Wed, 14 Mar 84 09:37:45 pst
Date: Wed, 14 Mar 84 09:37:45 pst
From: Rick McGeer (on an aaa-60-s) <mcgeer>
Message-Id: <8403141737.AA01437@ucbkim.ARPA>
To: jkf@ucbmike, chris@cory, layer@ucbdali, sklower@ucbdali, fateman@ucbdali
Subject: Re: lisps running wild 
Cc: local-lisp
In-Reply-To: Your message of Wed, 14 Mar 84 08:58:51 pst
Status: O

	John, your top level sets the ignoreeof flag.  Does it also set the
appropriate signal, or should your users do that themselves?


From jkf@ucbmike  Wed Mar 14 09:48:04 1984
Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
	id AA01603; Wed, 14 Mar 84 09:48:04 pst
Date: Wed, 14 Mar 84 09:42:15 pst
From: John Foderaro (on an h19-u) <jkf@ucbmike>
Message-Id: <8403141742.3833@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.17/3.5)
	id AA03833; Wed, 14 Mar 84 09:42:15 pst
To: mcgeer@ucbkim, fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
Subject: Re: lisps running wild 
Cc: local-lisp@ucbkim
In-Reply-To: Your message of Wed, 14 Mar 84 09:37:45 pst
Status: O

 Since ignoreeof is always set in the new top level, I'll make 'exit on
hangup' the default if you use the new top level.

  


From ROD@SU-AI.ARPA  Sat Mar 17 13:45:58 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22)
	id AA05623; Sat, 17 Mar 84 13:45:58 pst
Received: from SU-AI.ARPA by UCB-VAX.ARPA (4.24/4.25)
	id AA12441; Sat, 17 Mar 84 13:47:35 pst
Message-Id: <8403172147.AA12441@UCB-VAX.ARPA>
Date: 17 Mar 84  1347 PST
From: Rod Brooks <ROD@SU-AI.ARPA>
Subject: Don't use Franz sortcar!
To: franz-friends@BERKELEY
Status: O


Somewhat bizzarely it seems that Franz Lisp sort and sortcar have
different time complexities. sort is good and sortcar is bad so
I suggest you convert your sortcar's to sort's until someone sorts
this out. The code and transcript below use both sort and sortcar
to sort a list of length n (the list happens to start in precisely
reverse order). A count of the number of calls to the comparison
function is kept. The results show that sort takes n*log(n)
comparisons while sortcar takes n*n. The problem should
be fixable by throwing out code as there must be two sorters lurking
in there!

;;;;;;;;;;;;;;;

(defun gen (n)
    (do ((i 0 (1+ i))
	 (l () (cons (cons i ()) l)))
	((= i n)
	 l)))

(defun compare (x y)
    (setq *count* (1+ *count*))
    (< x y))

(defun compare-cars (x y) (compare (car x) (car y)))

(defun count-sort (n)
    (let ((*count* 0))
	 (sort (gen n) #'compare-cars)
	 *count*))

(defun count-sortcar (n)
    (let ((*count* 0))
	 (sortcar (gen n) #'compare)
	 *count*))

(defun test (n)
    (let ((csort (count-sort n))
	  (csortcar (count-sortcar n)))
	 (list n
	       csort
	       csortcar
	       (/$ (float csort) (*$ (float n) (log n)))
	       (/$ (float csortcar) (float (* n n))))))

;;;;;;;;;;;;;;;

Here's the transcript. The lists of 5 elements are:
	n
	compares for sort
	compares for sortcar
	compares for sort / n*log(n)
	compares for sortcar / n*n


Franz Lisp, Opus 38
-> (load 'test)
t
-> (test 3)
(3 3 6 0.910239226626837 0.6666666666666667)
-> (test 100)
(100 460 9900 0.9988773083774791 0.99)
-> (test 200)
(200 1020 39800 0.9625697456705496 0.995)
-> (test 300)
(300 1440 89700 0.8415468193831012 0.9966666666666667)
-> (test 400)
(400 2240 159600 0.9346629619469353 0.9975)
-> 


From @MIT-MC:smh@MIT-EMS  Wed Mar 28 06:11:15 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
	id AA06408; Wed, 28 Mar 84 06:11:15 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
	id AA23759; Wed, 28 Mar 84 06:10:43 pst
Message-Id: <8403281410.AA23759@UCB-VAX.ARPA>
Date: 28 Mar 1984 09:09:38-EST
From: <smh@mit-ems@mit-mc>
To: franz-friends@BERKELEY
Subject: Fixes for setf return value problem
Status: O

As FranzFriends readers will know, my message several days ago
generated a number of comments.  The clear consensus was that setf
should be fixed, not the documentation.  This was obvious.  The reason
I didn't suggest the fix myself was that I felt it was far more
important to preserve compatibility between Franz and the various other
more-or-less-source-compatible Lisps (aka Common Lisps).  It was my
impression that code relying on the value returned by setf would not
be portable.

I have since learned that Common Lisp does indeed define setf to return
the new value (its second argument), and that other implementations
(i.e. MIT and Symbolics Lisp Machines) indeed work this way.  (Mind
you, I haven't checked this myself -- the information is second hand.)
The fixes to setf are quite straightforward and are brief enough that I
am including them below.  For each case that the setf macro evaluates
to a {rplaca, rplacd, rplacx} the corresponding {car, cdr, cxr} is now
wrapped around it.  The Liszt compiler seems smart enough to remove the
extra reference if the value is ignored.

The new setf functions follow.  The starting version is the Opus 38.69
common2 identified by:
;; common2.l				-[Fri Jul  8 17:46:13 1983 by layer]-
(Although only two lines of setf-check-car+d were changed, the entire
function is included because the change is difficult to locate by
context.)  I suggest these changes be made in the official sources.
Whoever wants to install them should edit common2.l and remake the
Franz interpreter.  The Liszt compiler does not need to be changed.
====================

; modified 27Mar84 SMH@MIT-EMS@MT-MC (see comment below)
;
(defun setf-check-cad+r (name)
 (if (eq (getcharn name 1) #/c)
     then (let
	   ((letters (nreverse (cdr (exploden name)))))
	   (if (eq (car letters) #/r)
	       then (do ((xx (cdr letters) (cdr xx)))
			((null xx)
			 ;; form is c{ad}+r, setf form is
			 ;; (rplac<first a or d> (c<rest of a's + d's>r x))
			 (setq letters (nreverse letters))
			 (eval
			  `(defsetf ,name (e v)
					; SMH@MIT-EMS@MIT-MC	
					; added next line and matching rparen.
				    (list ',(implode `(#/c ,(car letters) #/r))
				     (list
				      ',(concat "rplac" (ascii (car letters)))
				      (list
				       ',(implode `(#/c ,@(cdr letters)))
				       (cadr e))
				      v))))	; SMH@MIT-EMS@MIT-MC
			 t)
			(if (not (memq (car xx) '(#/a #/d)))
			    then (return nil)))))))

. . .

;--- other setf's for car's and cdr's are generated automatically
;
; modified 27Mar84 SMH@MIT-EMS@MIT-MC
; Now whenever setf macro expands to a rplac[adx], the corresponding c[adx]r
; is now wrapped around it so that setf consistently returns its second arg.
; The compiler is smart enough to remove the extra operation if the value
; is not used.
;
(defsetf car (e v) `(car (rplaca ,(cadr e) ,v)))
(defsetf caar (e v) `(car (rplaca (car ,(cadr e)) ,v)))
(defsetf cadr (e v) `(car (rplaca (cdr ,(cadr e)) ,v)))
(defsetf cdr (e v) `(cdr (rplacd ,(cadr e) ,v)))
(defsetf cdar (e v) `(cdr (rplacd (car ,(cadr e)) ,v)))
(defsetf cddr (e v) `(cdr (rplacd (cdr ,(cadr e)) ,v)))
(defsetf cxr (e v) `(cxr ,(cadr e) (rplacx ,(cadr e) ,(caddr e) ,v)))

. . .

(defsetf nth (e v) `(car (rplaca (nthcdr ,(cadr e) ,(caddr e)) ,v)))
(defsetf nthelem (e v) `(car (rplaca (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))
(defsetf nthcdr (e v) `(cdr (rplacd (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))

. . .

; (defsetf args (e v) `(args ,(cadr e) ,v))	; no longer implemented?

====================

Steven Haflich
MIT Experimental Music Studio
(617)253-7441
smh@mit-ems@mit-mc
decvax!genrad!mit-ems!smh


From fateman@ucbdali  Thu Mar 29 12:07:33 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
	id AA20323; Thu, 29 Mar 84 12:07:33 pst
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.25)
	id AA22790; Thu, 29 Mar 84 12:07:08 pst
Received: by ucbdali.ARPA (4.24/4.22)
	id AA04139; Thu, 29 Mar 84 12:07:10 pst
Date: Thu, 29 Mar 84 12:07:10 pst
From: fateman@ucbdali (Richard Fateman)
Message-Id: <8403292007.AA04139@ucbdali.ARPA>
To: franz-friends@BERKELEY
Subject: commercialization of Franz
Status: O


Some people may have gotten the incorrect impression that 
the University of California will cease sending out 
tapes of Franz Lisp.  We intend to continue distribution
of the latest version which is the property of UCB.  This is
currently opus 38.91.  This distribution works, so far as we know,
on SUN releases (0.4, 1.0, 1.1) and Masscomp, and VAX 4.2BSD.
Such distributions will continue, and will continue to be unsupported.
Although we have made reasonable efforts to provide a useful,
portable, efficient, and complete system, we have spent too much of
our time and our sponsors' money in answering
questions about installation-dependent difficulties or 
(what USUALLY turns out to be non-existent) bugs.
I might point out that many of the questions come from commercial users.

Franz Inc. was formed to provide a mechanism for support, transportation
of Franz Lisp to new architectures, enhancements, documentation, etc.
It has the (non-exclusive) right to use, distribute, (etc) Franz Lisp,
and intends to produce enhancements that the University does not
have funding for. I expect that if enhancements of Franz Lisp at UCB 
are produced, these will next be made available on 4.3 BSD tapes. Earlier
distributions of contributed software or locally produced software
MAY occur, but cannot be promised.

I expect that there will continue to be a large number of Franz Lisp
users who are satisfied with the university distribution (on 4.2BSD)
or on the separate tapes (e.g. after opus 38.79) that UCB is sending out.
Others will want the enhanced, supported, version from Franz Inc.

The divergence of versions,
some of which has already occurred with local variants of older
systems being redistributed, seems inevitable regardless of Franz Inc.

I hope this clarifies UCB's position.



From @MIT-MC:smh@MIT-EMS  Wed Apr  4 15:44:42 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
	id AA07196; Wed, 4 Apr 84 15:44:42 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
	id AA01892; Wed, 4 Apr 84 15:14:05 pst
Message-Id: <8404042314.AA01892@UCB-VAX.ARPA>
Date: 4 Apr 1984 16:44:49-EST
From: <smh@mit-ems@mit-mc>
To: franz-friends@BERKELEY
Subject: Re: recent suggested fix to setf
Status: O

There was one mistake in my recent posting with fixes for the Franz
setf function.  I said that it was not necessary to remake liszt (the
compiler).  This was wrong:  code compiled with an old copy of liszt
will not use the modified setf definitions.

The fix is simply to remake liszt after the new Franz interpreter has
been generated.

Sorry about any confusion.

Steve Haflich
MIT Experimental Music Studio
decvax!genrad!mit-ems!smh
smh@mit-ems@mit-mc


From MCLINDEN@RUTGERS.ARPA  Wed Apr 18 20:37:26 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
	id AA16547; Wed, 18 Apr 84 20:37:26 pst
Received: from RUTGERS.ARPA (rutgers.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA29663; Wed, 18 Apr 84 20:36:21 pst
Message-Id: <8404190436.AA29663@UCB-VAX.ARPA>
Date: 18 Apr 84 23:37:14 EST
From: Sean McLinden  <MCLINDEN@RUTGERS.ARPA>
Subject: [Sean McLinden  <MCLINDEN@RUTGERS.ARPA>: Re: Franz on Suns under 4.2?]
To: franz-friends@BERKELEY
Status: O

Mail-From: MCLINDEN created at 18-Apr-84 23:33:56
Date: 18 Apr 84 23:33:56 EST
From: Sean McLinden  <MCLINDEN@RUTGERS.ARPA>
Subject: Re: Franz on Suns under 4.2?
To: allegra!jdd@UCB-VAX.ARPA
cc: MCLINDEN@RUTGERS.ARPA
In-Reply-To: Message from "allegra!jdd@Berkeley (John DeTreville)" of 18 Apr 84 13:10:10 EST



 I must be missing something with all of this discussion of Franz
 Lisp on Suns. We have had no trouble at all running the current
 (opus 38.91?) Berkeley release on Suns and have been running Sun
 Franz Lisp for nearly a year now.

 The only serious problem that I can recall happened a few sub versions
 ago and was due to a logical error in the C-coded algorithm which
 determined when to garbage collect (as things would have it, it
 never did). The result was that liszt was unable to compile some
 of the lisp coded sources due to the 2 Meg/process limit imposed
 by the Sun operating system (the bug existed in the Vax version as
 well but one would only see it if the lisp image exceeded 6 megs
 which is rare for a compiler run).

 Perhaps you could be more explicit in describing what, exactly,
 the problem is. The people at Berkeley most probably have Suns
 and I am sure that they don't release Sun versions without testing
 them.

 Sean McLinden
 Decision Systems Lab
 University of Pittsburgh
 School of Medicine
-------
-------

From varghese%colostate.csnet@csnet-relay.arpa  Fri May 25 18:47:11 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20472; Fri, 25 May 84 18:47:11 pdt
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA23631; Fri, 25 May 84 18:45:35 pdt
Message-Id: <8405260145.AA23631@UCB-VAX.ARPA>
Received: From colostate.csnet by csnet-relay;  25 May 84 21:17 EDT
Date: Fri, 25 May 84 13:47:24 mdt
From: varghese%colostate.csnet@csnet-relay.arpa
Received: by csu-cs.UUCP (4.12/3.14)
	id AA11606; Fri, 25 May 84 13:47:24 mdt
To: FRANZ-FRIENDS.BERKELEY@csnet-relay.arpa
Subject: Addition to mailing list




Please add us to the mailing list. Since there will be more than one 
person at this site who wants to be on the mailing list we decided to 
get everything mailed to one central mailbox. 
The mailbox address for this mailing list is 

	frnzlist@colostate

Please note that this is a CSnet address. Thank you,

						    Joe Varghese
						    varghese@colostate


From trk@cmu-cs-g.arpa  Sun Jun  3 19:15:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA07648; Sun, 3 Jun 84 19:15:03 pdt
Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA24832; Sun, 3 Jun 84 19:13:42 pdt
Date: 3 Jun 1984 22:02-EST
From: Todd.Kueny@CMU-CS-G.ARPA
Subject: Please add my name to the list
To: FRANZ-FRIENDS@BERKELEY
Message-Id: <455162572/trk@CMU-CS-G>

Please add my name to the FRANZ-FRIENDS list.
							-Todd K.

From Jonl.pa@Xerox.ARPA  Sun Jun  3 23:24:19 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA09575; Sun, 3 Jun 84 23:24:19 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
	id AA27487; Sun, 3 Jun 84 23:22:53 pdt
Message-Id: <8406040622.AA27487@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT
Date: 3 Jun 84 23:22 PDT
From: Jonl.pa@XEROX.ARPA
Subject: This is a test
To: Franz-Friends@BERKELEY

Sorry to bother you -- this is only a test of correct forwarding on this mailing list.


From @MIT-MC:sl@cmu-ri-isl1.arpa  Mon Jun 18 17:09:37 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA21265; Mon, 18 Jun 84 17:09:37 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA19453; Mon, 18 Jun 84 17:07:25 pdt
Message-Id: <8406190007.AA19453@UCB-VAX.ARPA>
Date: 18 Jun 1984 12:48:57-EDT
From: Simon.Lowenfeld@CMU-RI-ISL1
Subject: old messages
Apparently-To: <franz-friends@UCB-VAX>

Is there some kind of archive for old postings?
I am interested in the Franz/T argument
from earlier this year.


From wkc@Ardc.ARPA  Tue Jun 19 07:36:37 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA01983; Tue, 19 Jun 84 07:36:37 pdt
Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA01762; Tue, 19 Jun 84 07:34:31 pdt
Message-Id: <8406191434.AA01762@UCB-VAX.ARPA>
Date:     Tue, 19 Jun 84 10:31:27 EDT
From: William K. Cadwallender (LCWSL) <wkc@Ardc.ARPA>
To: franz-friends@BERKELEY
Subject:  Franz for VAX730

	We are about to purchase a VAX730 with BSD4.2 UNIX. Has anyone out thereheard of a port of Franz, or ANY LISP to a 730? Please reply to the net or directly to wkc@ARDC.
			Bill Cadwallender (wkc@ARDC)

From RZ@MIT-MC  Thu Jun 21 19:26:57 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA08546; Thu, 21 Jun 84 19:26:57 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA27996; Thu, 21 Jun 84 19:24:37 pdt
Message-Id: <8406220224.AA27996@UCB-VAX.ARPA>
Date: 21 June 1984 22:28-EDT
From: Richard E. Zippel <RZ@MIT-MC>
Subject:  MIT flavors
To: franz-friends@BERKELEY
Cc: zymelman@MITRE, smh@MIT-VAX
In-Reply-To: Msg of 21 Jun 1984  9:19:16 EDT () from Ari Zymelman <m13676 at mitre>

I am happy to report than the MIT flavor system is finally available.  I
won't try to correct the numerous bits of misinformation that have been
spread about this other than to say that the MIT flavor system can now be
freely distributed, if it is not used for profit, and the MIT copyrights are
maintained in the sources.  Berkeley has a copy of the most recent version
of the code and should include it in their standard distributions shortly.


From hoey@nrl-aic  Wed Jun 27 14:24:24 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA19372; Wed, 27 Jun 84 14:24:24 pdt
Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA13744; Wed, 27 Jun 84 14:21:16 pdt
Message-Id: <8406272121.AA13744@UCB-VAX.ARPA>
Date: 27 Jun 1984 16:42-EDT
From: Dan Hoey <hoey@NRL-AIC>
Subject: Incorrect "make fromasm" in 68k franz 38.91
To: franz-friends@BERKELEY
Cc: dejong@nrl-aic, franz-bugs@BERKELEY

Problem:
The "make fromasm" option for franz installation on a 68k does not work
as distributed.

Diagnosis:
The assembler is used to convert *.s files into *.o.  But the output of
as defaults to "a.out" and is not overridden, so no *.o files are
produced.

Fixes:
Specify the output file in the fromasm: option in lisplib/Makefile and
liszt/68k/Makefile.

In lisplib/Makefile, and (if make copylibrary has been done) in
/usr/lib/lisp/Makefile, change

<	for i in *.s; do echo $$i; ${LibDir}/as $$i; done
----
>	for i in *.s; do echo $$i; \
>	${LibDir}/as $$i -o `basename $$i .s`.o; done

In liszt/68k/Makefile, change

<	for i in *.s; do echo $$i; as $$i; done
----
>	for i in *.s; do echo $$i; \
>	as $$i -o `basename $$i .s`.o; done

Bugs:
1.  One version specifies ${LibDir}/as, the other uses vanilla as.  I
    didn't change it, but perhaps the liszt/68k/Makefile should also
    specify ${LibDir}/as.

2.  Isn't there a cleaner way of doing this?  Can a ".s.o:" rule be
    specified?

Dan

From @MIT-MC:rsw@cmu-cs-h.arpa  Mon Jul  9 22:06:26 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA17486; Mon, 9 Jul 84 22:06:26 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA24170; Mon, 9 Jul 84 22:05:52 pdt
Message-Id: <8407100505.AA24170@UCB-VAX.ARPA>
Date: 9 Jul 1984 21:10:53-EDT
From: Richard.Wallace@CMU-CS-H
Subject: Bell quote
Apparently-To: <franz-friends@UCB-VAX>

Lisp, designed about 1960 by John McCarthy, impressed me so 
much that I included the critcal data access primitives
in the architecture of the DEC System 10 in 1965 (still
about the fastest Lisp computer).

                        - C. Gordon Bell
                          IEEE Computer
                          June, 1984



From kanderso@bbn-vax  Tue Jul 10 11:41:39 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA25755; Tue, 10 Jul 84 11:41:39 pdt
Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA06454; Tue, 10 Jul 84 11:29:28 pdt
Message-Id: <8407101829.AA06454@UCB-VAX.ARPA>
Date: Tue, 10 Jul 84 14:28 EDT
From: Ken Anderson <kanderso@bbn-vax>
Subject: Problem compiling flavors in Opus 83.79
To: franz-friends@BERKELEY
Cc: franz-composers@BERKELEY, lbagnall@bbn, jchung@bbn

When trying to make flavors from the version in pub/lib on ucbkim,
liszt complains about calling an undefined function e-sub2.  Here is
the output of my makefile.  Any suggestions?

liszt -a flavorm
Compilation begins with Liszt vax version 8.36
source: flavorm.l, result: flavorm.o
[fasl /usr/lib/lisp/machacks.o]
[autoload /usr/lib/lisp/struct]
[fasl /usr/lib/lisp/struct.o]
flavor-plist
flavor-init-keywords
flavor-initable-instance-variables
flavor-settable-instance-variables
flavor-gettable-instance-variables
flavor-default-handler
flavor-which-operations
flavor-depends-on-all
flavor-includes
flavor-depended-on-by
flavor-depends-on
flavor-method-table
flavor-all-instance-variables
flavor-local-instance-variables
flavor-name
flavor-method-hash-table
flavor-bindings
make-flavor
alter-flavor
instancep
instancep::cmacro:g00079
send
lexpr-send
send-self
lexpr-send-self
g00100::send
%Note: flavorm.l: Compilation complete
%Note: flavorm.l:  Time: Real: 0:32, CPU: 0:11.10, GC: 0:0.00 for 0 gcs
%Note: flavorm.l: Assembly begins
%Note: flavorm.l: Assembly completed successfully
liszt -a flavors
Compilation begins with Liszt vax version 8.36
source: flavors.l, result: flavors.o
[fasl /usr/lib/lisp/machacks.o]
[fasl /usr/lib/lisp/lmhacks.o]
[fasl flavorm.o]
defflavor
defun-method
[autoload /usr/lib/lisp/struct]
[fasl /usr/lib/lisp/struct.o]
instance-variable-boundp
instance-flavor
instance-flavor::cmacro:g00068
instance-function
instance-function::cmacro:g00075
get-flavor
instance-typep
flavor-additional-instance-variables
flavor-additional-instance-variables::cmacro:g00101
flavor-instance-variable-initializations
flavor-instance-variable-initializations::cmacro:g00108
flavor-remaining-default-plist
flavor-remaining-default-plist::cmacro:g00115
flavor-remaining-init-keywords
flavor-remaining-init-keywords::cmacro:g00122
flavor-all-initable-instance-variables
flavor-all-initable-instance-variables::cmacro:g00129
g00133::flavor
Undefined function called from compiled code   e-sub2
?Error: flavors.l: : Lisp error during compilation
make: *** Error code 1 ***

From jkf@ucbmike  Tue Jul 10 12:18:28 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA27111; Tue, 10 Jul 84 12:18:28 pdt
Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
	id AA07135; Tue, 10 Jul 84 12:06:28 pdt
Date: Tue, 10 Jul 84 12:07:07 pdt
From: John Foderaro (on an sun) <jkf@ucbmike>
Message-Id: <8407101907.3780@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.24ucb/3.5)
	id AA03780; Tue, 10 Jul 84 12:07:07 pdt
To: kanderso@bbn-vax, franz-friends@BERKELEY
Subject: Re: Problem compiling flavors in Opus 83.79
Cc: jchung@bbn, lbagnall@bbn, franz-composers@BERKELEY
In-Reply-To: Your message of Tue, 10 Jul 84 14:28 EDT

 This bug was fixed a while back, but apparently after you got your lisp
distribution.  You should get the latest lisp distribution.



From @MIT-MC:stw@cmu-cs-spice.arpa  Tue Jul 10 13:29:15 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA28822; Tue, 10 Jul 84 13:29:15 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA08350; Tue, 10 Jul 84 13:28:25 pdt
Message-Id: <8407102028.AA08350@UCB-VAX.ARPA>
Date: 10 Jul 1984 13:46:05-EDT
From: Suzanne.Woolf@CMU-CS-SPICE
Subject: pretty printer
Apparently-To: <franz-friends@UCB-VAX>

Does anyone out there know of a well-documented pretty printer for lisp?  A
friend of mine needs one that can be hacked up.  Franz Lisp would be ideal,
but anything similar is fine.

Please send replies to:
Jaffe@cmu-psy-a

Thanks.



From @MIT-MC:smh@MIT-EMS  Tue Jul 10 15:29:20 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA02481; Tue, 10 Jul 84 15:29:20 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA10890; Tue, 10 Jul 84 15:28:30 pdt
Message-Id: <8407102228.AA10890@UCB-VAX.ARPA>
Date: 10 Jul 1984 18:24:02-EDT
From: <smh@mit-ems@mit-mc>
To: franz-friends@BERKELEY, kanderso@bbnvax
Subject: Re: Problem compiling flavors in Opus 83.79

A very quick check reveals the following suspiciousness:  The function
in flavors.l being compiled when the failure occurs is apparently:

(DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS)
  (SELECTQ OPERATION
	   (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE))
	   (:PRINT-SELF
	    (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS))
	       (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF))))
	   (:DESCRIBE (DESCRIBE-FLAVOR SELF))
	   (OTHERWISE
	    (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION))))

This is the first appearance in the file of defun with a "function
spec" instead of a symbol as the first argument.  This is a Lisp
Machine hack which basically means to squirrel the functional object
away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR.
(More precisely, the first arg is the Maclisp compatability syntax for
(:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...)

Liszt could be choking as it tries to store into the
function-definition slot of something other than a symbol.  Such
abilities of defun are not documented in Franz, and it might be that
your defun macro in common0.l has not been extended for such usage.
Locally it is defined as follows:

;--- defun
; maclisp style function defintion
;
(def defun
   (macro (l)
      (prog (name type arglist body specind specnam)
	 (setq name (cadr l) l (cddr l))
	 (cond ((dtpr name)
		(cond ((memq (cadr name) '(macro expr fexpr lexpr))
		       (setq l (cons (cadr name) l)
			     name (car name)))
		      (t (setq specnam (car name)
			       specind (cadr name)
			       name (concat (gensym) "::" specnam))))))
	 (cond ((null (car l)) (setq type 'lambda))
	       ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l)))
	       ((eq 'expr (car l))  (setq type 'lambda l (cdr l)))
	       ((eq 'macro (car l)) (setq type 'macro l (cdr l)))
	       ((atom (car l))
		(setq type 'lexpr
		      l (nconc (list (list (car l)))
			       (cdr l))))
	       (t (setq type 'lambda)))
	 (setq body (list 'def name (cons type l)))
	 (cond (specnam
		  (return (list 'progn ''compile
				body
				(list 'putprop
				      (list 'quote specnam)
				      (list 'getd
					    (list 'quote name))
				      (list 'quote specind)))))
	       (t (return body))))))

You could also check by invoking liszt without arguments and then
asking it
	(testmac '(defun (foo bar) () (hello goodbye)))
and seeing if it properly generates
	(progn 'compile (defun ... ) (putprop ... ))

On another matter, I have recently been making a number of minor
bugfixes to the flavor and various other MIT compatibility packages.
These files come indirecly from Maclisp or Lisp Machines, and the ports
have generally never been exercised sufficiently to check all the
obscure features.  These fixes postdate the versions Rich Zippel
recently transmitted to Berkeley.  I will shortly distribute the
new versions to Berkeley.

Believe it or not, the flavor system really does work under Franz.
So do hash tables, defstruct, format, etc.  I use them every day.

Steve Haflich, MIT Experimental Music Studio
smh@mit-ems@mit-mc
{decvax!genrad, ihnp4}!mit-eddie!smh


From abar@ucbernie  Tue Jul 10 23:04:16 1984
Received: from ucbernie.ARPA by ucbkim.ARPA (4.28/4.27)
	id AA08764; Tue, 10 Jul 84 23:04:16 pdt
Received: by ucbernie.ARPA (4.28/4.30)
	id AA06176; Tue, 10 Jul 84 23:02:56 pdt
Date: Tue, 10 Jul 84 23:02:56 pdt
From: abar@ucbernie (Robert Abarbanel)
Message-Id: <8407110602.AA06176@ucbernie.ARPA>
To: franz-friends@ucbernie
Subject: &optional, &rest, &aux

Any way to get these &args to work without compilation... that is, when
a function is working interpreted?

From kanderso@bbn-vax  Wed Jul 11 12:25:52 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA17391; Wed, 11 Jul 84 12:25:52 pdt
Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA19991; Wed, 11 Jul 84 12:24:54 pdt
Message-Id: <8407111924.AA19991@UCB-VAX.ARPA>
Date: Wed, 11 Jul 84 15:24 EDT
From: Ken Anderson <kanderso@bbn-vax>
Subject: bugs in hash.l and array.l
To: franz-friends@BERKELEY
Cc: lbagnall@bbn, jchung@bbn

To get Flavors working in Opus 38.91 you will need to fix a bug in
lisplib/hash.l.  Change all occurances of "getlength" to "vsize".

Although unrelated to Flavors, there are several problems with
the functions, fillarray fillarrayarray and listarray in
lisplib/array.l.  Here is an ed script produced by diff:

285,286c
	       (cond ((or (arrayp arr)		; KRA
			  (and (symbolp arr) (arrayp (setq arr (getd arr))))))
.
282,283c
    (lexpr (n)
	   (prog (arr size typ ret newv)
.
280a
; KRA 83-11-2:  Arrays need not be symbols.
.
279c
		    (replace (arrayref arrto i) (arrayref arrfrom i)))
		(return arrto))))	; KRA
.
270c
		    (cond ((cdr ls) (setq ls (cdr ls)))))
		(return arr))))		; KRA
.
244a
; KRA 83-11-2:  Fillarray  and fillarrayarray should return the array!
.

From jkf@ucbmike  Wed Jul 11 13:43:49 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA20014; Wed, 11 Jul 84 13:43:49 pdt
Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
	id AA21120; Wed, 11 Jul 84 13:32:32 pdt
Date: Wed, 11 Jul 84 13:32:52 pdt
From: John Foderaro (on an sun) <jkf@ucbmike>
Message-Id: <8407112032.5402@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.24ucb/3.5)
	id AA05402; Wed, 11 Jul 84 13:32:52 pdt
To: franz-friends@BERKELEY
Subject: Re: &optional, &rest, &aux
Cc: franz-composers@BERKELEY
In-Reply-To: Your message of 11 Jul 1984 15:12:07-EDT

 The problem with the &optional and &rest was due to abar using the
cmufile package, which redefines 'def' and doesn't look for those
keywords.



From uucp-5@cmu-cs-g.arpa  Wed Jul 11 20:29:28 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA25212; Wed, 11 Jul 84 20:29:28 pdt
Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA28089; Wed, 11 Jul 84 20:28:27 pdt
Reply-To: cadre!sm@CMU-CS-G.ARPA
Received: by cadre.UUCP (4.12/3.14)
	id AA22394; Wed, 11 Jul 84 23:22:09 edt
Date: Wed, 11 Jul 84 23:22:09 edt
From: cadre!sm (Sean McLinden)
Message-Id: <8407120322.AA22394@cadre.UUCP>
To: jkf@ucbmike.BERKELEY
Subject: redefinition of existing flavors
Cc: franz-friends@BERKELEY


 As distributed by Berkeley, the flavors package on Opus 38.89
 appears to work in all cases except when a flavor is redefined
 and perform-flavor-redefinition is invoked. The problem, I
 thought, was in copy-hunk-contents, since the default structures
 (and therefore flavors), in Opus 38.89, are VECTORS, not HUNKS.
 However, modifying copy-hunk-contents to copy VECTORS did not,
 completely, fix the problem (i.e, the first modification after
 redefinition of copy-hunk-contents caused an error, the second
 worked but then describe did not work for old instances of the
 flavor).

 Before delving into code with which I am unfamiliar are there
 any differences between Opus 38.89 and 38.91 which might explain
 this?

 Sean McLinden
 Decision Systems Lab
 University of Pittsburgh


From harrison@nrl-aic  Thu Jul 12 07:15:39 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA28967; Thu, 12 Jul 84 07:15:39 pdt
Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA07280; Thu, 12 Jul 84 07:14:50 pdt
Date: 12 Jul 1984 10:08-EDT
From: Patrick Harrison <harrison@NRL-AIC>
Subject: Lisp for Honeywell 6060 DPS-8
To: ailist@sri-ai
Cc: franz-friends@BERKELEY
Message-Id: <84/07/12 1008.550@NRL-AIC>


     Am looking for information on current versions of LISP (FranzLisp,
MacLisp) running in a Honeywell 6060, DPS-8 environment. Would also
like to implement OPS5 on same.  Address:
   
                        Dr. Patrick Harrison
                        Computer Science Department
                        U.S. Naval Academy
                        Annapolis, Maryland 21402.
 
Responses to above address or <harrison@nrl-aic>

From @MIT-MC:mhs@MIT-HTVAX  Tue Jul 17 12:45:10 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA00659; Tue, 17 Jul 84 12:45:10 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA02214; Mon, 16 Jul 84 16:28:19 pdt
Message-Id: <8407162328.AA02214@UCB-VAX.ARPA>
Date: 16 Jul 1984 16:32:48-EDT
From: mhs@mit-htvax@mit-mc
To: franz-friends@berkeley@mit-mc
Subject: Small bug in flavors.l
Cc: mhs@mit-htvax@mit-mc

    The following test demonstrates a problem with flavors.l as it is
distributed with Release 38.91.  (The "a" after the minor number indicates a
couple of changes made locally - mostly involving preloading struct, loop and
such.  flavors.l wasn't touched.)

    The problem is that simple method combination doesn't work for trivial
reasons.  A fix is suggested below.  As the example shows, the combined method
for :PROGN combination is wrong. (:OR, :LIST ... all have the same problem).

Franz Lisp, Opus 38.91a (with Zetalisp compatability package)
-> (defflavor object
     (color)
     ()
     :gettable-instance-variables
     :settable-instance-variables
     :initable-instance-variables
     (:method-combination (:progn :base-flavor-last :test1)))
object
-> (defmethod (object :test1) ()
     (format t "~&object :test1~%"))
(:method object :test1)
-> (defflavor car
     (price)
     (object)
     :gettable-instance-variables
     :settable-instance-variables
     :initable-instance-variables)
car
-> (defmethod (car :test1) ()
     (format t "~&car :test1~%"))
(:method car :test1)
-> (setq car (make-instance 'car))
#<car 591928>
-> (send car ':test1)
|Error:| eval: Undefined function  :progn
<1>: (debug)

<------debug------>

:bk

<------debug------>   <--- you are here
(eval (debug))
(break-err-handler (|ER%undef| 0 t |eval: Undefined function | :progn))
(:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.))
((lambda (.daemon-caller-args.) .daemon-caller-args. (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.))) (do ((g00005 g00004 (|1-| g00005)) (g00006 () (cons (arg g00005) g00006))) ((< g00005 1) g00006)))
,
,
,
(send car (quote :test1))
(eval (send car (quote :test1)))
<bottom of stack>

    Look at the combined method:

(:progn
     (lexpr-funcall (function car-test1-method) .daemon-caller-args.)
     (lexpr-funcall (function object-test1-method) .daemon-caller-args.))

    I think the problem is caused by the fact that in the older package system,
the keyword package inherited from the global package.  Thus :PROGN (in the
keyword package) was the same atom as PROGN (in global).  However, this isn't
true in Franz.  :PROGN isn't EQ to PROGN, and it shouldn't be.  (The same
problem occurs for all of the other simple method combination types too, e.g.
:OR, :LIST ...).  One possible fix is to add an alist
(SIMPLE-METHOD-COMBINATION-TYPE-ALIST) to store the correspondence between
:PROGN and PROGN, like so:  (I just tested this code locally and it seemed to
work.)

#+franz
(DEFCONST SIMPLE-METHOD-COMBINATION-TYPE-ALIST
        '((:PROGN . PROGN)
          (:AND . AND)
          (:OR . OR)
          (:MAX . MAX)
          (:MIN . MIN)
          (:+ . +)
          (:APPEND . APPEND)
          (:NCONC . NCONC)))

(DEFUN SIMPLE-METHOD-COMBINATION (FL MAGIC-LIST-ENTRY)
  (LET ((METHODS (GET-CERTAIN-METHODS MAGIC-LIST-ENTRY NIL NIL NIL NIL))
	(WRAPPERS-P (SPECIALLY-COMBINED-METHODS-PRESENT MAGIC-LIST-ENTRY)))
    (OR (AND (NOT WRAPPERS-P) (NULL (CDR METHODS)) (CAR METHODS))
	(HAVE-COMBINED-METHOD FL MAGIC-LIST-ENTRY)
	(MAKE-COMBINED-METHOD FL MAGIC-LIST-ENTRY
           ;; In the old package system, :progn maps to progn trivially
           ;; via package inheritance (keyword inherits from global).
           ;; In Franz, we use an alist to implement the mapping.
	   (CONS #-franz (CADR MAGIC-LIST-ENTRY)
                 #+franz (CDR (ASSQ (CADR MAGIC-LIST-ENTRY) 
                                 SIMPLE-METHOD-COMBINATION-TYPE-ALIST))
		         (MAPCAR 'METHOD-CALL
			         METHODS))))))


From "Gladd Tom"@LLL-MFE.ARPA  Wed Jul 18 10:44:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA00765; Wed, 18 Jul 84 10:44:03 pdt
Received: from LLL-MFE.ARPA (lll-mfe.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
	id AA01412; Wed, 18 Jul 84 10:42:20 pdt
Message-Id: <8407181742.AA01412@UCB-VAX.ARPA>
Date: Wed, 18 Jul 84 10:35 PDT
From: "Gladd Tom"@LLL-MFE.ARPA
Subject: join list 619-453-6580
To: franz-friends@BERKELEY

i would like to join your list. i am very interested in list in general
and have been trying to learn it in a near vacuum (small hi-tech company
in sandiego. i am especially interested in advanced coding techniques
(at least beyond the standard texts). my background is theoretical
plasma physics. i have used and am very interested in macsyma.
my address is "gladd tom%cma"@lll-mfe.arpa

From @MIT-MC:pmk@cmu-ri-isl2.arpa  Wed Jul 25 10:06:41 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA08698; Wed, 25 Jul 84 10:06:41 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA19747; Wed, 25 Jul 84 10:05:06 pdt
Message-Id: <8407251705.AA19747@UCB-VAX.ARPA>
Date: 25 Jul 1984 12:30:25-EDT
From: Philip.Kasprzyk@CMU-RI-ISL2
Subject: Lisp Speed Benchmarks
Apparently-To: <franz-friends@UCB-VAX>

~v
I am interested in determining the absolute speed of execution of a lisp
system. I realize that this is a complicated task that is application
and implementation dependant. Nevertheless I am seeking the following:

1) A "gibson mix" style benchmark for lisp based systems.

2) Any data that experienced users of lisp may have regarding performance.
    (I don't care what machine or dialect of lisp is reported)

3) Any method or program which translates a lisp program into another
    target high level language with execution speed as its objective.
	(I don't mean a normal lisp compiler)

Can anyone out there help me? 

If so send mail to pmk@isl2.



From mab@aids-unix  Fri Jul 27 14:35:21 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA29865; Fri, 27 Jul 84 14:35:21 pdt
Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA04068; Fri, 27 Jul 84 14:33:40 pdt
Message-Id: <8407272133.AA04068@UCB-VAX.ARPA>
Date: 27 Jul 84 14:23:47 PDT (Fri)
From: Mike Brzustowicz <mab@aids-unix>
Subject: Benchmarks
To: franz-friends@BERKELEY

Does anyone have any small LISP programs that can be abused as benchmarks?
(They need to be small is source only.)  I need some very soon.  Thanks!

-Mike
<mab@aids-unix>

From Masinter.pa@Xerox.ARPA  Fri Jul 27 15:15:06 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA01124; Fri, 27 Jul 84 15:15:06 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA04900; Fri, 27 Jul 84 15:13:09 pdt
Message-Id: <8407272213.AA04900@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT
Date: 27 Jul 84 15:14 PDT
From: Masinter.pa@XEROX.ARPA
Subject: Re: Benchmarks
In-Reply-To: Mike Brzustowicz <mab@AIDS-UNIX.ARPA>'s message of 27 Jul
 84 14:23:47 PDT (Fri)
To: mab@AIDS-UNIX.ARPA
Cc: franz-friends@BERKELEY

Here's a good benchmark:

(defun nilret () nil)

this is a good test of how fast your lisp returns NIL.

I also like

(defun retjunk (x) (cond((junkp x)  'junk)
				 ((cdr x) (retjunk (car x)))
				 ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x))))
				 (t (retjunk (cons 'junk x))))

(defun junkp (x) (equal (reverse (explode x)) (reverse (explode
'junk))))


This benchmark measures how fast your lisp can return junk, executing
the retjunk function.

Both of the benchmarks have the adavantage that they are small and can
be abused as benchmarks.

From @USC-ECL.ARPA:BENSON@ECLD  Tue Jul 31 20:02:20 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
	id AA21521; Tue, 31 Jul 84 20:02:20 pdt
Received: from USC-ECL.ARPA (usc-ecl.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA02839; Tue, 31 Jul 84 20:00:29 pdt
Message-Id: <8408010300.AA02839@UCB-VAX.ARPA>
Received: from ECLD by ECLA with ECLnet; Tue 31 Jul 84 19:56:31-PDT
Date: Tue 31 Jul 84 19:33:52-PDT
From: Eric Benson <BENSON@ECLD.#ECLnet>
Subject: Re: Lisp Speed Benchmarks
To: Philip.Kasprzyk@CMU-RI-ISL2.ARPA
Cc: BENSON@ECLD.#ECLnet, Franz-Friends@BERKELEY
In-Reply-To: Message from "Philip.Kasprzyk@CMU-RI-ISL2" of Wed 25 Jul 84 09:30:25-PDT

There is a set of benchmarks which have been run on a variety of Lisp
systems which have been compiled by Richard Gabriel at Stanford.  You
should contact Paul Wieneke (PW@SU-AI) for more information.
-------

From narain@rand-unix  Wed Aug  1 12:31:21 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00623; Wed, 1 Aug 84 12:31:21 pdt
Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA00567; Wed, 1 Aug 84 12:29:40 pdt
Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt
From: Sanjai Narain <narain@rand-unix>
Message-Id: <8408011804.AA01076@rand-unix.ARPA>
Date: 01 Aug 84 11:04:25 PDT (Wed)
To: franz-friends@BERKELEY
Subject: Fast recompiling


Often we have files consisting of large numbers of functions which are
compiled. Sometimes, just one of these functions needs to be changed. It
would be nice to recompile just this function, and copy already compiled
functions to produce a fresh version of the compiled file. Is there any
quick method of doing this in Franz Lisp i.e. is there an equivalent of
Interlisp's "recompile" function.

I would be grateful for your response.

-- Sanjai Narain

From fateman@ucbdali  Wed Aug  1 13:24:30 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03438; Wed, 1 Aug 84 13:24:30 pdt
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33)
	id AA01542; Wed, 1 Aug 84 13:06:01 pdt
Received: by ucbdali.ARPA (4.24/4.27)
	id AA00994; Wed, 1 Aug 84 13:07:35 pdt
Date: Wed, 1 Aug 84 13:07:35 pdt
From: fateman@ucbdali (Richard Fateman)
Message-Id: <8408012007.AA00994@ucbdali.ARPA>
To: franz-friends@BERKELEY, narain@rand-unix
Subject: Re:  Fast recompiling

This would be an interesting feature, but it is complicated by the
possibility that the compilation environment is built up in a typical
large Franz system, by processing the whole file.  I think that the
interlisp situation is usually simpler.  
  For example, in recompiling Macsyma, sometimes a file itself or
function definitions in it do not change at all. A "macro definition"
file which is included in the compilation environment can, however, change
the generated code, substantially.
  Something like UNIX's "make" might be needed.

Alternatively, you can use smaller files...

From jkf@ucbmike  Thu Aug  2 16:10:04 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA16097; Thu, 2 Aug 84 16:10:04 pdt
Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33)
	id AA00501; Thu, 2 Aug 84 16:08:09 pdt
Date: Thu, 2 Aug 84 16:09:45 pdt
From: John Foderaro (on an sun) <jkf@ucbmike>
Message-Id: <8408022309.1757@ucbmike.ARPA>
Received: by ucbmike.ARPA (4.24ucb/3.5)
	id AA01757; Thu, 2 Aug 84 16:09:45 pdt
To: franz-friends@BERKELEY
Subject: repeated messages
Cc: 

  I'm sorry about the repeated messages.  Our mailing machine got a bit
overloaded.  I've modified the organization of the list to try to
fix the problem.



From NET-ORIGIN@MIT-MC  Fri Aug  3 15:15:44 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA26463; Fri, 3 Aug 84 15:15:44 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA04086; Fri, 3 Aug 84 15:13:41 pdt
Received: from mit-heracles (mit-heracles.ARPA) by mit-charon (4.12/4.7)
	id AA13781; Fri, 3 Aug 84 14:32:51 edt
Received: by mit-heracles (4.12/4.7)
	id AA20045; Fri, 3 Aug 84 14:35:30 edt
From: yba@mit-heracles (Mark H Levine)
Message-Id: <8408031835.AA20045@mit-heracles>
Date:  3 Aug 1984 1435-EDT (Friday)
To: franz-friends@BERKELEY
Subject: Opus 37.79 building from source


Has anyone published a fix to the bug that causes "rawlisp" to take a
memory fault when built from vanilla 4.2bsd sources?

It seems that the routine "getatom" in franz/alloc.c calls strcmp
with "name" equal to "mod" and "aptr -> a.pname" equal to CNIL (-4).

This is presumably a side effect of some other error; it still causes
a memory fault in strcmp and prevents building from source.  The sources
have some Sept. '83 changes to the library code, but are otherwise con-
sistent with all the 4.2 code I have seen.

Got a fix handy?



From liz@maryland  Mon Aug  6 07:41:41 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA16830; Mon, 6 Aug 84 07:41:41 pdt
Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
	id AA06949; Mon, 6 Aug 84 07:39:52 pdt
Received: by maryland.ARPA (4.12/4.7)
	id AA01505; Mon, 6 Aug 84 10:40:52 edt
Date: Mon, 6 Aug 84 10:40:52 edt
From: liz@maryland (Liz Allen)
Message-Id: <8408061440.AA01505@maryland.ARPA>
To: franz-friends@BERKELEY, yba%mit-heracles@csnet-relay.ARPA
Subject: Re:  Opus 37.79 building from source

That sounds like an error I ran into recently -- only it was with Opus
38.91 and it was also because I was adding more strings to rawlisp.
Anyway, the fix was easy and is probably worth trying.  Go into
franz/data.c and change the size of i_strbuf and make it bigger.  Ours
was 600, and I made it 1000.  You'll also need to change the
initialization for i_strbuf; I changed ours from "i_strbuf + 599" to
"i_strbuf + 999".

Hope this helps!

				-Liz

From smotroff@bbncct  Wed Aug  8 14:39:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA23393; Wed, 8 Aug 84 14:39:03 pdt
Received: from bbncct (bbncct.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA21105; Wed, 8 Aug 84 14:39:58 pdt
Message-Id: <8408082139.AA21105@UCB-VAX.ARPA>
Date: Wed, 8 Aug 84 17:28:58 EDT
From: Ira Smotroff <smotroff@BBNCCT.ARPA>
Subject: add me to the list
To: franz-friends@BERKELEY

please add my name to the franz-friends list


smotroff at bbn


From booker@nrl-aic  Fri Aug 10 06:18:45 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA13113; Fri, 10 Aug 84 06:18:45 pdt
Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA14441; Fri, 10 Aug 84 06:19:43 pdt
Message-Id: <8408101319.AA14441@UCB-VAX.ARPA>
Date: 10 Aug 1984 09:09:24-PDT
From: Lashon Booker <booker@NRL-AIC>
To: franz-friends@BERKELEY
Subject: Interlisp Compatibility Package?

Has anyone written an Interlisp compatibility package
for Franz?  Thanks.

Lashon Booker
booker@nrl-aic

From @MIT-MC:smh@MIT-EMS  Fri Aug 10 13:14:44 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA01017; Fri, 10 Aug 84 13:14:44 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA21922; Fri, 10 Aug 84 13:15:43 pdt
Message-Id: <8408102015.AA21922@UCB-VAX.ARPA>
Date: 10 Aug 1984 16:06:48-EDT
From: smh@mit-ems@mit-mc
To: franz-friends@BERKELEY
Subject: (atom VECTOR): franz vs liszt

Versions: Franz 38.91, Liszt 8.39, and probably most others.

Description:
	The atom predicate operates inconsistently between compiled and
	interpreted code when passed a vector or vectori.

Repeat-by:
	Create and compile a file containing the following definition:
		(defun atum(x) (atom x))
	After loading it into the interpreter the following results can
	be obtained:
		(setq v (vector 1 2 3))
		(atom v)		===> t
		(atum v)		===> nil

Discussion:
	According to the manual, atom returns "t iff g_arg is not a list or
	hunk object."  By this definition, the interpreter is correct and the
	compiler incorrect.  However, one can make a strong argument that
	vectors, analogously to hunks, should not be considered atoms.
	Therefore, the both the documentation and interpreter should be
	changed.  (It is doubtful very much existing code depends on this.)

Suggested fix:
	Change the definition of atom section 2 of the manual to read:
		"t iff g_arg is not a list, hunk, vector, or vectori object."
	Add the following definition to franz/h/global.h, after the existing
	definition of HUNKP:
		#define HUNKORVECP(a1)	((TYPE(a1) >= 11) & (TYPE(a1) <= 19))
	Change the definition of Latom in franz/lam1.c:
		lispval
		Latom()
		{
			register struct argent *lb = lbot;
			chkarg(1,"atom");
	==>		if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val)))
				return(nil);
			else
				return(tatom);
		}

Alternative suggested fix:
	If franz-composers really feel that atom ought to treat hunks
	and vectors differently (sigh?), then fix the compiler instead
	of the interpreter and documentation.  The most important thing
	is that interpreted and compiler do the same thing!
	In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition
	of the mask constant.

Random (constructive) flame:
	The interpreter definition above has to lookup the type of its
	argument expensively in the typetable *three* times, to wit:
		#define ATOX(a1)	((((int)(a1)) - OFFSET) >> 9)
		#define	TYPE(a1)	((typetable+1)[ATOX(a1)])
	While compiled code is admirably streamlined, the interpreter
	could be made significantly faster here and elsewhere if TYPE
	were evaluated only once and held for examination in a
	temporary.  This would require a bunch more type predicate
	DEFINEs operating on TYPE values instead of object addresses.

Steve Haflich
smh%mit-ems@mit-mc
{decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh


From JonL.pa@Xerox.ARPA  Mon Aug 13 13:25:44 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03640; Mon, 13 Aug 84 13:25:44 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA05890; Mon, 13 Aug 84 13:26:52 pdt
Message-Id: <8408132026.AA05890@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 13 AUG 84 13:24:39 PDT
Date: 13 Aug 84 13:24 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: (atom VECTOR): franz vs liszt
In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 10 Aug 84 16:06:48
 EDT
To: "smh@mit-ems"@MIT-MC.ARPA
Cc: franz-friends@BERKELEY, GSB@MIT-ML.ARPA, ALAN@MIT-MC.ARPA

Perhaps this bug should be forwarded to BUG-LISP@MIT-MC, since the
original design flaw is in MacLisp.  The problem is that when Hunks were
first invented, there where some who wanted them as "annotated" list
cells (hence, they weren't ATOMs) while other wanted them as small
VECTORs (hence there should be ATOMs).  The resolution was some awful
switch setting for whether or not to treat them as ATOMs, but I don't
remember the default setting, nor the final results.

-- JonL --




From ALAN@MIT-MC  Mon Aug 13 17:15:11 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA07443; Mon, 13 Aug 84 17:15:11 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA10564; Mon, 13 Aug 84 17:16:03 pdt
Message-Id: <8408140016.AA10564@UCB-VAX.ARPA>
Date: 13 August 1984 20:08-EDT
From: Alan Bawden <ALAN@MIT-MC>
Subject:  (atom VECTOR): franz vs liszt
To: JonL.pa@XEROX
Cc: GSB@MIT-MC, franz-friends@BERKELEY, smh@MIT-EMS
In-Reply-To: Msg of 13 Aug 84 13:24 PDT from JonL.pa at XEROX.ARPA

    Date: 13 Aug 84 13:24 PDT
    From: JonL.pa at XEROX
    ...  The resolution was some awful switch setting for whether or not to
    treat them as ATOMs, but I don't remember the default setting, nor the
    final results.

There are indeed a couple of switches that control various random aspects
of hunks, but none of them have any effect on their atomic or non-atomic
nature.  Hunks are never atoms in MacLisp.  Everybody agrees that this is a
loss, but at this point it is rather deeply ingrained into things to think
about changing it.


From jmiller@csnet-relay.csnet  Tue Aug 14 01:53:12 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA13476; Tue, 14 Aug 84 01:53:12 pdt
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA23091; Tue, 14 Aug 84 01:54:22 pdt
Message-Id: <8408140854.AA23091@UCB-VAX.ARPA>
Received: From ct.csnet by csnet-relay;  14 Aug 84 4:31 EDT
Date: 13 Aug 1984 20:46:42-PST
From: jmiller%ct.csnet@csnet-relay.arpa
To: franz-friends@BERKELEY
Subject: bug in assoc

The following illustrates a rather unpleasant bug in Franz's ASSOC (as
of 38.26, anyhow).  Be forewarned....

------------------------------------------------------------------------------

8_(setq l '((a 1) (b 2) (c 3)))	       ;;set up an a-list
((a 1) (b 2) (c 3))

9_(setq foo 'l)			       ;;FOO points to the NAME of the a-list
l

10_(setq bar 'foo)		       ;;BAR points to the NAME of the NAME of
foo				       ;;the a-list

11_(assoc 'b l)			       ;;This does the right thing
(b 2)

12_(assoc 'b foo)		       ;;Gag me with a mouse -- should err
(b 2)				       ;;with "bad arg to <something>"

13_(assoc 'b bar)		       ;;Double gag me with a mouse!!
(b 2)

------------------------------------------------------------------------

For the record, ASSQ is flawed in the same way.


Jim Miller
Computer Thought, Dallas
jmiller@ctvax.csnet
...!convex!ctvax!jmiller

From @MIT-MC:smh@MIT-EMS  Tue Aug 14 07:35:27 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA14507; Tue, 14 Aug 84 07:35:27 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA26447; Tue, 14 Aug 84 07:36:36 pdt
Message-Id: <8408141436.AA26447@UCB-VAX.ARPA>
Date: 14 Aug 1984 08:40:00-EDT
From: smh@mit-ems@mit-mc
To: ALAN@mit-mc, GSB@mit-mc, JonL.pa@parc-maxc
Subject: (atom VECTOR): franz vs liszt
Cc: franz-friends@BERKELEY

Gentlemen, I think we are losing grasp on the original bug report.
This is probably my fault for including a discourse on the philosophy
of hunks (:-) in the bug report.

Maclisp ain't gonna change about hunks, and it would be a poor idea for
Franz to change.  Anyway, the bug is with vectors.  In Franz, compiled
and interpreted code disagree whether a vector is an atom.  Certainly
no one can defend this!

Maclisp doesn't *have* vectors, does it?

Steve Haflich
smh%mit-ems@mit-mc


From mcgeer  Tue Aug 14 11:03:10 1984
Received: by ucbkim.ARPA (4.24/4.27)
	id AA17397; Tue, 14 Aug 84 11:03:10 pdt
Date: Tue, 14 Aug 84 11:03:10 pdt
From: Rick McGeer (on an h19-u) <mcgeer>
Message-Id: <8408141803.AA17397@ucbkim.ARPA>
Phone: (415) 236-8262
To: ALAN@MIT-MC, JonL.pa@XEROX
Subject: Re:  (atom VECTOR): franz vs liszt
Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC
In-Reply-To: Your message of 13 August 1984 20:08-EDT

	The predicate atom in Franz appears to be:
	
(defun atom(foo)
   (if foo
      then (not (or (hunkp foo) (dtpr foo)))
      else t))

whereas a more natural implementation, it seems to me, is:

(defun atom(foo)
   (or (symbolp foo) (numberp foo)))

Since it seems to me that:

(xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))

should always be non-nil for non-nil objects.  Or, better put, that vectors,
hunks, dtprs, atoms, and arrays should partition the data space.  No?

					Rick.



From mcgeer  Tue Aug 14 11:53:28 1984
Received: by ucbkim.ARPA (4.24/4.27)
	id AA18832; Tue, 14 Aug 84 11:53:28 pdt
Date: Tue, 14 Aug 84 11:53:28 pdt
From: Rick McGeer (on an h19-u) <mcgeer>
Message-Id: <8408141853.AA18832@ucbkim.ARPA>
Phone: (415) 236-8262
To: jmiller%ct.csnet@csnet-relay.arpa, franz-friends
Subject: Re: bug in assoc
Cc: 
In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST

	"'Curiouser and curiouser', said Alice".  I dug out the source for
assoc (38.79), and here it is:

(def assoc
  (lambda (val alist)
	  (do ((al alist (cdr al)))
	      ((null al) nil)
	      (cond ((null (car al)))
		    ((not (dtpr (car al)))
		     (error "bad arg to assoc" al))
		    ((equal val (caar al)) (return (car al)))))))

So nothing particularly screwy is going on here.  However, when I do the
traces (after setting up stuff the way you did), I get:
=> (assoc 'b 'l)
1 <Enter> assoc (b l)
1 <EXIT>  assoc  (b 2)
(b 2)
=> (assoc 'b ''l)
1 <Enter> assoc (b 'l)
Error: bad arg to assoc (quote l) 
Form: (assoc 'b ''l)
{1} bar
foo
{1} (assoc 'b 'foo)
|2 <Enter> assoc (b foo)
|2 <EXIT>  assoc  (b 2)
(b 2)
{1} foo
l
{1} bar
foo
{1} (assoc 'b bar)
|2 <Enter> assoc (b foo)
|2 <EXIT>  assoc  (b 2)
(b 2)
{1} (assoc 'b ''l)
|2 <Enter> assoc (b 'l)
Error: bad arg to assoc (quote l) 
Form: (assoc 'b ''l)
{2}

Which is certainly *very* odd...


From mcgeer  Tue Aug 14 12:06:20 1984
Received: by ucbkim.ARPA (4.24/4.27)
	id AA19018; Tue, 14 Aug 84 12:06:20 pdt
Date: Tue, 14 Aug 84 12:06:20 pdt
From: Rick McGeer (on an h19-u) <mcgeer>
Message-Id: <8408141906.AA19018@ucbkim.ARPA>
Phone: (415) 236-8262
To: ALAN@MIT-MC, JonL.pa@XEROX
Subject: Re:  (atom VECTOR): franz vs liszt
Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC

	Sorry to anyone who's getting this twice: I can't figure out from
the mailer error message who got it and who didn't...


	The predicate atom in Franz appears to be:
	
(defun atom(foo)
   (if foo
      then (not (or (hunkp foo) (dtpr foo)))
      else t))

whereas a more natural implementation, it seems to me, is:

(defun atom(foo)
   (or (symbolp foo) (numberp foo)))

Since it seems to me that:

(xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))

should always be non-nil for non-nil objects.  Or, better put, that vectors,
hunks, dtprs, atoms, and arrays should partition the data space.  No?

					Rick.






From PSZ@MIT-MC  Tue Aug 14 13:53:19 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20310; Tue, 14 Aug 84 13:53:19 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA03508; Tue, 14 Aug 84 13:54:23 pdt
Message-Id: <8408142054.AA03508@UCB-VAX.ARPA>
Date: 14 August 1984 16:37-EDT
From: Peter Szolovits <PSZ@MIT-MC>
Subject:  on the issue of the "ATOMness" of hunks
To: ALAN@MIT-MC
Cc: GSB@MIT-MC, PSZ@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY, smh@MIT-EMS
In-Reply-To: Msg of 13 Aug 1984 20:08-EDT from Alan Bawden <ALAN>

I have a small quarrel with Alan Bawden's statement that "hunks never
being atoms in Maclisp" is a universally-agreed bug.  There are indeed
useful structures that one would like to build in Lisp that act as CONS
cells (i.e., CAR and CDR are applicable), but that can have further
structure.  I have sorely missed such objects in Lisp Machine Lisp and
NIL, where flavor-instances are always atomic, when I wanted to build
Brand X (interned "list structure" and universal property lists).  In
Maclisp, I could do this using hunks, though even that was not
completely right because I wanted to be able to disallow RPLACA and
RPLACD while allowing CAR and CDR, and this was hard, given the hunk
abstraction.  I would, however, love to have non-atomic flavor-instances 


From @MIT-MC:smh@MIT-EMS  Tue Aug 14 14:28:47 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20792; Tue, 14 Aug 84 14:28:47 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA04288; Tue, 14 Aug 84 14:29:41 pdt
Message-Id: <8408142129.AA04288@UCB-VAX.ARPA>
Date: 14 Aug 1984 17:13:29-EDT
From: smh@mit-ems@mit-mc
To: mcgeer@ucbkim@BERKELEY
Subject: Re: bug in assoc
Cc: franz-friends@BERKELEY, jmiller@ct.csnet@udel-relay@mit-mc

As McGeer@ucbkim points out, the code for assoc is (in common0.l):

(def assoc
  (lambda (val alist)
	  (do ((al alist (cdr al)))
	      ((null al) nil)
	      (cond ((null (car al)))
		    ((not (dtpr (car al)))
		     (error "bad arg to assoc" al))
		    ((equal val (caar al)) (return (car al)))))))

The reason for the reported strange behavior of assoc is as simple as
it is obscure!  First a couple hints:
 - This code is inside the executable franz interpreter and therefore
   runs compiled.
 - The same strangeness is exhibited by assq, which is C-coded inside
   the Franz kernel.
 - Both the cdr of a dtpr and the value of an atom are stored at offset
   zero within their respective structures.  The car and plist
   similarly share the same offset within their structures.
 - If you try to run the above assoc definition interpreted, it will
   properly fail to work, or rather, it will complain about a bad arg
   to car.
 - Of course, c[ad]r in the interpreter carfully check their arguments;
   In the compiler, they simple indirect through pointers for maximum
   speed.

Finally, in case by now it isn't absolutely clear to everyone what is
going on, assoc is (sort of) comparing val against the plist of bar and
subsequently foo, and then each time automagically effectively doing a
symeval on the atom to continue scanning down the "cdr" of the alist.

Moral:  Although the interpreter tries pretty hard to do the dynamic
typing and implied typechecking for which lisp is famous, type checking
in compiled code is often a myth.  Correct code only necessarily works
correctly when given corrent arguments.

Steve Haflich
MIT Experimental Music Studio
smh%mit-ems@mit-mc
{decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh


From JonL.pa@Xerox.ARPA  Wed Aug 15 16:33:44 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00784; Wed, 15 Aug 84 16:33:44 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA05115; Wed, 15 Aug 84 14:20:30 pdt
Message-Id: <8408152120.AA05115@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 14:19:35 PDT
Date: 15 Aug 84 14:18 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: (atom VECTOR): franz vs liszt
In-Reply-To: Alan Bawden <ALAN@MIT-MC.ARPA>'s message of 13 Aug 84 20:08
 EDT
To: ALAN@MIT-MC.ARPA
Cc: JonL.pa@XEROX.ARPA, GSB@MIT-MC.ARPA, franz-friends@BERKELEY,
        smh@MIT-EMS.ARPA

[Ah, confusion with Interlisp here].  

I meant to say "The resolution was some awful switch setting for whether
or not to treat them as LISTs" rather than "to treat them as ATOMs".
The switch name is HUNKP.

Interlisp's ATOM predicate is defined simply as (NOT (LISTP x)), and
LISTP is true only of cons cells [thus (LISTP NIL) is false].

-- JonL --



From JonL.pa@Xerox.ARPA  Wed Aug 15 18:21:08 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA02292; Wed, 15 Aug 84 18:21:08 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA09647; Wed, 15 Aug 84 18:21:57 pdt
Message-Id: <8408160121.AA09647@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT
Date: 15 Aug 84 18:18 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: bug in assoc
In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29
 EDT
To: "smh@mit-ems"@MIT-MC.ARPA
Cc: "mcgeer@ucbkim"@BERKELEY, franz-friends@BERKELEY,
        "jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA

Common Lisp also faces the possibility of inconsistent system code due
to the handling of cases marked "is an error" (see Manual, sec. 1.2.4);
that is, it is undefined as to what happens if you apply CAR to a
non-LISTP.  All portable system code should therefore certify the type
of a datum before taking car or cdr.  ASSOC (and ASSQ) from the Franz
sources clearly doesn't check the type of the arguments before carcdring
away on them.

Well, why not "all system code should certify the type before taking
car/cdr . . . " -- it certainly can't hurt to "signal an error" rather
than fall into some undefined morass.

-- JonL --


From JonL.pa@Xerox.ARPA  Wed Aug 15 19:49:22 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA02844; Wed, 15 Aug 84 19:49:22 pdt
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA10989; Wed, 15 Aug 84 19:50:13 pdt
Message-Id: <8408160250.AA10989@UCB-VAX.ARPA>
Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 19:48:41 PDT
Date: 15 Aug 84 15:00 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: (atom VECTOR): franz vs liszt
In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 08:40:00
 EDT
To: "smh@mit-ems"@MIT-MC.ARPA
Cc: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA, JonL.pa@XEROX.ARPA,
        franz-friends@BERKELEY

MacLisp indeed does have VECTORs, STRINGs, CLASSes, etc. in an extended
SmallTalk-like hierarchy, but they are not in the initial system.  Some
of these used to have autoload properties, but I'm not sure about the
state of things now.  None of the extended stuff got documented in the
1983 MacLisp manual, mostly because of Pitman's personal preferences for
not using the extended stuff.

HUNKs are relevant, because the extended heirarchy uses the USRHUNK
feature in order to cause system functions to "trap out" on hunks,
thereby viewing them in an object-oriented way rather than as lists
(Glaaaag!) or as mere simple vectors.

-- JonL --



From MLY@MIT-MC  Wed Aug 15 22:49:17 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04730; Wed, 15 Aug 84 22:49:17 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA13406; Wed, 15 Aug 84 22:49:59 pdt
Message-Id: <8408160549.AA13406@UCB-VAX.ARPA>
Date: 16 August 1984 01:49-EDT
From: Richard Mlynarik <MLY@MIT-MC>
Subject:  on the issue of the "ATOMness" of hunks
To: PSZ@MIT-MC
Cc: ALAN@MIT-MC, GSB@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY,
        smh@MIT-EMS
In-Reply-To: Msg of 14 Aug 1984 16:37-EDT from Peter Szolovits <PSZ>

    From: Peter Szolovits <PSZ>

    I have a small quarrel with Alan Bawden's statement that "hunks never
    being atoms in Maclisp" is a universally-agreed bug.  There are indeed
    useful structures that one would like to build in Lisp that act as CONS
    cells (i.e., CAR and CDR are applicable), but that can have further
    structure.  I have sorely missed such objects in Lisp Machine Lisp and
    NIL, where flavor-instances are always atomic, when I wanted to build
    Brand X (interned "list structure" and universal property lists).  In
    Maclisp, I could do this using hunks, though even that was not
    completely right because I wanted to be able to disallow RPLACA and
    RPLACD while allowing CAR and CDR, and this was hard, given the hunk
    abstraction.  I would, however, love to have non-atomic flavor-instances 

The MIT lisp machine system makes some attempt to "support" this sort
of thing, by sending :CAR, :CDR, etc messages to instances. The result
is that you get an error about an unclaimed message, rather than one
about an attempt to take the car of a non-nil atom. LISTP and CONSP
both still return NIL when applied to an instance. The way to get RPLACA
(or SETF of CAR), etc to not work is simply to not define methods for doing
these operations...

Is is not really clear to me what the value of such is, unless you get tired
of typing too many "(SEND"'s.


From goldfarb%ucf.csnet@csnet-relay.arpa  Fri Aug 17 16:44:40 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00202; Fri, 17 Aug 84 16:44:40 pdt
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA01032; Fri, 17 Aug 84 16:45:24 pdt
Received: From ucf.csnet by csnet-relay;  17 Aug 84 19:26 EDT
Received: by ucf-cs.UUCP (4.12/4.7)
	id AA00852; Fri, 17 Aug 84 15:29:05 edt
Date: Fri, 17 Aug 84 15:29:05 edt
From: Ben Goldfarb <goldfarb%ucf.csnet@csnet-relay.arpa>
Message-Id: <8408171929.AA00852@ucf-cs.UUCP>
To: franz-friends@BERKELEY
Subject: ChangeLog

The ReadMe file in /usr/src/cmd/ucb/lisp states that there are ChangeLog
files in the subdirectories franz and liszt.  We got no such files on
our distribution tape (Berkeley 4.2bsd).  I'd appreciate receiving copies
of these files, along with any other documentation of differences between
the 4.2 version and prior versions of Franz Lisp.  

Thanks,

Ben Goldfarb
University of Central Florida
uucp: {duke,decvax,princeton}!ucf-cs!goldfarb
ARPA: goldfarb.ucf-cs@csnet.relay
csnet: goldfarb@ucf

From gvax.bromley@Cornell.ARPA  Sun Aug 26 20:48:24 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA11969; Sun, 26 Aug 84 20:48:24 pdt
Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA18166; Sun, 26 Aug 84 20:46:52 pdt
Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
	id AA16455; Sun, 26 Aug 84 23:48:12 edt
Date: Sun, 26 Aug 84 23:45:55 edt
From: gvax.bromley@Cornell.ARPA (Mark Bromley)
Message-Id: <8408270345.AA14288@CORNELL-GVAX.ARPA>
Received: by CORNELL-GVAX.ARPA (4.30/4.30)
	id AA14288; Sun, 26 Aug 84 23:45:55 edt
To: gvax.arpa-franz@Cornell.ARPA
Subject: Bug in open coding of vseti in Liszt 8.36


If (vseti vector index expression) gets open coded by the compiler,
the resulting value is the value of index, not the value of expression.
This also holds for vseti-byte and vseti-word.

The problem is in d_vset in vector.l.  The code which builds the return
value for immediate vectors assumes that the value of expression is in
index-reg, but it never gets put there.

One solution would be to change the lines

         (if g-loc
             then  (if (eq type 'byte)

(occuring about 3/4 of the way through d_vset) to
         (if g-loc
             then (setq temp (cadr (assq type '((byte cvtbl)
                                                (word cvtwl)
                                                (long movl)))))
                  (e-write3 temp vect-val index-reg)

                  (if (eq type 'byte)

Mark Bromley
bromley@cornell


From forwarder@UWVAX  Mon Aug 27 14:25:15 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA19881; Mon, 27 Aug 84 14:25:15 pdt
Received: from wisc-rsch.arpa (wisc-rsch.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA05251; Mon, 27 Aug 84 14:23:30 pdt
Date: Mon, 27 Aug 84 16:26:07 cdt
Message-Id: <8408272126.AA14734@wisc-rsch.arpa>
Received: by wisc-rsch.arpa; Mon, 27 Aug 84 16:26:07 cdt
To: franz-friends@BERKELEY
Subject: FRANZ to VI and back
Cc: neves@wisc-rsch.arpa
Sender: forwarder@UWVAX
From: neves@wisc-rsch.arpa

Escuse me if this is a simple question, but i am a Unix novice.
What is the best way to go between VI & Franz when debugging a
program?  The way I currently do it is to ctrl-Z out of Franz,
FG to my VI process, correct my code, FG back to FRANZ, load the
corrected code.  Is there a better way (do not tell me about
Emacs because that is not an option)?
-thanks, david

From rad@mitre-bedford  Mon Aug 27 14:52:55 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20435; Mon, 27 Aug 84 14:52:55 pdt
Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA05840; Mon, 27 Aug 84 14:51:11 pdt
Message-Id: <8408272151.AA05840@UCB-VAX.ARPA>
Date: Monday, 27 Aug 1984 17:45-EDT
From: rad@Mitre-Bedford
To: neves@WISC-RSCH.ARPA
Cc: franz-friends@BERKELEY, neves@WISC-RSCH.ARPA
Subject: Re: FRANZ to VI and back
In-Reply-To: Your message of Monday, 27 Aug 1984 17:26-EDT.
             <8408272126.AA14734@wisc-rsch.arpa>


>>Escuse me if this is a simple question, but i am a Unix novice.
>>What is the best way to go between VI & Franz when debugging a
>>program?  The way I currently do it is to ctrl-Z out of Franz,
>>FG to my VI process, correct my code, FG back to FRANZ, load the
>>corrected code.  Is there a better way (do not tell me about
>>Emacs because that is not an option)?

It's undocumented in the franz opus 37 manual, but may be in the opus
38:  In franz, type (vi foo) and lisp will spin up vi.  If it can't
find the file foo, it tries for foo.l before creating a new file.  If
you invoke it as (vil foo), it will load foo back in after you exit
from vi.  There are similar functions called ex and exl.  

If you're using BSD4.2, you probably have opus 38.  A new book is out
called Lispcraft.  It is based on franz, opus 38 in particular.  You
might want to pick that up.  The old standby, Lisp, by Winston and
Horn, documented Maclisp which is close to franz.  Their new, 2nd
edition is based on Common Lisp, however, which is different, so watch 
out!

If you don't like ex or vi (say you're an ed-masochist), there are hooks
for other editors.  Put the following in the .lisprc file in your home
directory:

(def ed (nlambda (x)
		   (exvi 'ed x nil)))
(def edl (nlambda (x)
		    (exvi 'ed x t)))

These will give you the same function as ex/vi and exl/vil except
using ed.  These functions are found in /usr/lib/lisp/auxfns0.l (opus
37, anyway).

Dick Dramstad
rad@mitre-bedford


From liz@maryland  Tue Aug 28 10:17:28 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA28395; Tue, 28 Aug 84 10:17:28 pdt
Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA24861; Tue, 28 Aug 84 10:15:46 pdt
Received: by maryland.ARPA (4.12/4.7)
	id AA20274; Tue, 28 Aug 84 10:59:06 edt
Date: Tue, 28 Aug 84 10:59:06 edt
From: liz@maryland (Liz Allen)
Message-Id: <8408281459.AA20274@maryland.ARPA>
To: neves@WISC-RSCH.ARPA, rad@Mitre-Bedford
Subject: Re: FRANZ to VI and back
Cc: franz-friends@BERKELEY

One feature of our vi functions is to ask (after returning from vi)
whether or not you want to load the file.  This gives you the freedom
to decide later when you know if you modified the file.  To implement
this, you could change the last line of exvi from:

	(cond (doload (load edit_file)))

to:

	(cond ((or doload (query "Load " edit_file "? "))
	       (load edit_file)))

and define query:

	(defmacro (&rest prompt)
	  `(progn (msg ,@prompt) (yesp (read))))

(or something like that).  Exvi is defined in common1.l.

Enjoy!

				-Liz

PS  You could also send me mail asking about getting our software!


From @MIT-MC:iaeh@cmu-ri-isl2.arpa  Wed Aug 29 08:09:14 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA09035; Wed, 29 Aug 84 08:09:14 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA15198; Wed, 29 Aug 84 08:09:05 pdt
Message-Id: <8408291509.AA15198@UCB-VAX.ARPA>
Date: 29 Aug 1984 11:06:09-EDT
From: Ingemar.Hulthage@CMU-RI-ISL2
Subject: Vector algebra
Apparently-To: <franz-friends@UCB-VAX>


I am writing a package of functions for vector algebra in arbitrary (finite)
dimensions and it occured to me that I ought to post a message to find
out if something like this is alredy available. 

I am looking forward to the replies


From @MIT-MC:iaeh@cmu-ri-isl2.arpa  Fri Aug 31 10:16:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04497; Fri, 31 Aug 84 10:16:03 pdt
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA03527; Fri, 31 Aug 84 10:15:41 pdt
Message-Id: <8408311715.AA03527@UCB-VAX.ARPA>
Date: 31 Aug 1984 13:15:27-EDT
From: Ingemar.Hulthage@CMU-RI-ISL2
Subject: matrix inversion
Apparently-To: <franz-friends@UCB-VAX>


I need to numerically invert matrices of varying sizes and I would
appreciate pointers to any lisp functions that can do that.


From mccune@aids-unix  Fri Aug 31 10:42:29 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA05060; Fri, 31 Aug 84 10:42:29 pdt
Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA04133; Fri, 31 Aug 84 10:41:52 pdt
Message-Id: <8408311741.AA04133@UCB-VAX.ARPA>
Date: 31 Aug 84 10:40:13 PDT (Fri)
From: Brian McCune <mccune@aids-unix>
Subject: Mailing list
To: franz-friends@BERKELEY

Please remove my name from franz-friends.  Thanks.  

	Brian McCune
	MCCUNE@AIDS-UNIX

From ucsbcsl!dave@engrvax  Tue Sep  4 11:22:20 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA10583; Tue, 4 Sep 84 11:22:20 pdt
Received: by UCB-VAX.ARPA (4.24/4.33)
	id AA26490; Tue, 4 Sep 84 11:22:10 pdt
From: ucsbcsl!dave@engrvax
Received: from engrvax.UCSB (engrvax.ARPA) by ucsbcsl.UCSB (4.12/3.14.ucsb)
	id AA27209; Tue, 4 Sep 84 10:55:08 pdt
Date: Tue, 4 Sep 84 10:55:52 pdt
Message-Id: <8409041755.AA20764@engrvax.UCSB>
Received: by engrvax.UCSB (4.12/3.14.ucsb)
	id AA20764; Tue, 4 Sep 84 10:55:52 pdt
To: franz-friends@BERKELEY
Subject: I have moved.

Please change my mailing address to be 'ucsbcsl!chi!dave' from 'ucsbcsl!dave'.
Thanks.

From liz@maryland  Wed Sep  5 08:34:45 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA19892; Wed, 5 Sep 84 08:34:45 pdt
Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA14415; Wed, 5 Sep 84 08:34:27 pdt
Received: by maryland.ARPA (4.12/4.7)
	id AA09320; Wed, 5 Sep 84 11:33:56 edt
Date: Wed, 5 Sep 84 11:33:56 edt
From: liz@maryland (Liz Allen)
Message-Id: <8409051533.AA09320@maryland.ARPA>
To: franz-friends@BERKELEY
Subject: Maryland software

I'm mailing the announcement here again since a few things have
changed since I last sent it out here and I have had requests for
it.  Currently, we are completing the 4.2 switchover and will
(hopefully) be starting to distribute it by the end of September.

				-Liz Allen

-----------------------------------------------------------------

Greetings:


     This is to announce the availability of the Univ of Maryland
software distribution.  This includes source code for the follow-
ing packages which are currently running on a  VAX  11/780  under
Berkeley UNIX(tm) 4.1:

(1)  The flavors package written in Franz Lisp.  This package has
     been used successfully in a number of large systems at Mary-
     land, and while it does not implement all  the  features  of
     Lisp  Machine  Flavors, the features present are as close to
     the Lisp Machine version as possible within the  constraints
     of  Franz  Lisp.   (Note that Maryland flavors code *can* be
     compiled.)

(2)  Other Maryland Franz hacks including the INTERLISP-like  top
     level,  the  lispbreak error handling package, the for macro
     and the new loader package.

(3)  The YAPS production system written in Franz Lisp.   This  is
     similar  to  OPS5  but  more  flexible  in the kinds of lisp
     expressions that may appear as facts and patterns  (sublists
     are  allowed and flavor objects are treated atomically), the
     variety of tests that may appear in the left hand  sides  of
     rules  and the kinds of actions may appear in the right hand
     sides of rules.  In  addition,  YAPS  allows  multiple  data
     bases which are flavor objects and may be sent messages such
     as "fact" and "goal".

(4)  The windows package in the form of  a  C  loadable  library.
     This flexible package allows convenient management of multi-
     ple contexts on the screen and runs  on  ordinary  character
     display  terminals as well as bit-mapped displays.  Included
     is a Franz lisp interface to the window  library,  a  window
     shell  for  executing shell processes in windows, and a menu
     package (also a C loadable library).

(5)  The phone program.  This is a facility to allow two or  more
     users  to type messages to each other in separate windows on
     a tty screen.  It uses the Maryland window package and CMU's
     IPC facility.

(6)  The calend program, an appointment calendar maintainer.   It
     uses a user file of reminding messages and dates for remind-
     ing, and can notify a user by messages printed to his termi-
     nal,  sending them mail, or nagging them to get off the ter-
     minal at a certain time of day.  It  allows  one-time  only,
     weekly,  biweekly, monthly, yearly and other similar methods
     for being reminded.

(7)  The bbd program, a multiple bulletin  board  system  loosely
     based  on the 'msgs' program.  It accepts character-oriented
     commands and allows user-definable bulletin-boards.

(8)  Rzasm, a relocating Z80 cross-assembler.  Running on the vax
     it  puts  out  ld-style object files.  Its features include,
     among others: free-form input;  (very)  long  variable/label
     names;  conditional assembly; macros (in 'm4' format); digit
     labels; global, external, common and local  common  declara-
     tions; data and text segments; support of the "undocumented"
     Z80 instructions (that work on high and  low  bytes  of  the
     index registers separately); expressions using C syntax; and
     string constants.

(9)  Zrun, a z80 microprocessor simulator.   Zrun  simulates  the
     execution  of  a  z80 with 64k RAM, as directed by user com-
     mands.  In addition to the essential commands that cause  an
     rzasm  object  program  to be loaded and executed, there are
     commands to examine and set  registers,  flags,  and  memory
     locations,  to  set  a  breakpoint, to single-step through a
     program, to re-direct the  flow  of  data  through  the  z80
     ports, etc.

The distribution currently runs under Berkeley Unix 4.1,  but  we
will  be upgrading to 4.2 in early July and the upgrade should be
ready for distribution in September.  At that time, we will begin
to put both the 4.1 and 4.2 sources on the distribution tape.  If
you are running 4.2 or plan to be running 4.2 in the near future,
it  is  probably  worth  your while to wait for it.  Also at that
time, the fee for the distribution will go up from $100 to $250.

     We also include Franz Lisp in the distribution since  it  is
easier  to do that than to describe all the small changes that we
have made to the Franz sources.  For  the  4.1  distribution,  we
send  Franz  Opus 38.26.  For the 4.2 distribution, we do not yet
know which Franz we will be mailing, but it will be whichever  we
get with our 4.2 Berkeley Unix.


How to obtain a tape:

     To obtain the Univ of Maryland distribution tape:

(1)  Fill in the form below and sign it.  Please indicate whether
     you  want  just  the  4.1 distribution, both the 4.1 and 4.2
     distributions or if you will be obtaining  the  distribution
     via a third party or via the Arpanet.

(2)  Make out a check to "University of Maryland Foundation"  for
     $100  (US  dollars) or for $250 (US dollars) if you want the
     4.2 distribution.  Mail the check and form to:

                  Liz Allen
                  Univ of Maryland
                  Dept of Computer Science
                  College Park MD 20742


(3)  If you need an invoice,  send  me  mail.   Don't  forget  to
     include your non-electronic mailing address.

Upon receipt of the money, we will mail you a tape containing our
software  and  the technical reports describing the software.  We
will also keep you informed of bug fixes via electronic mail.  We
have  an  electronic  mailing address for this kind of thing.  It
is:

         Usenet:      ...!seismo!umcp-cs!um-software
         Arpanet:     um-software@maryland

Please note that bug fixes will be done  only  insofar  they  are
consistent  with the research purposes of the University of Mary-
land.

     If you have any technical questions, etc, send mail  to  the
above  mailing  list.   If you have any administrative questions,
contact Diane Miller via electronic mail:

           Usenet:      ...!seismo!umcp-cs!despina
           Arpanet:     despina@maryland

or via phone at (301) 454-4251.


                         Liz Allen

                         Usenet:      ...!seismo!umcp-cs!liz
                         Arpanet:     liz@maryland

-----------------------------------------------------------------

In exchange for the Maryland software tape, I certify to the fol-
lowing:

a.   I will not use any of the Maryland software distribution  in
     a commercial product without obtaining permission from Mary-
     land first.

b.   I will keep the Maryland copyright  notices  in  the  source
     code,  and acknowledge the source of the software in any use
     I make of it.

c.   I will not redistribute this software to anyone without per-
     mission from Maryland first.

d.   I will keep Maryland informed of any bug fixes.

e.   I understand that the software I will be receiving has  been
     developed  for  research  purposes  only and may be good for
     absolutely nothing.  The University of  Maryland  offers  no
     warranties of any kind.  Bug fixes will be done only insofar
     they are  consistent  with  the  research  purposes  of  the
     University of Maryland.

f.   I am the appropriate person at my  site  who  can  make  the
     guarantees in parts a through e.

g.   I would like the package indicated below:


     ___  4.1 distribution only.  I have  enclosed  a  check  for
          $100.


     ___  4.1 and 4.2 distribution.  I have enclosed a check  for
          $250.   I  also understand that the 4.2 distribution is
          not yet ready and that there will be a delay  until  at
          least August or September before my tape arrives.

     ___  License and technical reports only.  I have enclosed  a
          check  for $100 and will obtain the distribution from a
          site that already has the distribtution or will get  it
          from  Maryland via the Arpanet.  (Please note specifics
          at the bottom of the form.)




Signature:                  ______________________________

Name:                       ______________________________

Position:                   ______________________________

Company or Organization:    ______________________________

Address:                    ______________________________

                            ______________________________

Phone number:               ______________________________

Electronic mail address:    ______________________________


From gvax.bromley@Cornell.ARPA  Wed Sep  5 16:11:17 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA25823; Wed, 5 Sep 84 16:11:17 pdt
Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
	id AA21315; Wed, 5 Sep 84 16:10:58 pdt
Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
	id AA15943; Wed, 5 Sep 84 19:11:13 edt
Date: Wed, 5 Sep 84 19:06:27 edt
From: gvax.bromley@Cornell.ARPA (Mark Bromley)
Message-Id: <8409052306.AA19770@CORNELL-GVAX.ARPA>
Received: by CORNELL-GVAX.ARPA (4.30/4.30)
	id AA19770; Wed, 5 Sep 84 19:06:27 edt
To: franz-friends@BERKELEY
Subject: Bug in open coding of vseti in Liszt 8.36

There is a mistake in the open coding of (vseti vector index expression).
When the generated code is executed it returns the value of the index expression
and not the value of expression.  The problem is in d_vset in liszt/vector.l.
The code in d_vset that generates the assembler code to compute the
return value assumes that code has been generated to put the value of
expression in index-reg.  This assumption is false.

I don't know the 68000 well enough to suggest a solution for it, but the
following should work for the VAX.  Change the lines

         (if g-loc
             then  (if (eq type 'byte)

(occuring about 3/4 of the way through d_vset) to

         (if g-loc
             then
	         #+for-vax
		 (progn
		      (setq temp (cadr (assq type '((byte cvtbl)
                                                   (word cvtwl)
                                                   (long movl)))))
                      (e-write3 temp vect-val index-reg)
		  )
		  
		  #+for-68k
		  (comment Do the same thing for the 68k)

                  (if (eq type 'byte)

Also, what is the current Berkeley distribution policy.  I tried ftp'ing
from ucbvax, but the pub/lisp directory there is empty.  I'd like to get my
hands on a distribution that has the flavors package in it.

Mark Bromley
bromley@cornell




From jkf@ucbmike  Tue Oct 30 12:19:45 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA02909; Tue, 30 Oct 84 12:19:45 pst
Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31)
	id AA23363; Tue, 30 Oct 84 11:43:13 pst
Received: by ucbmike.arpa (4.24ucb/4.33)
	id AA04265; Tue, 30 Oct 84 12:43:39 pst
Date: Tue, 30 Oct 84 12:43:39 pst
From: John Foderaro (on a sun) <jkf@ucbmike>
Message-Id: <8410302043.AA04265@ucbmike.arpa>
To: mrose%udel-dewey.delaware@udel-relay.ARPA, franz-friends@BERKELEY
Subject: Re: Where is franz-friends-request
In-Reply-To: Your message of 28 Oct 84 10:04:05 EST (Sun)

 franz-friends-request@berkeley is valid.  occasionlly the mailer tries
 to look in the alias table while it is being updated.
 


From liz@tove  Tue Oct 30 13:18:32 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03406; Tue, 30 Oct 84 13:18:32 pst
Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA24224; Tue, 30 Oct 84 12:15:01 pst
Received: by tove.ARPA (4.12/4.7)
	id AA09504; Thu, 25 Oct 84 16:46:39 edt
From: Liz Allen <liz@tove>
Message-Id: <8410252046.AA09504@tove.ARPA>
Date: 25 Oct 1984 1646-EDT (Thursday)
To: Rene Bach <BACH@su-score>
Cc: franz-friends@BERKELEY
Subject: Re: A question
In-Reply-To: Your message of Thu 25 Oct 84 09:31:09-PDT.
             <8410251628.AA00848@UCB-VAX.ARPA>

	From: Rene Bach <BACH%su-score.arpa@csnet-relay.ARPA>

	I am new on this list and haven't seen any other messages.

There isn't too much mail here.

	Is there a way to find out what are all the atoms which
	have been defined in Franz (a la mapatoms of INterlisp) ??

The functions (oblist) returns a list of all the atoms.

				-Liz

From neves%wisc-ai.uwisc@wisc-crys.ARPA  Tue Oct 30 14:38:15 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04963; Tue, 30 Oct 84 14:38:15 pst
Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA27563; Tue, 30 Oct 84 14:36:12 pst
Received: from wisc-ai.uwisc by wisc-crys.arpa; Tue, 30 Oct 84 16:35:00 cst
Date: Tue, 30 Oct 84 16:34:59 cst
From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves)
Message-Id: <8410302234.AA21547@wisc-ai.uwisc>
Received: by wisc-ai.uwisc; Tue, 30 Oct 84 16:34:59 cst
To: franz-friends@BERKELEY
Subject: vi/franz question

This is a vi/franz question.
I would like to use "=" in VI to indent my lisp code.  When I
type "=" in front of some lisp code I get
No alternate filename to substitute for #0
How do I indent Lisp code (besides using autoindent)?
-Thanks, David

From Johnson%udel-dewey.delaware@udel-relay.ARPA  Wed Oct 31 05:54:58 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04156; Wed, 31 Oct 84 05:54:58 pst
Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA07029; Wed, 31 Oct 84 05:52:24 pst
Message-Id: <8410311352.AA07029@UCB-VAX.ARPA>
Received: From udel-dewey.ARPA by udel-relay.ARPA id a018834 ;31 Oct 84 8:55 EST
Date:     Wed, 31 Oct 84 8:47:19 EST
From: johnson <johnson%udel-dewey.delaware@udel-relay.ARPA>
To: franz-friends@BERKELEY
Cc: johnson%udel-dewey.delaware@udel-relay.ARPA
Subject:  response to lisp/vi question


in response to:

>I would like to use "=" in VI to indent my lisp code.  When I
>type "=" in front of some lisp code I get
>No alternate filename to substitute for #0
>How do I indent Lisp code (besides using autoindent)?

1. When I type "=" in vi (without :set lisp) I get no response at all.
	Is it possible that you defined a macro named "=" ?
	{
		check your ~/.exrc file for a line beginning:
		:map = <something-or-other>
	}

2. Even after:
	:set lisp

	A single "=" does not seem to cause the correct action, however,
	two successive "="s do.  

to summarize:
	1. remove any mapping of "=" from ~/.exrc
	2. :set lisp
    	3. use "==" rather than "="

- johnson@udel-ee


From raf%bostonu.csnet@csnet-relay.arpa  Wed Oct 31 11:35:57 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA07802; Wed, 31 Oct 84 11:35:57 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA13682; Wed, 31 Oct 84 11:33:13 pst
Received: from bostonu by csnet-relay.csnet id ac00303; 31 Oct 84 14:27 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA14678; Wed, 31 Oct 84 13:53:18 est
Date: Wed, 31 Oct 84 13:53:18 est
From: Rafail Ostrovsky <raf%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8410311853.AA14678@csvaxa.ARPA>
To: FRANZ-FRIENDS%ucb-vax.arpa@csnet-relay.arpa
Subject: MAILING LIST

Hello.
I would like to subscribe to your mailing list. 
I am a grad. student at Boston U. My address is:

raf%bostonu.csnet@CSNET-RELAY.CSNET

               Thank you, -Raf

From neves%wisc-ai.uwisc@wisc-crys.ARPA  Wed Oct 31 12:40:33 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA09034; Wed, 31 Oct 84 12:40:33 pst
Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA15180; Wed, 31 Oct 84 12:37:38 pst
Received: from wisc-ai.uwisc by wisc-crys.arpa; Wed, 31 Oct 84 14:35:47 cst
Date: Wed, 31 Oct 84 14:35:55 cst
From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves)
Message-Id: <8410312035.AA25488@wisc-ai.uwisc>
Received: by wisc-ai.uwisc; Wed, 31 Oct 84 14:35:55 cst
To: franz-friends@BERKELEY
Subject: re: Indenting lisp code in VI

Thanks for the response on indenting for Franz.  It seems as though
our systems people do not use Lisp and so have set up everyone's
.exrc file to map = to something else.  Your site might be doing the
same thing to this or other VI/Lisp features!  Stop them now.

From @MIT-MC:iaeh@cmu-ri-isl2.arpa  Wed Oct 31 17:37:36 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA14939; Wed, 31 Oct 84 17:37:36 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA02960; Wed, 31 Oct 84 17:14:37 pst
Message-Id: <8411010114.AA02960@UCB-VAX.ARPA>
Date: 31 Oct 84 20:08:41 EST
From: Ingemar.Hulthage@CMU-RI-ISL2
Subject: Floating point division
To: BBoard.Maintainer@CMU-CS-A


Is there a pre-defined  function in Franz Lisp that never uses integer
division when it differs from floating point division ?  Obviously it is easy
to write (quotient (float a) b) or to write a function/macro with the same
effect. However, since Franz does a good job of dealing with different kinds
of numbers in other cases, it is inconvenient and inefficient if such a
function is not available in the system.


From eng20201%BOSTONU.bitnet@WISCVM.ARPA  Thu Nov  1 16:02:58 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA05698; Thu, 1 Nov 84 16:02:58 pst
Received: from WISCVM.ARPA (wiscvm.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA08850; Thu, 1 Nov 84 16:00:19 pst
Message-Id: <8411020000.AA08850@UCB-VAX.ARPA>
Received: from ENG20201@BOSTONU.BITNET by WISCVM.ARPA on 11/01/84 at
   18:00:40 CST
Date:  1-Nov-84   18:58:53 EST
From: John Sutter               <eng20201%BOSTONU.bitnet@WISCVM.ARPA>
Subject: Pretty typer
To: franz-friends@BERKELEY
Cc: eng20201%BOSTONU.bitnet@WISCVM.ARPA

-----

  Does anyone know of a pretty typer for Franz Lisp?..

  If you do, please reply to me directly.

  Thanks

  ----  John

-----

From holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa  Sun Nov  4 14:39:06 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03203; Sun, 4 Nov 84 14:39:06 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA04466; Sun, 4 Nov 84 14:36:25 pst
Received: from ubc by csnet-relay.csnet id a004399; 4 Nov 84 15:43 EST
Date: Sun, 4 Nov 84 12:37:03 pst
Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
From: Neal Holtz <holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa>
To: franz-friends%ucb-vax.arpa@csnet-relay.arpa
Mmdf-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
Message-Id: 133:holtz@carleton.cdn
Subject: Franz on Apollos (or, Fritz Kunze, where are you?)

Sorry to send this to the newsgroup, but if Fritz (or anyone else,
for that matter) can tell me anything about the possibility of
having Franz run on Apollo workstations (under AEGIS) in the
near future, I would be most appreciative.


From holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa  Sun Nov  4 14:39:20 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03212; Sun, 4 Nov 84 14:39:20 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA04473; Sun, 4 Nov 84 14:36:37 pst
Received: from ubc by csnet-relay.csnet id a004408; 4 Nov 84 15:45 EST
Date: Sun, 4 Nov 84 12:37:03 pst
Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
From: Neal Holtz <holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa>
To: franz-friends%ucb-vax.arpa@csnet-relay.arpa
Mmdf-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
Message-Id: 133:holtz@carleton.cdn
Subject: Franz on Apollos (or, Fritz Kunze, where are you?)

Sorry to send this to the newsgroup, but if Fritz (or anyone else,
for that matter) can tell me anything about the possibility of
having Franz run on Apollo workstations (under AEGIS) in the
near future, I would be most appreciative.


From fkunze%ucbopal.CC%ucb-vax.arpa@csnet-relay.arpa  Sun Nov  4 23:25:12 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03125; Sun, 4 Nov 84 23:25:12 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA04781; Sun, 4 Nov 84 23:22:27 pst
Received: from ucb-vax.arpa by csnet-relay.arpa id a006482; 5 Nov 84 2:21 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA04236; Sun, 4 Nov 84 22:58:35 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.17/4.27.2)
	id AA14292; Sun, 4 Nov 84 22:59:18 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28)
	id AA03601; Sun, 4 Nov 84 22:59:26 pst
Date: Sun, 4 Nov 84 22:59:26 pst
From: Fritz Kunze <fkunze%ucbopal.CC%ucb-vax.arpa@csnet-relay.arpa>
Message-Id: <8411050659.AA03601@ucbopal.CC.Berkeley.ARPA>
To: franz-friends%ucb-vax.arpa%csnet-relay.arpa@csnet-relay.arpa,
        holtz%carleton.cdn%ubc.csnet%csnet-relay.arpa@csnet-relay.arpa
Subject: Re: Franz on Apollos (or, Fritz Kunze, where are you?)

We are working on an Apollo port right now. Due to some
non-standard features in the Apollo operating system,
the port is requiring far more time than we originally
anticipated.  We are very close to a working interpreter,
but the compiler will require more time.  Are you interested
in the Interpreter first?
---Fritz Kunze
   Franz Inc.
   2920 Domingo, suite 203
   Berkeley, CA 94705
   (415) 540-1224



From abrams@mitre  Mon Nov  5 11:41:38 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08762; Mon, 5 Nov 84 11:41:38 pst
Received: from mitre (mitre.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA06184; Mon, 5 Nov 84 11:38:18 pst
Message-Id: <8411051938.AA06184@UCB-VAX.ARPA>
Date:  5 Nov 1984 14:17:36 EST (Monday)
From: Marshall Abrams <abrams@mitre>
Subject: Call for papers: Expert Systems Symposium
To: add1:@mitre
Cc: abrams@mitre

Call for Papers

Expert Systems in Government Conference

October 23-25, 1985

THE CONFERENCE objective is to allow the developers and implementers
of expert systems in goverenment agencies to exchange information and
ideas first hand for the purpose of improving the quality of
existing and future expert systems in the government sector. 
Artificial Intelligence (AI) has recently been maturing so rapidly
that interest in each of its various facets, e.g., robotics, vision,
natural language, supercomputing, and expert systems, has acquired
an increasing following and cadre of practitioners.

PAPERS are solicited which discuss the subject of the conference. 
Original research, analysis and approaches for defining  expert   
systems issues and problems such as those identified in the
anticipated session topics, methodological approaches for analyzing
the scope and nature of expert system issues, and potential
solutions are of particular interest.  Completed papers are to be no
longer than 20 pages including graphics and are due 1 May 1985.
Four copies of papers are to be sent to:

Dr. Kamal Karna, Program Chairman
MITRE Corporation W852
1820 Dolley Madison Boulevard
McLean, Virginia  22102
Phone (703) 883-5866
ARPANET:  Karna @ Mitre

Notification of acceptance and manuscript preparation instructions
will be provided by 20 May 1985.

THE CONFERENCE is sponsored by the IEEE Computer Society and The
MITRE Corporation in cooperation with The Association for Computing
Machinery, The american Association for Artificial Intelligence and
The American Institute of Aeronautics and Astronautics National
Capital Section.  This conference will offer high quality technical
exchange and published proceedings.

It will be held at Tyson's Westpark Hotel, Tysons Corner, McLean,
VA, suburban Washington, D.C.


TOPICS OF INTEREST

The topics of interest include the expert systems in the following
applications domains (but are not limited to):

 1.  Professional:           Accounting, Consulting, Engineering,
                             Finance, Instruction, Law, Marketing,
                             Management, Medicine
                             Systems, Intelligent DBMS

 2.  Office Automation:      Text Understanding, Intelligent

 3.  Command & Control:      Intelligence Analysis, Planning,
                             Targeting, Communications, Air Traffic
                             Control

 4.  Exploration:            Space, Prospecting, Mineral, Oil

                             Archeology

 5.  Weapon Systems:         Adaptive Control, Electronic Warfare,
                             Star Wars, Target Identification

 6.  System Engineering:     Requirements, Preliminary Design,
                             Critical Design, Testing, and QA

 7.  Equipment:              Design Monitoring, Control, Diagnosis,  
                             Maintenance, Repair, Instruction

 8.  Project Management:     Planning, Scheduling, Control

 9.  Flexible Automation:    Factory and Plan Automation

10.  Software:               Automatic Programming, Specifications,
                             Design, Production, Maintenance and
                             Verification and Validation

11.  Architecture:           Single, Multiple, Distributed Problem
                             Solving Tools

12.  Imagery:                Photo Interpretation, Mapping, etc.

13.  Education:              Concept Formation, Tutoring, Testing,
                             Diagnosis, Learning

14.  Entertainment and       Intelligent Games, Investment and
     Expert Advice Giving:   Finances, Retirement, Purchasing,
                             Shopping, Intelligent Information
                             Retrieval



From decvax!utzoo!dciem!nrcaero!clan.carleton!holtz  Mon Nov  5 17:32:56 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA14064; Mon, 5 Nov 84 17:32:56 pst
Received: by UCB-VAX.ARPA (4.24/4.39)
	id AA14362; Mon, 5 Nov 84 17:30:11 pst
Return-Path: <decvax!utzoo!dciem!nrcaero!clan.carleton!holtz>
Received: by decvax.UUCP (4.12/1.0)
	id AA28321; Mon, 5 Nov 84 16:46:11 est
Date: Sun, 4 Nov 84 21:23:59 est
From: Neal Holtz <decvax!carleton!clan.carleton!holtz@clan.>
Message-Id: <8411050223.AA07104@clan. UUCP>
Received: by clan. UUCP (4.12/3.14)
	id AA07104; Sun, 4 Nov 84 21:23:59 est
To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends
Subject: Franz on Apollos (or -- Fritz Kunze, where are you?)

Sorry to send this to the newsgroup, but if Fritz (or anyone else,
for that matter) can tell me anything about the possibility of
having Franz run on Apollo workstations (under AEGIS) in the
near future, I would be most appreciative.







From asb@SCRC-STONY-BROOK.ARPA  Tue Nov  6 16:15:33 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA25403; Tue, 6 Nov 84 16:15:33 pst
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA06061; Tue, 6 Nov 84 16:12:18 pst
Message-Id: <8411070012.AA06061@UCB-VAX.ARPA>
Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 122057; Tue 6-Nov-84 19:13:41-EST
Date: Tue, 6 Nov 84 19:11 EST
From: Richard Brenner <asb@SCRC-CUPID.ARPA>
Subject: Job Opportunities
To: maple-sys@BERKELEY, symalg%rand-unix.arpa%csnet-relay.arpa@SCRC-CUPID.ARPA,
        franz-friends@BERKELEY
In-Reply-To: The message of 6 Nov 84 15:51-EST from Richard Pavelle <RP at SCRC-TENEX>


Symbolics, Inc. of Cambridge is the acknowledged leader in the field of
Symbolic Processing, offering the premier LISP-based Symbolic Processor
for advanced problem-solving applications.  We are a fast-growing,
high-tech company with new, modern facilities right in Cambridge. Recent
expansion has created opportunities for the following experienced
professionals:


Member of Technical Staff

You will assist with maintenance and enhancement of MACSYMA, a large
Computer Algebra System written in LISP and used by engineers and
scientists for performing symbolic computations.  Immediate projects
could include design and implementation of tools for conversion to
Common LISP, improving modularity, modernizing the user interface,
improving performance, and design and implementation of new mathematical
packages based on the latest available algorithms.  Work will be
performed on all versions of MACSYMA using Symbolics 3600 Family Lisp
Machines.  A strong background in mathematics and Lisp programming is
preferred.  Experience with MACSYMA is desirable.


Technical Sales Support Engineer

You will provide technical support to our internal sales staff, to
customers and to prospective customers.  Responsibilities include
assistance at demonstration sites, installations on several kinds of
machines, and a full range of customer support activities.  This could
include design, development and delivery of a trainging course for
MACSYMA users.  Qualified applicants will have experience with a
high-level language, preferably MACSYMA.  Good written and verbal
communication skills and prior software project involvement are desired.
B.S. degree or equivalent and 2 years experience preferred.


Qualified candidates should send their resume,in strict confidence,
including salary history, to Gina Setteducati, Personnel Supervisor,
Symbolics, Inc., 11 Cambridge Center, Cambridge, MA 02142.  An equal
opportunity employer.


From ssc-vax!steve@uw-beaver.arpa  Wed Nov  7 19:52:19 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08630; Wed, 7 Nov 84 19:52:19 pst
Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA05368; Wed, 7 Nov 84 18:51:47 pst
Received: by uw-beaver.arpa (4.12/2.2)
	id AA00936; Wed, 7 Nov 84 17:50:03 pst
Return-Path: <ssc-vax!steve>
Received: by ssc-vax (4.12/4.7)
	id AA06915; Wed, 7 Nov 84 17:24:40 pst
Date: Wed, 7 Nov 84 17:24:40 pst
From: ssc-vax!steve@uw-beaver.arpa (Steve White)
Message-Id: <8411080124.AA06915@ssc-vax>
To: uw-beaver!franz-friends@BERKELEY
Subject: readtable within fasl


In "fasl.c" before the literals are read back out of the object file,
the readtable is rebound to the 'standard-readtable'. This short-circuits
any type of character macro expansion. Does anyone known a workaround
for this? In NIL you can specify the readtable associated with the object
code, I guess I'm wondering how to mimic this behavior in franz?
			thanks
					steve white
				(ssc-vax!steve@uw-beaver)

From @MIT-MC:smh@MIT-EDDIE  Thu Nov  8 07:49:13 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA12925; Thu, 8 Nov 84 07:49:13 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA17112; Thu, 8 Nov 84 07:46:31 pst
Message-Id: <8411081546.AA17112@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA20888; Thu, 8 Nov 84 10:33:41 est
Date: Thu, 8 Nov 84 10:33:41 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: Re: readtable within fasl

I too was bothered by fasl's insistence on using the standard readtable
to process literals in liszt-compiled files until I realized the reason
for this limitation:

All source input to liszt is processed by `read' -- that is, the
compiler reads only forms, never ascii strings.  In order to place a
literal form in an object file, liszt must essentially convert the form
back into ASCII via `print'.  (Actually, a somewhat modified version
which knows how to wrap an assembler `.asciz' directive around the
printed representation of the form, etc.)  Unfortunately, liszt can make
no easy assumption about what strange readtable is likely to be active
at load time, so the only sane choice is to use the standard readtable.

In other words, you shouldn't think of literal forms stored in a fasl
object file as external (ASCII) representation of lisp data.  Rather,
liszt/fasl use ASCII as a convenient "position-independent" encoding of
a form which has already been processed by read at compile time.  This
is entirely analogous to what traditional compilers and assemblers do
with numeric constants represented in ASCII inside a program, except
their compiler-to-loader data format uses the native binary number
representation of the object machine.

One could argue that this isn't really a limitation provided one is
willing and able to provide the desired readtable at compile time.
Usually this isn't a problem, although I once I had a macro which wanted
to insert into a form a particular uninterned symbol which (obviously)
couldn't even exist until execution time.  I was forced to wrap the form
inside another function which would accomplish the substitution at load
time.

There is no reason liszt could not be made to copy ASCII forms into the
fasl file without read->print translation, but this would require
changes to the compiler and to fasl format, things not to be done
lightly.  If you *really* need the facility, and don't need to read huge
volumes of data, you could include ASCII forms inside a fasl file by
encoding them as lisp strings, and seeing that they get processed by an
appropriate function at load time, something like:

	(defun strange-read (str)
	       (let ((readtable strange-readtable))
		    (readlist (explodec str))))

Then you can do things like:
	(setq foo (strange-read ") a b )c d( e (")

[What?  You don't like my readtable with the parens reversed?]  The
invocation of `strange-read' can, of course, be conveniently macrofied.
If appropriate, automatic printing of literal strings can also be
performed by compile time macros.  You will have to deal with the
problem of escaping quotes inside these forms, and you might want to
enable string garbage collection if you do a lot of this sort of thing.

I know it's ugly, but...

Steve Haflich


From @MIT-MC:smh@MIT-EDDIE  Thu Nov  8 12:17:02 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA15294; Thu, 8 Nov 84 12:17:02 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA22393; Thu, 8 Nov 84 11:59:13 pst
Message-Id: <8411081959.AA22393@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA21531; Thu, 8 Nov 84 12:51:14 est
Date: Thu, 8 Nov 84 12:51:14 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: Re: Re: readtable within fasl

There was a typo in my previous mailing.  The function "explodec"
should have been "exploden".


From BACH@SU-SCORE.ARPA  Thu Nov  8 14:24:38 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA16474; Thu, 8 Nov 84 14:24:38 pst
Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA25584; Thu, 8 Nov 84 14:22:00 pst
Message-Id: <8411082222.AA25584@UCB-VAX.ARPA>
Date: Thu 8 Nov 84 14:21:16-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
Subject: printing delayed in Eunice
To: franz-friends@BERKELEY
Cc: bach@SU-SCORE.ARPA

It appears that printing gets delayed in Eunice. What I mean by that
is that I have a print statement which should indicate that the system
is progressing. However, the system is chugging along, nothing shows
for a long while and then the printing happens ALL at ONCE ! As if the
output was buffered and go printed when something else needed to be
printed.

As anyone run across this before ? Is there a flag one needs to set ?

Has it to do with Eunice ?  What I am printing is just an atom and a ", ".
When I print longer stuff, no buffering is noticed.

Thanks
Rene
-------

From JonL.pa@Xerox.ARPA  Thu Nov  8 16:34:36 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA17894; Thu, 8 Nov 84 16:34:36 pst
Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
	id AA27172; Thu, 8 Nov 84 15:30:06 pst
Message-Id: <8411082330.AA27172@UCB-VAX.ARPA>
Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 84 15:29:24 PST
Date: 8 Nov 84 15:22 PST
From: JonL.pa@XEROX.ARPA
Subject: Re: readtable within fasl
In-Reply-To: Steven M. Haflich <smh@mit-eddie.ARPA>'s message of Thu, 8
 Nov 84 10:33:41 est
To: smh@mit-eddie.ARPA
Cc: franz-friends@BERKELEY

The problems with a user-tailorable READ is one of the reasons why, over
12 years ago, we chose a format for MacLisp's FASL files that is
somewhat akin to a position-independent list encoding.  (But in fact, it
was primarily for speed that the READ-oriented option was abandoned).

However, there was still the need to introduce load-time evaluation, in
order to create structures that can't be known even faintly at compile
time; there is an "internal" marker, accessible to the MacLisp user as a
global variable (named SQUID, I believe), so that the portions of a
structure that need to be eval'd at load time could be marked.  E.g.
    (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE))))
and the #, signals a spot for load-time evaluation, even though the
overall structure is essentally a QUOTE form.  

One needn't imagine that #, is the only client of this "internal" marker
-- it provides the way to get all but the trivial datatypes into
quotified structures; for example, I may have an input syntax for
arrays, but still PRINT won't put them out (MacLisp PRINT won't, at
least), and certainly not every conceivable datatype needs a special
encoding for the FASL file format; merely a LIST, which is viewed as a
general program by EVAL, is satisfactory to create any createable
datatype instance.

Interlisp too has a loadtime evaluation construct, but it may only
replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such
as indicated by the #, above.  A primary reason for this limitation is
the similarity of Interlisp's and Franz's compiler output formats --
basically an ascii string to which READ is applied.   MacLisp's loader
is indeed quite more complex, but it results in a space savings for the
FASL files and a considerable time savings when loading them.

-- Jon L White --



From @MIT-MC:nss@cmu-ri-isl3.arpa  Fri Nov  9 12:09:40 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA26238; Fri, 9 Nov 84 12:09:40 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA04311; Fri, 9 Nov 84 12:06:51 pst
Message-Id: <8411092006.AA04311@UCB-VAX.ARPA>
Date: 9 Nov 84 14:02:29 EST
From: Nancy.Skooglund@CMU-RI-ISL3
Subject: opening file for output, append
To: BBoard.Maintainer@CMU-CS-A

Does anyone know how to open a file for output in Franz lisp and
@i(append) to that file?  The function "outfile" always deletes the old
version first.

Thanks,
Nancy Skooglund


From @MIT-MC:day@cmu-cs-h.arpa  Sun Nov 11 11:57:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA16052; Sun, 11 Nov 84 11:57:03 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA15747; Sun, 11 Nov 84 11:54:17 pst
Message-Id: <8411111954.AA15747@UCB-VAX.ARPA>
Date: 11 Nov 84 00:15:49 EST
From: David.Yaskin@CMU-CS-H
Subject: Franz Question
To: BBoard.Maintainer@CMU-CS-A


How does one change the depth and length of list returned from functions.
While using CMULisp it keeps returning & instead of my list.

		David Yaskin   ( day@h)


From Johnson%udel-dewey.delaware@udel-relay.ARPA  Sun Nov 11 19:11:37 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA19376; Sun, 11 Nov 84 19:11:37 pst
Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA21463; Sun, 11 Nov 84 19:08:46 pst
Message-Id: <8411120308.AA21463@UCB-VAX.ARPA>
Received: From udel-dewey.ARPA by udel-relay.ARPA id a010044
          ;11 Nov 84 22:09 EST
Date:     Sun, 11 Nov 84 22:07:41 EST
From: johnson <johnson%udel-dewey.delaware@udel-relay.ARPA>
To: David.Yaskin@cmu-cs-h.ARPA
Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA
Subject:  Re:  Franz Question

--------------------  for franz -----------------------------
In franz lisp, 'prinlevel' is a variable controlling the
depth to which the top-level is to print lists, 'prinlength'
controls how many elements of a list are printed by the
top-level. For either variable, a value of 'nil' represents
infinite depth or length.

If franz is printing expressions as '&' then 
prinlevel has a value of 0.

you should
(setq prinlevel nil)
to print lists of arbitrary depth.
(see Appendix B of the Franz manual)

----------------  for CMU --------------------

In CMULisp, tlprint does the top-level printing, and this is
defined, (in, at least the 2 systems that I use) as:

	'(lambda (x) (printlev x 4))

if your functions always return &, then perhaps someone has defined
it as '(lambda (x) (printlev x 0))

if you want to change it you may either:
1.  (sstatus translink nil)
    (defun tlprint (x) (printlev x <some-large-number>))

OR,  the solution  I prefer:

2.  (load 'toplevel)  ; unnecessary in some installations.
    (defun tlprint (x) (top-print x))
  
causing 'prinlevel' and 'prinlength' to have
the effect described above for the franz system.
 
 NB: the tempting solution:
 (defun tlprint (x) (printlev x prinlevel))
 FAILS in the case that prinlevel is nil


-johnson@udel-ee

From Johnson%udel-dewey.delaware@udel-relay.ARPA  Sun Nov 11 19:31:52 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA19491; Sun, 11 Nov 84 19:31:52 pst
Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA21770; Sun, 11 Nov 84 19:29:03 pst
Message-Id: <8411120329.AA21770@UCB-VAX.ARPA>
Received: From udel-dewey.ARPA by udel-relay.ARPA id a010257
          ;11 Nov 84 22:29 EST
Date:     Sun, 11 Nov 84 22:21:49 EST
From: johnson <johnson%udel-dewey.delaware@udel-relay.ARPA>
To: Nancy.Skooglund@cmu-ri-isl3.ARPA
Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA
Subject:  Re:  opening file for output, append

In later versions of franz, 'outfile' takes a second argument;
to open a file for appending:

    (setq portname (outfile '<filename> 'a))

{try:
    (help outfile)
for a full description.}

If this does not work on your version, I have a hack that associates a port
with ANY open file descriptor, but it uses 4.x system calls, - so don't
request it unless the you can't use the new 'outfile' function.

-johnson@udel-ee


From @MIT-MC:nss@cmu-ri-isl1.arpa  Mon Nov 12 06:45:39 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22731; Mon, 12 Nov 84 06:45:39 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA01316; Mon, 12 Nov 84 06:42:54 pst
Message-Id: <8411121442.AA01316@UCB-VAX.ARPA>
Date: 12 Nov 84 09:34:14 EST
From: Nancy.Skooglund@CMU-RI-ISL1
Subject: append to file answer found
To: BBoard.Maintainer@CMU-CS-A

Thanks to all who responded to my Franz lisp question about opening a
file for output and appending to it.  Here's how it works:

	(outfile '<filename> 'a)

'a may be replaced by any symbol or string whose name begins with a.

Nancy


From JAAKOV@WISDOM.BITNET  Tue Nov 13 04:26:24 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04324; Tue, 13 Nov 84 04:26:24 pst
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA20746; Tue, 13 Nov 84 04:25:59 pst
Received: from wisdom.BITNET
	by ucbjade.CC.Berkeley.ARPA (4.17/4.27.5)
	id AA10274; Tue, 13 Nov 84 04:24:53 pst
Received: by wisdom.BITNET (4.12/4.7)
        id AA01997; Tue, 13 Nov 84 11:29:45 -0200
Date: Tue, 13 Nov 84 11:29:45 -0200
From: jaakov@wisdom.BitNet (Jacob Levy)
Message-Id: <8411130929.AA01997@wisdom.BITNET>
To: franz-list@wisdom.BitNet
Subject: Announcement of new Lisp for UN*X 4.x VAXen

I don't know if this is the appropriate place for this announcement, but
here goes anyway :-


        YLISP, a Coroutine-based Lisp System for VAXen.
        -=============================================-

        A friend of  mine, Yitzhak  Dimitrovski, and  myself, wrote a Lisp
system for UN*X 4.x systems on VAXen. It has the following features :-

        o - Coroutines and  closures. The  system uses  these to implement
            the user-interface, single-stepping and  error-handling.  It's
            easy to write a scheduler and time-share YLISP between  two or
            more user programs.
        o - Multiple-dimension arrays.
        o - Multiple name  spaces (oblists) arranged  in a tree hierarchy.
            This is similar to the Lisp Machine facility.
        o - Defstruct structure definition package.
        o - Flavors object-oriented programming tools.
        o - User-extensible  evaluator (it is  possible to (re)define  the
            actions of 'eval', 'apply' and 'print'  relative to all  user-
            and pre-defined types).
        o - Integer arithmetic. No floating-point, sorry. don't think that
            that's  really  necessary, but *could*  be hacked. No  BIGNUMs
            either.
        o - Good user-interface with history, sophisticated error handling
            and function-call and variable-assignment tracing facilities.
        o - Extensive library of ported and user-contributed programs,such
            as a variant of the Interlisp  structure editor, 'loop' macro,
            'mlisp' Pascal-like embedded language, etc.
        o - Compiler  that  generates efficient native  assembler code for
            the VAXen. The  compiler is provided as a separate program,due
            to size  considerations. The compiler is  written entirely  in
            Lisp, of course.
        o - Extensive online documentation, as well as  a 400-page  manual
            describing the whole system from a programmer's point of view.

        The system is named  'YLISP', and was written for 4.1 when we were
students at the Hebrew University  at Jerusalem. Since  then, Yitzhak  has
left  for the  US and  is  currently a  Ph.D. student in  Prof. Schwartz's
Supercomputer group at Courant. I have continued to  develop the system on
my own, and have ported it to UN*X 4.2.

        I am looking for a site that is willing to handle the distribution
of this software from the US, by letting  one FTP it  from their computer.
Alternatively, I am also willing to supply people  with magtapes of YLISP,
for the cost of the tape and handling charges (about 70$ a piece).  If you
are interested, please respond by electronic mail to one of  the addresses
given below. I will be  ready  to  start distributing  the  system in  two
weeks' time.

        Rusty Red (AKA Jacob Levy)

        BITNET:                         jaakov@wisdom
        CSNET and ARPA:                 jaakov%wisdom.bitnet@wiscvm.ARPA
        UUCP: (if all else fails..)     ..!decvax!humus!wisdom!jaakov




From ssc-vax!steve@uw-beaver.arpa  Tue Nov 13 06:20:04 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04848; Tue, 13 Nov 84 06:20:04 pst
Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA05430; Mon, 12 Nov 84 15:45:22 pst
Received: by uw-beaver.arpa (4.12/2.2)
	id AA28549; Mon, 12 Nov 84 15:43:15 pst
Return-Path: <ssc-vax!steve@uw-beaver.arpa>
Received: by ssc-vax (4.12/4.7)
	id AA03520; Mon, 12 Nov 84 09:58:10 pst
Date: Mon, 12 Nov 84 09:58:10 pst
From: ssc-vax!steve@uw-beaver.arpa (Steve White)
Message-Id: <8411121758.AA03520@ssc-vax>
To: uw-beaver!JonL.pa@XEROX, uw-beaver!smh@mit-eddie
Subject: Re: readtable within fasl
Cc: uw-beaver!franz-friends@BERKELEY

My problem was a bit simplier then the general case you mention. In MRS
a 'variable' is really a reader-macro ($) that at read time assigns a special
value to each variable-base-name. Basically it does a
	(set (implode `(|$| . ,(explodec name))) 'bl).
for side-effects of marking the symbol as a variable.  When compiling files
containing MRS code the compiler would execute the call inside its environment,
placing the *unbound* literals (as .asciz) in the object file to be READ
in at load time... so MRS would get the symbols and treat them as symbols
not variables.

The only reason i mention this is that the workaround used might be useful
for others seeking side effects within macros etc.
My workaround (h.a.c.k) was to use a special variable
	liszt-eof-forms
as a queue of the above SET forms and to provide a different macro expansion
for compile-time.  So

(setsyntax '|$| 'macro
  #'(lambda nil (let ((varname (implode `(|$| ,@(explodec (read))))))
		     (addq `(setq ,varname 'bl) liszt-eof-forms)
		     varname)))		;; return variable name to liszt!

[where ADDQ does the correct thing if the variable has already been seen],
adds the following to the object file
	.asciz "$xyz"
	.asciz "(setq $xyz 'bl)"
which basically works (don't gag!)
					steve white

YAP -- (yet another problem) : does anyone at MIT have a list of fixes
to franz 38.91 to make the zeta-lisp environment work :-) I started fixing
a few things but it looks like something that might MIT may have already
done. ((or any plans to put NIL under UNIX? 8-) ))

From ucscc!pravda@ucscd.ucscc.UUCP  Thu Nov 15 18:09:13 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA12102; Thu, 15 Nov 84 18:09:13 pst
Received: by UCB-VAX.ARPA (4.24/4.39)
	id AA11658; Thu, 15 Nov 84 18:09:11 pst
Received: from ucscd.UCSC (ucscd.ARPA) by ucscc.UCSC (4.12/4.7)
	id AA23553; Thu, 15 Nov 84 10:48:02 pst
Received: by ucscd.UCSC (4.12/4.7)
	id AA04900; Thu, 15 Nov 84 10:45:19 pst
Date: Thu, 15 Nov 84 10:45:19 pst
From: ucscc!pravda@ucscd.ucscc.UUCP (05550000)
Message-Id: <8411151845.AA04900@ucscd.UCSC>
To: ucbvax!franz-friends@c.CC
Subject: mailing list name change

		
	Please stop sending to
		ucscc!figgy
	
	instead add
		ucbvax!ucscc!lispers
	
	Thank you.

From weeks@ucbruby.CC  Thu Nov 15 20:51:49 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA13810; Thu, 15 Nov 84 20:51:49 pst
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA14507; Thu, 15 Nov 84 20:51:52 pst
Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.18/4.27.5)
	id AA01653; Thu, 15 Nov 84 20:51:05 pst
Received: by ucbruby.CC.Berkeley.ARPA (4.18/4.27.6)
	id AA02961; Thu, 15 Nov 84 20:50:39 pst
Date: Thu, 15 Nov 84 20:50:39 pst
From: weeks@ucbruby.CC (Harry Weeks)
Message-Id: <8411160450.AA02961@ucbruby.CC.Berkeley.ARPA>
To: franz-friends@BERKELEY
Subject: Lisp implementation details.

Are there any technical reports or memoranda available which
describe the internal workings of Franz?
						-- Harry

From @MIT-MC:tg@cmu-cs-cad.arpa  Wed Nov 28 11:32:50 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA15208; Wed, 28 Nov 84 11:32:50 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA14658; Wed, 28 Nov 84 11:32:04 pst
Message-Id: <8411281932.AA14658@UCB-VAX.ARPA>
Date: 28 Nov 84 14:24:42 EST
From: Timothy.Glavin@CMU-CS-CAD
Subject: cmulisp docs
To: BBoard.Maintainer@CMU-CS-A

Does anyone know the location of on-line documentation for
cmulisp.  If not, is there a source for hard copy documentation?
I have the Foderaro Franz Lisp Manual, I only looking for info
on the CMU ideosyncracies.
					-- Tim (tg@cad)


From smith@nrl-aic  Fri Nov 30 09:17:53 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA15087; Fri, 30 Nov 84 09:17:53 pst
Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA24282; Fri, 30 Nov 84 09:15:33 pst
Date: 30 Nov 1984 11:50-EST
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: bugs using flavors (and more)
To: franz-friends@BERKELEY
Message-Id: <470681409/smith@nrl-aic>

I recently installed opus 38.91 on our VAX780 under 4.2BSD. The
installation went smoothly. The files used for the installation appear
to be the most recent available from ucbkim. This includes the flavors
stuff with appropriate modifications (for example, fixing hash.l to use
"vsize" instead of "getlength" on a vector). The flavors stuff I scarfed
TODAY was dated October 2nd I believe. Anyway, I tried out some things
with flavors and, in particular, with "describe"...with the
following result (done with "script"):
=============================================================================
% lisp
Franz Lisp, Opus 38.91
-> (defflavor ob () () :settable-instance-variables)
[autoload /usr/lib/lisp/flavors]
[fasl /usr/lib/lisp/flavors.o]
[fasl /usr/lib/lisp/machacks.o]
[fasl /usr/lib/lisp/lmhacks.o]
[fasl /usr/lib/lisp/flavorm.o]
[fasl /usr/lib/lisp/vanilla.o]
ob
-> (describe 'ob)
[autoload /usr/lib/lisp/describe]
[fasl /usr/lib/lisp/describe.o]

ob has property flavor: flavor[17]
Error: Undefined function called from compiled code  defstruct-description-name
<1>: (exit)
=============================================================================
[Well, "defstruct-description-name" is used all over the
"/usr/lib/lisp/struct.l" set of functions...apparently mostly with no
arguments...which, I think, is wrong. One fix made by SMH to "describe.l" 
replaced a call on this macro with one with an argument. But that's NOT this
problem anyway.]

(1) Is there a known fix to get the "describe", or anything else that
	 uses the "defstruct-description-name" macro, working correctly?

(2) Could it be that some sort of extended "defflavor" would load in an
	 appropriate file which on-the-fly defines this macro? That is,
	 did I do TOO simple a "defflavor"? [For example, doing:

		(load '/usr/pub/lisp/struct.l)

	 allows one to "(pp defstruct-description-name)" showing that
	 it requires an argument...without the "load" it is undefined.]

(3) Could the copy of the ftpable (???) opus38.91 files we have be out
	 of date (seem to be from around June 84)?

Any help would be much appreciated. We are attempting to develop
some stuff for use on both an LMI Lisp Machine and the VAX. This has
thrown the proverbial wrench into the work(s)...

Russ <Smith@nrl-aic>
Navy Center for Applied Research in Artificial Intelligence (whew!)

From MCLINDEN@RUTGERS.ARPA  Sat Dec  1 15:40:10 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04698; Sat, 1 Dec 84 15:40:10 pst
Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA03439; Sat, 1 Dec 84 14:28:56 pst
Message-Id: <8412012228.AA03439@UCB-VAX.ARPA>
Date: 30 Nov 84 22:45:59 EST
From: Sean McLinden  <MCLINDEN@RUTGERS.ARPA>
Subject: Re: bugs using flavors (and more)
To: smith@NRL-AIC.ARPA, franz-friends@BERKELEY
Cc: MCLINDEN@RUTGERS.ARPA
In-Reply-To: Message from "Russ Smith <smith@nrl-aic.ARPA>" of 30 Nov 84 11:50:00 EST


  There is a bug in the way that describe is compiled according to the
  makefile. Basically the problem is that defstruct-description-name
  is a macro which is NOT compiled so that when you fasl the compiled
  version of struct (as you are compiling describe), you don't get
  the proper definition for defstruct-description-name.

  You can either 1). load struct.l when compiling describe.l or
		 2). (declare (macros t)) in struct.l and recompile.

  Sean McLinden
  Decision Systems Laboratory
-------

From sridhar%wsu.csnet@csnet-relay.arpa  Sat Dec  1 17:03:50 1984
Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA06036; Sat, 1 Dec 84 16:55:15 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.38)
	id AA08322; Sat, 1 Dec 84 16:50:50 pst
Message-Id: <8412020050.AA08322@ucbernie.ARPA>
Received: from wsu by csnet-relay.csnet id a012949; 1 Dec 84 19:41 EST
Date:     Sat, 1 Dec 84 12:47 PST
From: "S. Sridhar" <sridhar%wsu.csnet@csnet-relay.arpa>
To: franz-friends@UCBERNIE.ARPA
Cc: sridhar%wsu.csnet@csnet-relay.arpa
Subject:  Documentation pblms.

Hi,
  I am an ardent Franz hack here at Wash. St. Univ, Pullman.
  I need some specific info on Franz Lisp.

 There is no documentation on 'Structures' in the Franz Lisp manual, that
we have here. (This is dated June 1983. The version we have is Opus 38.69,
June 1983). Specifically I need documentaion on all the macros related to
the use of structures like defstruct. I know for sure that these macros
are available on our system, but I am having problems on their usage. The
on-line documentation does not give any help either. Maybe you have an 
updated version of the Franz Lisp manual. Can you help around, please ?

As another instance, functions relating to hashtables are available here
but there is no documentation for it. 

Thanks.

Sridhar
------

From smith@nrl-aic  Mon Dec  3 12:17:10 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04104; Mon, 3 Dec 84 12:17:10 pst
Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA16806; Mon, 3 Dec 84 12:14:27 pst
Date: 3 Dec 1984 06:36-EST
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: followup to "flavors bugs (and more)"
To: franz-friends@BERKELEY
Message-Id: <470921820/smith@nrl-aic>

This is a followup to a previous note I sent requesting help with fixing
Opus 38.91 of Franz and Flavors running on a Vax780 under 4.2BSD.

First, I want to thank the many people who had helpful suggestions on
what may have been going wrong. Given the small amount of information I
provided on the problem, some of them were remarkably relevant.

The problem had to do with certain functions such as "describe" going
south when invoked on a FLAVOR object. The solution was (at least) two
fold. One, which I alluded to in the previous note, had to do with the
distributed file "hash.l" containing invalid calls on the intrinsic
"getlength" function with a vector argument. These calls had to be
changed to "vsize" instead (actually "getlength" could probably have
been redefined to allow vectors...). Whatever, that solved that part.

The second solution had to do with how WE at NCARAI were installing
Franz. We have a set of directories for "local" software into which
we wanted to put the "new" Franz. As such, I went through all the
"Makefile"s and changed default directories for such things as the
libraries and objects, etc. While doing this, it was noted that certain
files in the "lisplib" directory had hard-coded the default names for, for
example, the library. Since our library was not in the same place as
this default, these lines were "commented out" (with an "exit")...with
the result that the Franz and Liszt installations did not go as smoothly
as I thought. It turns out that these lines also should be changed to
reflect the appropriate directory. They are in the files "buildlisp.l",
"common1.l", and "fix.l" in the lisplib directory (possibly others exist as
well). The pertinent lines read something like:

	(or (boundp 'default-library-directory)
	    (setq default-library-directory '/usr/lib/lisp))

During the installation (done on a CRT) I was doing something else. Thus
when the mods made (namely changing the "setq" call above into an "exit")
were invoked, I didn't notice later that a number of things which SHOULD have
happened didn't (they'd gone off the screen...). Needless to say, this
caused all sorts of bizarre inconsistencies (especially since our last
installation DID use the default directories...).

Anyway, notes for the future:

	(1) If ftp'ing Franz from ucbkim be sure to get the stuff in the
	    "flavors" directory as well. This contains a new "hash.l"
	    modified by SMH to use "vsize" rather than "getlength".

	(2) If not using the default directories for the installation,
	    change the names in the above files as well to reflect the
	    appropriate place(s)...sigh.

Yours (with an apparently working Franz+flavors),

Russ <Smith@nrl-aic>
Navy Center for Applied Research in Artificial Intelligence (whew!)

From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 12:49:49 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20917; Tue, 4 Dec 84 12:49:49 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA24636; Tue, 4 Dec 84 12:13:23 pst
Message-Id: <8412042013.AA24636@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA19371; Tue, 4 Dec 84 14:50:26 est
Date: Tue, 4 Dec 84 14:50:26 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: the *real* flavor sources (etc.)

For some time I have been using and maintaining enhanced versions of the
several Franz lisplib modules which implement various Lisp Machine
compatibilities, most notably, the FLAVOR system and FORMAT output.
jkf@berkeley has authorized me to announce public availability of these
files via anonymous ftp from UCBKIM.  These seven files are compatible
with Opus 38.91, but supersede the versions in the 39.91 distribution.
There are a number of bugfixes and new features.

UCBKIM supports FTP with login "anonymous" and any password.  The
files are:
	 ~anonymous/pub/flavors/Makefile
				flavors.l
				flavorm.l
				vanilla.l
				hash.l
				describe.l
				format.l

The changes are too many to describe in detail.  Many of the FLAVOR
system changes are for compatibility with changes to Franz, although a
few non-working or missing features (but not all) have been bludgeoned
into functionality.  In particular, wrappers work.  The FORMAT module
fixes a number of format directives which apparently never worked.
However, some of the hairier ones are known still to be defective.

This "completely unsupported" software is graciously being made
available to all takers without any promises whatever:  there is no
promise of correctness, and no promise of support.  Also, the sources
total 160K and unsuitable for uucp distribution, and I don't have time
to deal with tape requests [sorry].

The above notwithstanding, I am as eager as anyone for additional
improvements to the code.  Anyone with additional bugfixes is encouraged
to communicate to me, and I will try to integrate the code.  I will try
to respond to bug reports, but it may be a rather low priority business.

Steve Haflich
MIT Experimental Music Studio
ARPA: smh@mit-eddie@mit-mc
UUCP: {ihnp4, decvax!genrad}!mit-eddie!smh


From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 19:32:49 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA26327; Tue, 4 Dec 84 19:32:49 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA26237; Tue, 4 Dec 84 13:26:17 pst
Message-Id: <8412042126.AA26237@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA20260; Tue, 4 Dec 84 15:44:20 est
Date: Tue, 4 Dec 84 15:44:20 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: fix for describe.l
Cc: MCLINDEN@RUTGERS@MIT-MC, smith@nrl-aic@mit-mc

Previous postings have correctly identified the problem (which was fixed
long ago in the versions announced today).  The best fix is to change
the (environment-lmlisp) invocation near the beginning of describe.l to
read as follows, then recompile it:

	(environment-lmlisp (compile eval) (files struct flavorm))

The struct and flavorm modules do not need to be around when the
compiled describe code is executed, so omitting load from the eval-when
saves some unnecessary fasl's.  Describe, by the way, is useful even
when flavors and defstructs are not being used.  For instance, it will
report the source module in which a compiled function lives.

Steve Haflich
smh@mit-eddie@mit-mc
{ihnp4, decvax!genrad}!mit-eddie!smh


From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 22:49:05 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA29026; Tue, 4 Dec 84 22:49:05 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA05974; Tue, 4 Dec 84 20:50:44 pst
Message-Id: <8412050450.AA05974@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA24308; Tue, 4 Dec 84 23:50:01 est
Date: Tue, 4 Dec 84 23:50:01 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: Franz documentation for MIT LM code
Cc: sridhar%wsu.csnet@csnet-relay

Sorry to report that there really is no official documentation for the
several Franz lisplib modules which implement a measure of compatibility
with Zetalisp, the dialect running on MIT Lisp Machines (and, more or
less, on Symbolics and LMI machines).  The Franz source code was adapted
from the MIT Lisp machine code several years ago; there is still
approximate compatibility, although new features and certain semantic
subtleties have diverged.  Driven partially by natural evolution and
partially by the standardization efforts of Common Lisp, Lisp Machine
compatibility is something of a moving target.

But do not despair; there are two standardly available sources for
documentation.  Reading them will give a very usable idea about the
packages.  Unfortunately, a few unimplemented features and semantic
differences will have to be discovered by experimentation or examination
of the source code.  (What do you want for free? :-)

(1) If you have available a MIT Lisp Machine Manual, the sections on
defstruct, flavors, format, hash, and loop output are still reasonable
approximations of documentation for the Franz versions.  Incidentally,
the `Blue' MIT Lisp Machine Manual circa 1981 corresponds most closely
with the Franz inplementation, although a few more recent features have
been retrofitted.  If available, Symbolics documentation is probably
only very slightly less good -- the older, the better.

(2) For defstruct, hash, and format the Guy Steele <Common Lisp: The
Language>, published by Digital Press (a branch of DEC), is usefully
close to the existing Franz code.  Again, experimentation and
examination of the source code will resolve the details.  Unfortunately,
Flavors and the loop macro are not (yet) part of the Common Lisp
specification, and may well be very different when they are.

Unofficially, there is another even better hope.  The MIT Athena project
will be `releasing' these packages into their standard Franz system this
in another month or two.  They are commencing a quick effort to edit
Lisp Machine documentation into proper format for inclusion as
appendixes in the Franz manual.  If at all possible, I will attempt to
get the results publically distributed.  (Translation:  My assistance is
essential to this documentation, so I am in position to insist they be
`reasonable' about it...)  But no promises just yet.

Steve Haflich
MIT


From MAILER@CUNYVM.BITNET  Thu Dec  6 13:53:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03880; Thu, 6 Dec 84 13:53:03 pst
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA27039; Thu, 6 Dec 84 11:43:13 pst
Received: from CUNYVM.BITNET
	by ucbjade.CC.Berkeley.ARPA (4.19/4.30)
	id AA27252; Thu, 6 Dec 84 11:44:10 pst
Message-Id: <8412061944.AA27252@ucbjade.CC.Berkeley.ARPA>
Received: by CUNYVM     id 8508; Thu, 06 Dec 84 14:41:26 EST
Date:         Thu, 6 Dec 84 14:39 EST
From: Henry Nussbacher <HJNCU@CUNYVM.BitNet>
To: <sf-lovers-request@rutgers.arpa>, <franz-friends@BERKELEY>,
        <ailist-request@sri-ai>, <works@rutgers.arpa>,
        <info-graphics@utexas-20.arpa>, <prolog-request@su-score.arpa>

Can you please register the following user to your lists:
arpalist%cunyvm.BITNET

Thank you,
Henry Nussbacher
BITNET Network Information Center

From mike@rice.ARPA  Thu Dec  6 18:20:03 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA07782; Thu, 6 Dec 84 18:20:03 pst
Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA05141; Thu, 6 Dec 84 17:55:14 pst
Received: from thule by rice.ARPA (AA02673); Thu, 6 Dec 84 19:41:33 CST
Received: by thule (AA02845); Thu, 6 Dec 84 19:38:53 cst
Date: Thu, 6 Dec 84 19:38:53 cst
From: Mike Caplinger <mike@rice.ARPA>
Message-Id: <8412070138.AA02845@thule>
To: franz-friends@BERKELEY
Subject: bug in 68k Opus 38.91 arrays

In 68k Opus 38.91, the expression
(array foo flonum-block 4 4)
generates an "Error: IMPROPER USE OF SET".

On the VAX, in Opus 38.79, this worked fine.  What's happening?

(I am on a Sun, compiled with sun_4_2.)

	- Mike

From @MIT-MULTICS.ARPA:POSTMASTER@VANDERBILT.MAILNET  Sat Dec  8 05:42:09 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA25844; Sat, 8 Dec 84 05:42:09 pst
Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA22892; Sat, 8 Dec 84 05:39:47 pst
Received: from VANDERBILT.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2648813816713007@MIT-MULTICS.ARPA>; 08 Dec 1984 08:36:56 est
Date:        06 Dec 84 15:26 CDT
From: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA
Reply-To:    David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA
To: "franz-friends"@BERKELEY
Subject:     FranzLISP on the S9000
Message-Id:  <30788@VUCCG1COM>
In-Reply-To: <30731@VUCCG1COM>

The AI Group at Vanderbilt would like to join the franz-friends
mailing list. We have version 38.87 running on the IBM Inruments
S9000 under CSOS 1.1, a very non-UNIX opsys. Both interpreter
and compiler are working and a farily large general-purpose
expert system tool set written on a VAX is up and running.



From MOHAN@USC-ECLC.ARPA  Mon Dec 10 12:06:53 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA18655; Mon, 10 Dec 84 12:06:53 pst
Received: from USC-ECLC.ARPA (usc-eclc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA04397; Mon, 10 Dec 84 12:04:27 pst
Message-Id: <8412102004.AA04397@UCB-VAX.ARPA>
Date: Mon 10 Dec 84 12:03:06-PST
From: MOHAN@USC-ECLC.ARPA
Subject: array  - space
To: franz-friends@BERKELEY
Cc: mohan@USC-ECLC.ARPA


I am working with images stored as fixnum arrays (with delta =1 i.e. four
pixels packed into a word)  aux as unmarked arrays. (I am on a VAX under
Eunice). How do I deallocate the array-space once I am done with it?
(I use small-segment to allocate space for the array).

Also I would appreciate any pointers of how to speed up programs with 
nested do loops (order of 512x512 x(5 x 5) itterations).

Thanks,

-Rakesh Mohan.
-------

From mike@rice.ARPA  Mon Dec 10 15:37:50 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20942; Mon, 10 Dec 84 15:37:50 pst
Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA08450; Mon, 10 Dec 84 15:35:12 pst
Received: from iapetus by rice.ARPA (AA26746); Mon, 10 Dec 84 17:28:43 CST
Received: by iapetus (AA16942); Mon, 10 Dec 84 17:29:45 CST
Date: Mon, 10 Dec 84 17:29:45 CST
From: Mike Caplinger <mike@rice.ARPA>
Message-Id: <8412102329.AA16942@iapetus>
To: franz-friends@BERKELEY
Subject: gensym and the compiler

How does one get code like the following:

; construct an identity transformation matrix.
(defun tm-new ()
    (let ((name (gensym)))
	(*array name 'flonum-block 4 4)
	(do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
	name)
)

to work under the compiler?  Compiled, this refuses to believe
in the existence of name.

Do I need to declare it as a lambda?  Is there a way to declare arrays?

	- Mike

From jkf@ucbmike  Mon Dec 10 16:03:40 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA21396; Mon, 10 Dec 84 16:03:40 pst
Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
	id AA08955; Mon, 10 Dec 84 16:01:22 pst
Received: by ucbmike.arpa (4.24ucb/4.33)
	id AA06150; Mon, 10 Dec 84 16:04:09 pst
Date: Mon, 10 Dec 84 16:04:09 pst
From: John Foderaro (on a sun) <jkf@ucbmike>
Message-Id: <8412110004.AA06150@ucbmike.arpa>
To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY
Subject: Re: array  - space
Cc: mohan@USC-ECLC.ARPA
In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST

 You would be better off using immediate vectors (vectori) which
are garbage collected.    Items allocated with small-segment aren't
gc'ed.




From jkf@ucbmike  Mon Dec 10 17:08:13 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22000; Mon, 10 Dec 84 17:08:13 pst
Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
	id AA10131; Mon, 10 Dec 84 17:05:36 pst
Received: by ucbmike.arpa (4.24ucb/4.33)
	id AA06315; Mon, 10 Dec 84 17:08:19 pst
Date: Mon, 10 Dec 84 17:08:19 pst
From: John Foderaro (on a sun) <jkf@ucbmike>
Message-Id: <8412110108.AA06315@ucbmike.arpa>
To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY
Subject: Re: array  - space
Cc: mohan@USC-ECLC.ARPA
In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST

 One small correction: small-segment space is garbage collected and
reclaimed, but only as individual elements: adjacent free elements are
not combined.   Vectors are different: adjacent free vectors are combined
into larger vectors.



From @MIT-MC:smh@MIT-EDDIE  Mon Dec 10 19:02:52 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA23540; Mon, 10 Dec 84 19:02:52 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
	id AA11754; Mon, 10 Dec 84 18:21:17 pst
Message-Id: <8412110221.AA11754@UCB-VAX.ARPA>
Received: by mit-eddie.Mit-chaos.Arpa id AA03264; Mon, 10 Dec 84 21:20:04 est
Date: Mon, 10 Dec 84 21:20:04 est
From: Steven M. Haflich <smh@mit-eddie>
To: franz-friends@BERKELEY
Subject: re: gensym and the compiler

<Mike@rice> wants to know how to make this function work:

	; construct an identity transformation matrix.
	(defun tm-new ()
	    (let ((name (gensym)))
		(*array name 'flonum-block 4 4)
		(do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
		name)
	)

The problem is that send is a macro (see lisplib/array.l), and at
compile time it is impossible for it to determine exactly the "data
type" of name.  Therefore, it expands the function to:

	(defun tm-new ()
	    (let ((name (gensym)))
		(*array name 'flonum-block 4 4)
		(do i 0 (1+ i) (= i 4) (name 1.0 i i))
		name)
	)

Essentially, it just assumes 'name is a symbol which has an array in its
function binding, or else which symevals (possibly recursively) to
something that is either an array, or a symbol with an array in its
function binding.  When the compiler compiles the expansion, it assumes
that it wants to call the function-binding of name, not the
function-binding of symeval of name.  In the interpreter it happens to
work because eval of a list in the interpreter (but not the compiler) is
defined to repetitively evaluate the car of the list until it finds a
recognizable function or array.  (See chapter 4.)  But note!!  If 'name
also has a function binding, the interpreter will find it instead of the
array!

What you really want to do, then, is this:

	(defun tm-new ()
	    (let ((name (gensym)))
		(*array name 'flonum-block 4 4)
		(do i 0 (1+ i) (= i 4) (funcall name 1.0 i i))
		name)
	)

This guarantees that name gets symevaled once before the interpreter
checks for function bindings, which also does the right thing in
compiled code.  Unfortunately, you will have to write this out by hand.
I don't see any way that the send macro can be fixed.  If it always
returned the extra funcall, then this simple case wouldn't work
compiled:

	(array foo ...)
	(store foo ...)

Did anyone follow any of this?


From BACH@SUMEX-AIM.ARPA  Tue Dec 11 20:05:09 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA06334; Tue, 11 Dec 84 20:05:09 pst
Received: from SUMEX-AIM.ARPA (sumex-aim.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA15218; Tue, 11 Dec 84 20:03:46 pst
Message-Id: <8412120403.AA15218@UCB-VAX.ARPA>
Date: Tue 11 Dec 84 20:04:16-PST
From: Rene Bach <BACH@SUMEX-AIM.ARPA>
Subject: Porting FRANZ to other OS running C ?
To: franz-friends@BERKELEY

I am interested in finding out if someone has ported FRANZ to some
other OS than UNIX. A friend of mine is interested in running a LISP
under VMS at no cost. He has C on his machine.
Is this feasible, how much work is involved ?

What about porting FRANZ to some UNIX look alike ?  How much work is
involved ?

Thanks for any leads
Rene
-------

From MCLINDEN@RUTGERS.ARPA  Tue Dec 11 20:44:19 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA06672; Tue, 11 Dec 84 20:44:19 pst
Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA16044; Tue, 11 Dec 84 20:42:36 pst
Message-Id: <8412120442.AA16044@UCB-VAX.ARPA>
Date: 11 Dec 84 23:41:49 EST
From: Sean McLinden  <MCLINDEN@RUTGERS.ARPA>
Subject: Re: Franz documentation for MIT LM code
To: smh%MIT-EDDIE@MIT-MC.ARPA, franz-friends@BERKELEY
Cc: sridhar%wsu.csnet@CSNET-RELAY.ARPA, MCLINDEN@RUTGERS.ARPA
In-Reply-To: Message from "Steven M. Haflich <smh@mit-eddie>" of 4 Dec 84 23:50:01 EST



 Regarding the documentation for Franz Lisp and the MIT/Lisp Machine
 compatibility packages:

 Another option exists for those who might be interested. We at Decision
 Systems Lab have been using a modified version of Opus 38.89 which in-
 cludes the  defstruct and flavors code already described. It also in-
 cludes an Interlisp compatibility package which allows Interlisp
 records as well as most of the CLISP forms (these are actually very
 easily simulated with LOOP but we chose a strategy which is more
 in keeping with the Interlisp implementation of CLISP involving
 hashed definitions for CLISP forms.

 The modified Lisp has all of the up-to-date flavors code and an
 edited version of the manual which describes the format, defstruct,
 and CLISP packages (borrowing heavily from the Laser edition of
 the Common Lisp manual by Guy Steele). It also includes a re-organization
 of much of the older manual into a more coherent form, and a number
 of examples of more difficult concepts.

 If there is any interest I can make this publicly available. It would
 be of little value to simply have the additional chapter since it
 refers, heavily, to material in other sections. Also, flavors is not,
 yet included, since the status of flavors in Franz was uncertain up
 to a few months ago.

 For those interested, I will not be prepared to answer requests before
 Christmas but after that I'll be around and can handle almost anything.

 Sean McLinden
 Decision Systems Laboratory
 University of Pittsburgh

-------

From @MIT-MC:ZZZ.RLK@MIT-OZ  Wed Dec 12 21:51:39 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08208; Wed, 12 Dec 84 21:51:39 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA07258; Wed, 12 Dec 84 21:03:56 pst
Message-Id: <8412130503.AA07258@UCB-VAX.ARPA>
Date: Wednesday, 12 December 1984, 19:53-EST
From: Robert L. Krawitz <ZZZ.RLK@MIT-OZ>
Reply-To: rlk%mit-eecs at mit-mc.arpa
To: franz-friends@BERKELEY

Hi.

I'm writing a term paper on the procedure call in various languages,
perhaps on various languages on the VAX, perhaps just on the procedure
call in various dialects of Lisp on the Vax.

Could someone mail me some info on this subject (i. e. the calling
conventions, how/if the Vax procedure call instructions are used, etc.)
quickly, as this is the last week of classes and I don't want to take
too long on this paper.  Thanks.

Robert^Z

From psm@mitre-bedford  Mon Dec 17 09:05:35 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20993; Mon, 17 Dec 84 09:05:35 pst
Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA19421; Mon, 17 Dec 84 09:04:32 pst
Message-Id: <8412171704.AA19421@UCB-VAX.ARPA>
Date: 17 Dec 1984 11:56:37-EST
From: psm@Mitre-Bedford
To: franz-friends@BERKELEY
Subject: Please add me to your  mailing list.
Cc: psm@Mitre-Bedford

Hi,

Would you please add me to your mailing list/ user's group.
(I hope this is the right place to make the request & it's not
franz-friends-request or something like that.  Sorry for the
inconvenience if it is.)

Peter Mager
(psm@mitre-bedford)

From jkf@ucbmike  Mon Dec 17 13:01:48 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00901; Mon, 17 Dec 84 13:01:48 pst
Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
	id AA24456; Mon, 17 Dec 84 13:00:55 pst
Received: by ucbmike.arpa (4.24ucb/4.33)
	id AA15009; Mon, 17 Dec 84 13:03:16 pst
Date: Mon, 17 Dec 84 13:03:16 pst
From: John Foderaro (on a sun) <jkf@ucbmike>
Message-Id: <8412172103.AA15009@ucbmike.arpa>
To: psm@Mitre-Bedford, franz-friends@BERKELEY
Subject: Re: Please add me to your  mailing list.
Cc: psm@Mitre-Bedford
In-Reply-To: Your message of 17 Dec 1984 11:56:37-EST

 I've added you to franz-friends.
 


From jkf@ucbmike  Mon Dec 17 13:06:53 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA01005; Mon, 17 Dec 84 13:06:53 pst
Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
	id AA24568; Mon, 17 Dec 84 13:05:59 pst
Received: by ucbmike.arpa (4.24ucb/4.33)
	id AA15044; Mon, 17 Dec 84 13:08:10 pst
Date: Mon, 17 Dec 84 13:08:10 pst
From: John Foderaro (on a sun) <jkf@ucbmike>
Message-Id: <8412172108.AA15044@ucbmike.arpa>
To: franz-friends@BERKELEY
Subject: I'll be away
Cc: 


  For the new few weeks I'll be unable to handle franz-friends requests.

  Happy Holidays to all of you.

  					john foderaro
					
  


From @MIT-MC:wah@cmu-cs-ius.arpa  Mon Dec 17 13:08:08 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA01035; Mon, 17 Dec 84 13:08:08 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA24610; Mon, 17 Dec 84 13:07:10 pst
Message-Id: <8412172107.AA24610@UCB-VAX.ARPA>
Date: 17 Dec 84 16:02:13 EST
From: Wilson.Harvey@CMU-CS-IUS
Subject: appending to files in lisp?
To: BBoard.Maintainer@CMU-CS-A


Does anyone have a function that will allow them to append to a file?  I
need to open a file and write some data to it then, at a later time, reopen
the same file and add some more data to it.  The only things that I could
find in Franz were "infile" and "outfile", and "outfile" truncates the file
when called.  It would be nice if the function would create the file if it
didn't already exist, but that is not necessary.

Thanks. --Wilson

P.S. I tried writing a C-function to handle this, but I didn't have any luck
passing the FILE pointer back into Franz.  It didn't recognize the pointer
as a port, and I don't know how to set it straight.


From cadwall@Ardc.ARPA  Mon Dec 17 13:31:59 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA01357; Mon, 17 Dec 84 13:31:59 pst
Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA25405; Mon, 17 Dec 84 13:30:56 pst
Message-Id: <8412172130.AA25405@UCB-VAX.ARPA>
Date:     Mon, 17 Dec 84 16:23:16 EST
From: William K. Cadwallender (LCWSL) <cadwall@Ardc.ARPA>
To: franz-friends@BERKELEY
Subject:  Please change my ID

The computer people here at ARDC have changed my ID: I was wkc@ARDC, I am
now cadwall@ARDC. Please update the franz-friends mailer accordingly.
				Thanks,
				Bill Cadwallender
				(now cadwall@ARDC)

From liz@tove  Tue Dec 18 12:19:24 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00302; Tue, 18 Dec 84 12:19:24 pst
Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA04349; Tue, 18 Dec 84 11:54:53 pst
Received: by tove.ARPA (4.12/4.7)
	id AA26165; Tue, 18 Dec 84 14:54:41 est
From: Liz Allen <liz@tove>
Message-Id: <8412181954.AA26165@tove.ARPA>
Date: 18 Dec 1984 1454-EST (Tuesday)
To: Wilson.Harvey@CMU-CS-IUS
Cc: franz-friends@BERKELEY
Subject: Re: appending to files in lisp?
In-Reply-To: Your message of 17 Dec 84 16:02:13 EST.
             <8412172107.AA24610@UCB-VAX.ARPA>

To append to a file, use the outfile function's second argument:

	(setq oport (outfile '<filename> 'append))

This is discussed in the documentation for outfile in the Franz Lisp
Manual.

				-Liz

From @MIT-MC:wah@cmu-cs-ius.arpa  Tue Dec 18 16:46:44 1984
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA02563; Tue, 18 Dec 84 16:46:44 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA10079; Tue, 18 Dec 84 16:15:50 pst
Message-Id: <8412190015.AA10079@UCB-VAX.ARPA>
Date: 17 Dec 84 23:04:24 EST
From: Wilson.Harvey@CMU-CS-IUS
Subject: appendfile question answered
To: BBoard.Maintainer@CMU-CS-A


Wow, was that an easy question.  All the responces were equally simple (use
"fileopen" with mode = a, or use "outfile" with the extra argument
"append").

I must have an outdated copy of the manual because I could find none of
these "features" documented.  A hearty "Thank you" to all who responded.

Wilson


From johnson@UDEL-EECIS2.DELAWARE  Wed Jan  2 03:00:04 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08140; Wed, 2 Jan 85 03:00:04 pst
Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
	id AA01144; Wed, 2 Jan 85 02:51:04 pst
Message-Id: <8501021051.AA01144@UCB-VAX.ARPA>
Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a029713
          ;2 Jan 85 5:57 EST
To: franz-friends@BERKELEY
Cc: johnson@udel-dewey
Subject: franz on 68k-based systems? (esp NCR tower)
Date: 02 Jan 85 05:57:37 EST (Wed)
From: johnson <johnson@udel-dewey>


Has anyone out there had experience using franz (or similar lisps)
on an NCR tower or tower XP? (or any other 68k-based unix system ?)

I am interested in answers to these questions:

 1. What version of (franz) lisp are you using.

 2. Are there any special problems you've discovered in this system?

 3. How does this system perform? (compared to franz on a VAX 11/70,
	assuming you have had experience with both)

 4. Where did you obtain your version of (franz) lisp and how?
    (what media, what cost, under what terms or license?)

 thanks in advance,
 johnson@udel-ee

From sridhar%wsu.csnet@csnet-relay.arpa  Thu Jan 24 00:31:15 1985
Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA12825; Thu, 24 Jan 85 00:31:15 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.40)
	id AA15268; Thu, 24 Jan 85 00:31:03 pst
Message-Id: <8501240831.AA15268@ucbernie.ARPA>
Received: from wsu by csnet-relay.csnet id a006053; 24 Jan 85 3:16 EST
Date:     Wed, 23 Jan 85 21:50 PST
From: "S. Sridhar" <sridhar%wsu.csnet@csnet-relay.arpa>
To: cross%lsu.csnet@csnet-relay.arpa
Cc: franz-friends@UCBERNIE.ARPA
Subject:  pretty printing

Is there any way I can pretty-print Franz lisp function (or files) with all
the comments in tact. Right now when I use the built in pp, it pretty prints
and strips off all comments. I mean is there any built-in function that does
this. Thanks.

Sridhar (sridhar@wsu)

From fsbrn@BRL-VOC.ARPA  Thu Jan 24 05:33:59 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA14557; Thu, 24 Jan 85 05:33:59 pst
Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA00666; Thu, 24 Jan 85 05:16:27 pst
Message-Id: <8501241316.AA00666@UCB-VAX.ARPA>
Date:     Thu, 24 Jan 85 7:59:46 EST
From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA>
To: "S. Sridhar" <sridhar%wsu.csnet@CSNET-RELAY.ARPA>
Cc: Franz-Friends@BERKELEY
Subject:  Re:  pretty printing

Haah,

Franz's (read) function trashes all comments on input. [Which means
you can document your data files.]  You have to pretty-print the
original code before Franz gets it.  I don't know of any stand-alone
programs to do this (surely someone has written one).  I use
Berkeley's "vi" editor because it has a lisp mode; all input is
automatically pretty-printed if you say
  :set ai lisp
(ai stands for autoindent)
Another way is to execute the vi "=" command while in lisp mode.  All
of this is documented in the vi manual.  Hope this helps.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

From @MIT-MC:smh@MIT-EMS  Thu Jan 24 06:01:33 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA14651; Thu, 24 Jan 85 06:01:33 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA00458; Thu, 24 Jan 85 06:00:41 pst
Message-Id: <8501241400.AA00458@UCB-VAX.ARPA>
Received: by mit-ems.Mit-chaos.Arpa id AA25956; Thu, 24 Jan 85 08:59:42 est
Date: Thu, 24 Jan 85 08:59:42 est
From: Steven Haflich <smh@mit-ems>
To: franz-friends@BERKELEY, sridhar%wsu.csnet@csnet-relay
Subject: Re: pretty printing

Since comments are not part of a Lisp form returned by `read', clearly
no pretty-print function can do what you want.  Certainly a far more
complicated pretty-printer could be written which would be passed an
ascii file to read and which would somehow preserve comments inside the
form in order to regurgitate them during formatting.  The problem has
several complications, however, such as how to handle ascii Lisp text
with conditionalized inclusions (`#+' constructions)...

Instead, what you want is probably provided the Lisp-mode `grind'
facilities available in several popular text editors -- in particular,
EMACS.  (I know CCA EMACS works, and believe Gosling EMACS does also.)
In these editors a couple keystrokes will specify a region of text and
apply one of several Lisp-indentation algorithms to it.  They almost
always indent in reasonable ways, and attempt to do reasonable things
with comments, at least.  The ones with which I am familiar will *not*,
however, adjust line length length by moving either comment or Lisp
text from line to line.  This is not a great problem for normal
human-typed text, such as programs, since one tends not to type
absurdly long lines.


From peck@sri-spam  Wed Feb  6 12:01:17 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA28782; Wed, 6 Feb 85 12:01:17 pst
Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA04441; Wed, 6 Feb 85 12:00:09 pst
Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
	id AA08198; Wed, 6 Feb 85 12:00:05 pst
Message-Id: <8502062000.AA08198@sri-spam.ARPA>
Date: 06 Feb 85 11:59:58 PST (Wed)
To: ailist-request@sri-ai, franz-friends@BERKELEY
Subject: AI, Lisp, Graphics on SUN computers?
From: peck@sri-spam

I would like to here from anyone using SUN computers 
who can supply answers or comments on any of these issues:
 Is Franz the only (best) lisp available?
 Has anyone used the Maryland Flavors to create useful tools/extensions?
 Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
 Any differential reports of Prolog (Quintus) vs Lisp ?
 Any obvious alternative to SUN? (vendor in same class (Tektronix?))
 Worst or hidden problems, pitfalls, gotcha's, etc.
> Can real AI development (even applications) be supported on SUN's? <

From kessler%utah-orion@utah-cs  Wed Feb  6 15:58:12 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03031; Wed, 6 Feb 85 15:58:12 pst
Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA06871; Wed, 6 Feb 85 13:46:19 pst
Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1)
	id AA03096; Wed, 6 Feb 85 14:37:05 MST
Received: by utah-orion.ARPA (4.42/4.40.1)
	id AA10406; Wed, 6 Feb 85 14:36:22 MST
Date: Wed, 6 Feb 85 14:36:22 MST
From: kessler%utah-orion@utah-cs (Robert Kessler)
Message-Id: <8502062136.AA10406@utah-orion.ARPA>
To: peck@sri-spam.ARPA
Cc: ailist-request@sri-ai.ARPA, franz-friends@BERKELEY
Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message)
In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed).
	     <8502062000.AA08198@sri-spam.ARPA>


 > I would like to here from anyone using SUN computers 
 > who can supply answers or comments on any of these issues:
 >  Is Franz the only (best) lisp available?
We have finally finished porting Portable Standard LISP (PSL) to yet
another machine.  This time it is now running on the SUN.  Initial
timing measurements indicate that its speed is somewhere between a 
Vax 750 and 780 (all running PSL), and about twice as fast as Franz running
the REDUCE algebra system test on Suns.  We are now running the Gabriel
benchmarks to discover where it fits in the set.  For more details
see the announcement at the end of this message.
 >  Has anyone used the Maryland Flavors to create useful tools/extensions?
PSL provides support for a simple flavors package that seems quite
useful.  However, the current version has no inheritance.
 >  Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
We have oload working which allows you to call externally compiled
routines (like other c sources).  So the interface should be easy to
add (but we haven't done it).
 >  Any differential reports of Prolog (Quintus) vs Lisp ?
None that I know of.
 >  Any obvious alternative to SUN? (vendor in same class (Tektronix?))
PSL also runs on Apollo's and HP Series 200 (both 68K based machines).
We have also ported a simple "educational" version to the 128K
Macintosh which is used in a beginning programming class.  We plan on
moving at least the Standard LISP subset and compiler to the 512K mac
(so if you want to go really cheap...... :-) )
 >  Worst or hidden problems, pitfalls, gotcha's, etc.
We had a lot of problems with the Sun port.  Some were hardware
related, others were differences between Unix 4.2 on the Sun and on the
Vax.  After we get some more experience using PSL on the machine, maybe
we could report more.
 > > Can real AI development (even applications) be supported on SUN's? <
I think so, as long as you can get one with enough memory.  Some of our
applications running on HP 9836's (which doesn't have virtual memory)
really fly (better than a 780 in speed).  So, memory is really a key to
a fast machine.
 > 
Bob.

		   PSL 3.2 for the SUN Workstation

We are pleased to announce that Portable Standard LISP (PSL) version
3.2 is now available for the Sun workstation.  PSL is about the power,
speed and flavor  of Franz LISP or  MACLISP, with growing  influence
from Common  LISP.  It  is recognized  as an  efficient and  portable
LISP implementation with  many  more capabilities  than  described in
the  1979 Standard LISP Report.  PSL's main  strength is its
portability across  many different  systems,   including:   Vax  BSD
Unix, Vax VMS,  Extended   Addressing DecSystem-20 Tops-20, Apollo
DOMAIN  Aegis, and HP  Series 200.  A  version for the IBM-370 is in
beta test and two Cray versions are being used on an experimental
basis.  Since PSL generates very efficient code, it is an ideal
delivery vehicle for LISP based applications (we can  also provide  PSL
reseller  licenses for  binary only  and  source distributions).

PSL is distributed for the  various systems with executables, all
sources, an approximately  500 page  manual and  release notes.   The
release  notes describe how to install the system and how to rebuild
the various  modules.  We are charging  $750 for the  Sun version of
PSL for Commercial  Site licenses.  Non-profit institutions and all
other versions of PSL will  not be charged a license fee.  We are also
charging a $250 tape distribution fee for each system.

PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard,
Rand, Stanford, Columbia and over  250 other sites.   Many existing
programs  and applications have been  adapted to  PSL including
Hearn's REDUCE  computer algebra system and GLISP, Novak's object
oriented LISP dialect.  These  are available from Hearn and Novak.

To obtain a copy of the license  and order form, please send a NET
message or letter with your US MAIL address to:

Utah Symbolic Computation Group Secretary
University of Utah - Dept. of Computer Science
3160 Merrill Engineering Building
Salt Lake City, Utah 84112

ARPANET: CRUSE@UTAH-20
USENET:  utah-cs!cruse

From cas@cvl  Thu Feb 21 11:40:59 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA17380; Thu, 21 Feb 85 11:40:59 pst
Received: from cvl.ARPA (cvl.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA23930; Thu, 21 Feb 85 11:33:27 pst
Received: by cvl.ARPA (4.12/4.7)
	id AA09421; Thu, 21 Feb 85 14:38:26 est
Date: Thu, 21 Feb 85 14:38:26 est
From: cas@cvl (Cliff Shaffer)
Message-Id: <8502211938.AA09421@cvl.ARPA>
To: franz-friends@BERKELEY
Subject: database system request


Does anybody know of a database system written in FRANZ or easily
compatible with FRANZ?  We have written a lot of software for a
geographic information system, and may want to redo the section which
handles random bits of information associated with polygons or points
stored in a map.  Right now we store this information as a property
list on an atom associated with the polygon or point in question.  This
becomes very inefficient when we want to find all such atoms with
a particular value for some arbitrary property.  Equally importantly,
there is very little relationship between the set of properties associated
with each polygon or point, so a system storing a fixed length record
for each polygon, with fields for each piece of information, would not work.
Any suggestions?
		Cliff Shaffer
		cas@cvl

From layer@ucbdali  Thu Feb 21 12:54:14 1985
Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA18356; Thu, 21 Feb 85 12:54:14 pst
Received: by ucbdali.ARPA (4.24/4.40)
	id AA16858; Thu, 21 Feb 85 12:53:47 pst
Date: Thu, 21 Feb 85 12:53:47 pst
From: layer@ucbdali (Kevin Layer)
Message-Id: <8502212053.AA16858@ucbdali.ARPA>
Phone: (415) 652-2405
To: cas@cvl, franz-friends@kim
Subject: Re:  database system request

You could use the dbm library, as supplied by UNIX (/usr/lib/libdbm.a),
via cfasl and getaddress.

	Kevin


From freemant%rpi.csnet@csnet-relay.arpa  Mon Feb 25 04:50:50 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20175; Mon, 25 Feb 85 04:50:50 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA24603; Mon, 25 Feb 85 04:43:20 pst
Date: Mon, 25 Feb 85 04:43:17 pst
Message-Id: <8502251243.AA24603@UCB-VAX.ARPA>
Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST
From: freemant%rpi.csnet@csnet-relay.arpa
To: franz-friends@BERKELEY

Hello!  Our version of lxref didn't work right when it was passed the -a
option, so I fixed it.  Someone may want to use the -a option on lxref one
of these days, so I am mailing you my fixes in hopes that you will
distribute them.  

Things are kind of chaotic around here, so I am not sure that I was working
with the most current version of lxref.  Make sure that your current version
of lxref matches the code that I changed before you edit in my changes.

The origional definition of the function process-annotate-file left files
open.  Because the lisp interpreter can only have a finite number of files
open at once, this caused lxref to bomb when it was given a large job to do.
To fix this, I changed the definition of process-annotate-file from:

(defun process-annotate-file (filename)
   (let (sourcep outp)
      ; make sure file exists and write annotate file as a
      ; file with the prefix #,
      (if (null (errset (setq sourcep (infile filename))))
	 then (msg "will ignore that file " N)
	 else ; will write to file.A (erasing the final l)
	      (let ((filen (concat "#," filename)))
		 (setq outp (outfile filen))
		 (anno-it sourcep outp)
		 (close outp)
		 ; now mv the original filename to #dfilename
		 ; and the annotated file to the original file
		 (let ((oldcopy (concat "#." filename)))
		    (if (null (errset
				 (progn (if (probef oldcopy)
					   then (sys:unlink oldcopy))
					(sys:link filename oldcopy)
					(sys:unlink filename)
					(sys:link filen filename)
					(sys:unlink filen))))
		       then (msg "An error occured while mving files around "
				 N
				 "files possibly affected "
				 filename oldcopy filen)))))))

to:

(defun process-annotate-file (filename)
   (let (sourcep outp)
      ; make sure file exists and write annotate file as a
      ; file with the prefix #,
      (if (null (errset (setq sourcep (infile filename))))
	 then (msg "will ignore that file " N)
	 else ; will write to file.A (erasing the final l)
	      (let ((filen (concat "#," filename)))
		 (setq outp (outfile filen))
		 (anno-it sourcep outp)
		 (close outp)
		 (close sourcep)
		 ; now mv the original filename to #dfilename
		 ; and the annotated file to the original file
		 (let ((oldcopy (concat "#." filename)))
		    (if (null (errset
				 (progn (if (probef oldcopy)
					   then (sys:unlink oldcopy))
					(sys:link filename oldcopy)
					(sys:unlink filename)
					(sys:link filen filename)
					(sys:unlink filen))))
		       then (msg "An error occured while mving files around "
				 N
				 "files possibly affected "
				 filename oldcopy filen)))))))

Note that the only change is the insertion of one close statement.

The other bug I found was that find-func miserably failed to do its job
right.  The origional version of the function looked like this:

(defun find-func (buf)
   ; first locate first space or tab
   (do ((i 1 (1+ i))
	(max (cxr 0 buf))
	(die))
       ((or (setq die (not (<& i max)))
	    (memq (cxr i buf) '(#\space #\tab)))
	(if die
	   then nil	; can find it, so give up
	   else ; find first non blank
		(do ((ii i (1+ ii)))
		    ((or (setq die (not (<& ii max)))
			 (not (memq (cxr ii buf) '(#\space #\tab))))
		     (if (or die (eq (cxr ii buf) #\lpar))
			then nil
			else ; fid first sep or left paren
			     (do ((iii (1+ ii) (1+ iii)))
				 ((or (not (<& iii max))
				      (memq (cxr iii buf)
					    '(#\space #\tab #\lpar)))
				  (implode-fun buf ii (1- iii)))))))))))

Not unsurprisingly, this code didn't work.  I discarded it and rewrote the
function in a much simpler fashion:

(defun find-func (buf)
    (let ((i 1)
	  (max (cxr 0 buf))
	  (result nil))
	 (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab)))
	       do (setq i (+ i 1)))
	 (loop while (and (not (greaterp i max))
			  (memq (cxr i buf) '(#\space #\tab))) do
	       (setq i (+ i 1)))
	 (loop until (or (greaterp i max)
			 (memq (cxr i buf) 
			       '(#\space #\tab #.(getcharn '|(| 1)))) do
	       (setq result (cons (cxr i buf) result))
	       (setq i (+ i 1)))
	 (if result then (implode (reverse result)) else nil)))

The error in the origional definition of find-func caused the -a option to
always do nothing.  It is surprising that no one caught the fact that the -a
option was useless earlier.  (However, I am not sure that the source that I
was looking at came from your tape, so perhaps it isn't your fault.)  In any
case, my version works.

Bye!
					Tim Freeman
					freemant@rpi

From bane@gymble  Wed Feb 27 12:20:08 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA19926; Wed, 27 Feb 85 12:20:08 pst
Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA13078; Wed, 27 Feb 85 12:12:21 pst
Received: by gymble.ARPA (4.12/4.7)
	id AA25775; Wed, 27 Feb 85 15:17:32 est
Date: Wed, 27 Feb 85 15:17:32 est
From: John R. Bane <bane@gymble>
Message-Id: <8502272017.AA25775@gymble.ARPA>
To: franz-friends@BERKELEY
Subject: symeval 'feature'

	I've just finished a half-hour "It works interpreted but not compiled"
debugging session with a user who was new to compiling Franz, and I have a
complaint. The function 'symeval' works misleadingly differently interpreted
and compiled.

	Compiled symeval open-codes into a symbol value-cell reference. This
is fine. Interpreted symeval is implemented as a pointer to 'eval'.  This
loses because something like (symeval '(+ 1 2)) is not an error interpreted,
and it should be because it turns into the worst kind of bug when compiled,
since it'll return some random pointer from cons node space.

	This 'feature' was observed in Opus 38.91.

From neves@wisc-ai.arpa  Thu Feb 28 11:37:06 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA04105; Thu, 28 Feb 85 11:37:06 pst
Received: from wisc-ai.arpa (wisc-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA08982; Thu, 28 Feb 85 11:29:20 pst
Date: Thu, 28 Feb 85 13:34:20 cst
From: neves@wisc-ai.arpa (David Neves)
Message-Id: <8502281934.AA26546@wisc-ai.arpa>
Received: by wisc-ai.arpa; Thu, 28 Feb 85 13:34:20 cst
To: franz-friends@BERKELEY
Subject: franz to vi & back

We have a heavily loaded vax on which we run our Lisp classes.  It
seems to me that we could lessen the load by not having VI start
up anew every time the student does a VIL in Franz.  

It would be nice to have two processes, one Lisp and the other VI.
There would be a function (like VIL) in Franz that would start up
a VI process if there wasn't one and if there was a VI process just
goto it.  When the student is finished editing the file he/she would
hit a key that would save out the file and return to Lisp (without
killing the VI process).  I believe that Gosling Emacs had something
like this, only more sophisticated.

My questions.  Has anyone done this for Franz & VI?  Would this help
the load average on a VAX?  If no one has done it, would it be difficult
to do?
-Thanks, David

From moore.losangel%ibm-sj.csnet@csnet-relay.arpa  Thu Feb 28 16:20:09 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08882; Thu, 28 Feb 85 16:20:09 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA05586; Thu, 28 Feb 85 16:12:12 pst
Message-Id: <8503010012.AA05586@UCB-VAX.ARPA>
Received: from ibm-sj by csnet-relay.csnet id ac15203; 28 Feb 85 19:11 EST
Date: Thu, 28 Feb 85 15:34:11 PST
From: Jim moore <moore.losangel%ibm-sj.csnet@csnet-relay.arpa>
To: info-ibmpc@usc-isi.ARPA, franz-friends@BERKELEY
Subject: Can/does Franz exist on PC/IX or VM/IX?

I am looking for a high quality LISP to run under PC(VM)/IX.
 
Is Franzlisp the one?  Who & How?
 
If not, which?
 
Thanks in advance -- Jim Moore
 
(MOORE.LOSANGEL@IBM)
 
p.s. pls reply directly since I'm not on this list.
 

From johnson@udel-dewey.ARPA  Fri Mar  1 04:29:27 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA17511; Fri, 1 Mar 85 04:29:27 pst
Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA18449; Fri, 1 Mar 85 04:21:31 pst
Message-Id: <8503011221.AA18449@UCB-VAX.ARPA>
Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009017
          ;1 Mar 85 7:18 EST
To: David Neves <neves@wisc-ai.arpa>
Cc: franz-friends@BERKELEY, johnson@udel-dewey
Subject: Re: franz to vi & back
In-Reply-To: Your message of Thu, 28 Feb 85 13:34:20 cst.
	     <8502281934.AA26546@wisc-ai.arpa>
Date: 01 Mar 85 07:18:11 EST (Fri)
From: johnson@udel-dewey


Subject: franz to vi & back

> We have a heavily loaded vax on which we run our Lisp classes.  It
> seems to me that we could lessen the load by not having VI start
> up anew every time the student does a VIL in Franz.  
> 
> It would be nice to have two processes, one Lisp and the other VI.
> There would be a function (like VIL) in Franz that would start up
> a VI process if there wasn't one and if there was a VI process just
> goto it.  When the student is finished editing the file he/she would
> hit a key that would save out the file and return to Lisp (without
> killing the VI process).  I believe that Gosling Emacs had something
> like this, only more sophisticated.
> 
> My questions.  Has anyone done this for Franz & VI?  Would this help
> the load average on a VAX?  If no one has done it, would it be difficult
> to do?
> 

I have developed something similar to what you describe, for franz
running under bsd4.2

It was moderately difficult at the time, but I was just learning to
exploit job control.

in this system, the user invokes: 
(vif  foo)
to edit the function foo.

when he is finished editing, he saves the current buffer by:
:w
then exits the editor by pressing:
^Z  [NOT wq!!]

(getting users o use ^Z rather than wq is the biggest difficulty)

the function is the read from a temporary file which is created
by vif.

if the user later wishes to modify the SAME function [often the case]
he simply invokes:
(vif)
- and is returned to the [stopped] editing session EXACTLY where
he left it.  
[ providing some motivation for putting up with ^Z ]


The system people around here aren't too adventurous, so the only people
who use this system are my friends and myself, so I can't say what effect
it has on the load, [but it can only help]

one problem:  files in /tmp may accumulate, as there is no way to force
a user to clean up all editing sessions before exiting lisp.
[but that is what /tmp is for!]  you might warn your system people
to remove all VIF files that are over 2days old, or something like that.


note: this package knows about changes made by [cmu]edit, and may
be simplified if you are using a system where cmuedit is unavailable.


NOTE!!!!!!
Neither the University of Delaware
nor Apperson H. Johnson
relinquishes any rightts toi this software.

Please do NOT transfer the software without written permission
from both The University of Delaware and Apperson H. Johnson.


**********************************************************
setting up the system:

Script started on Fri Mar  1 06:49:30 1985
% make jced
cc  -c jced.c
cc  -c eroar.c
ld -o jcedmod.o -r  jced.o eroar.o
% lisp
Franz Lisp, Opus 38.79
-> [load 'vif]
[load vif.l]
/usr/lib/lisp/nld -N -x -A /usr/ucb/lisp -T 95800 jcedmod.o -e _jced_ -o /tmp/Li8788.0  -lc
t
-> [dumplisp newlisp]
nil
-> (exit)
script done on Fri Mar  1 06:51:45 1985
*******************************************************************

"newlisp" is now the lisp to use - you can put it in some directory
in youtr student's path
----------  here is vif.l  --------------------------------
(setq sccid "#(@)vif.l	V1.1	johnson@udel	10/13/84")
(eval-when (compile)
	(msg "vif doen't work compiled!!!\\ "N) (exit))
(declare (localf sccid))
;
;  uses job-control to allow ^Z from 'vi' to return to inside of
;  Lisp function
;


; ::vif::
;
;  Usage: (vif [<function-name>])
;  returns: t if function is loaded without errors, nil otherwise
;  side-effect: starts vi with temporary file,
;
;  does NOT REMOVE FILE UNLESS SUCCESSFUL LOAD HAS BEEN MADE
;  AND user has "quit" the editor
;
;  - allows ~instantaneous return to file being edited if
;    vi has been exited by ^Z (or whatever the susp character is, [see stty.1])
;   
;  NOTE: file and vi session may stay "LIVE" even between invocations!!!
; eg:
;
;  (def jnk '(lambda (x) "i am jnk"))
;
;  (vif jnk)
;    --> vi session, followed by :w, and then ^Z
;  t
;  followed by  :
;     (vif jnk ) 
;  or:
;     (vif)
;   --> INSTANTLY returns to former vi session !!
;
;
;
(declare (special *jced_lastf* *jced_lastc*  %changes))

(def vif
  (nlambda (fn)
    (prog (res tf er ppflag)
          (cond
           (fn
            (cond
             ((or (not (boundp '*jced_lastf*))
                  (neq *jced_lastf* (car fn)))
              (setq ppflag t)
              (setq *jced_lastf* (car fn))))))
          (cond ((boundp '*jced_lastf*)
                 (setq tf
                       (substring (concat '/tmp/VF
                                          (concat (syscall 20)
                                                  (concat '_
                                                          *jced_lastf*)))
                                  1))
                 (cond
                  ((and (boundp '%changes)
                        (memq *jced_lastf* %changes)
                        (or (not (boundp '*jced_lastc*))
                            (neq *jced_lastc* (memq *jced_lastf* %changes))))
                   (setq ppflag t)))
                 (cond
                  (ppflag
                   (eval (list 'pp (list 'F tf) *jced_lastf*)))))
                (t (msg "vif: edit what ??" N) (return nil)))
     lp   (setq res (jced_ tf ""))
          (setq er nil)
          (setq ER%all '(lambda (x)
                                (setq er t))
                        )
          (cond
           ((not (probef tf))
            (msg "vif: cannot find " tf)
            (cond
             ((eq res 1)
              (msg " want to return to the editor? {y/n} ")
              (cond ((eq (read) 'y) (go lp)))
			  (return nil)))
            (msg " sorry." N)
            (makunbound '*jced_lastf*)
            (return t)))
          (errset (load tf))
          (cond
           ((boundp '%changes)
            (setq *jced_lastc* (memq *jced_lastf* %changes))))
          (cond
           (er (msg "vif: want to fix " *jced_lastf* "? {y/n} ")
               (cond ((eq (read) 'y) (go lp)))))
          (cond ((eq res 0)
                 (makunbound '*jced_lastf*)
                 (syscall 10 tf)
                 (return t))
                (t (return nil))))))


;
; include modules written in C
(cfasl 'jcedmod.o '_jced_ 'jced_ "integer-function")

;  initialization string for jced
(jced_ ":se lisp
" "edinit")

;  editor to use
(jced_ "/usr/ucb/vi" "editor")

--------------- -------     jced.c             ---------------
static char sccid[] = "@(#)jced.c	1.1	johnson@udel 11/2/84";

#include  <signal.h>
#include  <sgtty.h>
#include  <errno.h>
#include  <sys/wait.h>
#include  <sys/types.h>
#include  <sys/stat.h>
#include  <sys/file.h>
#include  <stdio.h>

#define streq(s1,s2)	(0 == strcmp(s1,s2))
#define file_exist(FN)  (0 == access(FN,F_OK))
static int chpgrp, pgrp;   
static union wait status;
static struct stat st0,st1;
static struct sigvec sv1 = { SIG_IGN, 0, 0};
static struct sigvec sv0;

static char curname[128];
static char ed_buf[] = "/usr/ucb/vi";
static char init_buf[] = "";
static char myname_buf[] = "jced_";
static char *editor = ed_buf;
static char *edinit = init_buf;
static char *myname = myname_buf;

/*	::jced_::
 *	
 *	Usage: (jced_ "filename" "")
 *	
 *			jced_ is a job-control editor
 *
 *	- starts an editor session with "filename"
 *	  (or resumes it if there is a 'living' session with that file)
 *	- returns 1 if the session remains alive, 0 if the session is over
 *	
 * 	NOTE: if the SECOND argument is not the EMPTY string, 
 *	then the following special calls may apply:
 *	
 *		 (jced_ "/usr/ucb/vi" "editor") 
 *	- causes jced to use /usr/ucb/vi as the editor (this is the default)
 *	
 *		: (jced_ ":se bla" "edinit") 
 *	- causes jced cause the editor to pretend that the user typed ":se bla"
 *	every time the editor is invoked (the default is "")
 *
 *		: (jced_ "jced_" "myname") 
 *	- causes jced to use the name "jced_" in its prompts and messages
 *	(this is the default)
 *
 */
int
jced_(fname,cmd)
char *fname, *cmd;
{
union wait  status;
char resp[2];


	if (*cmd) {
		if (streq(cmd,"editor")) newstring(&editor,fname);
		else if (streq(cmd,"edinit")) newstring(&edinit,fname);
		else if (streq(cmd,"myname")) newstring(&myname,fname);
		else fprintf(stderr,"%s: %s is an unknown command",myname,cmd);
		return(0);
	}

	if (*curname) {
		if (*fname &&  !streq(fname,curname)) {
				if (file_exist(curname))
					eroar(unlink(curname),0,"unlink %",curname);
				kvil_();
				strcpy(curname,fname);
				begin_vi(); resume_vi();
		} else {
 			/*
			 * if file has been modified elsewhere,
			 * new editing session is needed
			 */ 
			if (file_exist(curname)) { 
				eroar(stat(curname,&st1),0,"stat");
				if(st0.st_mtime != st1.st_mtime) {
					kvil_(); strcpy(curname,fname); begin_vi();
				}
			}
			resume_vi();
		}
	} else if (*fname) {
			strcpy(curname,fname);
			begin_vi(); resume_vi();
    } else
		return(0);
		
	return((*curname) ? 1 : 0);
}

/*  to be called when a function is modified elsewhwre */
kvil_()
{
	eroar(killpg(chpgrp,SIGKILL),0,"killpg %d",chpgrp);
	wait3(&status,WUNTRACED,0);
	curname[0] = '\0';
}

static
begin_vi()
{
	if (chpgrp = fork()) {
		pgrp = getpgrp(0);
		eroar(setpgrp(chpgrp,chpgrp),0,"setpgrp");
	} else {
		fakeinput(edinit);
		execlp(editor,editor,curname,0);
		fprintf(stderr,"%s: exec of %s failed\n",myname,editor);
    }
}


static
resume_vi()
{
char dum[2];

	for (;;) {
		eroar(sigvec(SIGTTOU,&sv1,&sv0),0,"sigvec -IGN TTOU");
		eroar(ioctl(0,TIOCSPGRP,&chpgrp),0,"SPGRP chpgrp");
		if (file_exist(curname))
			eroar(stat(curname,&st1),0,"stat");
		else
			st1.st_mtime = 0;
		killpg(chpgrp,SIGCONT);
		wait3(&status,WUNTRACED,0);
		eroar(ioctl(0,TIOCSPGRP,&pgrp),0,"ioctl SPGRP pid");
		eroar(sigvec(SIGTTOU,&sv0,0),0,"sigvec -DFL TTOU");
		if (file_exist(curname))
			eroar(stat(curname,&st0),0,"stat");
		else
			st0.st_mtime = st1.st_mtime;

		if(!status.w_status) {
		 	curname[0] = '\0'; break;
		}
		if(st0.st_mtime == st1.st_mtime) {
			fprintf(stderr,"%s: %s was not modified, try again? {y/n} ",
				myname, curname);
			if (1 == scanf("%1s",dum) && dum[0] == 'n')  break;
		} else 
			break;
	}
}

static
fakeinput(s)
char *s;
{
int i;
	/* pretend s was typed at the terminal */
	for(i=0;s[i]; ++i)
		ioctl(0,TIOCSTI,s+i);
}

static
newstring(sptr,s)
char **sptr, *s;
{
char *s2, *malloc();

	if (NULL == (s2 = malloc(1 + strlen(s)))) {
		fprintf(stderr,"%s: malloc failed\n",myname);
	} else {
		strcpy(s2,s);
		*sptr = s2;
	}
}

---------------------------  eroar.c  --------------------

static char sccid[] = "@(#)eroar.c	1.0	johnson@udel 10/13/84";

/*	::eroar.c::
 *	
 *	error reporter-handler for faulty system function calls
 *	
 *	Usage: eroar( <system-call>, <exit-code>, <printf-pattern>, 
 *						<printf-arg>, <printf-arg>,  ...... );
 *	
 *	behavior:
 *		if the system call is successful, returns (1) immediately
 *		else
 *			prints out the error message (from the printf pattern)
 *			  and prints an error explanation
 * 			if exit-code is non-zero, exits with that code
 *			else returns (0)
 */


#include <errno.h>
#include <stdio.h>
#define ERR_BUFMAX 128

extern int sys_nerr, errno;
extern char *sys_errlist[];

eroar(expr,code,s,p1,p2,p3,p4,p5,p6,p7,p8,p9)
int expr,code; char *s;
{
	static char errbuf[ERR_BUFMAX];
	if (-1 != expr) return(1);
	fprintf(stderr,s,p1,p2,p3,p4,p5,p6,p7,p8,p9);
	fprintf(stderr,": %s\n",
		(0 < errno && errno < sys_nerr) ?
				sys_errlist[errno] : "UNKNOWN ERROR");
	if (code) exit(code);
	return(0);
}

-----------------    makefile -----------------------

jced : jcedmod.o

jcedmod.o : jced.o eroar.o
	ld -o jcedmod.o -r  jced.o eroar.o
-------------------------------------------------------

... (share a little joke with the world) ...

net:		johnson@udel-ee
usmail: 	Apperson H. Johnson
			618 Lehigh Rd. apt S11
			Newark, De. 19711
--------------------------------------------------------

From jshaver@apg-3  Fri Mar  1 13:37:57 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22358; Fri, 1 Mar 85 13:21:35 pst
Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA28355; Fri, 1 Mar 85 13:13:39 pst
Message-Id: <8503012113.AA28355@UCB-VAX.ARPA>
Date:  1 Mar 1985 16:15:48 EST (Friday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Vax availability
To: franz-friends@BERKELEY
Cc: jshaver@apg-3

Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
not on the list.  Please add me to the list.

Thank you.
This is an Otrona Attache 1200 bps

 
John


From jshaver@apg-3  Mon Mar  4 06:10:51 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA11236; Mon, 4 Mar 85 06:10:51 pst
Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA03832; Mon, 4 Mar 85 06:05:00 pst
Message-Id: <8503041405.AA03832@UCB-VAX.ARPA>
Date:  4 Mar 1985  9:09:27 EST (Monday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Returned mail: User unknown
To: franz-friends@BERKELEY
Cc: jshaver@apg-3


----BEGINNING OF FORWARDED MESSAGES----
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA28859; Fri, 1 Mar 85 13:34:56 pst
Received: by ucbkim.ARPA (4.24/4.27)
	id AA00121; Fri, 1 Mar 85 13:37:57 pst
Date:  1 Mar 1985 16:15:48 EST (Friday)
From: MAILER-DAEMON%ucbkim@Berkeley (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8503012137.AA00121@ucbkim.ARPA>
To: <jshaver@apg-3>

   ----- Transcript of session follows -----
>>> RCPT To:<franz-friends-3@ucbmike.BERKELEY>
<<< 550 <franz-friends-3@ucbmike.BERKELEY>... User unknown
550 franz-friends-3@ucbmike... User unknown
>>> RCPT To:<franz-friends-score@ucbmike.BERKELEY>
<<< 550 <franz-friends-score@ucbmike.BERKELEY>... User unknown
550 franz-friends-score@ucbmike... User unknown

   ----- Unsent message follows -----
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22358; Fri, 1 Mar 85 13:21:35 pst
Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA28355; Fri, 1 Mar 85 13:13:39 pst
Message-Id: <8503012113.AA28355@UCB-VAX.ARPA>
Date:  1 Mar 1985 16:15:48 EST (Friday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Vax availability
To: franz-friends@BERKELEY
Cc: jshaver@apg-3

Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
not on the list.  Please add me to the list.

Thank you.
This is an Otrona Attache 1200 bps

 
John


----END OF FORWARDED MESSAGES----
Is it something I'm doing?


From jshaver@apg-3  Mon Mar  4 06:16:15 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA11275; Mon, 4 Mar 85 06:16:15 pst
Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA03880; Mon, 4 Mar 85 06:10:25 pst
Message-Id: <8503041410.AA03880@UCB-VAX.ARPA>
Date:  4 Mar 1985  9:10:31 EST (Monday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: mail request failure
To: franz-friends@BERKELEY
Cc: jshaver@apg-3


----BEGINNING OF FORWARDED MESSAGES----
Received: from CMU-CS-A.ARPA (cmu-cs-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA29648; Fri, 1 Mar 85 14:05:23 pst
Message-Id: <8503012205.AA29648@UCB-VAX.ARPA>
Date: 1 Mar 85 17:8:8 EST
From: Mailer <Gripe@CMU-CS-A.ARPA>
To: <@BERKELEY:jshaver@apg-3>
Reply-To: Gripe <Gripe@CMU-CS-A.ARPA>
Subject: mail request failure

   ----- Transcript of session follows -----

Mail being sent from disk area [N900AR0M]
*NMail 1 Mar 85 17:06:02 EST;@UCB-VAX.ARPA:jshaver@apg-3;927920.QED[n900ar0m];mark.stevenson@cmua
1 Mar 85 17:8:8 EST
?%No such person as 'mark.stevenson' at CMU-CS-A.


   ----- Unsent message follows -----
Received: from UCB-VAX.ARPA by CMU-CS-A.ARPA; 1 Mar 85 17:05:57 EST
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA28701; Fri, 1 Mar 85 13:30:28 pst
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22358; Fri, 1 Mar 85 13:21:35 pst
Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA28355; Fri, 1 Mar 85 13:13:39 pst
Message-Id: <8503012113.AA28355@UCB-VAX.ARPA>
Date:  1 Mar 1985 16:15:48 EST (Friday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Vax availability
To: franz-friends@Berkeley
Cc: jshaver@apg-3

Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
not on the list.  Please add me to the list.

Thank you.
This is an Otrona Attache 1200 bps

 
John



----END OF FORWARDED MESSAGES----
Try a return address of RREINER@Simtel20.  They forward everything to me.


From fsbrn@BRL-VOC.ARPA  Tue Mar  5 08:17:28 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00161; Tue, 5 Mar 85 08:17:28 pst
Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA09879; Tue, 5 Mar 85 08:11:28 pst
Message-Id: <8503051611.AA09879@UCB-VAX.ARPA>
Date:     Tue, 5 Mar 85 11:13:21 EST
From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA>
To: Franz-Friends@BERKELEY
Cc: Meself <fsbrn@BRL-VOC.ARPA>
Subject:  Trace bug

Haah,

We recently installed some revisions to our 4.2 BSD system, and the
Joseph Lister package is apparently broken.  Since our system
administrators don't use Franz, I poked around in the file trace.l.
An error run is shown below:

-> (getsyntax '\;)
vsplicing-macro
-> (trace intersect)
[autoload /usr/lib/lisp/trace]
[load /usr/lib/lisp/trace.l]
[load /usr/lib/lisp/charmac.l]
Error: Unbound Variable: ;;
<1>: (getsyntax '\;)
vcharacter

The trace code that is executing is:

(eval-when (eval)
  (setq old-read-table-trace readtable)
  (setq readtable (makereadtable t))
  (setq old-uctolc-value (status uctolc))
  (sstatus uctolc nil)		; turn off case conversion
  (load 'charmac)
  (setsyntax '\; 'macro 'zapline)
  )

What I think is happening is that the readtable is being clobbered by
the (makereadtable t) line.  The file charmac.l starts off with a
comment line, but the definition of ';' has changed in the readtable.
I copied trace.l and reversed the last 2 lines so ';' is macro'd to
zapline BEFORE charmac.l is loaded.  I can then load trace.l and
(trace) functions with no trouble.

My question is: Why did I have to reverse those lines ??  (trace) used
to work fine.  Is there a problem with (makereadtable) that I need to
fix ??  We are running Opus 38.79.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

"Me ears are on the wrong side of me 'ead."

From fsbrn@BRL-VOC.ARPA  Tue Mar  5 14:55:27 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00189; Tue, 5 Mar 85 14:55:27 pst
Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA16643; Tue, 5 Mar 85 13:15:11 pst
Message-Id: <8503052115.AA16643@UCB-VAX.ARPA>
Date:     Tue, 5 Mar 85 16:14:14 EST
From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA>
To: Franz-Friends@BERKELEY
Cc: Ferd Brundick <fsbrn@BRL-VOC.ARPA>, kanderso@bbn-vax.ARPA
Subject:  Re:  Trace bug

Haah,

  >>Why aren't you loading the compiled version of trace?
  >>Would that help?

That was the what the person who stumbled onto the bug said.  (I don't
use the trace package myself because everything works the first time
:-).  I don't see how that would matter because compiled code is just
as wrong; it just bombs faster.  Besides, my slightly obsolete Franz
manual says "the trace package ... usually in the file
/usr/lib/lisp/trace.l".  I'm just wondering why the file doesn't work
any more when it used to.  I'd rather fix the problem permanently
instead of patching around it.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>

"I think I pulled a muscle in me ear."

From hamscher@MIT-HTVAX.ARPA  Tue Mar 19 16:50:09 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22357; Tue, 19 Mar 85 16:50:09 pst
Received: from MIT-HTVAX.ARPA (mit-htvax.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA05308; Tue, 19 Mar 85 11:49:40 pst
Received: by MIT-HTVAX.ARPA (4.12/4.7) 
	id AA21434; Tue, 19 Mar 85 14:50:20 est
Date: Tue, 19 Mar 85 14:50:20 est
From: Walter Hamscher <hamscher@MIT-HTVAX.ARPA>
Message-Id: <8503191950.AA21434@MIT-HTVAX.ARPA>
To: Franz-Friends@BERKELEY
Subject: Franz -> Common Lisp ?

Reply-to: hamscher@mit-htvax.arpa

Is there a common lisp that runs on 4.2 BSD?  Seems to
me this is  a vacuum that many folks must be trying to fill.

I am wondering:

(1) Who's working on one?

    <<None of the following answers win brownie points:
	(a) DEC.  Their Unix common lisp is only for in-house use.
	(b) CCA.  Ain't ready yet.
	(c) David Betz (XLISP 1.4).  Currently only a small subset.
	(d) NIL.  No Unix implementation planned.>>

(2) Is there a common lisp compatability package for franz?

	<<Unlikely, I know.  Still, how much of common
	lisp already exists in compatability packages,
	e.g. Lexical scoping :-), Packages, Keyword
	arguments, Pathnames, Bit-arrays?>>

(3) Are folks at UCB thinking of spinning off a common
    lisp from the existing franz implementation?

	<<Also unlikely but surely the thought has occurred.>>

All answers and pointers appreciated.

	Thanks,
	Walter Hamscher

From shebs@utah-cs  Wed Mar 20 17:27:57 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08685; Wed, 20 Mar 85 17:27:57 pst
Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA11992; Wed, 20 Mar 85 16:51:20 pst
Received: by utah-cs.ARPA (4.42/4.40.2)
	id AA01825; Wed, 20 Mar 85 17:48:26 MST
Date: Wed, 20 Mar 85 17:48:26 MST
From: shebs@utah-cs (Stanley Shebs)
Message-Id: <8503210048.AA01825@utah-cs.ARPA>
To: Franz-Friends@BERKELEY, hamscher@mit-htvax.arpa
Subject: Re:  Franz -> Common Lisp ?

We have several versions of compatibility stuff for PSL (and it
would work under Franz without much change).  We're trying to
get CL while retaining the speed of PSL, so we haven't yet
embarked on a full standalone CL...

						stan shebs

From ingrid@UCLA-LOCUS.ARPA  Thu Mar 21 11:05:39 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA18463; Thu, 21 Mar 85 11:05:39 pst
Received: from ucla-locus.arpa (ucla-locus.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA12504; Thu, 21 Mar 85 10:37:45 pst
Date:           Thu, 21 Mar 85 10:35:28 PST
From: Ingrid Zukerman <ingrid@UCLA-LOCUS.ARPA>
To: franz-friends@BERKELEY
Subject:        setq command changes code
Message-Id:     <480278128-16289-ingrid@UCLA-LOCUS.ARPA>

I have the following problems:
1. After performing the command (setq x (list ... )), I noticed that
   the code in the function that initializes x was also changed to the
   new value. After consulting with my guru, he pointed out that this
   might be due to a sharing pattern I am not aware of, or to the way
   in which assignments are performed (e.g., by passing a pointer).
   I wasn't able to find this information, so my question is were I
   could find it in order to avoid such occurrences in the future. Of
   course, if somebody up there is terribly curious and wants to look
   at a transcript of the session, I'll be very appreciative.
2. The most updated copy we have of Franz is Opus 38.5. I hear that it
   is now Opus 38.91. What should I do in order to get an updated copy?
   Please don't advise me to contact the person in charge, because this
   person (who no longer wishes to be in charge) told me to contact you.
Thanks very much.
--Ingrid

From franz!schlafly  Mon Mar 25 18:03:33 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA20019; Mon, 25 Mar 85 18:03:33 pst
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA21825; Mon, 25 Mar 85 17:57:20 pst
Received: by ucbkim.ARPA (4.24/4.27)
	id AA20010; Mon, 25 Mar 85 18:03:19 pst
Received: by franz.uucp (1.2/3.14)
	id AA00961; Mon, 25 Mar 85 17:36:52 pst
Date: Mon, 25 Mar 85 17:36:52 pst
From: franz!schlafly (Roger Schlafly)
Message-Id: <8503260136.AA00961@franz.uucp>
To: franz-friends@BERKELEY
Subject: programs written in Franz Lisp


I am compiling a list of expert systems and expert
system building tools which are written in Franz Lisp.

I would appreciate it if people would send me:
(1) The name of each such program.
(2) A brief description of what it does.
(3) Whether it is available to the public.
(4) An electronic address for obtaining more information.

I will then make this list available to anyone who requests it.

	Roger Schlafly
	ucbvax!franz!schlafly


From franz!schlafly  Mon Mar 25 20:02:47 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA21162; Mon, 25 Mar 85 20:02:47 pst
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA23786; Mon, 25 Mar 85 19:56:37 pst
Received: by ucbkim.ARPA (4.24/4.27)
	id AA21150; Mon, 25 Mar 85 20:02:36 pst
Received: by franz.uucp (1.2/3.14)
	id AA01276; Mon, 25 Mar 85 19:37:31 pst
Date: Mon, 25 Mar 85 19:37:31 pst
From: franz!schlafly (Roger Schlafly)
Message-Id: <8503260337.AA01276@franz.uucp>
To: franz-friends@BERKELEY
Subject: programs written in Franz Lisp


I am compiling a list of expert systems and expert
system building tools which are written in Franz Lisp.

I would appreciate it if people would send me:
(1) The name of each such program.
(2) A brief description of what it does.
(3) Whether it is available to the public.
(4) An electronic address for obtaining more information.

I will then make this list available to anyone who requests it.

	Roger Schlafly
	ucbvax!franz!schlafly


From carter%ubc.csnet@csnet-relay.arpa  Tue Mar 26 12:52:24 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00886; Tue, 26 Mar 85 12:52:24 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA11893; Tue, 26 Mar 85 12:46:01 pst
Received: from ubc by csnet-relay.csnet id a017378; 26 Mar 85 15:03 EST
Received: from ubc-vision.UUCP by ubc.csnet id AA04906; Tue, 26 Mar 85 12:01:03 pst
Date: Tue, 26 Mar 85 12:00:43 pst
From: Alan Carter <carter%ubc.csnet@csnet-relay.arpa>
Message-Id: <8503262000.AA09422@ubc-vision.UUCP>
Received: by ubc-vision.UUCP id AA09422; Tue, 26 Mar 85 12:00:43 pst
To: franz-friends@BERKELEY
Subject: Lisp interface to C functions



Does anyone know if there is a problem with calling malloc and free from
C functions which are called by Franz ?


					Alan Carter
					carter@ubc-vision.UUCP

From mcgeer  Tue Mar 26 16:06:57 1985
Received: by ucbkim.ARPA (4.24/4.27)
	id AA03620; Tue, 26 Mar 85 16:06:57 pst
Date: Tue, 26 Mar 85 16:06:57 pst
From: Rick McGeer (on an aaa-60-s) <mcgeer>
Message-Id: <8503270006.AA03620@ucbkim.ARPA>
To: prolog@ernie, franz-friends
Subject: Lisp is faster than Prolog?
Cc: 

	A number of articles in recent IEEE Spectra have discussed Silicon
Compilation in Prolog, and concluded with a statement to the effect: for
performance reasons, we will go to Lisp for a production version.

	Is Lisp really faster than Prolog?  I used to think so.  Some time
ago, I wrote a Prolog interpreter in Lisp: after several versions, I gave
up, because I couldn't make my Prolog fast.  Its best speed was 100 LIPS
through the append loop on a 780, or about 7% of the speed of C-Prolog (1500
LIPS, according to the literature.

	Then it occured to me that I could not expect my Prolog to run
faster than an equivalent function coded in Lisp.  I coded the function, and
the result was the following:

(def my-append
   (lambda (x y)
      (cond (x (cons (car x) (my-append (cdr x) y)))
	    (t y))))

it can be seen that the time of the computation is invariant with respect to
the second argument.  Hence, for all the tests to be mentioned, the second
argument is '(1 2 3 4 5).

	I ran the program on the lists consisting of the first 100, 250, and
300 integers.  The results were the following:

list length	ticks (60/sec)	LIPS equivalent
  100		  14		  429
  250		  29		  517
  300		  34		  529

Or about one-third the published speed of of the same function in CProlog on
a 780.  I then wondered how the native Franz append would do.  This function
is compiled, and is optimized for tail recursion, so the experiment is not
really fair to CProlog.  In any case:

list length	ticks		LIPS equivalent
  100		  3		  2000
  250		  8		  1875
  300		 10		  1800

I don't know what this proves, but I know what it doesn't prove.  The Lisp
used, by the way, was Franz version 38.96 on a Vax 11/780 at the University
of California at Berkeley.  Despite numerous queries to Edinburgh, we still
don't have a version of C-Prolog for comparative measurement here, so I
can't personally vouch for the 1500 LIPS claim.

							Rick.


From chris@maryland  Tue Mar 26 16:18:52 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA03876; Tue, 26 Mar 85 16:18:52 pst
Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA16580; Tue, 26 Mar 85 16:12:34 pst
Received: by maryland.ARPA (4.12/4.7)
	id AA23203; Tue, 26 Mar 85 19:17:28 est
Date: Tue, 26 Mar 85 19:17:28 est
From: Chris Torek <chris@maryland>
Message-Id: <8503270017.AA23203@maryland.ARPA>
To: carter%ubc.csnet@csnet-relay.ARPA
Subject: Re:  Lisp interface to C functions
Cc: franz-friends@BERKELEY

I believe that there were.  In U of M Franz, we stuck in a version of
malloc and free that uses the Lisp allocator to get unGCable memory,
and a host of problems with the window library went away ... (the
window library uses malloc & free quite, er, freely :-) ).

Chris

From narain@rand-unix  Tue Mar 26 18:17:38 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA06939; Tue, 26 Mar 85 18:17:38 pst
Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA18369; Tue, 26 Mar 85 17:39:36 pst
Received: by rand-unix.ARPA; Tue, 26 Mar 85 17:33:48 pst
From: Sanjai Narain <narain@rand-unix>
Message-Id: <8503270133.AA16864@rand-unix.ARPA>
Date: 26 Mar 85 17:33:41 PST (Tue)
To: Rick McGeer <mcgeer@ucbkim>
Cc: prolog@ernie, franz-friends@ucbkim, narain@rand-unix
Subject: Re: Lisp is faster than Prolog?
In-Reply-To: Your message of Tue, 26 Mar 85 16:06:57 pst.
	     <8503270006.AA03620@ucbkim.ARPA>


Your first comparison of Prolog and Lisp is not very meaningful. You are
comparing a Prolog implemented in Lisp with a Lisp implemented in C.
Perhaps you could try to compare Lisp in Lisp with Prolog in Lisp.

In a certain sense, your comparison of Franzlisp and C-Prolog infact
indicates the superiority of C-Prolog. C-Prolog can be used to do append
and all other functional programming at almost the speed of FranzLisp.
However, in C-Prolog, you can do also do deduction, searching, pattern
matching and a lot of other AI-stuff at the same speed. To do these in
Franzlisp you must write Lisp functions and suffer the loss in speed
associated with simulating functionality in a high-level language.

-- Sanjai

From mcgeer  Tue Mar 26 18:30:58 1985
Received: by ucbkim.ARPA (4.24/4.27)
	id AA07153; Tue, 26 Mar 85 18:30:58 pst
Date: Tue, 26 Mar 85 18:30:58 pst
From: Rick McGeer (on an aaa-60-s) <mcgeer>
Message-Id: <8503270230.AA07153@ucbkim.ARPA>
To: narain@rand-unix
Subject: Re: Lisp is faster than Prolog?
Cc: narain@rand-unix, franz-friends, prolog@ernie
In-Reply-To: Your message of 26 Mar 85 17:33:41 PST (Tue)


	You misunderstood my message.  Prolog-in-Lisp really isn't under
examination: the only reason I brought it up was that it provided the
original motivation for the experiment (I wanted to determine a limit on the
speed I could expect out of my Prolog, reasoning that it could not possibly
be faster than native-coded Lisp.)

	The rest of your letter is essentially correct: the figures imply
that CProlog is at least as fast as Franz, since the relevant test is
interpreted code in each language (i.e., the first set of figures).
However, this should not imply that I believe that Prolog is a "better"
language than Lisp (I don't want to get into *that* debate), or imply
that Lisp has no advantages over Prolog.  Lisp may have real advantages over
Prolog, but there is no reason to believe that speed is one of them.

					Rick.


From hilfingr@ucbrenoir  Wed Mar 27 01:06:00 1985
Received: from ucbrenoir.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA11390; Wed, 27 Mar 85 01:06:00 pst
Received: by ucbrenoir.ARPA (4.24/4.42)
	id AA03594; Wed, 27 Mar 85 01:07:16 pst
Date: Wed, 27 Mar 85 01:07:16 pst
From: hilfingr@ucbrenoir (Paul Hilfinger)
Message-Id: <8503270907.AA03594@ucbrenoir.ARPA>
To: mcgeer@ucbkim, narain@rand-unix
Subject: Re: Lisp is faster than Prolog? A personal plea
Cc: prolog@ernie, franz-friends@ucbkim
In-Reply-To: Your message of 26 Mar 85 17:33:41PST


Please, please, please stop trying to compare the performance of Lisp and
Prolog by considering micro-benchmarks!  Even in languages that are
essentially "the same" (from my perspective as a semanticist/language
designer or from the perspective of a Prolog programmer, FORTRAN, Pascal,
Modula 2, and Ada are all the same); such benchmarks are imperfect guides.
When comparing Lisp and Prolog, where the programs one might write to do a
particular problem might be radically different in strategy, anything that
compares the performance of tiny programs conveys almost no useful
information.

Please, please, please, PLEASE don't try to compare Prolog with Lisp (etc.)
using LIPS as a part of the measure! In comparing Prolog implementations, I
suppose LIPS might be of some interest, but when comparing Lisp with Prolog,
they don't help at all. The reason is simple: if Lisp is not suited for
doing logical inferences (in the Prolog sense) quickly, then the good Lisp
programmer simply does not formulate his solution using logical inferences.
(Patient: Doctor! Doctor! It hurts when I do this. Doctor: Well, then don't
do that.) It's like saying that my APL implementation, which uses lazy
evaluation and a bit of cleverness to compute

	+/ ,((iota n) o.= iota n) x A +.x B

(the trace of the matrix product of nxn matrices A and B, I think) in time
O(n^2) instead of O(n^3), is "faster" than my FORTRAN implementation, which
requires time O(n^3) to do a direct transcription of this algorithm
(actually forming the full matrix product).  

I think it wrong to say

   "To do [deduction, searching, pattern matching and other AI-stuff] in
    Franzlisp you must write Lisp functions and suffer the loss in speed
    associated with simulating functionality in a high-level language."

because one DOESN'T use simulation if one wants speed, but instead goes
after an entirely different kind of solution (I won't argue that this
solution is "just as easy" as the Prolog solution; there are certainly many
instances in which Prolog solutions are simpler, and I haven't the foggiest
notion what the story is for large systems.)  

	* * *

Finally, a question.  I was struck by Sanjai Narain's  comment:

    "However, in C-Prolog, you can do also do deduction, searching, 
     pattern matching and a lot of other AI-stuff at the same speed."

I notice that the Prolog digest is full of interesting puzzles whose
solution involves search. But are these representative? I think pattern
matching is certainly a big part of any Prolog program, but do deduction and
searching really form a big part of actual Prolog applications in practice?

I recall an article by Drew McDermott called the "The Prolog Phenonmenon"
that appeared (I think) in SIGArt at some point, maybe July '82. He asked
why it was that Prolog had not died out, as had PLANNER, which also
purported to support searching et al. He said some things on what he liked
and disliked about Prolog, and then made the following comment (emphasis
mine):

	"The Europeans went in a different direction [from the Americans
	 in reaction to the problems of PLANNER-like languages].  What
	 they liked best about logic was its variable-binding machinery.
	 Their attitude towards backtracking has been simply that it is a
	 programmer's duty to remember that his program will be executed
	 backward as well as forward, that his programs must correct bad
	 guesses as well as exploit good ones.  If the backwards
	 execution blows up, he must debug his program, not rewrite the
	 interpreter [the American approach], just as with more prosaic
	 kinds of infinite loops.  Once this burden was shifted away
	 from the language implementer and onto the programmer, the
	 logical [!] next step was to freeze the interpreter design
	 and make it as efficient as possible.  THE RESULT IS A 
	 PROGRAMMING LANGUAGE, NOT A PROBLEM SOLVER OR THEOREM PROVER;
	 it doesn't compete with NOAH, but with Lisp.  And it's my
	 impression that it competes pretty well.
	 
	     "The effect is to reverse the usual images of the American 
	 and European computer scientists.  In this case, the Americans
	 have pursued impractical theoretical studies, while the
	 Europeans have bummed the hell out of a hack."

(By "backward execution," he is referring to backtracking, I believe). To
put this another way, one doesn't use Prolog's backtracking to do AI-style
(i.e., very large) search, but rather to do very local and carefully-
controlled "search," in the sense of "search this list (tree, ....) for an
element equal to this one" or "try all permutations of this tiny set for one
that satisfies P." Likewise, one doesn't use it to do what an AI
investigator would call "deduction." One CAN convince the Prolog machinery
to do more general AI-style searching efficiently, but only at the expense
of vastly obscuring the original clear, simple, declarative form of the
program.

Not being a real Prolog hacker (yet) I don't really know how accurate this
view is, and would appreciate some reaction (preferably semi-quantitative).



From franz!jkf  Wed Mar 27 08:03:25 1985
Received: by ucbkim.ARPA (4.24/4.27)
	id AA13270; Wed, 27 Mar 85 08:03:25 pst
Received: by franz.uucp (1.2/3.14)
	id AA06162; Wed, 27 Mar 85 07:59:36 pst
Date: Wed, 27 Mar 85 07:59:36 pst
From: franz!jkf (John Foderaro)
Message-Id: <8503271559.AA06162@franz.uucp>
To: hilfingr@ucbrenoir.BERKELEY, narain@rand-unix.ARPA, mcgeer@ucbkim.BERKELEY
Subject: Re: Lisp is faster than Prolog? A personal plea
Cc: franz-friends@ucbkim.BERKELEY, prolog@ernie
In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst

 While I find the discussion of Prolog vrs Lisp interesting, please do don't
include franz-friends in on the discussion.  When the mailing list has
strayed off the topic of Franz Lisp in the past,  I've gotten inundated with
complaints.	Thanks.
					John Foderaro
					



From mcgeer  Wed Mar 27 10:22:15 1985
Received: by ucbkim.ARPA (4.24/4.27)
	id AA15354; Wed, 27 Mar 85 10:22:15 pst
Date: Wed, 27 Mar 85 10:22:15 pst
From: Rick McGeer (on an aaa-60-s) <mcgeer>
Message-Id: <8503271822.AA15354@ucbkim.ARPA>
To: hilfingr@ucbrenoir, narain@rand-unix
Subject: Re: Lisp is faster than Prolog? A personal plea
Cc: franz-friends, prolog@ernie
In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst

	Good point, Paul, but I think you're missing something.  First you
plead with us not to use micro-benchmarks, then you point out (correctly)
that the strategy that one would use to write a program in Lisp instead of
Prolog can often differ.  I would think that the implication from the latter
observation is that large programs are fundamentally incomparable, and I
think that that is probably correct.

	So if you deny us micro-benchmarks, then we can not measure the
relative performance of these languages at all (or, more precisely, the
standard implementations of these languages on the 11/780).  Hence we might
as well accept the statements "Prolog is faster than Lisp" or "Lisp is faster
than Prolog" or "Lisp is faster than assembler" as essentially meaningless
statements, since we can't quantify any of them.

	Let me sputter out making one final point.  LIPS is not all that
bad a measure.  Perhaps if we called it "cycles through the append loop" or
"function calls per second" (essentially identical statements) I think most
people would agree that this is a fair measure of the performance of any
Lisp.  After all, Lisp does nothing other than call functions and manipulate
lists.

	I'm certainly not going to take issue with the rest of your letter,
which is really more directed at Sanjai's claims than mine, and walks rather
closer to debates on programming style than any sane man should dare to go.


	I remain, sir,

					Y'r obedient servant,

						Rick McGeer.


From jeffr@sri-spam  Fri Mar 29 16:22:50 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA09984; Fri, 29 Mar 85 16:22:50 pst
Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA04718; Fri, 29 Mar 85 16:16:10 pst
Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
	id AA29100; Fri, 29 Mar 85 16:22:32 pst
Message-Id: <8503300022.AA29100@sri-spam.ARPA>
Date: 29 Mar 85 16:22:30 PST (Fri)
To: franz-friends@BERKELEY
Subject: Problems Forking Around
From: jeffr@sri-spam

I am having problems getting child processes forked from Franz to exit
cleanly.  If I execute a simple forking function, such as

	(defun fork_test ()
       		(prog (pid)
	     	(cond ((setq pid (fork)) (return pid)))
	     	(exit)
	]

from the Franz interpreter, a zombie process is created which doesn't exit
until I exit the interpreter.  The same result holds when fork_test is
called from a compiled Franz daemon which is not associated with a tty.

It's Friday and I'm out of ideas; any you have, even if only speculation,
would be greatly appreciated.

					- Jeff Rininger
					  SRI International	

From larus@ucbdali  Fri Mar 29 16:50:22 1985
Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA10643; Fri, 29 Mar 85 16:50:22 pst
Received: by ucbdali.ARPA (4.24/4.42)
	id AA04603; Fri, 29 Mar 85 16:50:11 pst
Message-Id: <8503300050.AA04603@ucbdali.ARPA>
To: jeffr@sri-spam.ARPA
Cc: franz-friends@ucbdali
Subject: Re: Problems Forking Around
In-Reply-To: Your message of 29 Mar 85 16:22:30 PST (Fri).
	     <8503300022.AA29100@sri-spam.ARPA>
Date: 29 Mar 85 16:50:02 PST (Fri)
From: larus@ucbdali

This is a not-very-well-known bug/feature of Franz/Unix.  Try adding a
(wait) call in the main routine and the zombies will go away.

/Jim

From weeks@ucbruby.CC  Fri Mar 29 18:23:00 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA11898; Fri, 29 Mar 85 18:23:00 pst
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA07034; Fri, 29 Mar 85 18:16:19 pst
Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1)
	id AA11566; Fri, 29 Mar 85 18:22:39 pst
Received: by ucbruby.CC.Berkeley.ARPA (4.19/4.34.1)
	id AA10320; Fri, 29 Mar 85 18:21:53 pst
Date: Fri, 29 Mar 85 18:21:53 pst
From: weeks@ucbruby.CC (Harry Weeks)
Message-Id: <8503300221.AA10320@ucbruby.CC.Berkeley.ARPA>
To: jeffr@sri-spam
Subject: Re: Problems Forking Around
Cc: franz-friends@BERKELEY

It is a characteristic of Unix that processes do not really die
until they are waited for.  Your `zombie' process will not die
until you (wait) for it.  The (wait) function returns the dotted
pair (pid . status).  Thus the following examples will spawn
children that immediately die.
						--Harry

In simplest terms:

    (def beget
      (lambda nil
	(cond ((fork) (wait))
	      (t (exit 0)))))

In more realistic terms:

    (def beget
      (lambda nil
	(prog (child)
	      (setq child (fork))
	      (cond ((null child)
		     ; child branch: (fork) evaluated to nil
		     (exit 0))
		    ((> child 0)
		     ; parent branch: (fork) evaluated to pid
		     (princ "Begot ")
		     (princ child)
		     (princ ".")
		     (terpri)
		     (return (beget:wait child)))
		    ((< child 0)
		     ; error branch
		     (princ "Birth pain.")
		     (terpri)
		     (return child))
		    (t
		     ; impossible branch
		     (princ "Impossible pain.")
		     (terpri)
		     (return -1))))))
    (def beget:wait
      (lambda (child)
	(prog (pvec)
	      (setq pvec (wait))
	      (cond ((= (car pvec) child)
		     ; child we are waiting for died
		     (return (cdr pvec)))
		    ((< (car pvec) 0)
		     ; error
		     (princ "Wait error.")
		     (terpri)
		     (return (car pvec)))
		    (t
		     ; another child died, keep waiting for ours
		     (return (beget:wait child)))))))

From carter%ubc.csnet@csnet-relay.arpa  Tue Apr  2 16:48:37 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA15047; Tue, 2 Apr 85 16:48:37 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA26876; Tue, 2 Apr 85 16:48:19 pst
Received: from ubc by csnet-relay.csnet id a008974; 2 Apr 85 19:35 EST
Received: from ubc-vision.UUCP by ubc.csnet id AA06552; Tue, 2 Apr 85 16:28:06 pst
Date: Tue, 2 Apr 85 16:27:59 pst
From: Alan Carter <carter%ubc.csnet@csnet-relay.arpa>
Message-Id: <8504030027.AA14795@ubc-vision.UUCP>
Received: by ubc-vision.UUCP id AA14795; Tue, 2 Apr 85 16:27:59 pst
To: franz-friends@BERKELEY
Subject: C interface

Does anyone know if it is OK to call malloc and free from C functions
called by lisp?
				-- Alan Carter
				   carter@ubc-vision.UUCP

From dennis%boulder.csnet@csnet-relay.arpa  Wed Apr  3 19:05:09 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA09023; Wed, 3 Apr 85 19:05:09 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA24595; Wed, 3 Apr 85 19:04:50 pst
Message-Id: <8504040304.AA24595@UCB-VAX.ARPA>
Received: from boulder by csnet-relay.csnet id af16243; 3 Apr 85 21:51 EST
Received: by boulder.UCBOULDER (4.30/4.7)
	id AA10745; Wed, 3 Apr 85 09:58:09 mst
Date: Wed, 3 Apr 85 09:58:09 mst
From: Dennis Heimbigner <dennis%boulder.csnet@csnet-relay.arpa>
To: carter%ubc.csnet@csnet-relay.arpa, franz-friends@BERKELEY
Subject: Re:  C interface

If I recall correctly, the pre-4.2 malloc did not appear to work
with franz because it assumed that it had control
of all of free memory.  The malloc for 4.2 uses a buddy
system and should not care if, for example, franz
has pre-empted pieces of virtual memory for its own use.
On the other side, franz only looks at the memory
it gets from sbrk, so it doesn't care about malloc'd
areas of virtual memory.
.lp
More to the point, I have been using malloc inside
cfasl'd code and have not yet seen a problem.

Dennis Heimbigner
dennis.boulder@csnet-relay.


From @seismo.ARPA:prlb2!vauclair@seismo.ARPA  Fri Apr  5 01:13:08 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA27833; Fri, 5 Apr 85 01:13:08 pst
Received: from seismo.ARPA (css-ring-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA25779; Fri, 5 Apr 85 01:12:50 pst
Return-Path: <prlb2!vauclair@seismo.ARPA>
Received: from prlb2.UUCP by seismo.ARPA with UUCP; Fri, 5 Apr 85 04:12:31 EST
Received: by prlb2.UUCP (4.12/4.7)
	id AA01128; Fri, 5 Apr 85 10:36:51 -0200
Date: Fri, 5 Apr 85 10:36:51 -0200
From: prlb2!vauclair@seismo.ARPA (Marc Vauclair)
Message-Id: <8504050836.AA01128@prlb2.UUCP>
To: franz-friends@BERKELEY
Subject: Profiling options in Franz Lisp. Opus 38.91. UoM Var. 3.5.

Does anyone know how to set up profiling in Franz Lisp ?
We have Franz Lisp of University of Maryland : Opus 38.91, UoM Variation 3.5.

I have already made the following modifications :

1) as stated in the makefile : ../franz/vax/Makefile I have removed the #
   in :
------------------------------------------------------------------------------
ProfFlag = # -XP
ProfFlag2 = # -DPROF
------------------------------------------------------------------------------

giving :

------------------------------------------------------------------------------
ProfFlag =  -XP
ProfFlag2 =  -DPROF
------------------------------------------------------------------------------

2) I've changed in ../franz/vax/Makefile the line :

------------------------------------------------------------------------------
	/lib/cpp $< -I../h |\
------------------------------------------------------------------------------

to :

------------------------------------------------------------------------------
	/lib/cpp ${ProfFlag2} $< -I../h |\
------------------------------------------------------------------------------

3) I've changed in ../franz/vax/Makefile/qfuncl.c the lines :

------------------------------------------------------------------------------
#ifdef PROF
	.set	indx,0
#define Profile \
	movab	prbuf+indx,r0  \
	.set 	indx,indx+4 \
	jsb 	mcount
#define Profile2 \
	movl   r0,r5 \
	Profile	\
	movl   r5,r0 
#else
#define Profile
#define Profile2
#endif
------------------------------------------------------------------------------

to :

------------------------------------------------------------------------------
#ifdef PROF
	.set	indx,0
#define Profile \
	movab	prbuf+indx,r0 ; \
	.set 	indx,indx+4 ; \
	jsb 	mcount
#define Profile2 \
	movl   r0,r5 ; \
	Profile	; \
	movl   r5,r0 
#else
#define Profile
#define Profile2
#endif
------------------------------------------------------------------------------

After all these modifications, we have the following error message when
making it slow :

------------------------------------------------------------------------------
ld -x -o rawlisp -e start ../low.o ../lowaux.o crt0.o ../alloc.o ../data.o  bigmath.o qfuncl.o vax.o ../lisp.o ../eval.o ../eval2.o ../inits.o ../io.o ../error.o  ../sysat.o ../lam1.o ../lam2.o ../lam3.o ../lam4.o ../lam5.o ../lam6.o  ../lam7.o ../lam8.o 


../lam9.o ../lamr.o ../lamp.o  ../fex1.o ../fex2.o ../fex3.o ../fex4.o ../fexr.o ../fpipe.o  ../subbig.o ../pbignum.o ../divbig.o  ../ffasl.o ../fasl.o  ../trace.o ../evalf.o ../frame.o ../lamgc.o  ../lamuom.o ../hash.o  -lm -lc -ltermlib
mcount: ld:/lib/libc.a(mon.o): multiply defined
*** Error code 2

Stop.
*** Error code 1

Stop.
------------------------------------------------------------------------------

From franz!schlafly  Fri Apr  5 11:19:37 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA02221; Fri, 5 Apr 85 11:19:37 pst
Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA04091; Fri, 5 Apr 85 11:18:48 pst
Received: by ucbkim.ARPA (4.24/4.27)
	id AA02177; Fri, 5 Apr 85 11:18:45 pst
Received: by franz.uucp (1.2/3.14)
	id AA00261; Fri, 5 Apr 85 10:37:18 pst
Date: Fri, 5 Apr 85 10:37:18 pst
From: franz!schlafly (Roger Schlafly)
Message-Id: <8504051837.AA00261@franz.uucp>
To: franz-friends@BERKELEY
Subject: Franz Lisp applications



Here is my list of Franz Lisp applications. Enough people
requested copies that I am sending it to all franz-friends.
If anyone sees any notable omissions, please send me a
message and I will augment the list.

	Roger Schlafly
	ucbvax!franz!schlafly

============================================================



        AI and Expert System Tools and Applications
           Developed or Running under Franz Lisp



+ OPS-5
A rule based  environment  for  developing  expert  systems.
Available  from  Franz Inc. with Franz LISP at no charge, or
at no charge from Carnegie Mellon University.

Computer Science  Department,  Carnegie  Mellon  University,
Schenley Park, Pittsburgh PA 15213.  (412) 578-2592

+ Flavors
An object oriented extension of Lisp, developed at  MIT  and
the  University  of  Maryland.   Used  on the Symbolics Lisp
machines.  Available from Franz Inc. at no  charge  to  pur-
chasers of Franz Lisp.

+ DUCK
DUCK is an expert systems development environment.

Available  from  Smart  Systems  Technology,  6870  Elm  St.
McLean, VA.  22101 (703) 448-8562.

+ Boyer-Moore Theorem Prover
Available from Prof. Robert Boyer, University of Texas, Aus-
tin.    Computer  Science  Department,  3-28  Painter  Hall,
University of Texas, Austin, Texas 78712.  (512) 471-7316

+ GLISP
GLISP is a high-level language which is based on Lisp and is
compiled  into  Lisp.  It was developed at the University of
Texas at Austin by Prof. Gordon Novak.  Object-centered pro-
gramming  is  supported.   Message  interpretations  can  be
looked up at compile time  to  produce  efficient  code.   A
window-based  editor,  GEV, is available to inspect and edit
data according to its data structure description.  GLISP  is
available  from  Franz  Inc.  at  no charge to purchasers of
Franz Lisp, or from the University of Texas at Austin, Prof.
Gordon  Novak,  Computer  Science  Department,  3-28 Painter
Hall, University of Texas, Austin, Texas 78712.  (512)  471-
7316

+ FRL
A frame representation language for AI development.

Available from Steven Rosenberg, Hewlett Packard  (415)  857
5902

+ MRS
A logic based knowledge  representation  system.   Available
from Stanford University.

Attention: Pattie McCabe SUMEX Computing Facility,  Stanford
University  Medical Center, Room TB105, Stanford, California
94305, (415) 497-5141

+ Macsyma
Developed at MIT, Macsyma is a program that carries out sym-
bolic  computation.   It  will solve all those integrals you
learned about in your calculus class, as well as systems  of
differential equations and other mathematical problems.

+ Reduce
Reduce is similar to  Macsyma.   It  was  developed  at  the
University  of Utah.  Computer Science Department, 3160 Mer-
rill Engineering Bldg.  Salt Lake City, Utah  84112.   (801)
484-7651 Ext 205

+  XCON
Digital Equipment's famous expert system, written in  OPS-5,
originally  ran  on top of Franz Lisp.  XCON configures com-
puters before shipment.

+ ACE
Automatic Cable Expertise : A knowledge based expert  system
that  provides  trouble-shooting  and diagnostic reports for
telephone company managers.   Developed by Stolfo,  Vesonder
and  others  at  AT&T  Bell Labs. For details see "The Fifth
Generation Challenge" Proceedings ACM '84 Annual Conference.

+ Slang
A circuit design and analysis tool.  It  has  been  used  to
design  several  integrated  circuits  at  U.C. Berkeley.  A
detailed description is in the masters thesis of Korbin  Van
Dyke at U.C. Berkeley.

Available from: Industrial Liason Program, EECS  Department,
University of California, Berkeley CA 94720   (415) 642-0253

+ Lyra
A VLSI design rule checker.  A description is in the masters
thesis of Michael Arnold  at U.C. Berkeley.

+ Pearl
A database and AI representation language written  in  Franz
Lisp.   Available from Franz Inc. at no charge to purchasers
of Franz Lisp.

+ YAPS
Yet Another Production System.  Developed by  Liz  Allen  at
the  University  of  Maryland.   A forward driven production
rule system similar to OPS-5, but  with  added  flexibility.
YAPS  supports  objects in facts, and defines an object that
is a complete production system, so you can have  more  than
one expert around at a time.  See "YAPS: A Production System
Meets Object" by Liz Allen in AAAI-83 for more  information.
YAPS  is  available  at  nominal cost from the Universtiy of
Maryland.  The license fee is $100 for  BSD  4.1,  $250  for
4.2.   It's  also  Arpanet FTP'able for $100 for either ver-
sion.  Contact Bob Bane on Arpanet at  bane@maryland  or  on
Usenet  at  ...seismo!umcp-cs!bane  or  contact Liz Allen at
liz@tove.arpa or seismo!umcp-cs!liz .

+ GENIE
GENeric Inference  Engine.   An  expert  system  development
tool.   Written by John Dumer, Tim Hanratty, Paul Tanenbaum,
and Fred S. Brundick.  For more information contact: Fred S.
Brundick,

+ The Berkeley UNIX Consultant
An expert System incorporating a natural language  interface
which  answers  questions  about UNIX.  Under development at
U.C. Berkeley.  USABRL, APG, MD.  <fsbrn@brl-voc>

+ ROSS and SWIRL
ROSS is an object-oriented language developed  for  building
knowledge  based simulations.  SWIRL is a program written in
ROSS that embeds knowledge about defensive and offensive air
battle  strategies.  Developed by Narain, McArthur and Klahr
at The Rand Corporation, 1700 Main Street, Santa  Monica  CA
90406.    These  systems  were  implemented  in various LISP
environments including Franz  LISP.   A  comparison  of  hte
various  environments in terms of CPU usage, real-time usage
and user aids can be found in an article by the above in the
proceedings  of  the  1983 International Joint Conference on
Artificial Intelligence, Karlsruhe, W. Germany.

From liz@tove  Sat Apr  6 09:35:22 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA13697; Sat, 6 Apr 85 09:35:22 pst
Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
	id AA24792; Sat, 6 Apr 85 09:35:09 pst
Received: by tove.ARPA (4.12/4.7)
	id AA10092; Sat, 6 Apr 85 12:36:17 est
Message-Id: <8504061736.AA10092@tove.ARPA>
To: franz!schlafly@BERKELEY (Roger Schlafly)
Cc: franz-friends@BERKELEY
Subject: Re: Franz Lisp applications
In-Reply-To: Your message of Fri, 5 Apr 85 10:37:18 pst.
	     <8504051837.AA00261@franz.uucp>
Date: 06 Apr 85 12:36:04 EST (Sat)
From: Liz Allen <liz@tove>

A correction to one of the entries.

	From: franz!schlafly@Berkeley (Roger Schlafly)

	+ Flavors
	An object oriented extension of Lisp, developed at  MIT  and
	the  University  of  Maryland.   Used  on the Symbolics Lisp
	machines.  Available from Franz Inc. at no  charge  to  pur-
	chasers of Franz Lisp.

Actually, there are two implmentations of flavors available for
Franz; one written at MIT and the other at Univ of Maryland.  Franz
Inc distributes the one from MIT and we (at UofM) distribute our
version as part of the Maryland software distribution (which includes
Franz 38.91).  For more information about getting our distribution,
contact Bob Bane bane@gymble.arpa or seismo!umcp-cs!bane.

				-Liz


From wfi%ucsc.csnet@csnet-relay.arpa  Tue Apr  9 02:28:37 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA07208; Tue, 9 Apr 85 02:28:37 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA14376; Tue, 9 Apr 85 02:27:14 pst
Message-Id: <8504091027.AA14376@UCB-VAX.ARPA>
Received: from ucsc by csnet-relay.csnet id ad14837; 9 Apr 85 5:28 EST
Received: by vger.UCSC (4.12/4.7)
	id AA27515; Mon, 8 Apr 85 14:09:04 pst
Date: Mon, 8 Apr 85 14:09:04 pst
From: wfi <@csnet-relay.arpa,@ucsc.CSNET:wfi@ucsc.CSNET (Wayne F. Iba)>
To: franz-friends@BERKELEY
Subject: franz profiling
Cc: wfi@ucsc.CSNET


There is a short note in the documentation of liszt that "if the lisp
system is built with profiling", then using the -p option will allow
use of the UNIX prof command etc.

Can someone explain how to rebuild (if necessary) our lisp system
accordingly?

Thanks
--wayne (wfi%ucsc.csnet)


From klahr@rand-unix  Tue Apr  9 10:03:37 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA09758; Tue, 9 Apr 85 10:03:37 pst
Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA20618; Tue, 9 Apr 85 10:02:11 pst
Received: by rand-unix.ARPA; Tue, 9 Apr 85 09:41:46 pst
From: Phil Klahr <klahr@rand-unix>
Message-Id: <8504091741.AA17861@rand-unix.ARPA>
Date: 09 Apr 85 09:41:40 PST (Tue)
To: FRANZ-FRIENDS@BERKELEY
Cc: randvax!klahr
Subject: IJCAI-85 Registration -- Please post


The International Joint Conference on Artificial Intelligence will be
meeting in Los Angeles (at UCLA) August 18-23, 1985.  Conference
brochures (including registration information) have already been mailed
out.  If you have not received one, or would like extras, contact

	IJCAI-85
	c/o AAAI
	445 Burgess Drive
	Menlo Park, CA 94025
	415-328-3123 or 415-321-1118

Registration will be limited to 5,000 people.  Based on early projections,
up to 7,000 people may wish to attend, so early registration is highly
encouraged (if not necessary).

As a bonus, early registrants will receive a substantial reduction in
registration costs.  Through June 28, registration fees are $175 ($80 for
students); for registrations received after June 28 but prior to July 26,
fees will be $225 ($100 for students); and for on-site registration (if
available), fees will be $275 ($125 for students).  Substantial reductions
for early tutorial registrations are also in effect.

Further information on the technical conference, the tutorials, the
exhibition, and housing can be found in the conference brochure.

From jeffr@sri-spam  Tue Apr  9 16:38:17 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA00472; Tue, 9 Apr 85 16:38:17 pst
Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA29765; Tue, 9 Apr 85 16:36:41 pst
Received: by sri-spam.ARPA (4.22/4.16)
	id AA05175; Tue, 9 Apr 85 16:37:20 pst
Date: Tue, 9 Apr 85 16:37:20 pst
From: jeffr@sri-spam (Jeff Rininger)
Message-Id: <8504100037.AA05175@sri-spam.ARPA>
To: franz-friends@BERKELEY

Does anyone know of (or have) a Franz function that returns a character
corresponding to a given fixnum representation, but without the pesky
symbol delimiters that `ascii' returns ?

From g_keaton%scarolina.csnet@csnet-relay.arpa  Sat Apr 13 23:33:19 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA22504; Sat, 13 Apr 85 23:33:19 pst
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA13927; Sat, 13 Apr 85 23:32:05 pst
Message-Id: <8504140732.AA13927@UCB-VAX.ARPA>
Received: from scarolina by csnet-relay.csnet id a013785; 14 Apr 85 2:36 EST
Date:     Fri, 12 Apr 85 13:01 EST
From: Bonnell <g_keaton%scarolina.csnet@csnet-relay.arpa>
To: FRANZ-FRIENDS@BERKELEY
Subject:  Problems with *process.

I am attempting to have a Lisp process talk to a C process using
Lisp's *process function. This function works fine with system commands
such as 'ls' but fails when the C process is a typical user program.
I hope someone has run into similar difficulties and can provide some
enlightenment. We are using a set Sun workstations running Berkley Unix.
The same problem also occurs on our VAX. 

			Thanks,
				Gar Keaton

From narain@rand-unix  Mon Apr 15 11:33:17 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA08082; Mon, 15 Apr 85 11:33:17 pst
Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA08871; Mon, 15 Apr 85 11:31:51 pst
Received: by rand-unix.ARPA; Mon, 15 Apr 85 11:29:44 pst
From: Sanjai Narain <narain@rand-unix>
Message-Id: <8504151929.AA12668@rand-unix.ARPA>
Date: 15 Apr 85 11:29:40 PST (Mon)
To: Bonnell <g_keaton%scarolina.csnet@csnet-relay.ARPA>
Cc: FRANZ-FRIENDS@BERKELEY, narain@rand-unix
Subject: Re: Problems with *process.
In-Reply-To: Your message of Fri, 12 Apr 85 13:01 EST.
	     <8504140732.AA13927@UCB-VAX.ARPA>


I once set up a link between Franzlisp and C-Prolog using process instead of
*process and it worked fine. It was on Vax 11/780, but it was most probably
on an earlier version of Unix, rather than 4.2bsd.

-- Sanjai Narain

From chin@ucbdali  Sat Apr 20 11:50:19 1985
Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
	id AA03799; Sat, 20 Apr 85 11:50:19 pst
Received: by ucbdali.ARPA (4.24/4.45)
	id AA08585; Sat, 20 Apr 85 11:50:12 pst
Date: Sat, 20 Apr 85 11:50:12 pst
From: chin@ucbdali (David N. Chin)
Message-Id: <8504201950.AA08585@ucbdali.ARPA>
To: franz-friends@ucbdali
Subject: profiling

Does anyone have a profiling package for FRANZ that provides execution
time statistics?  The prof.l package in the lisplib only provides call
frequency statistics, and the liszt -p option only works if lisp was
created with profiling (not to mention that you would have to recompile
all your code to use it).

				Thanks in advance,
				David Chin
				chin@BERKELEY
				ucbvax!chin

From smh@mit-eddie.ARPA  Sun Apr 21 14:13:02 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
	id AA17063; Sun, 21 Apr 85 14:13:02 pst
Received: from mit-eddie.ARPA (mit-eddie.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
	id AA03920; Sun, 21 Apr 85 14:11:39 pst
Received: by mit-eddie.ARPA (4.12/4.8)  id AA03273; Sun, 21 Apr 85 17:11:05 est
Date: Sun, 21 Apr 85 17:11:05 est
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8504212211.AA03273@mit-eddie.ARPA>
To: franz-friends@BERKELEY
Subject: Gnu EMACS customization for Lisp

Lisp hackers who use Gnu EMACS might want to try this useful
customization.  It emulates the standard keybinding of CCA EMACS
that makes C-Z (i.e. control-Z) a prefix which both CONTROL- and
META-izes to the following keystroke.  This is particularly useful
for Lisp because most of the special Lisp editing commands are bound
to ESC CONTROL characters.

This text can be placed in the personal .emacs file in your home
directory.  The suspend-emacs function previously run by C-Z is
still available as either C-X C-Z or C-Z C-Z .

But first: The two "^Z" strings in the text below have been sanitized
to pass through mailers and, as mailed, contain a two character
sequence representing CONTROL-Z to humans.  You will have to edit
them to contain the single literal character C-Z, which can be typed
in EMACS via the two-keystroke sequence: C-Q C-Z .

======================================
(defun c-m-prefix ()
 "Apply both META and CONTROL to the next command character"
 (interactive)
 (command-execute
  (lookup-key esc-map (char-to-string (logand 31 (read-char))))))

(define-key global-map "^Z" 'c-m-prefix)
(define-key esc-map "^Z" 'suspend-emacs)

From @MIT-MC:wah@cmu-cs-ius.arpa  Tue Apr 23 17:48:24 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA18909; Tue, 23 Apr 85 17:48:24 pst
Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA10636; Tue, 23 Apr 85 17:46:11 pst
Message-Id: <8504240146.AA10636@UCB-VAX.ARPA>
Received: from CMU-CS-IUS.ARPA by MIT-MC.ARPA; 22 APR 85 12:13:41 EST
Date: 22 Apr 85 12:05:53 EST
From: Wilson.Harvey@CMU-CS-IUS
Subject: #ifdef for liszt?
To: BBoard.Maintainer@CMU-CS-A


Is there anything for the lisp compiler akin to the "#ifdef" statement
for the C compiler?  Can anyone point me to something similar?
Thanks.  -- Wilson



From liz@tove  Wed Apr 24 12:02:32 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA01778; Wed, 24 Apr 85 12:02:32 pst
Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA02711; Wed, 24 Apr 85 12:00:04 pst
Received: by tove.ARPA (4.12/4.7)
	id AA15012; Wed, 24 Apr 85 15:00:27 est
Message-Id: <8504242000.AA15012@tove.ARPA>
To: Wilson.Harvey@cmu-cs-ius
Cc: franz-friends@BERKELEY
Subject: Re: #ifdef for liszt?
In-Reply-To: Your message of 22 Apr 85 12:05:53 EST.
	     <8504240146.AA10636@UCB-VAX.ARPA>
Date: 24 Apr 85 15:00:16 EST (Wed)
From: Liz Allen <liz@tove>

	From: Wilson.Harvey@CMU-CS-IUS

	Is there anything for the lisp compiler akin to the "#ifdef" statement
	for the C compiler?  Can anyone point me to something similar?
	Thanks.  -- Wilson

The reader has built into it a switch that works in both liszt and
lisp.  You can tell lisp whether or not to read an expression by
putting before that expression something like:

	#+feature	
	#-feature
	#+(or feature ...)
	#+(and feature ...)

where feature is on iff it is on the "(status features)" list (which
can be modified).  Thus you can do something like this:

	#-uomlisp (defun morerecent (file1 file2) ...)

since uomlisp is turned only in Franz's that contain all our hacks and
morerecent happens to already be defined in our stuff.  If you look at
the liszt code, you'll see lots of "#+vax"'s and "#+68k"'s where the
code needs to be different, eg:

	(defun cc-foo (x y z)
	   (bar #+vax vax-arg
		#+68k 68k-arg)
	    ...)

It can be quite convenient especially when you have two lisps that are
almost the same, you can maintain just one source containing these
things whenever the sources for the different lisps must be different.

I know this stuff is documented in the code in charmac.l; I can't
remember right now if it is documented in the Franz reference manual
and I don't have it with me right now to check.


Hope this helps.

				-Liz

From jaffe@CMU-PSY-A  Mon Jun 17 13:57:45 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA01719; Mon, 17 Jun 85 13:57:45 pdt
Received: from CMU-PSY-A (cmu-psy-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA25593; Mon, 17 Jun 85 13:54:08 pdt
Message-Id: <8506172054.AA25593@UCB-VAX.ARPA>
Date:     Monday, 17 Jun 85 16:50:28 EDT
From: jaffe@cmu-psy-a (elliot jaffe)
Subject:  Cursor Package?
To: franz-friends@BERKELEY

Does anyone out there have a working cursor package for franz lisp?

I know that the franz distribution at one time came with such a package,
but the version that I have does not work.  For some reason, a function
called "ospeed" is defined both in franz and in curses.

I am working on a VMS machine with version 38.91.  I've also got franz on 
a Sun workstation (version 41.?) but both franzs have the same problem.

Any help with a cursor package or pointers to such a package would be
greatly appreciated.

Replies to:	Jaffe@cmu-psy-a.arpa

Thanks,
Elliot Jaffe.

From cornwell@nrl-css  Fri Jun 21 09:04:54 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA13519; Fri, 21 Jun 85 09:04:54 pdt
Received: from nrl-css (nrl-css.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA18873; Fri, 21 Jun 85 09:00:48 pdt
Date: Wed, 19 Jun 85 13:47:52 edt
From: Mark Cornwell <cornwell@nrl-css>
Message-Id: <8506191747.AA09210@nrl-css>
To: Jaffe@cmu-psy-a.ARPA
Subject: Cursor Package!
Cc: franz-friends@BERKELEY


We've been using Jim Larus's franz lisp interface to the Berkeley curses
package for several years.  It works fine under UNIX 4.2bsd with
franz 38.91.  I recall some twiddling with ospeed a long time back to
make it go.  If you are interested I can send you our sources and the
makefile.

Alan Bull of NRL has put together an emulation of the the curses package
to help us port programs from franz to a symbolics.

Mark Cornwell   
cornwell@nrl-css

From greep@rand-unix  Fri Jun 21 14:35:37 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA17578; Fri, 21 Jun 85 14:35:37 pdt
Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA24632; Fri, 21 Jun 85 14:31:34 pdt
Received: by rand-unix.ARPA; Wed, 19 Jun 85 23:10:38 pdt
From: Steve Tepper <greep@rand-unix>
Message-Id: <8506200610.AA09405@rand-unix.ARPA>
Date: 19 Jun 85 23:10:20 PDT (Wed)
To: jaffe@cmu-psy-a
Cc: franz-friends@BERKELEY, greep@rand-unix
Subject: Re: Cursor Package?
In-Reply-To: Your message of Monday, 17 Jun 85 16:50:28 EDT.
	     <8506172054.AA25593@UCB-VAX.ARPA>

Just a few days ago I started hacking up a script to convert the
names of the Berkeley curses routines into appropriate cfasl
and getaddress routines for Franz.  I also had to hack the
library to change the name "ospeed", as you pointed out --
I did this by modifying the binary (shudder) rather than
recompiling.  I just started playing with it so I don't know
if everything works right.  One thing I noticed is that in some
cases lisp will hang if one of these functions is called with
the wrong number of arguments.  Since there doesn't appear to
be any way of telling lisp how many arguments your C function
takes, you have to be careful.

Anyway, I'll send it to you in a separate message.

From peck@sri-spam  Mon Jun 24 16:17:46 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA12734; Mon, 24 Jun 85 16:17:46 pdt
Received: from sri-spam.ARPA (sri-spam-test.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
	id AA04274; Mon, 24 Jun 85 16:13:12 pdt
Received: from localhost by sri-spam.ARPA (5.4/4.16)
	id AA11802; Mon, 24 Jun 85 16:15:22 PDT
Message-Id: <8506242315.AA11802@sri-spam.ARPA>
Date: 24 Jun 85 16:15:18 PDT (Mon)
To: franz-friends@BERKELEY
Cc: peck@sri-spam
Subject: Sun Graphics and external data structures
From: Jeff Peck <peck@sri-spam>

I would like to here from any people who have found a solution 
either of the following problems:

1) Interfacing with Sun graphics, either SunCore or preferably,
at the Pixwind/Pixrect level. The main problem is that the interface
that sun provides is in terms of C header files defining C "structs".
So a related solution would be:

2) A package to allow franz programs to manipulate external structures.
That is, the ability to follow pointers and write into memory that was
not allocated by franz.  I can use vectori to create blocks with one can
pass TO a C-program, but when the system returns a pointer to a
structure, franz just see a fixnum and will not treat it as a pointer.
Has anyone extented/subverted the datatyping in franz to allow treating
arbitrary pointers as for example, hunks?

I will probably attempt to solve these problems, so ANY help or
collaboration will be greatly appreciated.

j. peck

From bane@gymble  Thu Jun 27 17:03:26 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA25488; Thu, 27 Jun 85 17:03:26 pdt
Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
	id AA01585; Thu, 27 Jun 85 13:25:03 pdt
Received: by gymble.ARPA (4.12/4.7)
	id AA08257; Thu, 27 Jun 85 16:21:37 edt
Date: Thu, 27 Jun 85 16:21:37 edt
From: John R. Bane <bane@gymble>
Message-Id: <8506272021.AA08257@gymble.ARPA>
To: franz-friends@BERKELEY
Subject: Franz-f77 strange I/O?

	A company I'm doing some consulting for wants to use Franz to
drive a Ramtek color display whose graphics routines are written in
Fortran, so they're calling the display routines as foreign functions.
The problem they've been having is this: the output these routines should
generate is going into a file named something like "fort6" instead of to
standard out, and that file's buffers don't flush correctly. Anybody
know what's going on here?
				- Bob Bane
				(bane@maryland, ...umcp-cs!bane)

From boyle@anl-mcs  Sun Jun 30 19:11:39 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
	id AA11920; Sun, 30 Jun 85 19:11:39 pdt
Received: from anl-mcs.ARPA (anl-mcs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
	id AA06306; Sun, 30 Jun 85 19:07:20 pdt
Return-Path: <boyle@anl-mcs>
Received: by anl-mcs.ARPA ; Sun, 30 Jun 85 21:11:49 cdt
Date: Sun, 30 Jun 85 21:11:49 cdt
From: boyle@anl-mcs (James M. Boyle)
Message-Id: <8507010211.AA11456@anl-mcs.ARPA>
To: bane@gymble.ARPA, franz-friends@BERKELEY
Subject: Re:  Franz-f77 strange I/O?
Cc: boyle@anl-mcs

I have seen this problem also.  In version 38.44 of Franz, the fortran
output came to standard output, along with that from Lisp.  The change
occurred somewhere between version 38.44 and 38.69 or there abouts.
I, too, would kile to know of a fix.  It was much better to get the
output on the standard output.


From peck@sri-spam  Wed Jul  3 15:48:58 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA07336; Wed, 3 Jul 85 15:48:58 pdt
Received: from sri-spam.ARPA (sri-spam-test.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
	id AA00157; Wed, 3 Jul 85 15:44:06 pdt
Received: from localhost by sri-spam.ARPA (5.4/4.16)
	id AA08158; Wed, 3 Jul 85 15:45:45 PDT
Message-Id: <8507032245.AA08158@sri-spam.ARPA>
Date: 03 Jul 85 15:45:42 PDT (Wed)
To: franz-friends@BERKELEY
Subject: "nil" on the sun implementation
From: Jeff Peck <peck@sri-spam>

On the vax, the location of nil is linked to be location zero
(ie (maknum nil) => 0).
On the sun, the location of nil comes out as 32768
This is true on both v38.91 and v40.03a
Problems i have noticed because of this include are:
1. some C routines that check for nil shortcut with a zero check
   this works on the vax but fails on the sun.
2. (array ...) and by extension, other storage requests, on the
   vax return an array of nil (zero), but on the sun, zero is
   a pointer to unknown space, and causes errors.  
   (array name ...) needs to be followed by (fillarray 'name '(nil))
   to have an effect similar to that on the vax.

Questions: Is this particular to the way I am installing these programs?
	(ie, does (maknum nil) return zero on your sun?)

	Is this going to be changed? Has it been changed?
	Will (segment) or (small-segment) be modified to return storage
	initialized to nil?

	Will someone at FranzInc tell me if this is fixed in current releases?

J. Peck

From schlimme@uci-icse  Mon Jul  8 10:03:43 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA20308; Mon, 8 Jul 85 10:03:43 pdt
Received: from UCI-ICSE (uci-icse.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
	id AA03142; Mon, 8 Jul 85 09:58:53 pdt
Message-Id: <8507081658.AA03142@UCB-VAX.ARPA>
To: franz-friends@BERKELEY
Cc: schlimmer@uci-icse, arango@uci-icse
Subject: Namestack Overflow
Date: 08 Jul 85 10:02:13 PDT (Mon)
From: Jeff Schlimmer <schlimme@uci-icse>
Received: from Localhost by UCI-ICSE; 08 Jul 85 10:02:27 PDT (Mon)

     Several of the graduate students here at UCI are working on a large
   Franz Lisp program which requires several hundred levels of recursion.
   This causes a namestack overflow error in Franz. Is there a way to
   expand the size of the namestack? 

   --Jeff Schlimmer
   --Guillermo Arango

From liz@tove  Tue Jul  9 08:46:46 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA00559; Tue, 9 Jul 85 08:46:46 pdt
Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
	id AA09926; Tue, 9 Jul 85 07:46:38 pdt
Received: by tove.ARPA (4.12/4.7)
	id AA02537; Tue, 9 Jul 85 10:49:16 edt
Message-Id: <8507091449.AA02537@tove.ARPA>
To: Jeff Schlimmer <schlimme@uci-icse>
Cc: franz-friends@BERKELEY, arango@uci-icse
Subject: Re: Namestack Overflow
In-Reply-To: Your message of 08 Jul 85 10:02:13 PDT (Mon).
	     <8507081658.AA03142@UCB-VAX.ARPA>
Date: 09 Jul 85 10:48:56 EDT (Tue)
From: Liz Allen <liz@tove>

	From: Jeff Schlimmer <schlimme@uci-icse>

	     Several of the graduate students here at UCI are
	   working on a large Franz Lisp program which requires
	   several hundred levels of recursion.  This causes a
	   namestack overflow error in Franz. Is there a way to
	   expand the size of the namestack?

Yes, there is.  In ../franz/h/global.h, there is a #define for
NAMESIZE which is the size of the name stack.  It can be changed
to something larger.

				-Liz

From boyle@anl-mcs  Tue Jul  9 09:29:07 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA01193; Tue, 9 Jul 85 09:29:07 pdt
Received: from anl-mcs.ARPA (anl-mcs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
	id AA09323; Tue, 9 Jul 85 07:08:27 pdt
Return-Path: <boyle@anl-mcs>
Received: by anl-mcs.ARPA ; Tue, 9 Jul 85 09:12:21 cdt
Date: Tue, 9 Jul 85 09:12:21 cdt
From: boyle@anl-mcs (James M. Boyle)
Message-Id: <8507091412.AA10613@anl-mcs.ARPA>
To: arango@uci-icse, franz-friends@BERKELEY, schlimmer@uci-icse
Subject: Re: Namestack Overflow; Large list storage
Cc: boyle@anl-mcs

In the directory   franz/h   search for NAMESIZE in the file  global.h
and change it; then rebuild the system.  (Use a `make clean' first,
because not all the dependencies are in the makefile, I think.  You 
can rebuild with `make fast' [ha!]).

I changed the NAMESIZE in our system from 3072 to 16384 without difficulty.

However, I have a problem, franz-friends--I tried to increase the list
storage (TTSIZE) from the default 6000 or so 512 byte pages to 32000.
When the storage goes above the 10216 pages or so, I get bizzare behavior,
usually culminating in an illegal instruction.  Is 10216 somehow a hard
limit on the list storage size?  Has anyone built a system bigger than
10216 and had it work for large jobs?  (This is not a problem with our
system datasize limit; it happens before the datasize is exceeded.)

Thanks.
				Jim Boyle

From JPG@MIT-MC.ARPA  Thu Jul 11 20:23:07 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA01049; Thu, 11 Jul 85 20:23:07 pdt
Received: from MIT-MC.ARPA (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
	id AA27795; Wed, 10 Jul 85 09:44:41 pdt
Date: Wed, 10 Jul 85 12:50:05 EDT
From: Jeffrey P. Golden <JPG@MIT-MC.ARPA>
Subject: Franz Lisp for Eunice 4.1
To: franz-friends@BERKELEY
Cc: JPG@MIT-MC.ARPA
Message-Id: <[MIT-MC.ARPA].570311.850710.JPG>

We are running Franz Lisp, opus 38.79 in VMS 4.1, Eunice 4.1 . 
The way "funny" VMS filenames such as  i.am.funny  (two dots) and 
longfilename.l  (more than 9 characters in first-filename) are hashed by 
Eunice was changed from version 3.X (HSN/HSH filename extensions) to 
version 4.X ($-sign encoding).
The problem is even though we are running in VMS/Eunice 4.1, Franz only 
understands the VMS/Eunice 3.X funny filename hashing e.g. for 
(load "longfilename.l") .  It gives a "file not found error" if the 
filename is hashed using the 4.X hashing scheme.
Can anyone clarify this situation for me?  I.e. is it likely to be a Franz 
problem or a Eunice problem we are facing?  We have not rebuilt Franz yet, 
but would this help?  Would recompiling some C file help?  There's a 
function cvt_unix_to_vms .  Is this the culprit?  Is this a Franz function 
or a Eunice function?  Any advice would be appreciated.

Also, some .exe files work fine without rebuilding from 3.X .  Others 
err out with: [EUNICE: $IMGACT failed, Status = %X84d8cbc - Couldn't get 
message string].  Does anyone know what this means?


From zoll@CMU-PSY-A  Mon Jul 15 09:07:27 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA04385; Mon, 15 Jul 85 09:07:27 pdt
Received: from CMU-PSY-A (cmu-psy-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
	id AA08819; Mon, 15 Jul 85 09:02:06 pdt
Message-Id: <8507151602.AA08819@UCB-VAX.ARPA>
Date:     Monday, 15 Jul 85 12:00:57 EDT
From: zoll@cmu-psy-a (john zoll)
Subject:  Franz, Eunice, 4.0
To: jpg@mit-mc
Cc: zoll@CMU-PSY-A, franz-friends@BERKELEY

cvt_unix_to_vms() is not part of the Franz sources: it is a Eunice function.
We don't have 4.0 Eunice yet, but it should be easy to test this function out
of context. Although I don't have the exact specs for 4.0 filenames, I'd guess
that you probably could probably just blow away all calls to cvt_unix_to_vms()
(there's only a few of them). Or writing your own wouldn't be too tough.

-------

I suspect the Eunice image activation error message is in reality VMS's 
IMG_SIZ error message (found on 2-205 of the 4.0 System Messages Manual).
This means that your image header is fotched. Here's what happened to me:
we've got a bunch of MicroVaxes and VaxStation 100s running various 
incarnations of VMS 4.X. Recently I tried to port Franz to them from our 780
(running VMS and Eunice). Initially I just copied the Franz image to the
workstation, but this resulted in the aforementioned image activation error.
So then I copied the components needs to build an interpreted Franz by hand
--- Rawlisp and the 10 or so .l files. This worked, but if I did a (dumplisp)
to save the lisp, I would get the image activation error again. As it turns 
out, the code for (dumplisp ...) has a slight bug that has only become 
apparent under 4.X. 

The fix is trivial ---- there is a field in image headers that need not be
set under 3.X, but must be set under 4.X. NDumplisp, the routine that creates
a new lisp image, was not setting this field. Below is a fragment of my hack
to NDumplisp:

File:		Fex3.C
Routine:	NDumplisp
-------------------------

/* Setting up the image header... */

	Buffer.Header.Ihd.majorid[1]	= '2';
	Buffer.Header.Ihd.minorid[0]	= '0';
	Buffer.Header.Ihd.minorid[1]	= '2';

/* Here's the hack..... */

	Buffer.Header.Ihd.hdrblkcnt	= 1;	

/* EOH */

	Buffer.Header.Ihd.imgtype	= IHD_EXECUTABLE;
	Buffer.Header.Ihd.privreqs[0]	= -1;
	Buffer.Header.Ihd.privreqs[1]	= -1;

-----

If anyone is planning to be running on 4.0, you must set this field, or any
lisp created via dumplisp will not run.

John Zoll
Carnegie-Mellon University
Zoll@Cmu-Psy-A.Arpa


From KASHTAN@SRI-AI.ARPA  Mon Jul 15 13:57:48 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA09840; Mon, 15 Jul 85 13:57:48 pdt
Received: from SRI-AI.ARPA (sri-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
	id AA05591; Mon, 15 Jul 85 13:52:21 pdt
Message-Id: <8507152052.AA05591@UCB-VAX.ARPA>
Date: Mon 15 Jul 85 13:56:28-PDT
From: KASHTAN@SRI-AI.ARPA
Subject: Re: Franz, Eunice, 4.0
To: jpg@MIT-MC.ARPA, zoll@CMU-PSY-A.ARPA
Cc: franz-friends@BERKELEY

Here is a VERY simple "C" program that will patch the VMS image header to
make the "hdrblkcnt" 1 instead of 0.  You can use this program any time
you do a dumplisp and want to run it on VMS 4.0 (without having to recompile
the basic Franz Lisp):

main(argc,argv)
char *argv[];
{
	int i;
	for(i = 1; i < argc; i++) patch(argv[i]);
}

patch(filename)
char *filename;
{
	int fd;
	char hdrblkcnt = 1;

	fd = open(filename,2);
	if (fd < 0) {perror("open"); return;}
	lseek(fd,16,0);
	write(fd,&hdrblkcnt,1);
	close(fd);
}


David
-------

From @MIT-MC.ARPA:KS20@CMU-CS-A.ARPA  Mon Jul 22 07:23:24 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
	id AA29235; Mon, 22 Jul 85 07:23:24 pdt
Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by UCB-VAX.ARPA (4.24/5.3)
	id AA22657; Mon, 22 Jul 85 07:17:56 pdt
Message-Id: <8507221417.AA22657@UCB-VAX.ARPA>
Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 22 Jul 85 10:22:52 EDT
Date: 22 July 1985 1022-EDT
From: Karsten.Schwans@CMU-CS-A
To: BBoard.Maintainer@CMU-CS-A
Subject: FranzLisp IPC
Attention: franzlisp bboard

We are having trouble with FranzLisp on Berkeley 4.2. We don't
seem to be able to call the Berkeley IPC without causing undue
danamge to the system. Does anyone have a working piece
of code you might send us Thanks, Karsten
P.S.: Pleas send responses to Schwan@ohio-state.csnet or schwans@cmua



From john%mtu.csnet@csnet-relay.arpa  Mon Aug 19 15:55:07 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA00203; Mon, 19 Aug 85 15:55:07 PDT
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3)
	id AA06773; Mon, 19 Aug 85 14:22:12 pdt
Message-Id: <8508192122.AA06773@UCB-VAX.ARPA>
Received: from mtu by csnet-relay.csnet id a001523; 19 Aug 85 17:23 EDT
Received: by mtu.UUCP (4.12/4.7)
	id AA22034; Mon, 19 Aug 85 09:58:17 edt
Date: Mon, 19 Aug 85 09:58:17 edt
From: John Lowther <john%mtu.csnet@csnet-relay.arpa>
To: franz-friends@BERKELEY
Subject: List Membership
Cc: john@mtu.CSNET

Please add Michigan Technological University ( c/o John Lowther)
to franz-friends@BERKELEY distribution.
Thanks,
			Dr. John Lowther
			Associate Professor of Computer Science
			Computer Science
			Michigan Technological University
			Houghton, Michigan 49931

			Office: (906) 487-2183
			Secretary: (906) 487-2068

			uucp: {lanl, ihnp4, glacier}!mtu!john
			arpa/csnet: john%mtu@csnet-relay


From leff%smu.csnet@csnet-relay.arpa  Tue Aug 27 18:54:44 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA12084; Tue, 27 Aug 85 18:54:44 PDT
Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3)
	id AA15443; Tue, 27 Aug 85 18:51:23 pdt
Received: from smu by csnet-relay.csnet id ae17053; 27 Aug 85 21:47 EDT
Received: by csevax.smu (4.12/4.7)
	id AA20402; Tue, 27 Aug 85 17:01:03 cdt
Date: 27 Aug 1985 16:55-EST
From: leff%smu.csnet@csnet-relay.arpa
Subject: 
To: franz-friends@BERKELEY
Message-Id: <494027757/leff@smu>

One of our Franz users (Opus 38.79) has gotten the error message

"Space request would exceed maximum memory allocation
[Storage space totally exhausted]
Error: Space exhausted when allocating list"

I seem to recall reading in the manual that there was some function
to reconfigure the amount of space used by cons as opposed to
print-name space or something but a search of the manual fails
to turn anything up.  Is there anything I can do for our user
short of telling him to write his code to use less memory space."

(Note to moderator: This sounds like a straightforward question
but it has got us stumped.  Perhaps you can forward it to someone
who can answer it without bothering the whole net.)

Thanks,


Leff


From sklower@ucbdali  Wed Sep 11 17:53:47 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA01203; Wed, 11 Sep 85 17:53:47 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3)
	id AA00745; Wed, 11 Sep 85 17:49:44 pdt
Received: by ucbdali.ARPA (5.5/4.48)
	id AA06062; Wed, 11 Sep 85 17:48:39 PDT
Date: Wed, 11 Sep 85 17:48:39 PDT
From: sklower@ucbdali (Keith Sklower)
Message-Id: <8509120048.AA06062@ucbdali.ARPA>
To: rsm@carl.UTEXAS.EDU
Subject: -H flag
Cc: franz-friends@BERKELEY

we have built macsyma here at berkeley without using the -H
flag on the sun.  The only thing it would buy you is sharing of
text space if two people were running macsyma on the same sun,
 a foolish proposition at best.  Just link rawlisp to rawhlisp.

From @CSNET-RELAY.ARPA@BERKELEY  Tue Sep 24 16:11:53 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA20743; Tue, 24 Sep 85 16:11:53 PDT
Received: by UCB-VAX.ARPA (5.25/5.9)
	id AA14107; Tue, 24 Sep 85 16:11:28 PDT
Message-Id: <8509242311.AA14107@UCB-VAX.ARPA>
Received: from umn-cs by csnet-relay.csnet id ag03295; 24 Sep 85 19:11 EDT
Received: by umn-cs.UMN (4.12/4.7)
	id AA25965; Mon, 23 Sep 85 17:39:06 cdt
Date: Mon, 23 Sep 85 17:39:06 cdt
From: Raj Doshi <doshi%umn.csnet@CSNET-RELAY.ARPA>
To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa
Subject: FRANZ-unix question...


> In Franz, how can I access the following:-
        (1) The user's name  (not just the login name, but also
            the actual name from the '.plan' (or whatever) file  ???
        (2) The date.

Thank you very much.

--- raj doshi,  University of Minnesota
      
                doshi%umn.csnet@csnet-relay.arpa
               
		Raj Doshi
		2030 Wilson Avenue, Apt #27
		Saint Paul, MN 55119
		(612)-739-2353
		(612)-739-2151




From @CSNET-RELAY.ARPA@BERKELEY  Tue Sep 24 21:13:35 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA24010; Tue, 24 Sep 85 21:13:35 PDT
Received: by UCB-VAX.ARPA (5.25/5.9)
	id AA20438; Tue, 24 Sep 85 21:13:25 PDT
Message-Id: <8509250413.AA20438@UCB-VAX.ARPA>
Received: from umn-cs by csnet-relay.csnet id ab04924; 25 Sep 85 0:11 EDT
Received: by umn-cs.UMN (4.12/4.7)
	id AA17034; Tue, 24 Sep 85 20:58:58 cdt
Date: Tue, 24 Sep 85 20:58:58 cdt
From: Raj Doshi <doshi%umn.csnet@CSNET-RELAY.ARPA>
To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa,
        franz-friends@berkley, moen@umn.CSNET
Subject: unknown prop.lists ..


**** QUESTION about FRANZ-LISP, atoms & their properties :-

Suppose that I have access to an atom (i.e. I know its NAME).
But I dont know anything more about it.  

Now, is there a FRANZ function, whereby I can
ask franz to RETURN/LIST all the properties, 
(given to the atom via PUTPROPs by the user).  
if any, (and maybe their values) to me ???

Maybe the creators of FRANZ didnt see the need for such a function
or maybe they didnot think about this, but,
I am sure FRANZ has to keep track of an atom's properties 
(probably in an array or frame like structure).

HOW DOES FRANZ actually STORE THE properties OF ATOMS ??
If I know this, I could (probably?) write the function myself.

Thanks in advance.

--- raj doshi,  University of Minnesota
      
                doshi%umn.csnet@csnet-relay.arpa
               
		Raj Doshi
		2030 Wilson Avenue, Apt #27
		Saint Paul, MN 55119
		(612)-739-2353
		(612)-739-2151




From @CSNET-RELAY.ARPA@BERKELEY  Tue Sep 24 21:14:14 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA24021; Tue, 24 Sep 85 21:14:14 PDT
Received: by UCB-VAX.ARPA (5.25/5.9)
	id AA20453; Tue, 24 Sep 85 21:13:57 PDT
Message-Id: <8509250413.AA20453@UCB-VAX.ARPA>
Received: from umn-cs by csnet-relay.csnet id ad04924; 25 Sep 85 0:12 EDT
Received: by umn-cs.UMN (4.12/4.7)
	id AA18092; Tue, 24 Sep 85 21:53:59 cdt
Date: Tue, 24 Sep 85 21:53:59 cdt
From: Raj Doshi <doshi%umn.csnet@CSNET-RELAY.ARPA>
To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa,
        franz-friends@BERKELEY, moen@umn.CSNET
Subject: i AND o ....


**** Question about CONCURRENT i/o to the SAME file.

I am trying to do the following in Franz-Lisp:-
     I have a file which has some stuff in it (= it is non-empty).
     First, I want to  *append* something to it (that is, I want
        to write something FROM its end-of-file;  I want to preserve
        its original contents).
     Then, I want to read something from the start-of-the-file.
     Then, I want to  *append*  something-new to the new-version
        of this file.

Now, I have tried the following:-
     Lets say that the file name is fn.
     TRY #1 :  setq portout (outfile 'fn)
               fseek portout 
                     (filestat:size (filestat 'fn)) ;Filestat take only 2 param.
                     0)
               (defun p-raj () (patom "Hi-raj" portout))
               (p-raj) 
               (p-raj)
               ----------------
               The problem with this is that the
                    >setq portout (outfile 'fn)
                    seems to AUTOMATICALLY and PERMANENTLY 
                    put the r/w-cursor at the START of the file
                    (without my permission).  Also, once this is
                    done, FSEEK become impotent.  It will always
                    send back a zero.  Also, a FILEPOS has no effect.
                    Basically, you cannot move the @<@!!# cursor
                    unless you write  (and therefore overwrite the
                    original contents) something to the file.
                       Note however that, if I had not done
                       setq portout (outfile 'fn)
                       then, 
                           >(filestat:size (filestat 'fn))
                       does return the true (unix) size of the file.
               @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
     TRY #2 :  (setq inout (infile 'fn))
               (fileopen 'fn 'w+)  ; FILEOPEN takes only 2 parameters.
               ; you can also try the following
               ; (fileopen 'fn 'a+)
               (filepos portio)
		   [this gives back a zero, which is ok.]
               (filestat:size (filestat 'junk))
		   [this does give its true size, say 232 blocks.]
               (filepos portio (filestat:size (filestat 'junk)))
		   [this does put the r/w-cursor at 232.]
               (filepos portio)
                   [this confirms that.]
               (patom "IS this really going to get appended ?" portio)
		   [this prints the above string on the TERMINAL,
		    not onto the file fn.]
               (filepos portio)
		   [the cursor is STILL at 232.]
	       -----------
	       Basically, I think that the reason it wont write to the file fn,
	       in this second case is that the <inout> was defined
	       for reading and not for writing.
		   {Is this the correct impression ?}

[I have tried many many different permutations also.]

SO, in brief, a <setq pi (outfile..>
         automatically puts the cursor at the start-of-the-file;
    and the FILEOPEN, FILEPOS, FSEEK dont seem to have any effect.
    and, a <setq po (infile...> 
	 never allows me to write onto the file atall
	 even if I do a  <FILEOPEN 'fn 'w+>.

>>>>>>   QUESTION: What am I missing here ??  <<<<<<

Thanks in advance. 


--- raj doshi,  University of Minnesota
      
                doshi%umn.csnet@csnet-relay.arpa
               
		Raj Doshi
		2030 Wilson Avenue, Apt #27
		Saint Paul, MN 55119
		(612)-739-2353
		(612)-739-2151




From @CSNET-RELAY.ARPA@BERKELEY  Tue Sep 24 21:14:42 1985
Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
	id AA24035; Tue, 24 Sep 85 21:14:42 PDT
Received: by UCB-VAX.ARPA (5.25/5.9)
	id AA20463; Tue, 24 Sep 85 21:14:15 PDT
Message-Id: <8509250414.AA20463@UCB-VAX.ARPA>
Received: from umn-cs by csnet-relay.csnet id ae04924; 25 Sep 85 0:12 EDT
Received: by umn-cs.UMN (4.12/4.7)
	id AA18092; Tue, 24 Sep 85 21:53:59 cdt
Date: Tue, 24 Sep 85 21:53:59 cdt
From: Raj Doshi <doshi%umn.csnet@CSNET-RELAY.ARPA>
To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa,
        franz-friends@BERKELEY, moen@umn.CSNET
Subject: i AND o ....


**** Question about CONCURRENT i/o to the SAME file.

I am trying to do the following in Franz-Lisp:-
     I have a file which has some stuff in it (= it is non-empty).
     First, I want to  *append* something to it (that is, I want
        to write something FROM its end-of-file;  I want to preserve
        its original contents).
     Then, I want to read something from the start-of-the-file.
     Then, I want to  *append*  something-new to the new-version
        of this file.

Now, I have tried the following:-
     Lets say that the file name is fn.
     TRY #1 :  setq portout (outfile 'fn)
               fseek portout 
                     (filestat:size (filestat 'fn)) ;Filestat take only 2 param.
                     0)
               (defun p-raj () (patom "Hi-raj" portout))
               (p-raj) 
               (p-raj)
               ----------------
               The problem with this is that the
                    >setq portout (outfile 'fn)
                    seems to AUTOMATICALLY and PERMANENTLY 
                    put the r/w-cursor at the START of the file
                    (without my permission).  Also, once this is
                    done, FSEEK become impotent.  It will always
                    send back a zero.  Also, a FILEPOS has no effect.
                    Basically, you cannot move the @<@!!# cursor
                    unless you write  (and therefore overwrite the
                    original contents) something to the file.
                       Note however that, if I had not done
                       setq portout (outfile 'fn)
                       then, 
                           >(filestat:size (filestat 'fn))
                       does return the true (unix) size of the file.
               @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
     TRY #2 :  (setq inout (infile 'fn))
               (fileopen 'fn 'w+)  ; FILEOPEN takes only 2 parameters.
               ; you can also try the following
               ; (fileopen 'fn 'a+)
               (filepos portio)
		   [this gives back a zero, which is ok.]
               (filestat:size (filestat 'junk))
		   [this does give its true size, say 232 blocks.]
               (filepos portio (filestat:size (filestat 'junk)))
		   [this does put the r/w-cursor at 232.]
               (filepos portio)
                   [this confirms that.]
               (patom "IS this really going to get appended ?" portio)
		   [this prints the above string on the TERMINAL,
		    not onto the file fn.]
               (filepos portio)
		   [the cursor is STILL at 232.]
	       -----------
	       Basically, I think that the reason it wont write to the file fn,
	       in this second case is that the <inout> was defined
	       for reading and not for writing.
		   {Is this the correct impression ?}

[I have tried many many different permutations also.]

SO, in brief, a <setq pi (outfile..>
         automatically puts the cursor at the start-of-the-file;
    and the FILEOPEN, FILEPOS, FSEEK dont seem to have any effect.
    and, a <setq po (infile...> 
	 never allows me to write onto the file atall
	 even if I do a  <FILEOPEN 'fn 'w+>.

>>>>>>   QUESTION: What am I missing here ??  <<<<<<

Thanks in advance. 


--- raj doshi,  University of Minnesota
      
                doshi%umn.csnet@csnet-relay.arpa
               
		Raj Doshi
		2030 Wilson Avenue, Apt #27
		Saint Paul, MN 55119
		(612)-739-2353
		(612)-739-2151




From sokol@mitre.ARPA  Mon Oct  7 10:41:27 1985
Received: by ucbkim (5.28/5.12)
	id AA02846; Mon, 7 Oct 85 10:41:27 PDT
Received: by UCB-VAX.ARPA (5.28/5.11)
	id AA00642; Mon, 7 Oct 85 06:55:41 PDT
Received: by mitre.ARPA (4.12/4.7)
	id AA11068; Mon, 7 Oct 85 09:56:30 edt
Message-Id: <8510071356.AA11068@mitre.ARPA>
To: franz-friends@BERKELEY
Cc: sokol@mitre.ARPA
Subject: arpa list
Date: 07 Oct 85 09:55:24 EDT (Mon)
From: Lisa Sokol <sokol@mitre.ARPA>

Could you please add my name to your mailing list-- sokol@mitre

Thank youl
 
Lisa Sokol

From dcdwest!benson@SDCSVAX.ARPA  Fri Oct 11 19:56:25 1985
Received: by kim (5.28/5.12)
	id AA06307; Fri, 11 Oct 85 19:56:25 PDT
Received: by UCB-VAX (5.28/5.12)
	id AA01765; Fri, 11 Oct 85 19:56:11 PDT
Received: by sdcsvax.ARPA (5.28/4.41)
	id AA08044; Fri, 11 Oct 85 15:35:25 PDT hops=0
From: dcdwest!benson@SDCSVAX.ARPA (Peter Benson)
Date: Fri, 11 Oct 85 15:14:30 pdt
Message-Id: <8510112214.AA04005@dcdwest.ITT>
Received: by dcdwest.ITT; Fri, 11 Oct 85 15:14:30 pdt
To: franz-friends@BERKELEY
Subject: Could you ...

put me on the mailing list ??
Thanks.

                                _
Peter Benson                    | ITT Defense Communications Division
(619)578-3080                   | 10060 Carroll Canyon Road
decvax!ittvax!dcdwest!benson    | San Diego, CA 92131
ucbvax!sdcsvax!dcdwest!benson   | 

From fateman@dali  Wed Oct 30 12:22:05 1985
Received: by kim (5.28/5.12)
	id AA10131; Wed, 30 Oct 85 12:22:05 PST
Received: by dali.ARPA (5.31/4.48)
	id AA19284; Wed, 30 Oct 85 12:21:57 PST
Date: Wed, 30 Oct 85 12:21:57 PST
From: fateman@dali (Richard Fateman)
Message-Id: <8510302021.AA19284@dali.ARPA>
To: franz-friends@kim
Subject: new implementation of Franz?

Actually, a compatible version of Franz (compatible with VAX/UNIX, and
the 680x0 UNIX systems) might be made available on an as-yet-unannounced
UNIX-based workstation made by a major computer manufacturer. 

It appears that this would be coupled with substantial donations of
the hardware to universities, by the manufacturer.

If the attractiveness of the workstation TO YOU would be enhanced by the
availability of Franz Lisp, please send me a note. (don't respond
to franz-friends.) As a group, we can lobby more effectively, and
get the manufacturer to supply it.  You may also include comments about
the desirability of additional dialects of Lisp.

Thanks, 
 Richard Fateman, UC Berkeley.

From YE15%mrca.co.uk@ucl-cs.arpa  Tue Nov  5 01:29:26 1985
Received: by kim (5.28/5.12)
	id AA03832; Tue, 5 Nov 85 01:29:26 PST
Received: by ucb-vax.berkeley.edu (5.31/1.2)
	id AA06898; Tue, 5 Nov 85 01:29:03 PST
Received: from mrca.co.uk by 44d.Cs.Ucl.AC.UK   via PSS with NIFTP  id a006249;
          5 Nov 85 9:24 GMT
From: at GEC Research <YE15%mrca.co.uk@ucl-cs.arpa>
To: franz-friends <franz-friends%ucb-vax.arpa@ucl-cs.arpa>
Date:    Tue, 5 Nov 85 09:04
Subject: Receiving "franz-friends"
Message-Id: <05 NOV 1985 09:15:13 YE15@uk.co.mrca>

     I would like to get my name added to the distribution
list for "franz-friends". I saw a reference to it in AIList
Digest recently, but couldn't find anyone in the UK who knew
about it. Can you either give me information about how to
receive "franz-friends" or add my name to the list of
recipients, whichever is appropriate. My address is,
 
      Kevin Poulter (YE15%uk.co.mrca@uk.ac.ucl.cs)
      GEC Research Ltd
      Marconi Research Centre
      West Hanningfield Road
      Great Baddow
      Chelmsford
      Essex 
      CM2 8HN
      United Kingdom
 
 
     Thanks,
 
         Kevin Poulter (YE15%uk.co.mrca@uk.ac.ucl.cs)
 
 


From bzs%buit4%bostonu.csnet@csnet-relay.arpa  Sat Nov  9 16:53:26 1985
Received: by kim (5.28/5.12)
	id AA20036; Sat, 9 Nov 85 16:53:26 PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
	id AA04628; Sat, 9 Nov 85 16:53:20 PST
Received: from bostonu by csnet-relay.csnet id ac19699; 9 Nov 85 19:45 EST
Received: from buit4.ARPA by bu-cs.ARPA (4.12/4.7)
	id AA06442; Sat, 9 Nov 85 19:34:45 est
Return-Path: <bzs@buit4>
Received: by buit4.ARPA (2.2/4.7)
	id AA05580; Sat, 9 Nov 85 19:36:36 est
Date: Sat, 9 Nov 85 19:36:36 est
From: Barry Shein <bzs%buit4%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8511100036.AA05580@buit4.ARPA>
To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA
Subject: Re: IMPROPER USE OF SET error on SUNs


I don't know if this was answered (I haven't seen it) but I am
quite sure the problem is in the definition of *array in array.l,
down near the bottom there is a (do ((i size)) ((zerop i))
(set (arrayref tname (setq i......)

the error is coming I believe from that (set) for fixnum-block type
arrays. If someone can come up with the fix I would appreciate,
(or already has) otherwise I'll try and figure out what should be
there. Thanks in advance.

	-Barry Shein, Boston University



From bzs%buit1%bostonu.csnet@csnet-relay.arpa  Sun Nov 10 12:27:50 1985
Received: by kim (5.28/5.12)
	id AA01767; Sun, 10 Nov 85 12:27:50 PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
	id AA17353; Sun, 10 Nov 85 12:27:28 PST
Received: from bostonu by csnet-relay.csnet id ai00716; 10 Nov 85 15:16 EST
Received: from buit1.ARPA by bu-cs.ARPA (4.12/4.7)
	id AA25424; Sun, 10 Nov 85 14:43:05 est
Return-Path: <bzs@buit1>
Received: by buit1.ARPA (2.2/4.7)
	id AA09529; Sun, 10 Nov 85 14:42:43 est
Date: Sun, 10 Nov 85 14:42:43 est
From: Barry Shein <bzs%buit1%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8511101942.AA09529@buit1.ARPA>
To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA
Subject: minor annoying bug in cfasl


If I try to cfasl something with:

	(cfasl 'foo.o '_foo 'foo "whatever")

I get a ld line that looks like:

	... /tmp/TMPXYZZY (null) -lc

that is, a null pointer is being passed to sprintf() and it is putting
'(null)' out (and the sh invoked by system() barks and the whole thing fails.)

A workaround is to add a null string at the end of the arglist

	(cfasl 'foo.o '_foo 'foo "whatever" "")

A fix is to go into the file franz/ffasl.c and change: (in function Lcfasl)

	if(work==nil)
		largs = 0 ;
to
	if(work==nil)
		largs = "" ;
I believe (trying it now, takes a while to compile this beast, no?)

	-Barry Shein, Boston University


From root%buit1%bostonu.csnet@csnet-relay.arpa  Mon Nov 11 06:50:27 1985
Received: by kim (5.28/5.12)
	id AA13546; Mon, 11 Nov 85 06:50:27 PST
Received: by ucbvax.berkeley.edu (5.31/1.2)
	id AA04671; Mon, 11 Nov 85 06:50:19 PST
Received: from bostonu by csnet-relay.csnet id af00429; 11 Nov 85 9:38 EST
Received: from buit1.ARPA by bu-cs.ARPA (4.12/4.7)
	id AA01783; Mon, 11 Nov 85 01:35:02 est
Return-Path: <root@buit1>
Received: by buit1.ARPA (2.2/4.7)
	id AA00418; Mon, 11 Nov 85 01:32:21 est
Date: Mon, 11 Nov 85 01:32:21 est
From: Operator <root%buit1%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8511110632.AA00418@buit1.ARPA>
To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA
Subject: Re: SET error on 68K


I believe the following fix repairs the problem in lisplib/array.l
(I think this only affects you if you are on a 68k)
---

in function *array, towards the bottom change:

		 ; if type is fixnum or flonum
		 ; we must intialize to 0 or 0.0
		 (cond ((or (and (eq 'fixnum type)
				 (setq rtype 0))
			    (and (eq 'flonum type)
				 (setq rtype 0.0))
			    (and (or (status feature 68k)
				     (status feature for-68k))
				 (progn (setq rtype nil) t)))
			(do ((i size))
			    ((zerop i))
			    (set (arrayref tname (setq i (1- i))) rtype))))
to be:

		 ; if type is fixnum or flonum
		 ; we must intialize to 0 or 0.0
		 (cond ((or (and (or (eq 'fixnum type)(eq 'fixnum-block type))
				 (setq rtype 0))
			    (and (or (eq 'flonum type)(eq 'flonum-block type))
				 (setq rtype 0.0))
			    (and (or (status feature 68k)
				     (status feature for-68k))
				 (progn (setq rtype nil) t)))
			(do ((i size))
			    ((zerop i))
			    (store (funcall tname (setq i (1- i))) rtype))))

The main problem being that the (status) call was testing true.
Without changing the SET to a STORE I was still having troubles,
so I changed that also. Flames welcome, not sure I understand everything
going on here (yet.)

	-Barry Shein, Boston University

P.S. typical apologies if this has all been solved before.
(while you are in there you might want to fix the spelling of 'intialize')