Return to lispnews CVS log

Up to [CSRG BSD Unix] / 43BSD / ucb / lisp

Annotation of 43BSD/ucb/lisp/lispnews, revision 1.1

1.1     ! root        1: From jkf Tue Apr 13 00:12:22 1982
        !             2: To: /na/doe/jkf/lispnews
        !             3: Subject: new features
        !             4: Status: RO
        !             5: 
        !             6:  In response to requests from franz users, these enhancements have been
        !             7: made:
        !             8: 
        !             9: In Lisp 38.07,  if the lisp variable 'displace-macros' is set to non-nil,
        !            10: then when a macro expansion is done by the evaluator, the resulting
        !            11: expansion replaces the original call.  This means that macro expansion
        !            12: is only done once.  
        !            13: 
        !            14: In Liszt 8.03, the 'function' function is open coded.  If you have
        !            15:        (function (lambda ....))
        !            16: in your code then the lambda expression is compiled as a separate function
        !            17: and the result of the function call is a 'bcd' object which points
        !            18: to that compiled lambda.
        !            19: 
        !            20: 
        !            21: 
        !            22: From jkf Sun Apr 18 13:16:46 1982
        !            23: To: local-lisp
        !            24: Subject: opus 38.09
        !            25: Status: RO
        !            26: 
        !            27:  The new features of this version are:
        !            28:        If the load function ends up fasl'ing in a file, then load will
        !            29:   do what is necessary to insure that the new functions are linked in
        !            30:   correctly. Previously, if you turned on the transfer tables with
        !            31:   (sstatus translink on) or (sstatus translink t) and then fasl'ed in
        !            32:   functions which already existed, the old versions of the functions
        !            33:   would still be used, unless you did (sstatus translink on) yourself.
        !            34:   Now this is done automatically.
        !            35: 
        !            36:       tyi now accepts a second argument which is the object to return
        !            37:   upon eof.  -1 is the default.
        !            38: 
        !            39:      (pp-form 'g_obj ['p_port]) should be used instead of $prpr
        !            40:  for pretty printing a form.
        !            41: 
        !            42:      The storage allocator and collector has been modified to add
        !            43:  two new data types: vector and vector immediate.  They are not in
        !            44:  their final form so I suggest that you not try to use them. 
        !            45:  However, be on the lookout for garbage collection bugs.
        !            46: 
        !            47: 
        !            48: 
        !            49: From jkf Wed Apr 21 07:45:54 1982
        !            50: To: local-lisp
        !            51: Subject: liszt 8.04
        !            52: Status: RO
        !            53: 
        !            54:   the new features of liszt 8.04 are:
        !            55: 
        !            56: 1) init files:
        !            57:     Before liszt begins compiling, it looks for an init file to load in.
        !            58:     It first searches in the current directory, and then it searches
        !            59:     your home directory (getenv 'HOME).
        !            60:     It looks for file names:
        !            61:        .lisztrc.o  .lisztrc.l  lisztrc.o lisztrc.l
        !            62:     It loads only the first one it finds.
        !            63: 
        !            64: 2) interrupt handling
        !            65:     If you interrupt liszt  (with ^C typically), it will remove its
        !            66:     temporary file and exit.
        !            67: 
        !            68: 3) preallocation of space
        !            69:     It preallocates space in order to reduce the number of gc's done
        !            70:     during compiling.
        !            71: 
        !            72:        
        !            73:        
        !            74: 
        !            75: 
        !            76: From jkf Wed Apr 21 13:47:50 1982
        !            77: To: local-lisp
        !            78: Subject: lisp opus 38.10
        !            79: Status: RO
        !            80: 
        !            81:  lisp will now look for a lisprc in a way similar to liszt.
        !            82: 
        !            83:  It will first search in . and then in $HOME
        !            84:  It will look for the file .lisprc or lisprc ending with .o, .l and then
        !            85: just .lisprc or lisprc.
        !            86: 
        !            87:  Shortly, it will only look for files ending in .l and .o since we don't
        !            88: want to encourage files with non-standard filename extensions.
        !            89: 
        !            90: 
        !            91:  
        !            92: 
        !            93: 
        !            94: From jkf Wed Apr 21 23:40:59 1982
        !            95: To: local-lisp
        !            96: Subject: lisp opus 38.11
        !            97: Status: RO
        !            98: 
        !            99:  I finally got sick of showstack and baktrace and rewrote them in lisp,
        !           100: rincorporating some of the features people have been requesting.
        !           101: Showstack now works as follows:
        !           102:        (showstack) : show all interesting forms.  Forms resulting from
        !           103:                      the trace package are not printed as well as 
        !           104:                      extraneous calls to eval.  In the form printed,
        !           105:                      the special form <**> means 'the previous expression
        !           106:                      printed'.  prinlevel and prinlength are set to 
        !           107:                      reasonable values to prevent the expression from
        !           108:                      getting too large
        !           109:        (showstack t) : same as above but print all expressions.
        !           110:        (showstack 5) : print only the first 5 expressions. of course, 5
        !           111:                      is not the only possible numeric argument.
        !           112:        (showstack lev 3) : set prinlevel to 3 before printing
        !           113:        (showstack len 4) : set prinlength to 4 before printing
        !           114:  the above arguments can be used in combination.
        !           115: 
        !           116: The default value of prinlevel is showstack-prinlevel, that of prinlength
        !           117: is showstack-prinlength.  the default showstack printer is the
        !           118: value of showstack-printer (default is 'print').
        !           119: 
        !           120: baktrace accepts the same arguments as showstack, but it ignores the
        !           121: prinlevel and prinlength arguments.
        !           122: 
        !           123: 
        !           124: 
        !           125: 
        !           126: From jkf Sat Apr 24 08:55:18 1982
        !           127: To: local-lisp
        !           128: Subject: lisp opus 38.12, liszt 8.05
        !           129: Status: RO
        !           130: 
        !           131:   these changes and enhancements were made:
        !           132: 
        !           133: 1) the function 'function' in the interpreter acts just like 'quote'
        !           134:    In the compiler, 'function' will act like 'quote' unless the
        !           135:    argument is a lambda expression, in which case liszt will replace
        !           136:    the lambda expression with a unique symbol.  That unique symbol's
        !           137:    function cell will contain a compiled version of the lambda 
        !           138:    expression.   These changes will make Franz compatible with Maclisp
        !           139:    type lisps, as far as the treatment of 'function'
        !           140: 
        !           141: 2) Mechanisms were added to permit user written C or Fortran code to call 
        !           142:    lisp code. Everything isn't quite ready yet.
        !           143: 
        !           144: 3) Signal was fixed so that if you ask for a signal to be ignored, the
        !           145:    operating system will be notified.  The correct way to fork a lisp
        !           146:    is now:
        !           147:        (cond ((fork) (signal 2 (prog1 (signal 2) (wait)))))
        !           148: 
        !           149: 4) You can select the default function trace uses to print the arguments and
        !           150:    results.  Just lambda bind trace-printer to the name of the function
        !           151:    you want it to use.  The standard trace-printer sets prinlevel and
        !           152:    prinlength to the values of trace-prinlevel and trace-prinlength before
        !           153:    printing.  By default, trace-prinlevel is 4, and trace-prinlength is 5
        !           154: 
        !           155: 
        !           156:    
        !           157: 
        !           158: 
        !           159: From jkf Sun Apr 25 23:46:16 1982
        !           160: To: local-lisp
        !           161: Subject: lisp opus 38.13
        !           162: Status: RO
        !           163: 
        !           164:   Functions 1+ and 1- are now part of the interpreter, rather than
        !           165: being made equivalent to add1 and sub1.
        !           166: 
        !           167: 
        !           168: 
        !           169: From jkf Wed Apr 28 09:52:43 1982
        !           170: To: local-lisp
        !           171: Subject: Opus 38.14
        !           172: Status: RO
        !           173: 
        !           174:   Has these new features:
        !           175:        1) the message [load filename] will appear before load
        !           176:           reads in a lisp source file.  This can be disabled by
        !           177:           setting $ldprint to nil.
        !           178:        2) a function 'truename' as been added.  It takes a port
        !           179:           and returns the name of the file associated with that port.
        !           180:           It returns a string if there is a file associated with
        !           181:           the port, otherwise it returns nil.
        !           182: 
        !           183: 
        !           184: 
        !           185: From jkf Wed Apr 28 10:36:34 1982
        !           186: To: local-lisp
        !           187: Subject: more on opus 38.14
        !           188: Status: RO
        !           189: 
        !           190:  $ldprint is lambda bound to nil during the loading of the lisprc file.
        !           191: 
        !           192: 
        !           193: 
        !           194: 
        !           195: From jkf Wed May  5 08:30:00 1982
        !           196: To: local-lisp
        !           197: Subject: opus 38.15
        !           198: Status: RO
        !           199: 
        !           200:  a minor modification: 'makhunk' is now more efficient.
        !           201: 
        !           202: 
        !           203: From jkf Wed May  5 20:56:40 1982
        !           204: To: local-lisp
        !           205: Subject: Opus 38.16
        !           206: Status: RO
        !           207: 
        !           208:  A new function was added:
        !           209:        (hunk-to-list 'h_hunk) 
        !           210:        returns the elements of h_hunk as a list.
        !           211: 
        !           212:  Also, the error message printed when an oversized print name is encountered
        !           213: has been improved.
        !           214: 
        !           215: 
        !           216: 
        !           217: From jkf Fri May  7 20:03:40 1982
        !           218: To: local-lisp
        !           219: Subject: Liszt version 8.06
        !           220: Status: RO
        !           221: 
        !           222: 
        !           223:  Local declarations are now supported.  You can say:
        !           224: (defun foo (a b)
        !           225:    (declare (special a))
        !           226:    ... body ...)
        !           227: 
        !           228: and the special declaration for 'a' will affect the body of function
        !           229: foo only.  The 'a' which is an argument to foo will also be special
        !           230: in this case.    Declarations may be 
        !           231:  1) at the top level, not within a function body.
        !           232:  2) at the beginning of a  'lambda' body.
        !           233:  3) at the beginning of a 'prog' body
        !           234:  4) at the beginning of a 'do' body.
        !           235: 
        !           236: 'the beginning' means either the first, second or third form in the body.
        !           237: When the compiler is searching for declarations, it will not macroexpand.
        !           238: 
        !           239: 
        !           240:  Fixnum declarations now have meaning.  If you do
        !           241:        (declare (fixnum i j))
        !           242: then
        !           243:        (greaterp i  j)  will be converted to (>& i j)
        !           244: 
        !           245:  The declare function is now defined in the compiler.  Previously,
        !           246: the only way to declare something was for the compiler to 'compile'
        !           247: the declaration form.  Now, if you load or fasl in a file with
        !           248: a declare statement in it, the declare statement will have the
        !           249: proper effect in the compiler.
        !           250: 
        !           251: 
        !           252:  (function (lambda () ...)), (function (nlambda () ...)) and
        !           253:  (function (lexpr () ...))  are all supported.
        !           254: 
        !           255: 
        !           256: 
        !           257: From jkf Wed May 12 08:15:37 1982
        !           258: To: local-lisp
        !           259: Subject: Lisp Opus 38.17
        !           260: Status: RO
        !           261: 
        !           262:  ... has a minor bug fix:  The port returned by 'fileopen' will now print
        !           263: correctly.
        !           264: 
        !           265: 
        !           266: 
        !           267: From jkf  Tue May 25 06:18:04 1982
        !           268: Date: 25-May-82 06:17:51-PDT (Tue)
        !           269: From: jkf
        !           270: Subject: opus 38.18
        !           271: Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue)
        !           272: To: local-lisp
        !           273: Status: RO
        !           274: 
        !           275:   The msg macro will now evaluate all atom arguments except the ones 
        !           276: for carriage control (N B).  Thus if you used (msg foo) you should
        !           277: now use (msg "foo").
        !           278: 
        !           279: 
        !           280: 
        !           281: From jkf Thu May 27 08:29:29 1982
        !           282: To: local-lisp
        !           283: Subject: liszt 8.08
        !           284: Status: RO
        !           285: 
        !           286:  Fixes a bug in the code which converts generic arithmetic to fixnum only
        !           287: arithmetic.   Liszt was converting from generic to fixnum operators based on
        !           288: the first argument only due to a typo in the code.
        !           289: 
        !           290:  
        !           291: 
        !           292: 
        !           293: From jkf Wed Jun  9 07:25:19 1982
        !           294: To: local-lisp
        !           295: Subject: lisp Opus 38.20
        !           296: Status: RO
        !           297: 
        !           298:   There is now a character macro for reading hexadecimal.
        !           299:   #x1f = #X1f = #X1F = 31
        !           300:   #x-1f = -31
        !           301:   
        !           302: 
        !           303: 
        !           304: From jkf Thu Jun 17 15:42:54 1982
        !           305: To: local-lisp
        !           306: Subject: Lisp Opus 38.21
        !           307: Status: RO
        !           308: 
        !           309:   Has two routines for interfacing with termcap.  These routines were
        !           310: written by morris djavaher and are meant to be called by lisp programs
        !           311: which have yet to be installed.
        !           312: 
        !           313: 
        !           314: 
        !           315: 
        !           316: From jkf  Tue Jun 22 09:09:25 1982
        !           317: Date: 22-Jun-82 09:09:13-PDT (Tue)
        !           318: From: jkf
        !           319: Subject: opus 38.22
        !           320: Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue)
        !           321: To: local-lisp
        !           322: Status: RO
        !           323: 
        !           324:   setq with no arguments will now return nil.
        !           325:   
        !           326: 
        !           327: 
        !           328: From jkf  Wed Jun 30 19:05:54 1982
        !           329: Date: 30-Jun-82 19:05:32-PDT (Wed)
        !           330: From: jkf (John Foderaro)
        !           331: Subject: liszt 8.09
        !           332: Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed)
        !           333: To: local-lisp
        !           334: Status: RO
        !           335: 
        !           336:   liszt will now look in 12 places for an init file when it starts up.
        !           337: It will load in the first one it comes to only.
        !           338: The files it looks for are:
        !           339: 
        !           340:   { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , }
        !           341: 
        !           342:  
        !           343: 
        !           344: 
        !           345: From jkf  Tue Sep 14 08:53:03 1982
        !           346: Date: 14-Sep-82 08:52:44-PDT (Tue)
        !           347: From: jkf (John Foderaro)
        !           348: Subject: lisp opus 38.26
        !           349: Message-Id: <[email protected]>
        !           350: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999;
        !           351:        14-Sep-82 08:53:03-PDT (Tue)
        !           352: To: local-lisp
        !           353: Status: RO
        !           354: 
        !           355:   Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx.  Now it reads
        !           356: them (and other similar symbols) correctly.
        !           357: 
        !           358: 
        !           359: 
        !           360: 
        !           361: From jkf  Sat Oct  2 15:15:48 1982
        !           362: Date: 2-Oct-82 15:15:32-PDT (Sat)
        !           363: From: jkf (John Foderaro)
        !           364: Subject: lisp opus 38.27
        !           365: Message-Id: <[email protected]>
        !           366: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796;
        !           367:        2-Oct-82 15:15:48-PDT (Sat)
        !           368: To: local-lisp
        !           369: Status: RO
        !           370: 
        !           371:   If you set the variable top-level-print to a non nil value, then that
        !           372: value will be used by the top-level to print out the result of the
        !           373: evaluation.  This has effect in break loops too.
        !           374:   For example, if you want the pretty printer to print out the top level
        !           375: values, type  (setq top-level-print 'pp-form).
        !           376: 
        !           377: 
        !           378:   
        !           379: 
        !           380: 
        !           381: From jkf  Sun Oct  3 19:28:45 1982
        !           382: Date: 3-Oct-82 19:28:29-PDT (Sun)
        !           383: From: jkf (John Foderaro)
        !           384: Subject: lisp opus 38.28
        !           385: Message-Id: <[email protected]>
        !           386: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829;
        !           387:        3-Oct-82 19:28:45-PDT (Sun)
        !           388: To: local-lisp
        !           389: Status: RO
        !           390: 
        !           391:  A modification has been made to the load function.
        !           392:    Normally if you type (load 'x), the load function will first try to fasl
        !           393: the file x.o and failing that it will try to load x.l
        !           394:    If you (setq load-most-recent t),  and if x.l and x.o both exist, then
        !           395: load will fasl or load the most recently modified file.
        !           396:    The load-most-recent flag only has an effect if you type the filename
        !           397: without a trailing .l or .o.
        !           398: 
        !           399: 
        !           400: 
        !           401: 
        !           402: From jkf  Tue Oct  5 21:01:55 1982
        !           403: Date: 5-Oct-82 21:01:33-PDT (Tue)
        !           404: From: jkf (John Foderaro)
        !           405: Subject: liszt 8.12, lisp 38.29
        !           406: Message-Id: <[email protected]>
        !           407: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358;
        !           408:        5-Oct-82 21:01:55-PDT (Tue)
        !           409: To: local-lisp
        !           410: Status: RO
        !           411: 
        !           412:   Liszt will now check that you are passing the correct number of arguments
        !           413: to functions.   As a result, some files which have compiled without
        !           414: complaint in the past may compile now with warnings or errors.  In this
        !           415: note, I'll explain what the compiler knows, what it looks for in your
        !           416: program, and how you can help the compiler understand your program.
        !           417: 
        !           418:   For each function, liszt either knows nothing about the the number of
        !           419: arguments to a function, or it knows the minimum number of arguments, or the
        !           420: maximum number of arguments, or both the minimum and maximum number of
        !           421: arguments.   This information comes about in one of three ways:
        !           422:   1) it is known when liszt starts (by virtue of a value stored under the
        !           423:      fcn-info indicator on a function's property list)
        !           424:   2) it is declared by the user, either via (declare (*arginfo ...))
        !           425:      or (declare (*args ...)) [see below]
        !           426:   3) it is determined when a (lambda) function is compiled.
        !           427:      When a lambda is compiled, the compiler can easily figure out the
        !           428:        minimum and maximum number of arguments.
        !           429:      When an nlambda or lexpr function is compiled, the compiler doesn't
        !           430:      make a guess as to how many arguments are expected.  The user should
        !           431:      use the (declare (*args ...)) form to tell the compiler how many
        !           432:      arguments are expected.
        !           433:      For lexpr's generated via 'defun' using &optional and &rest keywords,
        !           434:      the correct declaration is generated automatically.
        !           435: Once liszt determines the number of arguments to a function, it uses that
        !           436: information to check that the function is called with the correct number of
        !           437: arguments.  It does not check calls to the function that occured before it
        !           438: determined the correct number of arguments.  [This backward checking will
        !           439: be added sometime in the future.]
        !           440: 
        !           441:   If liszt finds that a function is called with the wrong number of
        !           442: arguments, it prints an informative message.  That message is a error if the
        !           443: function being called is one which is open coded by the compiler. The
        !           444: message is a warning otherwise.  The reason for the distinction is that
        !           445: you are free to redefine functions not open coded by the compiler. If the
        !           446: number of arguments is not correct, it may just be that the compiler's
        !           447: database and your code are refering to two different functions.
        !           448: If you redefine system functions, you should use the
        !           449: (declare (*arginfo ...)) form to let the compiler know about the number
        !           450: of arguments expected by your version of the functions.
        !           451: 
        !           452:   You can declare the number of arguments to functions using this form
        !           453: 
        !           454: (declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...))
        !           455:   where each min or max is either a fixnum or nil (meaning "I don't know")
        !           456:   
        !           457: for example, here are some `correct' declarations:
        !           458: 
        !           459: (declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil)))
        !           460:   
        !           461:  explanation:
        !           462:    (read 0 2) means that the function read expects between 0 and 2
        !           463:        arguments (inclusive).
        !           464:    (cons 2 2) means that cons expects 2 arguments.
        !           465:    (boole 3 nil) means that boole expects at least 3 arguments.
        !           466:    (append nil nil) means that append expects any number of arguments,
        !           467:       this is equivalent to (append 0 nil).
        !           468:       
        !           469: 
        !           470: The *arginfo declaration is usually made at the top level of a file.
        !           471: 
        !           472: To declare the argument characteristics of the current function being
        !           473: compiled use the '*args' declaration. It looks somewhat like the
        !           474: *arginfo declaration.
        !           475: 
        !           476: It is best explained with examples
        !           477: 
        !           478: (def read
        !           479:    (lexpr (n)
        !           480:        (declare (*args 0 2))
        !           481:        ... code for read
        !           482:        ))
        !           483: 
        !           484: (def process
        !           485:   (nlambda (x)
        !           486:       (declare (*args 1 3))
        !           487:       ... code for process
        !           488:       ))
        !           489: 
        !           490: Note: the *args declaration is not needed for lambda's.
        !           491: 
        !           492: 
        !           493: 
        !           494:   If you get an error or warning which you believe is incorrect, it is
        !           495: probably due to an incorrect database entry.  Please let me know and I will
        !           496: fix it immediately.   I expect that there will be quite a few of these
        !           497: errors because much of the database was built by hand.
        !           498: 
        !           499: 
        !           500:      
        !           501: 
        !           502: 
        !           503: 
        !           504: From jkf  Fri Oct  8 12:55:45 1982
        !           505: Date: 8-Oct-82 12:55:31-PDT (Fri)
        !           506: From: jkf (John Foderaro)
        !           507: Subject: lisp 38.30, liszt 8.13
        !           508: Message-Id: <[email protected]>
        !           509: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140;
        !           510:        8-Oct-82 12:55:45-PDT (Fri)
        !           511: To: local-lisp
        !           512: Status: RO
        !           513: 
        !           514: There are now three new functions for dealing with processes:
        !           515:   *process
        !           516:   *process-send
        !           517:   *process-receive
        !           518: 
        !           519:  These functions are designed to replace the 'process' function, which, due
        !           520: to its nlambda'ness, was difficult to use.  All of the above functions
        !           521: are lambda's or lexpr's.
        !           522: 
        !           523:   See chapter 6 of the manual (its on-line) for the details of these
        !           524: functions.  This is a quick summary:
        !           525: 
        !           526:   (*process-send 'st_command)
        !           527:   tells the shell to run the command st_command concurrently, and returns
        !           528:   a write-only port.  Characters written to this port will appear at
        !           529:   the standard input of st_command.
        !           530:   example:
        !           531:      (setq p (*process-send "mail jkf"))
        !           532:      (print 'HiThere p)
        !           533:      (close p)
        !           534: 
        !           535:      
        !           536:   (*process-receive 'st_command)
        !           537:   tells the shell to run st_command concurrently, and returns a
        !           538:   read-only port.  Characters written to the standard output by
        !           539:   st_command will be available by reading from the given port.
        !           540:   Characters written on the standard error by st_command will
        !           541:   appear on lisp's the standard error (the terminal most likely).
        !           542:   example:
        !           543:     ; to see if foo is logged in:
        !           544:     (setq p (*process-receive "u"))
        !           545:     (do ((user (read p '**eof**) (read p '**eof**)))
        !           546:         ((eq '**eof** user) (print 'Not-Logged-In))
        !           547:        (cond ((eq 'foo user) (print 'Is-Logged-In))))
        !           548:     (close p)
        !           549: 
        !           550: 
        !           551:   (*process 'st_command ['g_readp ['g_writep]])
        !           552:   this is the general function which process, *process-send and
        !           553:   *process-receive call.  If called with one argument it
        !           554:   starts the new process and waits for it to end, e.g:
        !           555:   (*process (concat "vi " filename))
        !           556:   In this case *process return the exit code of the process.
        !           557: 
        !           558:   The g_readp and g_writep arguments, if given, tell *process to
        !           559:   run the process concurrently.  If g_read is non nil then
        !           560:   *process will return a port just like *process-receive.
        !           561:   If g_writep is non-nil, then *process will set up a pipe like
        !           562:   *process-send.
        !           563:   *process will return a list of the form
        !           564:     (readport writeport process-id)
        !           565:     where readport and writeport will only be a port if g_readp
        !           566:     or g_writep are non nil.
        !           567: 
        !           568: 
        !           569:  A little know fact about processes is that  a process, once started,
        !           570: cannot die and disappear until its parent asks about its status.
        !           571: Take the mail example given above:
        !           572:      (setq p (*process-send "mail jkf"))
        !           573:      (print 'HiThere p)
        !           574:      (close p)
        !           575: after the mail process finishes it work, it will attempt to die, returning
        !           576: an integer called the 'exit status'.  However until the lisp program
        !           577: asks about its status the mail process will remain in existence
        !           578: in a Zombie state, somewhere between life and death. ps will show this:
        !           579: 
        !           580:   PID TT STAT  TIME COMMAND
        !           581:  3876 p0 Z     0:01 <exiting>
        !           582: 
        !           583: A user is only allowed a small number of processes, so if you continue
        !           584: to generate processes and leave them around as Zombies, you will eventually
        !           585: run out of processes.  The way to let the Zombie die is to call
        !           586: the wait function, e.g.
        !           587:     -> (wait)
        !           588:     (3876 . 0)
        !           589:     -> 
        !           590: this says that process 3876 died with exit status 0.
        !           591: 
        !           592: Also, when you exit lisp the shell will clean up the Zombies.
        !           593: 
        !           594: If you start a  process with (*process "vi foo") then lisp will wait
        !           595: for it to complete before continuing, so you don't have to worry about
        !           596: Zombies.  You only have to worry if you run a process concurrently,
        !           597: such as when you use *process-send or *process-receive.
        !           598: 
        !           599:       
        !           600:        
        !           601:       
        !           602: 
        !           603: 
        !           604: 
        !           605: From jkf  Tue Oct 12 10:44:22 1982
        !           606: Date: 12-Oct-82 10:43:52-PDT (Tue)
        !           607: From: jkf (John Foderaro)
        !           608: Subject: lisp opus 38.31
        !           609: Message-Id: <[email protected]>
        !           610: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
        !           611:        id A29800; 12-Oct-82 10:44:22-PDT (Tue)
        !           612: To: local-lisp
        !           613: Status: RO
        !           614: 
        !           615:   new function:  (time-string ['x_time])
        !           616:     if given no arguments, it returns the current time as a string.
        !           617: 
        !           618:     if given an argument, x_time, then it converts that argument to
        !           619:       a time string and returns that string.
        !           620:       The argument should represent the number of seconds since
        !           621:       Jan 1, 1970 (GMT).
        !           622: 
        !           623:   note that this makes (status ctime) obsolete.
        !           624:  
        !           625: 
        !           626: 
        !           627: From jkf  Tue Oct 12 14:35:26 1982
        !           628: Date: 12-Oct-82 14:34:10-PDT (Tue)
        !           629: From: jkf (John Foderaro)
        !           630: Subject: also in opus 38.31
        !           631: Message-Id: <[email protected]>
        !           632: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
        !           633:        id A05086; 12-Oct-82 14:35:26-PDT (Tue)
        !           634: To: local-lisp
        !           635: Status: RO
        !           636: 
        !           637:   If top-level-read is set to a non nil value, then the lisp
        !           638: top level will funcall it to read a form for evaluation.
        !           639: It will be funcalled with two arguments, a port and an eof marker.
        !           640: top-level-read will be used in break levels too.
        !           641:   Be very careful when setting top-level-read because if you set it
        !           642: to an illegal value, there is no way to correct it.
        !           643: 
        !           644: 
        !           645: 
        !           646: 
        !           647: 
        !           648: From jkf  Tue Oct 19 18:54:18 1982
        !           649: Date: 19-Oct-82 18:54:02-PDT (Tue)
        !           650: From: jkf (John Foderaro)
        !           651: Subject: lisp tags
        !           652: Message-Id: <[email protected]>
        !           653: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !           654:        id A00195; 19-Oct-82 18:54:18-PDT (Tue)
        !           655: To: franz-friends
        !           656: Status: RO
        !           657: 
        !           658:   We also use vi style tags so emacs users and vi users can share the same
        !           659: tags file.  Rather than modify ctags, we use this shell script:
        !           660: 
        !           661: #!/bin/csh 
        !           662: # make a tags file for lisp source files.
        !           663: # use:
        !           664: #      lisptags foo.l bar.l baz.l ... bof.l
        !           665: # generate the file 'tags'
        !           666: #
        !           667: awk -f /usr/local/lib/ltags $* | sort > tags
        !           668: 
        !           669: 
        !           670: where the file /usr/local/lib/ltags is
        !           671: 
        !           672: /^\(DEF/       { print $2 "    " FILENAME "    ?^" $0 "$?" }
        !           673: /^\(def/       { print $2 "    " FILENAME "    ?^" $0 "$?" }
        !           674: 
        !           675: 
        !           676: 
        !           677: From jkf  Tue Oct 19 22:50:40 1982
        !           678: Date: 19-Oct-82 22:50:29-PDT (Tue)
        !           679: From: jkf (John Foderaro)
        !           680: Subject: Lisp Opus 38.32, Liszt 8.14
        !           681: Message-Id: <[email protected]>
        !           682: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !           683:        id A03968; 19-Oct-82 22:50:40-PDT (Tue)
        !           684: To: local-lisp
        !           685: Status: RO
        !           686: 
        !           687: 
        !           688: Topic 1:
        !           689:     liszt can now autoload macros.   If liszt encounters a symbol without
        !           690:     a function definition but with a macro-autoload indicator on the
        !           691:     property list, then the value of the indicator is a file to load which
        !           692:     should define the macro.
        !           693: 
        !           694:     The interpreter's undefined function handler will also look for
        !           695:     macro-autoload properties, thus you needn't give a symbol both an
        !           696:     autoload and a macro-autoload property.
        !           697: 
        !           698:     The default lisp contains macro-autoload properties for the macros
        !           699:     defstruct, loop and defflavor.
        !           700: 
        !           701: Topic 2:
        !           702:     It is now possible to define 'compiler only macros' or cmacros.
        !           703:     A cmacro acts like a normal macro, but will only be used by the
        !           704:     compiler.   A cmacro is stored on the property list of a
        !           705:     symbol under the indicator 'cmacro'.    Thus a function can
        !           706:     have a normal definition and a cmacro definition.
        !           707:     The macro 'defcmacro' has a syntax identical to 'defmacro' and
        !           708:     creates cmacros instead of macros.
        !           709:     For an example of the use of cmacros, see the definitions
        !           710:     of nthcdr and nth in /usr/lib/lisp/common2.l
        !           711: 
        !           712:  Topic 3:
        !           713:     If the form (foo ...) is macro expanded and the result also begins
        !           714:     with the symbol foo, then liszt will stop macro expanding (previously
        !           715:     it got into an infinite loop).
        !           716:     
        !           717:  Topic 4:
        !           718:     The function nth has been added to Franz.
        !           719:     (nth 'x_index 'l_list)
        !           720:     returns the nth element of l_list, where the car of the list
        !           721:     is accessed with (nth 0 'l_list)
        !           722: 
        !           723:     The macros (push 'g_value 'g_stack), and
        !           724:               (pop 'g_stack ['g_into])
        !           725:     have been added to franz.
        !           726:     typical uses
        !           727:       (setq foo nil)
        !           728:       (push 'xxx foo)
        !           729:       (push 123 foo)
        !           730:       now foo = (123 xxx)
        !           731:       (pop foo) returns 123
        !           732:       now foo = (xxx)
        !           733:       (pop foo yyy) returns xxx and sets yyy to xxx
        !           734: 
        !           735:       
        !           736:  Topic 5:
        !           737:     The version of Flavors written at Mit for Franz have been transported
        !           738:     here.  Flavors is a system for doing object oriented programming in
        !           739:     lisp.  The documentation for flavors in the Lisp Machine manual
        !           740:     from Mit.  Since Lisp Machine manuals are rather scarce around here,
        !           741:     perhaps we can find someone to make copies of the flavor chapter for
        !           742:     those interested in it.  There is a description of the unique
        !           743:     features of the Franz Flavors in /usr/lib/lisp/flavors.usage.
        !           744:     As mentioned above, the flavors code will be autoloaded
        !           745:     when you call 'defflavor' for the first time.
        !           746:     Our local flavors expert is Eric Cooper (r.ecc).
        !           747:  
        !           748:     
        !           749:     
        !           750:     
        !           751: 
        !           752: 
        !           753: 
        !           754: From jkf  Fri Oct 22 15:46:51 1982
        !           755: Date: 22-Oct-82 15:46:32-PDT (Fri)
        !           756: From: jkf (John Foderaro)
        !           757: Subject: lisp opus 38.34
        !           758: Message-Id: <[email protected]>
        !           759: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !           760:        id A05610; 22-Oct-82 15:46:51-PDT (Fri)
        !           761: To: local-lisp
        !           762: Status: RO
        !           763: 
        !           764: 
        !           765:   Franz lisp now has a form of closure called an fclosure.  A fclosure is a
        !           766: compromise between a funarg and the type of functional object that we
        !           767: currently have in Franz. In this short note, I'll explain through examples
        !           768: what fclosures are and where you might use them, and finally describe the new
        !           769: functions.  The fclosure system was designed to be compatible with the Lisp
        !           770: Machine closures, so you may want to look at a Lisp Machine manual for more
        !           771: information.  fclosure are related to closures in this way:
        !           772:    (fclosure '(a b) 'foo) <==> (let ((a a) (b b)) (closure '(a b) 'foo))
        !           773: 
        !           774: A example of the use of fclosures:
        !           775: 
        !           776: ->(setq counter 0)
        !           777: 0
        !           778: ->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
        !           779: fclosure[1]
        !           780: 
        !           781: The function 'fclosure' creates a new type of object called a fclosure.
        !           782: A fclosure object contains a functional object, and a set of symbols and
        !           783: values for the symbols.  In the above example, the fclosure functional
        !           784: object is (lambda (val) (setq counter (+ val counter)))
        !           785: and the set of symbols and values just contains the symbol 'counter' and
        !           786: zero, the value of counter when the fclosure was created.
        !           787: 
        !           788: When  a fclosure is funcall'ed:
        !           789:   1) the lisp system lambda binds the symbols in the fclosure to their
        !           790:      values in the fclosure.
        !           791:   2) it continues the funcall on the functional object of the fclosure
        !           792:   3) finally it un-lambda binds the symbols in the fclosure and at the
        !           793:      same time stores the current values of the symbols in the fclosure.
        !           794: 
        !           795: To see what that means, let us continue the example:
        !           796: -> (funcall x 32)
        !           797: 32
        !           798: -> (funcall x 21)
        !           799: 53
        !           800: 
        !           801: Notice that the fclosure is saving the value of the symbol 'counter'.
        !           802: Each time a fclosure is created, new space is allocated for saving
        !           803: the values of the symbols.
        !           804: If we executed the same fclosure function:
        !           805: ->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
        !           806: fclosure[1]
        !           807: 
        !           808: We now have two independent counters:
        !           809: -> (funcall y 2)
        !           810: 2
        !           811: -> (funcall y 12)
        !           812: 14
        !           813: -> (funcall x 3)
        !           814: 56
        !           815: 
        !           816: To summarize:
        !           817: 
        !           818: (fclosure 'l_vars 'g_funcobj)
        !           819:  l_vars is a list of symbols (not containing nil)
        !           820:  g_funcobj is lambda expression or a symbol or another fclosure
        !           821: 
        !           822:   examples: (fclosure '(foo bar baz) 'plus)
        !           823:             (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #'
        !           824:                        which will make the compiler compile the
        !           825:                        lambda expression.
        !           826: 
        !           827: 
        !           828: There are time when you want to share variables between fclosures.
        !           829: This can be done if the fclosures are created at the time times using
        !           830: fclosure-list:
        !           831: 
        !           832: (fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...])
        !           833:   This creates a list of closures such that if a symbol appears in
        !           834:   l_varsN and l_varsM then its value will be shared between the
        !           835:   closures associated with g_funcobjN and g_funcobjM.
        !           836: 
        !           837:   example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y))
        !           838:                                     '(c a) '(lambda () (setq c a))))
        !           839:            (fclosure[4] fclosure[7])
        !           840:           -> (funcall (car x) 123)   ; set the value of a in the 1st fclosure
        !           841:           123
        !           842:           -> (funcall (cadr x))     ; read the same value in the 2nd fclosure
        !           843:           123
        !           844: 
        !           845: 
        !           846: Other fclosure functions:
        !           847: 
        !           848: (fclosure-alist 'c_fclosure)
        !           849:   returns an assoc list giving the symbols and values in the fclosure
        !           850: 
        !           851: (fclosurep 'g_obj)
        !           852:   returns t iff g_obj is a fclosure
        !           853: 
        !           854: (fclosure-function 'c_fclosure)
        !           855:   returns the functional object of the fclosure
        !           856: 
        !           857: 
        !           858: 
        !           859: Note: If a throw (or error) occurs during the evaluation of a fclosure,
        !           860:  which passes control out of the fclosure, then current values of the
        !           861:  symbols will not be stored.   This may be a bug.  We could set up
        !           862:  an unwind-protect, but it would then take longer to funcall
        !           863:  a fclosure.  If you think an unwind protect is important, let me know.
        !           864: 
        !           865: Note 2: you can also 'apply' a fclosure.
        !           866: 
        !           867: 
        !           868: 
        !           869:   
        !           870: 
        !           871: 
        !           872: From jkf  Sat Oct 23 08:58:07 1982
        !           873: Date: 23-Oct-82 08:57:53-PDT (Sat)
        !           874: From: jkf (John Foderaro)
        !           875: Subject: more on closures
        !           876: Message-Id: <[email protected]>
        !           877: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !           878:        id A21572; 23-Oct-82 08:58:07-PDT (Sat)
        !           879: To: local-lisp
        !           880: Status: RO
        !           881: 
        !           882:   I sent the maryland people the flavors.usage file from mit so that they
        !           883: could compare their implementation with mit's.   What follows is their
        !           884: analysis.   Some of the differences between the two versions is due to
        !           885: different schemes for getting around the fact that franz didn't have a form
        !           886: of closure.   RZ has indicated that now that franz has fclosures, it may be
        !           887: possible to use more of the 'official' lisp machine flavor code.  fclosures
        !           888: will probably affect the maryland implementation too:
        !           889: Date:     22 Oct 82 15:39:18 EDT  (Fri)
        !           890: From:     Liz Allen <liz.umcp-cs@UDel-Relay>
        !           891: Subject:  flavors
        !           892: To:       jkf at Ucb-C70
        !           893: Via:  UMCP-CS; 23 Oct 82 9:09-EDT
        !           894: 
        !           895: Wow, implementing closure in one day is amazing.  We had thought
        !           896: about writing some kind of closure...  We've been discussing how
        !           897: having closures would affect our code.  It might make it easier to
        !           898: read and modify, but it might be less efficient.  Can you tell us
        !           899: how your implementation works and what it looks like to a user?
        !           900: 
        !           901: About the MIT implementation.  Ours is probably better in a couple
        !           902: of respects but probably loses a couple of places, too.  Pros:
        !           903: 
        !           904:        1.  With ours, there is no need to discard instances when
        !           905:        redefining a flavor.  The only time this would be necessary
        !           906:        is if the instance variables change which rarely happens
        !           907:        since methods change much more often than the instance
        !           908:        variables.  Without a structure editor, you tend to reload the
        !           909:        file containing flavors in order to change a method.
        !           910: 
        !           911:        2.  We can compile files with flavors (he didn't say if you
        !           912:        can compile MIT's Franz flavors) and when they are compiled
        !           913:        they run *fast*.  Most of the overhead occurs at combine
        !           914:        time and compiled flavors shouldn't have to be recombined.
        !           915: 
        !           916:        3.  We use hunks to store instance variables (actually, an
        !           917:        instance is a hunk whose cxr 0 is the name of the flavor and
        !           918:        whose cxr n (> 0) are the values of instance variables).  We
        !           919:        pay a price at combine time since instance variable references
        !           920:        in method code are replaced with cxr and rplacx calls (but MIT
        !           921:        pays the same price in putting hash calls in the methods), but
        !           922:        we win over MIT since the cxr calls are much faster than the
        !           923:        hash table calls.  We do have to have "ghost" methods which
        !           924:        are copies of methods containing different cxr calls when the
        !           925:        referenced variables of a method don't align in flavors
        !           926:        which inherit the method.  This, however, happens only
        !           927:        rarely.
        !           928: 
        !           929:        4.  We handle getting and setting instance variables better
        !           930:        than the MIT implementation -- we don't need to send a message
        !           931:        and the syntax is much better.  We recently added the
        !           932:        functions << and >> which get and set instance variables, eg:
        !           933: 
        !           934:                (<< foo 'instance-var)
        !           935:        and
        !           936:                (>> foo 'instance-var 'value)
        !           937: 
        !           938:        where foo is a flavor instance.
        !           939: 
        !           940:        5.  Our describe function has a hook which (if the variable
        !           941:        *debugging-flavors* is set to non-nil) allows the user to
        !           942:        follow pointers to any instances referenced in the describe.
        !           943:        This is done by assigning to a variable (made from its unique
        !           944:        id) the value of the instance.
        !           945: 
        !           946: Cons:
        !           947: 
        !           948:        1.  They implement more things from Lisp Machine flavors
        !           949:        (like wrappers/whoppers, init-keywords), but we really haven't
        !           950:        found the need for them.  We implement less closely to LM
        !           951:        flavors, but in a way that's better suited to Franz Lisp.
        !           952: 
        !           953:        2.  We didn't implement the method table as a hash table, but
        !           954:        there's no reason why we couldn't.
        !           955: 
        !           956:        3.  Things we don't have, but could easily implement include:
        !           957:        describe-method, defun-method/declare-flavor-instance-variables,
        !           958:        and storing flavor information in hunks instead of on the
        !           959:        property lists.
        !           960: 
        !           961:        4.  We don't handle method types like :and and :or.  We just
        !           962:        have primary/untyped methods and :before and :after daemons.
        !           963: 
        !           964: We have people reading our documentation.  After we get some feedback
        !           965: from them, we'll send the tape and docs to you.  That should be early
        !           966: next week.
        !           967: 
        !           968:                                -Liz Allen and Randy Trigg
        !           969: 
        !           970: 
        !           971: 
        !           972: 
        !           973: 
        !           974: 
        !           975: 
        !           976: From jkf  Mon Oct 25 12:56:59 1982
        !           977: Date: 25-Oct-82 12:55:44-PDT (Mon)
        !           978: From: jkf (John Foderaro)
        !           979: Subject: lisp Opus 38.35, liszt 8.15
        !           980: Message-Id: <[email protected]>
        !           981: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !           982:        id A17542; 25-Oct-82 12:56:59-PDT (Mon)
        !           983: To: local-lisp
        !           984: Status: RO
        !           985: 
        !           986: 
        !           987: New features:
        !           988:  1) tilde-expansion:  franz will now expand filenames which begin with ~
        !           989:        just like csh does.  It will only do the expansion if
        !           990:        the symbol tilde-expansion has a non-nil value.  The default
        !           991:        value for tilde-expansion is t.
        !           992:        These functions do tilde expansion: If I've left any out, let
        !           993:        me know:
        !           994:         load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir
        !           995:         sys:access, sys:unlink [these are new functions, see below]
        !           996: 
        !           997:  2) liszt will remove its temporary file if given a SIGTERM signal
        !           998:     (SIGTERM is sent by default when you give the kill command from the shell)
        !           999: 
        !          1000:  3) load will now print a helpful message if an read error occurs when it
        !          1001:     is reading a file.
        !          1002:     
        !          1003:  4) new functions:
        !          1004: 
        !          1005:      (lexpr-funcall 'function 'arg1 ... 'argn)
        !          1006:         This is a cross between funcall and apply.
        !          1007:        The last argument, argn, must be a list (possibly empty).
        !          1008:        The element of list argn are stacked and then the function is
        !          1009:        funcalled.
        !          1010:        For example:
        !          1011:        (lexpr-funcall 'list 'a 'b 'c '(d e f))
        !          1012:        is the same as
        !          1013:        (funcall 'list 'a 'b 'c 'd 'e 'f)
        !          1014:        
        !          1015:        Also
        !          1016:        (lexpr-funcall 'list 'a 'b 'c nil)
        !          1017:        is the same as
        !          1018:        (funcall 'list 'a 'b 'c)
        !          1019:        
        !          1020:      (tilde-expand 'st_filename)
        !          1021:      returns: symbol whose pname is the filename, with a leading tilde
        !          1022:             expanded.  if st_filename doesn't begin with a tilde, it
        !          1023:             just returns st_filename
        !          1024: 
        !          1025:      (username-to-dir 'st_name)
        !          1026:      returns: the home directory of the given user, if that user exists.
        !          1027:              Saves old information so doesn't have to keep searching
        !          1028:              the passwd file.
        !          1029: 
        !          1030:      Some low level system functions.  These are listed here for completeness.
        !          1031:      The perform a function from the unix library (see the unix manual
        !          1032:       for details).
        !          1033:      (sys:getpwnam 'st_username)
        !          1034:        return passwd file info.
        !          1035:      (sys:access 'st_file 'x_mode)
        !          1036:      (sys:unlink 'st_file)
        !          1037: 
        !          1038: 
        !          1039: Bug fixes:
        !          1040:   1) patom will handle prinlevel and prinlength correctly.
        !          1041:   2) it is now safe for an interpreted function to redefine itself.
        !          1042:   3) the information return by 'evalframe' about a funcall'ed function
        !          1043:      is now correct.
        !          1044: 
        !          1045:   
        !          1046:   
        !          1047: 
        !          1048: 
        !          1049: 
        !          1050: From jkf  Mon Oct 25 14:57:00 1982
        !          1051: Date: 25-Oct-82 14:56:25-PDT (Mon)
        !          1052: From: jkf (John Foderaro)
        !          1053: Subject: 'if' macro: request for comments
        !          1054: Message-Id: <[email protected]>
        !          1055: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1056:        id A21567; 25-Oct-82 14:57:00-PDT (Mon)
        !          1057: To: local-lisp
        !          1058: Status: RO
        !          1059: 
        !          1060:   Would anyone object if we added a macro called 'if' to the default franz
        !          1061: system?   'if' is a common name and I want to make sure that it doesn't
        !          1062: break any existing code before I add it.
        !          1063: 
        !          1064: Some background:
        !          1065:  At mit the 'if' macro is used all over the place.
        !          1066:  Its form is
        !          1067:        (if <predicate> <then-expr> [ <else-expr>])
        !          1068:        
        !          1069:  I've always felt that macros should make the code more readable and
        !          1070:  that the 'if' macro makes code more obscure because it isn't easy
        !          1071:  to tell in complicated 'if' expressions where the <then-expr>
        !          1072:  and <else-expr>'s begin.  Also, there is no provision for
        !          1073:  an 'elseif' expression.
        !          1074: 
        !          1075:  I wrote a macro called 'If' which uses keywords to separate clauses.
        !          1076:  (If <pred> 
        !          1077:     then <then-expr> 
        !          1078:   [elseif <pred> then <then-expr>]* 
        !          1079:   [else <else-expr>])
        !          1080: 
        !          1081:  These two macros are not incompatible.  one macro could do the job
        !          1082:  of both.  There is an ambigous case:
        !          1083:        (if p then x) could be (cond (p then) (t x))
        !          1084:                        or (cond (p x))
        !          1085:  but it isn't likely that 'if' macro users would write something like
        !          1086:  that.
        !          1087: 
        !          1088: Thus I propose that we add a macro, if, which act's like 'If' if
        !          1089: its second arg is 'then' or like 'if' it the second arg is not 'then'
        !          1090: and there are two or three arguments.  Other cases would cause
        !          1091: an error.
        !          1092: 
        !          1093: 
        !          1094:        
        !          1095: 
        !          1096: 
        !          1097: From jkf  Mon Oct 25 22:37:24 1982
        !          1098: Date: 25-Oct-82 22:37:09-PDT (Mon)
        !          1099: From: jkf (John Foderaro)
        !          1100: Subject: opus 38.36
        !          1101: Message-Id: <[email protected]>
        !          1102: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1103:        id A01666; 25-Oct-82 22:37:24-PDT (Mon)
        !          1104: To: local-lisp
        !          1105: Status: RO
        !          1106: 
        !          1107:   I've added the 'if' macro to franz.  If you have any objections, it is still
        !          1108: not too late to voice them.
        !          1109:   I've also defined 'If' to be the same as 'if'.
        !          1110: 
        !          1111:   As I mentioned in my earlier request for comments, the 'if' macro is a
        !          1112: cross between the mit version and a locally written version using keywords.
        !          1113: The following documentation describes the various forms.
        !          1114: As you know, you can test out the 'if' macro by using apply. for example:
        !          1115: 
        !          1116: => (apply 'if '(if a then b c  elseif d thenret else e))
        !          1117: (cond (a b c) (d) (t e))
        !          1118: 
        !          1119: 
        !          1120: ;
        !          1121: ;  This macro is compatible with both the crufty mit-version and
        !          1122: ; the keyword version at ucb.
        !          1123: ;
        !          1124: ;  simple summary:
        !          1125: ;   non-keyword use:
        !          1126: ;      (if a b) ==> (cond (a b))
        !          1127: ;      (if a b c d e ...) ==> (cond (a b) (t c d e ...))
        !          1128: ;   with keywords:
        !          1129: ;      (if a then b) ==> (cond (a b))
        !          1130: ;      (if a thenret) ==> (cond (a))
        !          1131: ;      (if a then b c d e) ==> (cond (a b c d e))
        !          1132: ;      (if a then b c  else d) ==> (cond (a b c) (t d))
        !          1133: ;      (if a then b c  elseif d  thenret  else g)
        !          1134: ;              ==> (cond (a b c) (d) (t g))
        !          1135: ;
        !          1136: ;   
        !          1137: ;
        !          1138: ;
        !          1139: ; In the syntax description below,
        !          1140: ;    optional parts are surrounded by [ and ],
        !          1141: ;    + means one or more instances.
        !          1142: ;    | means 'or'
        !          1143: ;    <expr> is an lisp expression which isn't a keyword
        !          1144: ;       The keywords are:  then, thenret, else, elseif.
        !          1145: ;    <pred> is also a lisp expression which isn't a keyword.
        !          1146: ; 
        !          1147: ; <if-stmt> ::=  <simple-if-stmt>
        !          1148: ;             | <keyword-if-stmt>
        !          1149: ; 
        !          1150: ; <simple-if-stmt> ::=  (if <pred> <expr>)
        !          1151: ;                    | (if <pred> <expr> <expr>)
        !          1152: ; 
        !          1153: ; <keyword-if-stmt> ::= (if <pred> <then-clause> [ <else-clause> ] )
        !          1154: ; 
        !          1155: ; <then-clause> ::=  then <expr>+
        !          1156: ;                 | thenret
        !          1157: ; 
        !          1158: ; <else-clause> ::=  else <expr>+
        !          1159: ;                 | elseif <pred> <then-clause> [ <else-clause> ]
        !          1160: 
        !          1161: 
        !          1162: 
        !          1163:   
        !          1164: 
        !          1165: 
        !          1166: From jkf  Tue Oct 26 09:20:25 1982
        !          1167: Date: 26-Oct-82 09:20:04-PDT (Tue)
        !          1168: From: jkf (John Foderaro)
        !          1169: Subject: no more jkfmacs
        !          1170: Message-Id: <[email protected]>
        !          1171: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1172:        id A11552; 26-Oct-82 09:20:25-PDT (Tue)
        !          1173: To: local-lisp
        !          1174: Status: RO
        !          1175: 
        !          1176: 
        !          1177:   Since Franz now has the push, pop, if and msg macros, there is no
        !          1178: reason for jkfmacs to exist.  I've removed the code in jkfmacs and
        !          1179: replaced it with a warning message which will be printed if you load it.
        !          1180:   If you used the jkfmacs version of 'push' you will have to go through
        !          1181: your code and switch the order of arguments.  The Franz version is
        !          1182:        (push value stack)
        !          1183: Also, the unpush macro, defined in jkfmacs, no longer exists: just use
        !          1184: pop with one argument.
        !          1185: 
        !          1186: 
        !          1187: 
        !          1188: From jkf  Wed Oct 27 20:35:07 1982
        !          1189: Date: 27-Oct-82 20:34:25-PDT (Wed)
        !          1190: From: jkf (John Foderaro)
        !          1191: Subject: liszt 8.16
        !          1192: Message-Id: <[email protected]>
        !          1193: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1194:        id A27561; 27-Oct-82 20:35:07-PDT (Wed)
        !          1195: To: local-lisp
        !          1196: Status: RO
        !          1197: 
        !          1198:   Back on May 6, a modification to liszt was made which turned 'declare'
        !          1199: into a user callable function which provided information to the compiler.
        !          1200: The purpose of the change was to permit one to 'load' a file containing
        !          1201: declarations, instead of 'include'ing it.  It turns out that this was a bad
        !          1202: idea since if the compiler were to evaluate an interpreted function with
        !          1203: local declarations, it would assume that those local declarations were
        !          1204: describing the current file being compiled.
        !          1205:    Thus declare has it old meaning: it is a no-op unless the compiler is
        !          1206: compiling the form.  If one really wants to actively declare something,
        !          1207: we've added the function 'liszt-declare', which looks just like declare
        !          1208: but can be evaluated within the compiler.
        !          1209: 
        !          1210:   If you are confused by all this, don't worry.  There is very little chance
        !          1211: that it will affect you.
        !          1212: 
        !          1213: 
        !          1214: 
        !          1215: From jkf  Fri Oct 29 09:34:11 1982
        !          1216: Date: 29-Oct-82 09:33:59-PDT (Fri)
        !          1217: From: jkf (John Foderaro)
        !          1218: Subject: cmacros
        !          1219: Message-Id: <[email protected]>
        !          1220: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1221:        id A08411; 29-Oct-82 09:34:11-PDT (Fri)
        !          1222: To: local-lisp
        !          1223: Status: RO
        !          1224: 
        !          1225:   A week ago, Joe Faletti mentioned that one problem with cmacros is that if
        !          1226: you redefine a function, the cmacro property stays around and thus the
        !          1227: redefinition of the function isn't communicate to the compiler.
        !          1228:   He suggested that whenever a function is defined (via 'def' or when fasl'ed
        !          1229: in) any cmacro properties should be remprop'ed.   I've been trying to think
        !          1230: of an alternative to this, but I can't think of one.  Unless someone
        !          1231: has a better idea, I'll implement his suggestion.
        !          1232:   This means that if you want to define the function 'foo' and a cmacro for
        !          1233: 'foo', the cmacro definition must appear later in the file than 'foo's
        !          1234: definition.
        !          1235: 
        !          1236: 
        !          1237: 
        !          1238: 
        !          1239: From jkf  Fri Oct 29 10:11:36 1982
        !          1240: Date: 29-Oct-82 10:10:54-PDT (Fri)
        !          1241: From: jkf (John Foderaro)
        !          1242: Subject: LetS: An Expressional Loop Notation
        !          1243: Message-Id: <[email protected]>
        !          1244: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1245:        id A09176; 29-Oct-82 10:11:36-PDT (Fri)
        !          1246: To: local-lisp
        !          1247: Status: RO
        !          1248: 
        !          1249:   I've got a copy of a paper by Richard Waters (at mit) describing a system
        !          1250: for writing loops in lisp (and other languages).  Basically you describe the
        !          1251: loop in functional programming terms (similar to Backus's FP, or apl) and
        !          1252: the LetS package converts it into an iterative form for efficient execution
        !          1253: in lisp.
        !          1254:   We don't have the LetS code here to play with, and we probably won't be
        !          1255: able to get it for a while since our arpanet connection is hopelessly
        !          1256: clogged for anything but tiny messages.   However you might be interested in
        !          1257: stopping by my office and looking at the paper.
        !          1258: 
        !          1259: 
        !          1260: 
        !          1261: 
        !          1262: From jkf  Fri Oct 29 12:06:47 1982
        !          1263: Date: 29-Oct-82 12:06:08-PDT (Fri)
        !          1264: From: jkf (John Foderaro)
        !          1265: Subject: Re:  cmacros
        !          1266: Message-Id: <[email protected]>
        !          1267: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1268:        id A12141; 29-Oct-82 12:06:47-PDT (Fri)
        !          1269: To: baden, local-lisp
        !          1270: In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday)
        !          1271: Status: RO
        !          1272: 
        !          1273:   I could make it a 'Note'.  I would prefer not to make it a warning because
        !          1274: such redefinition is guaranteed to occur when the compiler compiles itself
        !          1275: and the lisp code part of the lisp system.
        !          1276: 
        !          1277: 
        !          1278: 
        !          1279: From fateman Sat Oct 30 09:17:49 1982
        !          1280: To: franz-friends
        !          1281: Subject: fugue # 2
        !          1282: Status: RO
        !          1283: 
        !          1284:                         FUGUE Notes
        !          1285: 
        !          1286:                An occasional publication of the
        !          1287:     Franz Lisp User Group under Unix and Eunice (FUGUE)
        !          1288: 
        !          1289:                   Number 2 (October, 1982)
        !          1290:                 edited by Richard J. Fateman
        !          1291:                   University of California
        !          1292:                      Berkeley CA 94720
        !          1293:                             USA
        !          1294:                       fateman@berkeley
        !          1295: 
        !          1296: 1.  Welcome!
        !          1297: 
        !          1298:      It seems  about time to publish  the  second  of  these
        !          1299: newsletters,  since  we  have  accumulated  a  number of new
        !          1300: items.  We would also like to relay to others such  informa-
        !          1301: tion as has been forwarded to us. The reports of projects at
        !          1302: Berkeley (and elsewhere) may strike sympathetic chords  with
        !          1303: other research.
        !          1304: 
        !          1305: 2.  New programs
        !          1306: 
        !          1307: 2.1.  OPS-5
        !          1308: 
        !          1309:      OPS-5 is a "production system" written by Charles Forgy
        !          1310: of  CMU.   It  appears to work just fine in Franz, and is in
        !          1311: wide use.  Interested persons may obtain copies of  documen-
        !          1312: tation and the program from Charles.Forgy@CMU-10A. ( Charles
        !          1313: Forgy, Computer Science Department, Carnegie-Mellon  Univer-
        !          1314: sity, Pittsburgh, PA  15213)
        !          1315: 
        !          1316: It is their policy to send it to anyone who wants it free of
        !          1317: charge.
        !          1318: 
        !          1319: 2.2.  GLISP
        !          1320: 
        !          1321:      GLISP is a system which provides interesting linguistic
        !          1322: features for generic operations and data abstraction.  Writ-
        !          1323: ten by Gordon Novak at Stanford University,  it  was  origi-
        !          1324: nally  developed for Interlisp, but has been ported to other
        !          1325: lisps, including Franz.
        !          1326: 
        !          1327: 2.3.  Flavors
        !          1328: 
        !          1329:      There are now two distinct implementations,  apparently
        !          1330: with  identical  functionally,  of "flavors" as appearing in
        !          1331: the MIT Lisp Machine software.  One is described in TR-1174,
        !          1332: ____________________
        !          1333: 9   UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
        !          1334: SRI Int'l, and Univ. of Calif.
        !          1335: 
        !          1336: 
        !          1337: 
        !          1338: 9
        !          1339: 
        !          1340: 
        !          1341: 
        !          1342: 
        !          1343: 
        !          1344: 
        !          1345: 
        !          1346: 
        !          1347: 
        !          1348: 
        !          1349: "Franz Flavors" by Richard J. Wood (Dept of C.S.,  Univ.  of
        !          1350: Maryland,  College  Pk, MD 20742).  The other was written by
        !          1351: Juan R. Loaiza of MIT, Laboratory for Computer Science.   We
        !          1352: have  a  copy  of  the  latter  on-line  here, and expect to
        !          1353: receive a copy of the Maryland one,  shortly.   Eric  Cooper
        !          1354: here at Berkeley is in charge of the flavors situation.
        !          1355: 
        !          1356:      There is an implementation of closures, mostly compati-
        !          1357: ble  with  the Lisp Machine specification, announced by John
        !          1358: Foderaro for Opus 38.33. The incompatibility is a result  of
        !          1359: what  we  perceive to be a high performance penalty for eso-
        !          1360: terica.
        !          1361: 
        !          1362: 2.4.  Database Interfaces
        !          1363: 
        !          1364:      Jim Larus at UCB has cooked up interfaces to  both  the
        !          1365: INGRES  relational  database  system,  and the simpler TROLL
        !          1366: database system.  These will be described in his forthcoming
        !          1367: MS report, along with the next item.
        !          1368: 
        !          1369: 2.5.  Cursor-control and Menus
        !          1370: 
        !          1371:      Larus has provided an implementation of screen  manage-
        !          1372: ment which uses the UNIX "curses" package for primitive win-
        !          1373: dow  management.   A  menu-based  interface  has  also  been
        !          1374: developed as part of this.
        !          1375: 
        !          1376: 2.6.  Vaxima and Algebraic Manipulation
        !          1377: 
        !          1378:      A new version of vaxima, the VAX version of the MACSYMA
        !          1379: algebraic  manipulation system, was released in July by UCB,
        !          1380: incorporating some bug fixes, improved programs, and a large
        !          1381: number  of  user-contributed subroutine libraries.  This was
        !          1382: made available to test-site licensees.   Unfortunately,  MIT
        !          1383: has  suspended  new  test-site  licensing since about April,
        !          1384: 1982.  We hope that MIT will be liberalizing  its  distribu-
        !          1385: tion policy to non-commercial sites.
        !          1386: 
        !          1387:      See the note below about MACSYMA being sold.
        !          1388: 
        !          1389:      As a counterpoint to this, UC Berkeley has  received  a
        !          1390: substantial grant from the System Development Foundation for
        !          1391: work on Mathematical Representation and Manipulation,  which
        !          1392: should  result in some more advanced systems for application
        !          1393: of  computers  to  symbolic  mathematics.   Recruiting   for
        !          1394: researchers,  staff,  and  students  is  underway  now,  and
        !          1395: interested persons should contact Richard Fateman.
        !          1396: 
        !          1397: 2.7.  VLSI Design Rule Checker
        !          1398: 
        !          1399:      Lyra, written in Lisp by Michael Arnold, is a retarget-
        !          1400: able,  hierarchical,  design rule checker for VLSI circuits.
        !          1401: Lyra features a rule  compiler  (also  written  in  Lisp  of
        !          1402: 
        !          1403: 
        !          1404: 
        !          1405: 
        !          1406: 
        !          1407: 
        !          1408: 
        !          1409: 
        !          1410: 
        !          1411: 
        !          1412: 
        !          1413: 
        !          1414: 
        !          1415: course!)  which translates symbolic design rule descriptions
        !          1416: to lisp code for checking the rules.  Lyra was used for  the
        !          1417: RISC  project.  It  is  currently  being used extensively at
        !          1418: Berkeley, and will be included in the  Fall-82  distribution
        !          1419: of  of the Berkeley CAD tools.  For more information contact
        !          1420: Michael Arnold or John Ousterhout at Berkeley.
        !          1421: 
        !          1422: 2.8.  Generic Arithmetic
        !          1423: 
        !          1424:      As a proposed extension to  Franz  arithmetic,  Richard
        !          1425: Fateman,  Keith  Sklower  and Scott Morrison, have written a
        !          1426: simple-minded  generic  arithmetic  package  which  includes
        !          1427: modules which can be loaded to support exact rational arith-
        !          1428: metic, software-simulated IEEE  extended  arithmetic,  arbi-
        !          1429: trary  precision floating point, complex, interval, and mul-
        !          1430: tivariate polynomial. Combinations of some of these are sup-
        !          1431: ported,  although  the  package is as yet incomplete in some
        !          1432: areas.  The IEEE arithmetic  simulation  is  written  in  C.
        !          1433: These  packages  are  probably  not in good enough shape for
        !          1434: casual use by others.
        !          1435: 
        !          1436: 
        !          1437: 3.  New features
        !          1438: 
        !          1439:      Various performance enhancements  and  bug  fixes  have
        !          1440: been  incorporated  in  versions of Franz (now on Opus 38.33
        !          1441: and the compiler, Liszt 8.14) These are mentioned  in  brief
        !          1442: here;  more  details  accompany  updates  of  the system and
        !          1443: manual included in the forthcoming Berkeley 4.2BSD UNIX dis-
        !          1444: tribution.
        !          1445: 
        !          1446: 3.1.  Franz
        !          1447: 
        !          1448:      We added a switch to cause the evaluator to save  macro
        !          1449: expansions so they need only be expanded once.
        !          1450: 
        !          1451:      We added vector and vector-immediate data types.
        !          1452: 
        !          1453:      We rewrote showstack and backtrace so they  are  easier
        !          1454: to use.
        !          1455: 
        !          1456:      We made the lisp to  foreign  function  interface  more
        !          1457: secure.  The system now allows foreign function to call lisp
        !          1458: functions.
        !          1459: 
        !          1460:      We added closures and support  flavors,  features  from
        !          1461: the Lisp Machine.
        !          1462: 
        !          1463: 3.2.  Liszt
        !          1464: 
        !          1465:      Liszt will check the  number  of  arguments  to  system
        !          1466: functions and user defined functions.
        !          1467: 9
        !          1468: 
        !          1469: 9
        !          1470: 
        !          1471: 
        !          1472: 
        !          1473: 
        !          1474: 
        !          1475: 
        !          1476: 
        !          1477: 
        !          1478: 
        !          1479: 
        !          1480:      Liszt supports local declarations.
        !          1481: 
        !          1482:      Liszt will  automatically  compile  lambda  expressions
        !          1483: headed by the function `function'.
        !          1484: 
        !          1485:      Liszt supports compiler-only macros and  will  autoload
        !          1486: macros if necessary.
        !          1487: 
        !          1488: 4.  MC68000
        !          1489: 
        !          1490:      Keith Sklower and Kevin Layer have been working on  the
        !          1491: MC68000  version  of  Franz  under the UNIX operating system
        !          1492: (using a DUAL System 83). While the current configuration is
        !          1493: a  swapping  system, the Lisp should be able to use the full
        !          1494: address space of the CPU. We expect to have this system run-
        !          1495: ning  on the UNIX 4.2 BSD SUN software, too. The base system
        !          1496: on the DUAL, including  the  interpreter,  reader,  bignums,
        !          1497: fasl, works; the compiler is being perfected.
        !          1498: 
        !          1499: 
        !          1500: 5.  Other Lisps
        !          1501: 
        !          1502:      We now have, in-house tried 4  (other)  VAX  UNIX  lisp
        !          1503: systems:  YLISP,  Interlisp,  PSL,  and VLISP.  We know that
        !          1504: Interlisp can run also on  VMS  using  the  Eunice  package.
        !          1505: Interested parties can contact David Dyer at USC-ISI.  There
        !          1506: is also a version of lisp which runs  on  VMS  only,  namely
        !          1507: NIL,  from  MIT, which appears to be undergoing limited dis-
        !          1508: tribution.  Two other lisps under development under UNIX are
        !          1509: Yale's  answer to NIL, namely "T", and Common Lisp, from CMU
        !          1510: and friends.
        !          1511: 
        !          1512:      Counting Franz, that makes  7 lisp systems for the  VAX
        !          1513: computer line. Not counting variants on 2 operating systems.
        !          1514: A Paen to standardization.
        !          1515: 
        !          1516:      Dick Gabriel states some  useful  principles  for  com-
        !          1517: parisons  in  the conference record of the 1982 ACM Lisp and
        !          1518: Functional Programming Conference, which was held in August.
        !          1519: We  understand  he  now has a collection of some 18 programs
        !          1520: which he is continuing to time on various systems.
        !          1521: 
        !          1522: 6.  Work in Progress
        !          1523: 
        !          1524: 6.1.  BITGRAPH SUN AED-512
        !          1525: 
        !          1526:      Greg Foster at UCB is working on  raster-graphics  sup-
        !          1527: port in Franz for the 800 by 1000 b/w raster displays of the
        !          1528: BBN Bitgraph and/or the SUN Workstation,  and  possibly  the
        !          1529: color  512 by 512 AED system.  We are probably going to han-
        !          1530: dle mice and Bitpad (stylus) input for pointing.  There  are
        !          1531: lots  of  projects  we hear about with similar systems, e.g.
        !          1532: just recently from the University of  Maryland,  using  UNIX
        !          1533: 
        !          1534: 
        !          1535: 
        !          1536: 
        !          1537: 
        !          1538: 
        !          1539: 
        !          1540: 
        !          1541: 
        !          1542: 
        !          1543: 
        !          1544: 
        !          1545: 
        !          1546: and multiplexed files for window management of a 68000-based
        !          1547: home-grown workstation.
        !          1548: 
        !          1549: 6.2.  RISC-LISP
        !          1550: 
        !          1551:      Yes, Reduced Instruction Set Computer  fans,  who  else
        !          1552: but  UCB  would  be  so bold... Carl Ponder is examining the
        !          1553: issues involved in constructing a fast lisp interpreter  and
        !          1554: compiler  for  the  RISC architecture.  You see, we have all
        !          1555: these chips...
        !          1556: 
        !          1557: 
        !          1558: 7.  Work Contemplated
        !          1559: 
        !          1560: 7.1.  Fast Number Compiler
        !          1561: 
        !          1562:      Undergraduate Jeff Cohen at  Berkeley  is  starting  to
        !          1563: look  at  this.   There are several industrial concerns that
        !          1564: have expressed interest in using such a system, but expected
        !          1565: it to be subsidized by someone else.
        !          1566: 
        !          1567: 7.2.  IBM Franz
        !          1568: 
        !          1569:      Even more nibbles on this one, but not yet.
        !          1570: 
        !          1571: 8.  Business News
        !          1572: 
        !          1573: 8.1.  Eunice SOLD
        !          1574: 
        !          1575:      Some of you may have heard  that  the  Eunice  software
        !          1576: package was sold by SRI to the Wollongong Group, a UNIX sup-
        !          1577: port group in Palo Alto.   Prices  range  from  $2k  (educa-
        !          1578: tional)  to  $5k (commercial).  Naturally this package is of
        !          1579: interest beyond the availability of Franz Lisp.  We have not
        !          1580: compared  this  product  to  other similar ones, but we know
        !          1581: that TWG has been distributing a working Franz opus 38.
        !          1582: 
        !          1583:      As far as alternatives to Eunice, we  are  aware  of  a
        !          1584: system  developed  at  Rice University, and another by Human
        !          1585: Computing  Resources  (HCR)  in  Toronto.    We   have   not
        !          1586: evaluated either of these.
        !          1587: 
        !          1588: 8.2.  MACSYMA SOLD
        !          1589: 
        !          1590:      MIT has sold exclusive rights to MACSYMA, a large alge-
        !          1591: braic  manipulation  system, to Symbolics, Inc. of Cambridge
        !          1592: Mass. This package runs in Franz Lisp, (among  other  Lisps)
        !          1593: We  hope that soon it will again be available to educational
        !          1594: institutions with VAX systems either from us  or  Symbolics,
        !          1595: at a nominal charge.  We understand that commercial licenses
        !          1596: (from Symbolics) for versions of MACSYMA  on  PDP-10s,  Lisp
        !          1597: Machines,  etc.   will distributed at non-nominal prices and
        !          1598: offered with maintenance contracts.
        !          1599: 
        !          1600: 
        !          1601: 
        !          1602: 
        !          1603: 
        !          1604: 
        !          1605: 
        !          1606: From liz.umcp-cs@UDel-Relay Mon Nov  1 17:43:52 1982
        !          1607: Date:     29 Oct 82 12:04:24 EDT  (Fri)
        !          1608: From:     Liz Allen <liz.umcp-cs@UDel-Relay>
        !          1609: Subject:  Re:  Flavor system
        !          1610: To:       ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc
        !          1611: Cc:       randy.umcp-cs at UDel-Relay
        !          1612: In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley
        !          1613: Via:  UMCP-CS; 30 Oct 82 5:40-EDT
        !          1614: Status: RO
        !          1615: 
        !          1616:        Date: 25 October 1982 16:29-EDT
        !          1617:        From: ECC@MIT-MC@Berkeley
        !          1618:        Subject:  Flavor system
        !          1619:        To: FRANZ-FRIENDS at MIT-MC
        !          1620: 
        !          1621:        Can someone give me a pointer to the Franz flavor system
        !          1622:        developed by U. Maryland?  I am looking for information on how to
        !          1623:        FTP the files -- what machine, whether public, what files, etc.
        !          1624: 
        !          1625: Since the U. of Maryland is not (yet) an Arpanet host, you can't
        !          1626: FTP files directly from here.  We are right now completing some
        !          1627: documentation for all of our hacks -- including documentation for
        !          1628: some recent improvements for our flavors system.  When that
        !          1629: documentation is complete, we will be ready to distribute the
        !          1630: packages developed here.  Besides flavors, this includes a top
        !          1631: level called userexec which is based on INTERLISP's top level and
        !          1632: a production system called YAPS similar to but more flexible than
        !          1633: OPS5.
        !          1634: 
        !          1635: We are supposed to become an Arpanet host in a few months...  (Read
        !          1636: open ended period of time.)  Meanwhile, if you would like to get
        !          1637: our code, mail me a tape, and I will mail it back with the code and
        !          1638: documentation on it.  I'd appreciate it if someone would volunteer
        !          1639: to let other folks FTP the files from their machine until we do
        !          1640: become an Arpanet host.  My address is:
        !          1641: 
        !          1642:        Liz Allen
        !          1643:        Univ of Maryland
        !          1644:        Dept of Computer Science
        !          1645:        College Park MD 20783
        !          1646:        (301) 454-4247
        !          1647:        liz.umcp-cs@udel-relay
        !          1648: 
        !          1649:                                -Liz
        !          1650: 
        !          1651: 
        !          1652: 
        !          1653: From jkf  Wed Nov  3 15:49:29 1982
        !          1654: Date: 3-Nov-82 15:48:50-PST (Wed)
        !          1655: From: jkf (John Foderaro)
        !          1656: Subject: lisp opus 38.40
        !          1657: Message-Id: <[email protected]>
        !          1658: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1659:        id A16460; 3-Nov-82 15:49:29-PST (Wed)
        !          1660: To: local-lisp
        !          1661: Status: RO
        !          1662: 
        !          1663:   putprop will now put new properties at the head of the property list.
        !          1664:   
        !          1665:   
        !          1666: 
        !          1667: 
        !          1668: From ecc@UCBARPA  Thu Nov  4 10:28:49 1982
        !          1669: Date: 4-Nov-82 10:19:26-PST (Thu)
        !          1670: From: ecc@UCBARPA (Eric C. Cooper)
        !          1671: Subject: Lisp song
        !          1672: Message-Id: <[email protected]>
        !          1673: Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82])
        !          1674:        id A24537; 4-Nov-82 10:19:28-PST (Thu)
        !          1675: Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1676:        id A00305; 4-Nov-82 10:28:49-PST (Thu)
        !          1677: To: local-lisp@kim
        !          1678: Status: O
        !          1679: 
        !          1680: [This has been forwarded from uucp through Xerox through info-lispm.]
        !          1681: 
        !          1682: >From decvax!utzoo!utcsrgv!roderick Mon Nov  1 14:24:35 1982
        !          1683: 
        !          1684: Another Glitch in the Call
        !          1685: ------- ------ -- --- ----
        !          1686:    (Sung to the tune of a recent Pink Floyd song.)
        !          1687: 
        !          1688: 
        !          1689: We don't need no indirection
        !          1690: We don't need no flow control
        !          1691: No data typing or declarations
        !          1692:    Hey! Did you leave the lists alone?
        !          1693: 
        !          1694: Chorus:
        !          1695:    All in all, it's just a pure-LISP function call.
        !          1696: 
        !          1697: We don't need no side effect-ing
        !          1698: We don't need no scope control
        !          1699: No global variables for execution
        !          1700:    Hey! Did you leave those args alone?
        !          1701: 
        !          1702: (Chorus)
        !          1703: 
        !          1704: We don't need no allocation
        !          1705: We don't need no special nodes
        !          1706: No dark bit-flipping in the functions
        !          1707:    Hey! Did you leave the bits alone?
        !          1708: 
        !          1709: (Chorus)
        !          1710: 
        !          1711: We don't need no compilation
        !          1712: We don't need no load control
        !          1713: No link edit for external bindings
        !          1714:    Hey! Did you leave that source alone?
        !          1715: 
        !          1716: (Chorus, and repeat)
        !          1717: 
        !          1718: From jkf  Sat Nov 13 20:53:41 1982
        !          1719: Date: 13-Nov-82 20:53:16-PST (Sat)
        !          1720: From: jkf (John Foderaro)
        !          1721: Subject: lisp opus 38.41
        !          1722: Message-Id: <[email protected]>
        !          1723: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
        !          1724:        id A00490; 13-Nov-82 20:53:41-PST (Sat)
        !          1725: To: local-lisp
        !          1726: Status: O
        !          1727: 
        !          1728:   added functions:
        !          1729:        (remq 'g_val 'l_list) - just like remove but uses eq instead of equal
        !          1730:        (command-line-args) - returns a list of the command line arguments
        !          1731:                when lisp was started.  This function will return
        !          1732:                only those arguments typed by the user, even if the
        !          1733:                lisp was started with the autorun feature (liszt -r).
        !          1734:        (sys:gethostname) - returns the name of the machine.
        !          1735:        (status domain) - returns 'ucb' here.
        !          1736: 
        !          1737: 
        !          1738: 
        !          1739: From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982
        !          1740: Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST
        !          1741: Date: 28 Nov 1982 11:47:28-EST
        !          1742: From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A
        !          1743: Subject: (random) problems
        !          1744: Status: RO
        !          1745: 
        !          1746: I am having two problems using (random) in Franz lisp.  The first problem is
        !          1747: that I can't find any way to set the seed.  Every time I enter lisp, the
        !          1748: generator is in the same state.  I have had to resort to cfasling a c
        !          1749: procedure that calls srand() (as (random) seems to be defined in c by a call
        !          1750: on rand()).  Is there a way to do this within lisp?  The other problem is
        !          1751: more serious.  The generator seems to generate tight cycles for (at least)
        !          1752: arguments that are small powers of 2.  For example, repeatedly executing
        !          1753: (random 2) yields the sequence 01010101..., and (random 4) yields
        !          1754: 01230123....  These sequences apparently occur no matter to what value I set
        !          1755: the seed.  Does anyone one know what I could be doing wrong, or have a
        !          1756: working random number generator?
        !          1757: 
        !          1758: 
        !          1759: From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982
        !          1760: Status: O
        !          1761: 
        !          1762: From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982
        !          1763: Date:     28 Nov 82 22:40:14 EST  (Sun)
        !          1764: From:     Tim Maroney <tim.unc@UDel-Relay>
        !          1765: Subject:  rng
        !          1766: To:       franz-friends at Ucb-C70
        !          1767: Via:  UNC; 28 Nov 82 23:38-EST
        !          1768: Status: O
        !          1769: 
        !          1770: To the person who asked about random number generators and deficiencies
        !          1771: in (random) [I can't write mail to you for some reason]:
        !          1772: 
        !          1773: You're not doing anything wrong; that's the way the sucker works.
        !          1774: One good way to get random numbers is to do the syscall that gets
        !          1775: you the number of seconds since whenever-it-is, and use the mod
        !          1776: function. This is especially good for getting a random one or zero,
        !          1777: by using the evenp function.
        !          1778: 
        !          1779:                                        Tim Maroney
        !          1780:                                        tim@unc@udel-relay
        !          1781: 
        !          1782: 
        !          1783: From jkf  Tue Nov 30 09:21:10 1982
        !          1784: Date: 30-Nov-82 09:21:10-PST (Tue)
        !          1785: From: jkf (John Foderaro)
        !          1786: Subject: opus 38.42
        !          1787: Message-Id: <[email protected]>
        !          1788: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
        !          1789:        id AA11699; 30-Nov-82 09:21:10-PST (Tue)
        !          1790: To: local-lisp
        !          1791: Status: O
        !          1792: 
        !          1793:   added: (sys:link 'oldname 'newname) that what the ln program does.
        !          1794: 
        !          1795:   changed: the order of arguments to the vset functions is now:
        !          1796:        (vset 'vector 'index 'value).
        !          1797:        
        !          1798:        [This shouldn't affect anyone since vectors haven't been officially
        !          1799:         released yet and won't be until I make one more major modification]
        !          1800: 
        !          1801:        setf now knows about vectors.  You can say
        !          1802:                (setf (vref 'vector 'index) 'value)
        !          1803:        and not have to worry about the order of arguments to vset.
        !          1804: 
        !          1805: 
        !          1806: 
        !          1807: From jkf  Tue Nov 30 10:42:00 1982
        !          1808: Date: 30-Nov-82 10:42:00-PST (Tue)
        !          1809: From: jkf (John Foderaro)
        !          1810: Subject: Re: opus 38.42
        !          1811: Message-Id: <[email protected]>
        !          1812: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
        !          1813:        id AA13143; 30-Nov-82 10:42:00-PST (Tue)
        !          1814: To: jeffc, local-lisp
        !          1815: In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday)
        !          1816: Status: O
        !          1817: 
        !          1818:   It can't do symbolic links (I've only been adding system calls that I had
        !          1819: a use for).
        !          1820: 
        !          1821:   setf is a generalized setq.  The target can be an expression which locates
        !          1822: a value.  setf figures out how to store in the target.
        !          1823: for example:
        !          1824: 
        !          1825:   (setf x 3)        ==  (setq x 3)
        !          1826:   (setf (car x) 3)  == (rplaca x 3)
        !          1827:   (setf (get foo 'bar) 3) == (putprop foo 3 'bar)
        !          1828: 
        !          1829: the target must be something it has been 'taught' to understand, or it can
        !          1830: be a macro, in which case setf macro-expands it and takes another look.
        !          1831: 
        !          1832: The setf macro (and a list of targets it knows about is in
        !          1833: /usr/lib/lisp/common2.l)
        !          1834: 
        !          1835: 
        !          1836: 
        !          1837: 
        !          1838: From jkf@UCBKIM  Wed Dec  1 09:13:23 1982
        !          1839: Date: 1-Dec-82 09:13:03-PST (Wed)
        !          1840: From: jkf@UCBKIM (John Foderaro)
        !          1841: Subject: Random Numbers in Franz
        !          1842: Message-Id: <[email protected]>
        !          1843: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
        !          1844:        id AA03615; 1-Dec-82 09:13:03-PST (Wed)
        !          1845: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82])
        !          1846:        id A18406; 1-Dec-82 09:13:23-PST (Wed)
        !          1847: To: franz-friends@berkeley
        !          1848: Status: RO
        !          1849: 
        !          1850: Date: 29-Nov-82 15:56:09-PST (Mon)
        !          1851: From: alice!sola!mitch
        !          1852: Subject: Random Numbers in Franz
        !          1853: To: alice!ucbvax!franz-friends
        !          1854: 
        !          1855: In general, it is very bad practice to compute a random number between 0
        !          1856: and n by any expression such as (mod (random) n).  In fact, Franz's
        !          1857: random function does exactly that, returning the number generated by the
        !          1858: C function rand(3) modulo n.  This technique uses only the rightmost 
        !          1859: bits of successive calls to rand, and the righmost n bits of congruential
        !          1860: sequences (like that returned by rand(3)) have a period of AT MOST 2**n
        !          1861: (See Knuth vol.2 p. 12).  So using the rightmost two bits will indeed give
        !          1862: you sequences of at most period 4.  (If your lisp doesn't have this 
        !          1863: behavior, you're not using the standard rand.)
        !          1864: 
        !          1865: A better way to do it is to use the high order bits, by dividing the entire
        !          1866: range up into n pieces and then seeing where you fall.  (This method is
        !          1867: biased if n is of the same order as the range, though.)
        !          1868: 
        !          1869: The code I use is:
        !          1870: 
        !          1871: 
        !          1872: (or (getd '$old-random) (putd '$old-random (getd 'random)))
        !          1873: 
        !          1874: (defun random n
        !          1875:   (cond ((eq n 0) ($old-random))
        !          1876:        ((fix (quotient (boole 1 ($old-random) #o 7777777777)
        !          1877:                        (quotient #o 7777777777 (arg 1)))))))
        !          1878: 
        !          1879:                Mitch Marcus
        !          1880: 
        !          1881: 
        !          1882: 
        !          1883: 
        !          1884: 
        !          1885: From jkf  Thu Dec  2 08:04:37 1982
        !          1886: Date: 2-Dec-82 08:04:37-PST (Thu)
        !          1887: From: jkf (John Foderaro)
        !          1888: Subject: Franz Lisp distribution
        !          1889: Message-Id: <[email protected]>
        !          1890: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
        !          1891:        id AA14414; 2-Dec-82 08:04:37-PST (Thu)
        !          1892: To: franz-friends, net-lang-lisp@k
        !          1893: Status: O
        !          1894: 
        !          1895: 
        !          1896:        Franz Lisp Distribution
        !          1897:        
        !          1898:   This note describes our distribution policy for Franz Lisp.
        !          1899: 
        !          1900: What is being distributed:
        !          1901:   We distribute only source code in order to keep the distribution
        !          1902:   small and relatively Unix independent.   Makefiles are provided to
        !          1903:   build the entire lisp system from source, even if you don't have
        !          1904:   a version of lisp running already.  This process takes about 3 cpu
        !          1905:   hours on a Vax 780.  [This version for the Vax only, a 68000 version
        !          1906:   is being worked on.  Contact ucbkim.sklower@berkeley or 
        !          1907:   ucbkim.layer@berkeley]
        !          1908: 
        !          1909:   The following source is provided:
        !          1910:     lisp interpreter, 
        !          1911:     compiler (liszt),
        !          1912:     cross reference program (lxref),
        !          1913:     lisp manual,
        !          1914:     and other utility programs:
        !          1915:        trace, step, debug, cmu library functions, (and other minor ones),
        !          1916:        and these packages from the MIT lisp library:
        !          1917:            defstruct, loop, flavors. 
        !          1918:            [These programs are provided as a convenience to those who can't
        !          1919:             access the arpanet and copy them.  There is no documentation for
        !          1920:             them in the Franz Lisp manual.  The best source of documentation
        !          1921:             is the Lisp Machine manual (available from MIT, Symbolics
        !          1922:             or LMI)]
        !          1923: 
        !          1924:    Regarding Flavors:  there are two implementations of flavors for
        !          1925:        Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
        !          1926:        and one from the University of Maryland (contact person
        !          1927:        Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
        !          1928:        exactly like flavors on the Lisp Machine (due to differences between
        !          1929:        Lisp Machine lisp and Franz Lisp), and the implementations differ
        !          1930:        from each other.    We incorporated the Mit version into the
        !          1931:        standard distribution because the high bandwidth between here and
        !          1932:        MIT will insure that it keeps up to date with the current Franz.
        !          1933:        This is not to imply that it is the better implementation.
        !          1934:        We haven't had enough experience with flavors to judge.
        !          1935:        Those seriously interested in Flavors should contact Liz
        !          1936:        Allen and ask for the Tech Report on the Univ Of Maryland Flavors
        !          1937:        system.
        !          1938: 
        !          1939: What is the form of the distribution:
        !          1940:   The files are packaged in a giant (2.1Mbyte) shell script.  Running this
        !          1941: shell script through 'sh' will result in a directory tree.  A ReadMe file
        !          1942: in the current directory will contain instructions on building the lisp
        !          1943: system.  The shell script is broken into a number of smaller files.
        !          1944: The current distribution looks like:
        !          1945: % ls
        !          1946: total 2092
        !          1947:  195 opus38.40.aa       195 opus38.40.ae        195 opus38.40.ai
        !          1948:  195 opus38.40.ab       195 opus38.40.af        195 opus38.40.aj
        !          1949:  195 opus38.40.ac       195 opus38.40.ag        142 opus38.40.ak
        !          1950:  195 opus38.40.ad       195 opus38.40.ah
        !          1951: 
        !          1952: The '38.40' means Opus 38, minor version 40.  These numbers may be different
        !          1953: by the time you get your distribution.  In order to extract the lisp
        !          1954: files from this shell script, you need only type:
        !          1955:        cat * | sh
        !          1956: 
        !          1957: 
        !          1958: To get a copy of the distribution:
        !          1959:   The distribution may be obtained either using FTP from an arpanet site,
        !          1960: or on a magnetic tape through the U.S Mail.
        !          1961: 
        !          1962:  Arpanet:
        !          1963:    The files are stored on the ucb-c70 (NCP) arpanet host in the
        !          1964:    directory /users/lisp/lispuser.  If you have an account on the ucb-c70,
        !          1965:    you are free to take FTP a copy of these files.
        !          1966:    If you do not have an account on the ucb-c70, send me (jkf@berkeley) a
        !          1967:    message and I will set up a temporary account for you.
        !          1968:    If you are on a TCP host, write me and we will set up an account on one
        !          1969:    of our Vax's for you to FTP the files.  Eventually we will have an
        !          1970:    anonymous login on a TCP machine.
        !          1971: 
        !          1972:  Mag Tape:
        !          1973:    In order to get a copy of the distribution mailed to you, send a check to
        !          1974:  cover our tape copying and mailing costs (fees are listed below).  We will
        !          1975:  purchase the mag tape and you are free to keep it.  Please do NOT
        !          1976:  send us a tape.
        !          1977: 
        !          1978:      Fees:
        !          1979:                $50     - distribution tape mailed 3rd class
        !          1980:            add $10     - a copy of the Lisp Manual (we will only
        !          1981:                          send one copy, you are free to photocopy it)
        !          1982:            add $7      - send tape via 1st class mail.
        !          1983: 
        !          1984:             -or-
        !          1985:                $15     - for just a copy of the Lisp Manual
        !          1986: 
        !          1987:  The address to send checks to is 
        !          1988: 
        !          1989:        Keith Sklower
        !          1990:        EECS/Computer Science Division
        !          1991:        524 Evans Hall
        !          1992:        University of California
        !          1993:        Berkeley, CA  94720
        !          1994: 
        !          1995:  All checks should be made out to "Regents, University of California."
        !          1996:  We require pre-payment.  We will not invoice or process purchase orders.
        !          1997: 
        !          1998: 
        !          1999: 
        !          2000: Disclaimers:
        !          2001:     This distribution works on the latest versions of Unix running at
        !          2002:     Berkeley (4.1a).  We can't guarantee that it will work on older
        !          2003:     versions (although, if you are running 4.1, it is almost certain
        !          2004:     that it will work, but we have not verified it).
        !          2005:     VMS users who are using a typical Unix compatibility package will 
        !          2006:     probably not be able to build a lisp from this distribution unless they
        !          2007:     know a great deal about VMS and their compatibility package.
        !          2008:     At least one package (Eunice) supports Franz at this time.
        !          2009:     
        !          2010: Redistribution:
        !          2011:     If you get a copy of the distribution, you are free to give it to
        !          2012:     other people.  We appreciate being informed of new sites so they
        !          2013:     can be put on a mailing list (electronic and conventional).  This
        !          2014:     list is used to announce new releases.  To be put on this list,
        !          2015:     send U.S. Mail to Keith Sklower (address above) or to 
        !          2016:     franz-friends-request@berkeley or ucbvax!franz-friends-request
        !          2017: 
        !          2018: 
        !          2019: 
        !          2020: From jkf  Mon Dec  6 08:50:45 1982
        !          2021: Date: 6-Dec-82 08:50:45-PST (Mon)
        !          2022: From: jkf (John Foderaro)
        !          2023: Subject: opus 38.43
        !          2024: Message-Id: <[email protected]>
        !          2025: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2026:        id AA12951; 6-Dec-82 08:50:45-PST (Mon)
        !          2027: To: local-lisp
        !          2028: Status: O
        !          2029: 
        !          2030:   The size of vectors is now recorded in bytes rather than longwords.
        !          2031:   We've imported a few more commands to deal with fclosures.
        !          2032:   (symeval-in-fclosure 'fclosure 'symbol)
        !          2033:   (set-in-fclosure 'fclosure 'symbol 'value)
        !          2034: 
        !          2035:   (let-fclosed vars function)
        !          2036:   
        !          2037: 
        !          2038: 
        !          2039: 
        !          2040: From jkf  Mon Dec 13 10:35:43 1982
        !          2041: Date: 13-Dec-82 10:35:43-PST (Mon)
        !          2042: From: jkf (John Foderaro)
        !          2043: Subject: enhancemants to trace
        !          2044: Message-Id: <[email protected]>
        !          2045: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2046:        id AA12160; 13-Dec-82 10:35:43-PST (Mon)
        !          2047: To: local-lisp
        !          2048: Status: O
        !          2049: 
        !          2050:   The function 'retrace' will insure that all functions which should be
        !          2051: traced are indeed traced.   This will solve the problem of reloading
        !          2052: a file whose functions are traced.  After you load a file, you can
        !          2053: type (retrace) and those functions which became untraced during the loading
        !          2054: process, will be traced again.
        !          2055: 
        !          2056:   The top-level-print and top-level-read variables will now take effect
        !          2057: within a trace break.
        !          2058: 
        !          2059: 
        !          2060: 
        !          2061: 
        !          2062: 
        !          2063: From jkf  Tue Dec 14 12:40:41 1982
        !          2064: Date: 14-Dec-82 12:40:41-PST (Tue)
        !          2065: From: jkf (John Foderaro)
        !          2066: Subject: Re: #!, exec and lisp
        !          2067: Message-Id: <[email protected]>
        !          2068: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2069:        id AA10379; 14-Dec-82 12:40:41-PST (Tue)
        !          2070: To: lime!burdvax!puder
        !          2071: Cc: franz-friends
        !          2072: In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon)
        !          2073: Status: O
        !          2074: 
        !          2075:    It is easy to make #! do a zapline.   If you have a recent version of
        !          2076: lisp, just execute:
        !          2077: 
        !          2078: (defsharp ! (x) (zapline))
        !          2079: 
        !          2080: (this could be put in your .lisprc, if you don't want to affect other 
        !          2081: people).    The problem with adding this to Franz by default is that the
        !          2082: sharpsign macro is shared by a number of lisps and few of them run under
        !          2083: Unix.   Therefore, few other lisps are going to want #! to be zapline.
        !          2084: 
        !          2085: 
        !          2086:   Regarding the -f switch:  The -f switch is used to communicate between the
        !          2087: bootstrap at the beginning of a fasl file and the lisp interpreter.  It
        !          2088: wasn't meant as a general 'fasl this file' switch for users to make use of.
        !          2089: The choice of '-f' was bad, it should have been something more unique like
        !          2090: '-- autorun' so that a user would be unlikely to type it.   We have avoided
        !          2091: assigning meanings to switches on lisp's command line because we want to give
        !          2092: each user the opportunity to assign whatever meaning he wants to whatever
        !          2093: switch he wants.   It isn't difficult to write a program to scan the command
        !          2094: line.
        !          2095: 
        !          2096: Re:
        !          2097:     The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be
        !          2098:     necessary, because the exec syscall supplies the full path name, because
        !          2099:     the shell has already done the path searching on the command name.  The
        !          2100:     only place that might have to be searched is the current directory.
        !          2101: 
        !          2102: This isn't true.  (argv 0) is the command that you typed, not the full path
        !          2103: name to the command.  Only by prepending all the directories in the
        !          2104: search list can you find the location of the command.
        !          2105: 
        !          2106: 
        !          2107:                                ---john foderaro
        !          2108:                                
        !          2109: 
        !          2110: 
        !          2111: From jkf  Mon Jan 10 15:04:02 1983
        !          2112: Date: 10-Jan-83 15:04:02-PST (Mon)
        !          2113: From: jkf (John Foderaro)
        !          2114: Subject: opus 38.45
        !          2115: Message-Id: <[email protected]>
        !          2116: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2117:        id AA19240; 10-Jan-83 15:04:02-PST (Mon)
        !          2118: To: local-lisp
        !          2119: Status: O
        !          2120: 
        !          2121:   showstack will again report correctly for compiled calls if the
        !          2122: transfer tables are unlinked (status translink nil).
        !          2123: 
        !          2124: 
        !          2125: 
        !          2126: From jkf  Mon Jan 10 19:46:06 1983
        !          2127: Date: 10-Jan-83 19:46:06-PST (Mon)
        !          2128: From: jkf (John Foderaro)
        !          2129: Subject: opus 38.46
        !          2130: Message-Id: <[email protected]>
        !          2131: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2132:        id AA24831; 10-Jan-83 19:46:06-PST (Mon)
        !          2133: To: local-lisp
        !          2134: Status: O
        !          2135: 
        !          2136:  This version incorporates some fixes from mit.  You shouldn't notice
        !          2137: any differences but if you do, let me know.
        !          2138: 
        !          2139: 
        !          2140: 
        !          2141: 
        !          2142: 
        !          2143: From jkf  Wed Jan 12 09:03:32 1983
        !          2144: Date: 12-Jan-83 09:03:32-PST (Wed)
        !          2145: From: jkf (John Foderaro)
        !          2146: Subject: opus38.47
        !          2147: Message-Id: <[email protected]>
        !          2148: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2149:        id AA01981; 12-Jan-83 09:03:32-PST (Wed)
        !          2150: To: local-lisp
        !          2151: Status: O
        !          2152: 
        !          2153:   The setf macro will now handle all car and cdr forms (i.e. c{ad}+r).
        !          2154:   Thanks to peter norvig for this.
        !          2155: 
        !          2156:   There is a new macro called 'defvar'.  It is used to declare special
        !          2157: variables and optionally to give them an initial value.  It is used
        !          2158: at top level in a file (outside of defuns).
        !          2159: 
        !          2160: forms:
        !          2161: (defvar foo)   ; declares foo to be special
        !          2162: (defvar bar 3) ; declares bar to be special and when this file is read in
        !          2163:                ; bar will be given the value 3 if it is unbound.
        !          2164: An advantage of '(defvar foo)' over '(declare (special foo))' is that if
        !          2165: a file containing defvars is loaded (or fasl'ed) in during compilation,
        !          2166: the variables mentioned in the defvar's will be declared special.  The only
        !          2167: way to have that effect with '(declare (special foo))' is to 'include'
        !          2168: the file.  
        !          2169: 
        !          2170:  There is a new macro, 'environment', which can be used at the beginning of
        !          2171: a file to specify what sort of environment this file needs in order to be
        !          2172: compiled or run.  For example:
        !          2173: (environment (compile eval) (files mymacros othermacros)
        !          2174:             (compile) (syntax maclisp))
        !          2175: 
        !          2176: says that when compiling or loading into the interpreter, the files
        !          2177: mymacros and othermacros should be loaded (if they aren't loaded already).
        !          2178: When compiling, the maclisp syntax should be used.
        !          2179: The general form of 'environment' is:
        !          2180:    (environment when1 what1
        !          2181:                when2 what2
        !          2182:                ...    ...
        !          2183:                whenN whatN)
        !          2184: the when's are a subset of (eval compile load), and the symbols have the
        !          2185: same meaning as they do in 'eval-when'.
        !          2186: The what's are either
        !          2187:        (files file1 file2 ... fileN)
        !          2188:                insure that the named files are loaded.  To see if fileX
        !          2189:                is loaded, it looks for a 'version' property under
        !          2190:                fileX's property list.  Thus to prevent multiple loading,
        !          2191:                you should put
        !          2192:                (putprop 'myfile t 'version) at the end of myfile.l
        !          2193:        (syntax type)
        !          2194:                type is either maclisp, intlisp, ucilisp, franzlisp
        !          2195:                This sets the syntax correctly.
        !          2196: 
        !          2197: There are additional macros to set of standard environments:
        !          2198: (environment-maclisp)  sets up the maclisp environment.  This is what
        !          2199:        you would get by using the -m switch to liszt.
        !          2200: 
        !          2201: (environment-lmlisp)  sets up the lisp machine environment. This is like
        !          2202:        maclisp but it has additional macros.
        !          2203: 
        !          2204:        
        !          2205: It is possible to add when's and what's to the specialized environments,
        !          2206: e.g.
        !          2207:  (environment-maclisp (compile eval) (files foo bar))
        !          2208: 
        !          2209: 
        !          2210: 
        !          2211:   
        !          2212: 
        !          2213: 
        !          2214: 
        !          2215: From norvig Wed Jan 12 13:12:45 1983
        !          2216: To: jkf local-lisp
        !          2217: Subject: defvar
        !          2218: Status: O
        !          2219: 
        !          2220: Shouldn't defvar take any number of arguments, like setq?  As it is,
        !          2221: (defvar a 1 b 2) sets a to 1, but ignores the other arguments.
        !          2222: 
        !          2223: From fateman Wed Jan 12 13:23:08 1983
        !          2224: To: jkf local-lisp norvig
        !          2225: Subject: Re:  defvar
        !          2226: Status: O
        !          2227: 
        !          2228: I suspect the extra arguments to defvar are used in other systems for
        !          2229: storage of documentation strings in appropriate places.  E.g.
        !          2230: (defvar dozen 12 "initially 12 except in the baker system when it is 13")
        !          2231: causes some association with defvar and documentation should be put on
        !          2232: a file.
        !          2233: 
        !          2234: 
        !          2235: From jkf  Wed Jan 12 14:25:02 1983
        !          2236: Date: 12-Jan-83 14:25:02-PST (Wed)
        !          2237: From: jkf (John Foderaro)
        !          2238: Subject: Re: defvar
        !          2239: Message-Id: <[email protected]>
        !          2240: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2241:        id AA13079; 12-Jan-83 14:25:02-PST (Wed)
        !          2242: To: norvig, local-lisp
        !          2243: In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday)
        !          2244: Status: O
        !          2245: 
        !          2246:  fateman is correct that there is an optional third argument for
        !          2247: documentation.   We don't want to add multiple arguments because defvar
        !          2248: it will mean that code we write here can't be transported to
        !          2249: other lisp which only expect one defvar argument.
        !          2250: 
        !          2251: 
        !          2252: 
        !          2253: From jkf  Thu Jan 13 09:49:13 1983
        !          2254: Date: 13-Jan-83 09:49:13-PST (Thu)
        !          2255: From: jkf (John Foderaro)
        !          2256: Subject: liszt 8.17
        !          2257: Message-Id: <[email protected]>
        !          2258: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2259:        id AA00331; 13-Jan-83 09:49:13-PST (Thu)
        !          2260: To: local-lisp
        !          2261: Status: O
        !          2262: 
        !          2263:  The vector reference functions are open coded.  These are
        !          2264:        vref, vrefi-byte, vrefi-word, vrefi-long
        !          2265: 
        !          2266: 
        !          2267: 
        !          2268: From G:alpines  Thu Jan 13 20:31:34 1983
        !          2269: Date: 13 Jan 1983 20:24-PST
        !          2270: From: alpines@G   (Harry Weeks at Vax-Populi)
        !          2271: Subject: Franz on 68000's
        !          2272: Message-Id: <83/01/13 2024.733@Vax-Populi>
        !          2273: Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
        !          2274:        id AA12970; 13-Jan-83 20:28:37-PST (Thu)
        !          2275: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2276:        id AA14908; 13-Jan-83 20:31:34-PST (Thu)
        !          2277: To: franz@BERKELEY
        !          2278: Cc: franz-friends@BERKELEY
        !          2279: Status: O
        !          2280: 
        !          2281: >Date: 13 Jan 1983 20:01-PST
        !          2282: From: G.alpines at Berkeley (Harry Weeks at Vax-Populi)
        !          2283: Subject: Franz on 68000's.
        !          2284: To: franz-friends-request@Berkeley
        !          2285: Message-Id: <83/01/13 2001.733@Vax-Populi>
        !          2286: 
        !          2287: Please put me on your mailing list for information concerning
        !          2288: implementation of Franz, esp. on 68000's, but I'd like to keep
        !          2289: informed generally as well.  Thanks.
        !          2290: 
        !          2291:                                        Harry Weeks
        !          2292:                                        Bytek
        !          2293:                                        1730 Solano Avenue
        !          2294:                                        Berkeley, CA 94707
        !          2295:                                        
        !          2296:                                        (415) 527-1157
        !          2297: 
        !          2298: 
        !          2299: From jkf  Sun Jan 16 21:22:54 1983
        !          2300: Date: 16-Jan-83 21:22:54-PST (Sun)
        !          2301: From: jkf (John Foderaro)
        !          2302: Subject: change to lisptags program
        !          2303: Message-Id: <[email protected]>
        !          2304: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2305:        id AA23656; 16-Jan-83 21:22:54-PST (Sun)
        !          2306: To: local-lisp
        !          2307: Status: O
        !          2308: 
        !          2309:  lisptags will now surround the search string with /'s instead of ?'s
        !          2310: in order to be compatible with ctags.   Both types should work with vi,
        !          2311: emacs people will probably have to make a minor modification to their
        !          2312: tags.ml file.
        !          2313:   My version in ~jkf/elib/tags.ml.
        !          2314:  
        !          2315: 
        !          2316: 
        !          2317: 
        !          2318: 
        !          2319: 
        !          2320: From jkf  Tue Jan 18 16:43:23 1983
        !          2321: Date: 18-Jan-83 16:43:23-PST (Tue)
        !          2322: From: jkf (John Foderaro)
        !          2323: Subject: lisp opus 38.48, liszt 8.19
        !          2324: Message-Id: <[email protected]>
        !          2325: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2326:        id AA10935; 18-Jan-83 16:43:23-PST (Tue)
        !          2327: To: local-lisp
        !          2328: Status: O
        !          2329: 
        !          2330:   This is a long message so I'll put the most important thing first, in case
        !          2331: you choose not to read the rest of the message:
        !          2332:   *** object files generated by liszt 8.19 will not run in any lisp
        !          2333:   *** older than 38.48.    Object files which were generated by
        !          2334:   *** liszt's before 8.19 will continue to work in the new lisp.
        !          2335: 
        !          2336: 
        !          2337: There were two major changes to lisp and liszt:
        !          2338:  1) compiled functions will test at runtime to make sure that they
        !          2339:     are passed the correct number of arguments.
        !          2340: 
        !          2341:  2) the lambda list keywords &optional, &rest and &aux are open compiled
        !          2342:     in an efficient manner.
        !          2343: 
        !          2344: I'll refresh your memory on what the possible forms are for the & keywords:
        !          2345: 
        !          2346:   the formal parameter list of a def has this form
        !          2347:   ( required-args
        !          2348:     [ &optional optional-arguments ]
        !          2349:     [ &rest rest-argument ]
        !          2350:     [ &aux  aux-arguments ])
        !          2351: 
        !          2352:  as in this example which shows all possible forms:
        !          2353: 
        !          2354:  (def foo 
        !          2355:    (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g)
        !          2356:        (compute)))
        !          2357: 
        !          2358:    
        !          2359:  the meaning and forms of the various parts of the formal parameter list are:
        !          2360: 
        !          2361:  required-args: a sequence of n (zero or more) symbols which will be bound
        !          2362:        to the first n actual arguments.
        !          2363: 
        !          2364:  optional-args:        a sequence of m (zero or more) symbols which will be
        !          2365:        bound to the next m actual arguments if they are present, or
        !          2366:        to default values.
        !          2367:        the forms of an optional argument are:
        !          2368:        
        !          2369:        foo     - bind foo to the argument if it present, otherwise bind it
        !          2370:                  to nil
        !          2371:        (foo (expr)) - bind foo to the argument if it is present, otherwise
        !          2372:                evaluate (expr) and bind foo to the result.
        !          2373: 
        !          2374:        (foo (expr) foo-p)  - bind foo to the argument if it is present, 
        !          2375:                otherwise evaluate (expr) and bind foo to the result.
        !          2376:                Also, bind foo-p to t if the argument is present, otherwise
        !          2377:                bind foo-p to nil.  foo-p will be treated like an &aux
        !          2378:                variable (see below) but it should NOT be declared in the
        !          2379:                &aux list!
        !          2380: 
        !          2381:   rest-arg : a single symbol which will be bound to a list of the rest of the
        !          2382:        arguments.  This list is cons'ed up each time the function is called.
        !          2383: 
        !          2384:   aux-args : these args are just like arguments to let or prog within the
        !          2385:        function body so this & keyword isn't really necessary (but there
        !          2386:        are few things in lisp that really are necessary).
        !          2387: 
        !          2388:        the forms of the aux arg are:
        !          2389: 
        !          2390:        foo - bind foo to nil
        !          2391:        (foo (expr))  - evaluate (expr) and bind foo to the result.
        !          2392: 
        !          2393: 
        !          2394: 
        !          2395: The compiler understands the &keywords but the interpreter does not.  'def'
        !          2396: will convert a form with &keywords to a lexpr which is almost equivalent.
        !          2397: The differences are:
        !          2398:     The interpreted form, being a lexpr, is allowed to use the 'arg'
        !          2399:        function.  The compiled form, even with optional args,
        !          2400:        is not a lexpr and thus 'arg' is illegal.
        !          2401: 
        !          2402:     The order that &aux variables are lambda bound is slightly different
        !          2403:         between interpreted and compiled code.  As long as default
        !          2404:        expressions reference no formal parameters after them in the
        !          2405:        formal parameter list, there should be no problems.
        !          2406: 
        !          2407:     The interpreted version will not check for the correct number of
        !          2408:         arguments.
        !          2409: 
        !          2410: Local functions cannot have &keywords. 
        !          2411: 
        !          2412: If you have any questions on this, send me mail.  This change should
        !          2413: only break functions which expect a variable number of argument and
        !          2414: which don't declare the fact using &optional programs.  There may be,
        !          2415: of course, implementation errors.  If you notice anything unusual
        !          2416: please let me know right away.  The old compiler will be
        !          2417: in /usr/ucb/oliszt for a while.
        !          2418: 
        !          2419: 
        !          2420: 
        !          2421:        
        !          2422:     
        !          2423:        
        !          2424: 
        !          2425: 
        !          2426: 
        !          2427: From layer  Thu Jan 20 01:55:55 1983
        !          2428: Date: 20-Jan-83 01:55:55-PST (Thu)
        !          2429: From: layer (Kevin Layer)
        !          2430: Subject: liszt 8.20
        !          2431: Message-Id: <[email protected]>
        !          2432: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2433:        id AA17788; 20-Jan-83 01:55:55-PST (Thu)
        !          2434: To: local-lisp
        !          2435: Phone: (415) 652-2405
        !          2436: Status: O
        !          2437: 
        !          2438:     There are now three new command line features for liszt:
        !          2439: 
        !          2440:     1. -E <s-expr>, where <s-expr> will be evaluated before compilation
        !          2441:        starts.  For example, the setting of constants can be done in this way:
        !          2442: 
        !          2443:           liszt -E '(setq foobar "***foobar-string***")' foobar.l
        !          2444: 
        !          2445:        and in the file being compiled, foobar is accessed as '#.foobar.
        !          2446: 
        !          2447:     2. -I <include-file>, where <include-file> will be loaded (via load)
        !          2448:        before compilation starts.
        !          2449: 
        !          2450:     3. A combination of the -S and -o switches will set the .s file, as in:
        !          2451: 
        !          2452:         liszt -S -o foo.vax.s foo.l
        !          2453: 
        !          2454:       where previously, the -S determined the name of the .s file (foo.s in
        !          2455:       the above example).
        !          2456:       
        !          2457: 
        !          2458: 
        !          2459: From jkf  Thu Jan 20 19:42:38 1983
        !          2460: Date: 20-Jan-83 19:42:38-PST (Thu)
        !          2461: From: jkf (John Foderaro)
        !          2462: Subject: some mods to liszt 8.20
        !          2463: Message-Id: <[email protected]>
        !          2464: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2465:        id AA07334; 20-Jan-83 19:42:38-PST (Thu)
        !          2466: To: local-lisp
        !          2467: Status: O
        !          2468: 
        !          2469:  the -E and -I flags are now -e and -i
        !          2470:  there may be more than one -i flag given on the command line.
        !          2471:  
        !          2472: 
        !          2473: 
        !          2474: From fateman Thu Jan 20 20:20:31 1983
        !          2475: To: local-lisp
        !          2476: Subject: fame, if not fortune
        !          2477: Status: RO
        !          2478: 
        !          2479: In the latest Scientific American, Feb. 1983, Hofstader's column
        !          2480: is the first of several on the programming language "lisp".  He
        !          2481: mentions the particular dialect he is using .... Franz !
        !          2482: 
        !          2483: From wilensky  Thu Jan 20 20:57:27 1983
        !          2484: Date: 20-Jan-83 20:57:27-PST (Thu)
        !          2485: From: wilensky (Robert Wilensky)
        !          2486: Subject: Re: fame, if not fortune
        !          2487: Message-Id: <[email protected]>
        !          2488: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2489:        id AA08824; 20-Jan-83 20:57:27-PST (Thu)
        !          2490: To: fateman, local-lisp
        !          2491: In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday)
        !          2492: Status: RO
        !          2493: 
        !          2494: 
        !          2495: On the other hand, being referenced by Hofstader is a dubious honor.
        !          2496: 
        !          2497: 
        !          2498: From UCBKIM:jkf  Fri Jan 21 08:15:04 1983
        !          2499: Date: 21-Jan-83 08:11:01-PST (Fri)
        !          2500: From: UCBKIM:jkf (John Foderaro)
        !          2501: Subject: test message, ignore
        !          2502: Message-Id: <[email protected]>
        !          2503: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2504:        id AA18650; 21-Jan-83 08:11:01-PST (Fri)
        !          2505: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2506:        id AA24887; 21 Jan 83 08:09:27 PST (Fri)
        !          2507: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2508:        id AA18766; 21-Jan-83 08:15:04-PST (Fri)
        !          2509: To: franz-friends@BERKELEY
        !          2510: Status: O
        !          2511: 
        !          2512:  This will give our mailer a chance to tell me how many of our franz friends
        !          2513: are no longer reachable.
        !          2514: 
        !          2515: 
        !          2516: 
        !          2517: From JTSCHUDY@USC-ISIE  Sat Jan 22 16:42:19 1983
        !          2518: Date: 22 Jan 1983 1634-PST
        !          2519: From: JTSCHUDY@USC-ISIE
        !          2520: Subject: MAILINGLIST ADDITION
        !          2521: Message-Id: <[email protected]>
        !          2522: Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2523:        id AA01747; 22 Jan 83 16:37:17 PST (Sat)
        !          2524: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2525:        id AA18903; 22-Jan-83 16:42:19-PST (Sat)
        !          2526: To: franz-friends@BERKELEY
        !          2527: Status: O
        !          2528: 
        !          2529: Hi!  My name is Jim.  I am presently attending the Naval Post Graduate
        !          2530: School in Monterey California.  I am in the Air Force  enrolled  in  a
        !          2531: DOD  sponsored  graduate  degree in Command Control and Communications
        !          2532: Systems Technology.
        !          2533: 
        !          2534: i  would  like  to  be  added to your mailing list.  My net address is
        !          2535: JTSCHUDY at ISIE.
        !          2536: 
        !          2537: Thanks - Jim.
        !          2538: -------
        !          2539: 
        !          2540: 
        !          2541: From jkf  Sat Jan 22 17:38:41 1983
        !          2542: Date: 22-Jan-83 17:38:41-PST (Sat)
        !          2543: From: jkf (John Foderaro)
        !          2544: Subject: opus 38.49
        !          2545: Message-Id: <[email protected]>
        !          2546: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2547:        id AA20020; 22-Jan-83 17:38:41-PST (Sat)
        !          2548: To: local-lisp
        !          2549: Status: O
        !          2550: 
        !          2551:   A longstanding bug in the determination of the number of free dtpr objects
        !          2552: has been found and fixed.  The effect of this bug was that the function
        !          2553: which is responsible for allocating more memory pages didn't allocate
        !          2554: enough dtpr pages because it thought that there were a large number of
        !          2555: cells free.
        !          2556: 
        !          2557: 
        !          2558: 
        !          2559: From MCLINDEN@RUTGERS  Mon Jan 24 10:33:14 1983
        !          2560: Date: 24 Jan 1983 1324-EST
        !          2561: From: Sean McLinden  <MCLINDEN@RUTGERS>
        !          2562: Subject: Franz Lisp and floating point accelerator
        !          2563: Message-Id: <[email protected]>
        !          2564: Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2565:        id AA19602; 24 Jan 83 10:25:06 PST (Mon)
        !          2566: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2567:        id AA27143; 24-Jan-83 10:33:14-PST (Mon)
        !          2568: To: franz-friends@UCBVAX
        !          2569: Status: O
        !          2570: 
        !          2571: 
        !          2572:   Has anyone determined if a floating point accelerator speeds up
        !          2573:  Vax Franz Lisp jobs in any significant fashion?
        !          2574: 
        !          2575:   Pointers would be appreciated.
        !          2576: 
        !          2577:   Sean McLinden
        !          2578:   Decision Systems Lab
        !          2579: -------
        !          2580: 
        !          2581: From mike@rand-unix  Mon Jan 24 18:47:03 1983
        !          2582: Date: Monday, 24 Jan 1983 15:34-PST
        !          2583: From: mike@RAND-UNIX
        !          2584: Subject: emacs interface to franz?
        !          2585: Message-Id: <[email protected]>
        !          2586: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2587:        id AA00058; 24 Jan 83 16:08:36 PST (Mon)
        !          2588: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2589:        id AA00921; 24-Jan-83 18:47:03-PST (Mon)
        !          2590: To: franz-friends@BERKELEY
        !          2591: Status: O
        !          2592: 
        !          2593: 
        !          2594: Does anyone have a snazzy interface to emacs for franz?  
        !          2595: 
        !          2596: Thanks,
        !          2597:   Michael
        !          2598: 
        !          2599: 
        !          2600: From @udel-relay.ARPA,@UDel-Relay:[email protected]  Tue Jan 25 16:29:19 1983
        !          2601: Date: 25 Jan 1983  9:58-EST
        !          2602: From: Tim Finin <Tim.UPenn@UDel-Relay>
        !          2603: Subject: emacs interface to franz?
        !          2604: Message-Id: <[email protected]>
        !          2605: Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2606:        id AA29320; 25 Jan 83 16:22:57 PST (Tue)
        !          2607: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2608:        id AA01561; 25-Jan-83 16:29:19-PST (Tue)
        !          2609: Return-Path: <[email protected]@UDel-Relay>
        !          2610: To: mike@Rand-Unix
        !          2611: Cc: franz-friends@BERKELEY
        !          2612: Via:  UPenn; 25 Jan 83 19:21-EST
        !          2613: Status: O
        !          2614: 
        !          2615: 
        !          2616: We have a simple interface from Franz to Emacs, but I much prefer to go the
        !          2617: other way, i.e. run Franz as a inferior job under Emacs.  I believe there
        !          2618: are several Emacs packages which allow one to run inferior jobs in an Emacs
        !          2619: window (I have my own which is, unfortunately totally undocumented). Some of
        !          2620: the benefits of this set up include:
        !          2621: 
        !          2622:     - one has all of the text editing functions available in Emacs
        !          2623:     - one has many lisp-based editing functions available in Emacs
        !          2624:       (thru mock-lisp packages like electriclisp)
        !          2625:     - one has a history of the session in the editing buffer
        !          2626:     - one has an environment which supports multiple concurrent
        !          2627:       processes running in seperate windows.
        !          2628:     - it is very easy to experiment with new interface features such as
        !          2629:       symbol completion and re-evaluation of previously issued commands
        !          2630:     
        !          2631: Tim
        !          2632:     
        !          2633: 
        !          2634: From CARR@UTAH-20  Fri Jan 28 08:19:08 1983
        !          2635: Date: 28 Jan 1983 0912-MST
        !          2636: From: Harold Carr <CARR@UTAH-20>
        !          2637: Subject: franz distribution
        !          2638: Message-Id: <[email protected]>
        !          2639: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2640:        id AA20646; 28 Jan 83 08:15:18 PST (Fri)
        !          2641: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2642:        id AA16991; 28-Jan-83 08:19:08-PST (Fri)
        !          2643: To: franz-friends@UCBVAX
        !          2644: Status: O
        !          2645: 
        !          2646: What is the distribution policy?
        !          2647: 
        !          2648: I work for a company that has opus 36 and is now currently running opus 37.
        !          2649: Here at the University of Utah we are running opus 38.04. Is it OK to
        !          2650: make a tape of the University's 38.04 to bring my company more up to
        !          2651: date? Do I have to make it more formal by signing a transfer agreement
        !          2652: or by obtaining the release directly from Berkeley?
        !          2653: 
        !          2654:                               Thanks in advance,
        !          2655:                                  Harold Carr
        !          2656:                                 CARR@UTAH-20
        !          2657: -------
        !          2658: 
        !          2659: From UCBKIM:jkf  Fri Jan 28 15:09:32 1983
        !          2660: Date: 28-Jan-83 08:34:33-PST (Fri)
        !          2661: From: UCBKIM:jkf
        !          2662: Subject: Re: franz distribution
        !          2663: Message-Id: <[email protected]>
        !          2664: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2665:        id AA17319; 28-Jan-83 08:34:33-PST (Fri)
        !          2666: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2667:        id AA02275; 28 Jan 83 14:58:37 PST (Fri)
        !          2668: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2669:        id AA00402; 28-Jan-83 15:09:32-PST (Fri)
        !          2670: To: CARR@UTAH-20
        !          2671: Cc: franz-friends@UCBVAX
        !          2672: In-Reply-To: Your message of 28 Jan 1983 0912-MST
        !          2673: Status: O
        !          2674: 
        !          2675:   Here is our current distribution policy.  This differs a bit from
        !          2676: the one sent out a month ago [in particular, we now have anonymous ftp]
        !          2677: 
        !          2678:                                    -[Fri Jan 28 08:31:45 1983 by jkf]-
        !          2679:        Franz Lisp Distribution
        !          2680:        
        !          2681:   This note describes our distribution policy for Franz Lisp.
        !          2682: 
        !          2683: What is being distributed:
        !          2684:   We distribute only source code in order to keep the distribution
        !          2685:   small and relatively Unix independent.   Makefiles are provided to
        !          2686:   build the entire lisp system from source, even if you don't have
        !          2687:   a version of lisp running already.  This process takes about 3 cpu
        !          2688:   hours on a Vax 780.  [This version for the Vax only, a 68000 version
        !          2689:   is being worked on.  Contact ucbkim.sklower@berkeley or 
        !          2690:   ucbkim.layer@berkeley]
        !          2691: 
        !          2692:   The following source is provided:
        !          2693:     lisp interpreter, 
        !          2694:     compiler (liszt),
        !          2695:     cross reference program (lxref),
        !          2696:     lisp manual,
        !          2697:     and other utility programs:
        !          2698:        trace, step, debug, cmu library functions, (and other minor ones),
        !          2699:        and these packages from the MIT lisp library:
        !          2700:            defstruct, loop. 
        !          2701:            [These programs are provided as a convenience to those who can't
        !          2702:             access the arpanet and copy them.  There is no documentation for
        !          2703:             them in the Franz Lisp manual.  The best source of documentation
        !          2704:             is the Lisp Machine manual (available from MIT, Symbolics
        !          2705:             or LMI)]
        !          2706: 
        !          2707:    Regarding Flavors:  there are two implementations of flavors for
        !          2708:        Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
        !          2709:        and one from the University of Maryland (contact person
        !          2710:        Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
        !          2711:        exactly like flavors on the Lisp Machine (due to differences between
        !          2712:        Lisp Machine lisp and Franz Lisp), and the implementations differ
        !          2713:        from each other.    The MIT version cannot be distributed by 
        !          2714:        us (yet) due to licensing problems.   If you have a Lisp Machine
        !          2715:        Source license from Symbolics, you should be able to get a copy
        !          2716:        from MIT.
        !          2717:        For a Tech Report on Maryland flavors, write to Liz Allen.
        !          2718: 
        !          2719: What is the form of the distribution:
        !          2720:   The files are packaged in a giant (2.1Mbyte) shell script.  Running this
        !          2721: shell script through 'sh' will result in a directory tree.  A ReadMe file
        !          2722: in the current directory will contain instructions on building the lisp
        !          2723: system.  The shell script is broken into a number of smaller files.
        !          2724: The current distribution looks like:
        !          2725: 
        !          2726: total 2089
        !          2727:  489 -rw-r--r--  1 jkf        500003 Jan 26 11:33 opus38.50.aa
        !          2728:  489 -rw-r--r--  1 jkf        500002 Jan 26 11:35 opus38.50.ab
        !          2729:  489 -rw-r--r--  1 jkf        500047 Jan 26 11:37 opus38.50.ac
        !          2730:  489 -rw-r--r--  1 jkf        500007 Jan 26 11:38 opus38.50.ad
        !          2731:  133 -rw-r--r--  1 jkf        136038 Jan 26 11:39 opus38.50.ae
        !          2732: 
        !          2733: The '38.50' means Opus 38, minor version 50.  These numbers may be different
        !          2734: by the time you get your distribution.  In order to extract the lisp
        !          2735: files from this shell script, you need only type:
        !          2736:        cat * | sh
        !          2737: 
        !          2738: 
        !          2739: To get a copy of the distribution:
        !          2740:   The distribution may be obtained either using FTP from an arpanet site,
        !          2741: or on a magnetic tape through the U.S Mail.
        !          2742: 
        !          2743:  Arpanet:
        !          2744:    The files are stored on the arpanet host 'ucb-vax' [ if you have an out
        !          2745:    of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
        !          2746:    internet number is 10.2.0.78].
        !          2747:    You can login as 'anonymous'.   Use your name as the password.
        !          2748:    The files are in the subdirectory pub/lisp.
        !          2749:    
        !          2750:    For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
        !          2751: 
        !          2752:  Mag Tape:
        !          2753:    In order to get a copy of the distribution mailed to you, send a check to
        !          2754:  cover our tape copying and mailing costs (fees are listed below).  We will
        !          2755:  purchase the mag tape and you are free to keep it.  Please do NOT
        !          2756:  send us a tape.
        !          2757: 
        !          2758:      Fees:
        !          2759:                $50     - distribution tape mailed 3rd class
        !          2760:            add $10     - a copy of the Lisp Manual (we will only
        !          2761:                          send one copy, you are free to photocopy it)
        !          2762:            add $7      - send tape via 1st class mail.
        !          2763: 
        !          2764:             -or-
        !          2765:                $15     - for just a copy of the Lisp Manual
        !          2766: 
        !          2767:  The address to send checks to is 
        !          2768: 
        !          2769:        Keith Sklower
        !          2770:        EECS/Computer Science Division
        !          2771:        524 Evans Hall
        !          2772:        University of California
        !          2773:        Berkeley, CA  94720
        !          2774: 
        !          2775:  All checks should be made out to "Regents, University of California."
        !          2776:  We require pre-payment.  We will not invoice or process purchase orders.
        !          2777: 
        !          2778: 
        !          2779: 
        !          2780: Disclaimers:
        !          2781:     This distribution works on the latest versions of Unix running at
        !          2782:     Berkeley (4.1a).  We can't guarantee that it will work on older
        !          2783:     versions (although, if you are running 4.1, it is almost certain
        !          2784:     that it will work, but we have not verified it).
        !          2785:     VMS users who are using a typical Unix compatibility package will 
        !          2786:     probably not be able to build a lisp from this distribution unless they
        !          2787:     know a great deal about VMS and their compatibility package.
        !          2788:     At least one package (Eunice) supports Franz at this time.
        !          2789:     
        !          2790: Redistribution:
        !          2791:     If you get a copy of the distribution, you are free to give it to
        !          2792:     other people.  We appreciate being informed of new sites so they
        !          2793:     can be put on a mailing list (electronic and conventional).  This
        !          2794:     list is used to announce new releases.  To be put on this list,
        !          2795:     send U.S. Mail to Keith Sklower (address above) or to 
        !          2796:     franz-friends-request@berkeley or ucbvax!franz-friends-request
        !          2797: 
        !          2798: 
        !          2799: 
        !          2800: From Kim:fateman  Sun Jan 30 02:12:28 1983
        !          2801: Date: 28 Jan 83 08:32:08 PST (Fri)
        !          2802: From: Kim:fateman (Richard Fateman)
        !          2803: Subject: Re:  franz distribution
        !          2804: Message-Id: <[email protected]>
        !          2805: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2806:        id AA21039; 28 Jan 83 08:31:58 PST (Fri)
        !          2807: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2808:        id AA10132; 30-Jan-83 02:12:28-PST (Sun)
        !          2809: To: CARR@UTAH-20
        !          2810: Cc: franz-friends@ucbvax
        !          2811: Status: O
        !          2812: 
        !          2813: Our policy is that you may move copies of Franz elsewhere
        !          2814: without notifying us.  We continue to be interested in sharing anything
        !          2815: you or your company wish to provide us, in suggestions, programs, etc.
        !          2816: 
        !          2817: 
        !          2818: From UCBCAD:pettengi  Sun Jan 30 02:33:52 1983
        !          2819: Date: 28-Jan-83 10:54:51-PST (Fri)
        !          2820: From: UCBCAD:pettengi (Rob Pettengill)
        !          2821: Subject: emacs interface to franz?
        !          2822: Message-Id: <[email protected]>
        !          2823: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
        !          2824:        id AA26156; 28-Jan-83 10:54:51-PST (Fri)
        !          2825: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2826:        id AA00374; 28 Jan 83 12:53:44 PST (Fri)
        !          2827: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2828:        id AA10578; 30-Jan-83 02:33:52-PST (Sun)
        !          2829: To: mike@rand-unix, franz-friends@ucbvax
        !          2830: Cc: pettengi@UCBCAD
        !          2831: Status: O
        !          2832: 
        !          2833:        While I was at TI I used a very nice interface that let one start up
        !          2834: a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
        !          2835: under our VMS.  Try Kashtan@SRI-AI.
        !          2836: 
        !          2837: Rob Pettengill
        !          2838: E-Systems, Dallas, Tx.
        !          2839: 
        !          2840: From UCBKIM:jkf  Sun Jan 30 02:44:27 1983
        !          2841: Date: 28-Jan-83 08:34:33-PST (Fri)
        !          2842: From: UCBKIM:jkf (John Foderaro)
        !          2843: Subject: Re: franz distribution
        !          2844: Message-Id: <[email protected]>
        !          2845: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2846:        id AA17319; 28-Jan-83 08:34:33-PST (Fri)
        !          2847: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2848:        id AA02275; 28 Jan 83 14:58:37 PST (Fri)
        !          2849: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2850:        id AA10772; 30-Jan-83 02:44:27-PST (Sun)
        !          2851: To: CARR@UTAH-20
        !          2852: Cc: franz-friends@UCBVAX
        !          2853: In-Reply-To: Your message of 28 Jan 1983 0912-MST
        !          2854: Status: RO
        !          2855: 
        !          2856:   Here is our current distribution policy.  This differs a bit from
        !          2857: the one sent out a month ago [in particular, we now have anonymous ftp]
        !          2858: 
        !          2859:                                    -[Fri Jan 28 08:31:45 1983 by jkf]-
        !          2860:        Franz Lisp Distribution
        !          2861:        
        !          2862:   This note describes our distribution policy for Franz Lisp.
        !          2863: 
        !          2864: What is being distributed:
        !          2865:   We distribute only source code in order to keep the distribution
        !          2866:   small and relatively Unix independent.   Makefiles are provided to
        !          2867:   build the entire lisp system from source, even if you don't have
        !          2868:   a version of lisp running already.  This process takes about 3 cpu
        !          2869:   hours on a Vax 780.  [This version for the Vax only, a 68000 version
        !          2870:   is being worked on.  Contact ucbkim.sklower@berkeley or 
        !          2871:   ucbkim.layer@berkeley]
        !          2872: 
        !          2873:   The following source is provided:
        !          2874:     lisp interpreter, 
        !          2875:     compiler (liszt),
        !          2876:     cross reference program (lxref),
        !          2877:     lisp manual,
        !          2878:     and other utility programs:
        !          2879:        trace, step, debug, cmu library functions, (and other minor ones),
        !          2880:        and these packages from the MIT lisp library:
        !          2881:            defstruct, loop. 
        !          2882:            [These programs are provided as a convenience to those who can't
        !          2883:             access the arpanet and copy them.  There is no documentation for
        !          2884:             them in the Franz Lisp manual.  The best source of documentation
        !          2885:             is the Lisp Machine manual (available from MIT, Symbolics
        !          2886:             or LMI)]
        !          2887: 
        !          2888:    Regarding Flavors:  there are two implementations of flavors for
        !          2889:        Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
        !          2890:        and one from the University of Maryland (contact person
        !          2891:        Liz Allen  (liz.umcp-cs@udel-relay)).  Neither implementation is
        !          2892:        exactly like flavors on the Lisp Machine (due to differences between
        !          2893:        Lisp Machine lisp and Franz Lisp), and the implementations differ
        !          2894:        from each other.    The MIT version cannot be distributed by 
        !          2895:        us (yet) due to licensing problems.   If you have a Lisp Machine
        !          2896:        Source license from Symbolics, you should be able to get a copy
        !          2897:        from MIT.
        !          2898:        For a Tech Report on Maryland flavors, write to Liz Allen.
        !          2899: 
        !          2900: What is the form of the distribution:
        !          2901:   The files are packaged in a giant (2.1Mbyte) shell script.  Running this
        !          2902: shell script through 'sh' will result in a directory tree.  A ReadMe file
        !          2903: in the current directory will contain instructions on building the lisp
        !          2904: system.  The shell script is broken into a number of smaller files.
        !          2905: The current distribution looks like:
        !          2906: 
        !          2907: total 2089
        !          2908:  489 -rw-r--r--  1 jkf        500003 Jan 26 11:33 opus38.50.aa
        !          2909:  489 -rw-r--r--  1 jkf        500002 Jan 26 11:35 opus38.50.ab
        !          2910:  489 -rw-r--r--  1 jkf        500047 Jan 26 11:37 opus38.50.ac
        !          2911:  489 -rw-r--r--  1 jkf        500007 Jan 26 11:38 opus38.50.ad
        !          2912:  133 -rw-r--r--  1 jkf        136038 Jan 26 11:39 opus38.50.ae
        !          2913: 
        !          2914: The '38.50' means Opus 38, minor version 50.  These numbers may be different
        !          2915: by the time you get your distribution.  In order to extract the lisp
        !          2916: files from this shell script, you need only type:
        !          2917:        cat * | sh
        !          2918: 
        !          2919: 
        !          2920: To get a copy of the distribution:
        !          2921:   The distribution may be obtained either using FTP from an arpanet site,
        !          2922: or on a magnetic tape through the U.S Mail.
        !          2923: 
        !          2924:  Arpanet:
        !          2925:    The files are stored on the arpanet host 'ucb-vax' [ if you have an out
        !          2926:    of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
        !          2927:    internet number is 10.2.0.78].
        !          2928:    You can login as 'anonymous'.   Use your name as the password.
        !          2929:    The files are in the subdirectory pub/lisp.
        !          2930:    
        !          2931:    For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
        !          2932: 
        !          2933:  Mag Tape:
        !          2934:    In order to get a copy of the distribution mailed to you, send a check to
        !          2935:  cover our tape copying and mailing costs (fees are listed below).  We will
        !          2936:  purchase the mag tape and you are free to keep it.  Please do NOT
        !          2937:  send us a tape.
        !          2938: 
        !          2939:      Fees:
        !          2940:                $50     - distribution tape mailed 3rd class
        !          2941:            add $10     - a copy of the Lisp Manual (we will only
        !          2942:                          send one copy, you are free to photocopy it)
        !          2943:            add $7      - send tape via 1st class mail.
        !          2944: 
        !          2945:             -or-
        !          2946:                $15     - for just a copy of the Lisp Manual
        !          2947: 
        !          2948:  The address to send checks to is 
        !          2949: 
        !          2950:        Keith Sklower
        !          2951:        EECS/Computer Science Division
        !          2952:        524 Evans Hall
        !          2953:        University of California
        !          2954:        Berkeley, CA  94720
        !          2955: 
        !          2956:  All checks should be made out to "Regents, University of California."
        !          2957:  We require pre-payment.  We will not invoice or process purchase orders.
        !          2958: 
        !          2959: 
        !          2960: 
        !          2961: Disclaimers:
        !          2962:     This distribution works on the latest versions of Unix running at
        !          2963:     Berkeley (4.1a).  We can't guarantee that it will work on older
        !          2964:     versions (although, if you are running 4.1, it is almost certain
        !          2965:     that it will work, but we have not verified it).
        !          2966:     VMS users who are using a typical Unix compatibility package will 
        !          2967:     probably not be able to build a lisp from this distribution unless they
        !          2968:     know a great deal about VMS and their compatibility package.
        !          2969:     At least one package (Eunice) supports Franz at this time.
        !          2970:     
        !          2971: Redistribution:
        !          2972:     If you get a copy of the distribution, you are free to give it to
        !          2973:     other people.  We appreciate being informed of new sites so they
        !          2974:     can be put on a mailing list (electronic and conventional).  This
        !          2975:     list is used to announce new releases.  To be put on this list,
        !          2976:     send U.S. Mail to Keith Sklower (address above) or to 
        !          2977:     franz-friends-request@berkeley or ucbvax!franz-friends-request
        !          2978: 
        !          2979: 
        !          2980: 
        !          2981: From Kim:fateman  Mon Jan 31 19:30:20 1983
        !          2982: Date: 28 Jan 83 08:32:08 PST (Fri)
        !          2983: From: Kim:fateman (Richard Fateman)
        !          2984: Subject: Re:  franz distribution
        !          2985: Message-Id: <[email protected]>
        !          2986: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          2987:        id AA21039; 28 Jan 83 08:31:58 PST (Fri)
        !          2988: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          2989:        id AA03502; 31-Jan-83 19:30:20-PST (Mon)
        !          2990: To: CARR@UTAH-20
        !          2991: Cc: franz-friends@ucbvax
        !          2992: Status: O
        !          2993: 
        !          2994: Our policy is that you may move copies of Franz elsewhere
        !          2995: without notifying us.  We continue to be interested in sharing anything
        !          2996: you or your company wish to provide us, in suggestions, programs, etc.
        !          2997: 
        !          2998: 
        !          2999: From UCBCAD:pettengi  Mon Jan 31 19:55:02 1983
        !          3000: Date: 28-Jan-83 10:54:51-PST (Fri)
        !          3001: From: UCBCAD:pettengi (Rob Pettengill)
        !          3002: Subject: emacs interface to franz?
        !          3003: Message-Id: <[email protected]>
        !          3004: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
        !          3005:        id AA26156; 28-Jan-83 10:54:51-PST (Fri)
        !          3006: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3007:        id AA00374; 28 Jan 83 12:53:44 PST (Fri)
        !          3008: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3009:        id AA03987; 31-Jan-83 19:55:02-PST (Mon)
        !          3010: To: mike@rand-unix, franz-friends@ucbvax
        !          3011: Cc: pettengi@UCBCAD
        !          3012: Status: O
        !          3013: 
        !          3014:        While I was at TI I used a very nice interface that let one start up
        !          3015: a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
        !          3016: under our VMS.  Try Kashtan@SRI-AI.
        !          3017: 
        !          3018: Rob Pettengill
        !          3019: E-Systems, Dallas, Tx.
        !          3020: 
        !          3021: From Kim:fateman  Mon Jan 31 21:34:44 1983
        !          3022: Date: 28 Jan 83 08:32:08 PST (Fri)
        !          3023: From: Kim:fateman (Richard Fateman)
        !          3024: Subject: Re:  franz distribution
        !          3025: Message-Id: <[email protected]>
        !          3026: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3027:        id AA21039; 28 Jan 83 08:31:58 PST (Fri)
        !          3028: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3029:        id AA00642; 31-Jan-83 21:34:44-PST (Mon)
        !          3030: To: CARR@UTAH-20
        !          3031: Cc: franz-friends@ucbvax
        !          3032: Status: RO
        !          3033: 
        !          3034: Our policy is that you may move copies of Franz elsewhere
        !          3035: without notifying us.  We continue to be interested in sharing anything
        !          3036: you or your company wish to provide us, in suggestions, programs, etc.
        !          3037: 
        !          3038: 
        !          3039: From UCBCAD:pettengi  Mon Jan 31 22:12:30 1983
        !          3040: Date: 28-Jan-83 10:54:51-PST (Fri)
        !          3041: From: UCBCAD:pettengi (Rob Pettengill)
        !          3042: Subject: emacs interface to franz?
        !          3043: Message-Id: <[email protected]>
        !          3044: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
        !          3045:        id AA26156; 28-Jan-83 10:54:51-PST (Fri)
        !          3046: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3047:        id AA00374; 28 Jan 83 12:53:44 PST (Fri)
        !          3048: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3049:        id AA01266; 31-Jan-83 22:12:30-PST (Mon)
        !          3050: To: mike@rand-unix, franz-friends@ucbvax
        !          3051: Cc: pettengi@UCBCAD
        !          3052: Status: O
        !          3053: 
        !          3054:        While I was at TI I used a very nice interface that let one start up
        !          3055: a Franz lisp inside an Emacs window.  It came from SRI when we got Eunice to run
        !          3056: under our VMS.  Try Kashtan@SRI-AI.
        !          3057: 
        !          3058: Rob Pettengill
        !          3059: E-Systems, Dallas, Tx.
        !          3060: 
        !          3061: From UCBKIM:jkf  Tue Feb  1 10:35:21 1983
        !          3062: Date: 1-Feb-83 10:32:24-PST (Tue)
        !          3063: From: UCBKIM:jkf (John Foderaro)
        !          3064: Subject: multiple messages
        !          3065: Message-Id: <[email protected]>
        !          3066: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3067:        id AA00599; 1-Feb-83 10:32:24-PST (Tue)
        !          3068: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3069:        id AA00473; 1 Feb 83 10:32:35 PST (Tue)
        !          3070: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3071:        id AA00644; 1-Feb-83 10:35:21-PST (Tue)
        !          3072: To: franz-friends@ucbvax
        !          3073: Status: RO
        !          3074: 
        !          3075:   I'm sorry for the multiple messages.  The franz-friends mailing list is
        !          3076: huge and the machine which does the mailing is crashing often.  Our local
        !          3077: mail wizard informs me that if it crashes while in the middle of sending
        !          3078: mail it will not have a record of who it sent to before the crash.
        !          3079:   I hope you don't get too many copies of this message.
        !          3080:   
        !          3081:   
        !          3082: 
        !          3083: 
        !          3084: 
        !          3085: From mike@rand-unix  Wed Feb  2 05:33:01 1983
        !          3086: Date: Tuesday,  1 Feb 1983 15:06-PST
        !          3087: From: mike@RAND-UNIX
        !          3088: Subject: response to "emacs interface to franz?"
        !          3089: Message-Id: <[email protected]>
        !          3090: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3091:        id AA00221; 2 Feb 83 05:25:50 PST (Wed)
        !          3092: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3093:        id AA24463; 2-Feb-83 05:33:01-PST (Wed)
        !          3094: To: franz-friends@BERKELEY
        !          3095: Cc: mike@RAND-UNIX
        !          3096: Status: RO
        !          3097: 
        !          3098: 
        !          3099: Here are the responses that I received to my question "What's out
        !          3100: there for emacs?"  
        !          3101: 
        !          3102: 
        !          3103: ------- Forwarded Messages
        !          3104: 
        !          3105: Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983
        !          3106: Date: Mon 24 Jan 83 22:43:01-PST
        !          3107: From: Jay Lark <[email protected]>
        !          3108: Subject: Re: emacs interface to franz?
        !          3109: To: [email protected]
        !          3110: In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST
        !          3111: 
        !          3112: I'm sure you've probably received several messages similar to this one,
        !          3113: but just in case...
        !          3114: 
        !          3115: There exists the capability in Unix Emacs to run a process in its own
        !          3116: buffer.  Typein can be directed to the process, and output is just sent
        !          3117: right to the buffer.  This is an excellent way of running Lisp, because 
        !          3118: you get all of the nice Emacs features (paren balancing, local sexpr
        !          3119: editing) at essentially no cost.  I have been largely unsuccessful with
        !          3120: trying to run Emacs under Lisp.
        !          3121: 
        !          3122: The process package is part of the standard Unix Emacs distribution.
        !          3123: 
        !          3124: Jay Lark
        !          3125: -------
        !          3126: 
        !          3127: 
        !          3128: ------- Message 2
        !          3129: 
        !          3130: Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983
        !          3131: Date: 25 Jan 1983 7:20-MST
        !          3132: From: Russ Fish <utah-gr!fish@UTAH-CS> (host 10.0.0.4)
        !          3133: Subject: Re: emacs interface to franz?
        !          3134: To: mike@RAND-UNIX
        !          3135: Cc: utah-gr!galway@UTAH-CS
        !          3136: In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST
        !          3137: 
        !          3138: We have been running our PSL (Portable Standard Lisp) in gemacs
        !          3139: (Gosling's emacs) windows for some time.  I suspect it would be a minor
        !          3140: hack to convert it to Franz, but haven't done it and am not a Franz
        !          3141: user.  I could mail you our .ml code if you wanted to undertake
        !          3142: converting it to Franz (or just using it for inspiration and hacking
        !          3143: your own) and distributing it to Franz folks.
        !          3144: 
        !          3145: It works like this:  The lisp process is associated with a gemacs
        !          3146: buffer/window.  In that window you can carry on a normal line-by-line
        !          3147: conversation, if you wish.  <CR> sends the current line, (back to mark,
        !          3148: which is left after the prompt) into the lisp.  We mostly use the PSL
        !          3149: in Rlisp syntax, which is algol-like, but this part of the code is just
        !          3150: a wrapping for the new-shell function in process.ml with appropriate
        !          3151: editting syntax set, so you could do the same with no work for any
        !          3152: Lisp.
        !          3153: 
        !          3154: You can send an expression, fn def, etc. from any other lisp-mode
        !          3155: window with a single keypress.  Echoing as input in the dialog window
        !          3156: is inhibited if a prefix arg is provided, so you don't have to look at
        !          3157: long exprs or fn defs again, just the lisp response.  
        !          3158: 
        !          3159: Sending multiple line exprs in response to a single prompt depends on
        !          3160: the fact that PSL numbers the prompts for history, like the c-shell.  A
        !          3161: gemacs mlisp output filter process monitors the output for toploop
        !          3162: prompts and feeds another line of input if the same prompt number comes
        !          3163: back, instead of printing the prompt.
        !          3164: 
        !          3165: The result is pretty classy.  You get the full many-window gemacs
        !          3166: editing environment with tags, etc. for random-access navigation and
        !          3167: just send chunks of code as you change them.  The extreme of usage is
        !          3168: "menu" like windows which contain debugging code in clusters rather
        !          3169: than sequences.  You select exprs with the cursor and send them in any
        !          3170: order.
        !          3171: 
        !          3172: We also provide key fns for the common case of sending single lines to
        !          3173: the toploop or single-character commands to the break-loop without
        !          3174: editting them into a buffer.
        !          3175: 
        !          3176: Best respond directly to me, since I am not on Franz-Friends.
        !          3177: 
        !          3178: -Russ Fish  (Fish@Utah-20, utah-cs!fish)
        !          3179: 
        !          3180: 
        !          3181: 
        !          3182: ------- Message 3
        !          3183: 
        !          3184: Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983
        !          3185: Return-Path: <israel.umcp-cs@UDel-Relay>
        !          3186: Date:     25 Jan 83 15:13:51 EST  (Tue)
        !          3187: From: Bruce Israel <israel.umcp-cs@UDel-Relay>
        !          3188: Subject:  Re:  emacs interface to franz?
        !          3189: To: mike@RAND-UNIX
        !          3190: In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX
        !          3191:                <[email protected]>
        !          3192: Via:  UMCP-CS; 25 Jan 83 20:45-EST
        !          3193: 
        !          3194: We have a few franz<->emacs interfaces, but I'm not sure what you mean.
        !          3195: One is the process.ml package that comes with gosling's emacs (the emacs
        !          3196: that I assume you are talking about).  With this package, you can run
        !          3197: franz inside a window from within emacs and have the facilities of an
        !          3198: editor along with lisp.  The other thing we have is a local Franz
        !          3199: package called the load1 package.  This package was written for
        !          3200: compiling flavors (like in the lisp machine; another local package)
        !          3201: and has a function called vi.  (vi 'lisp-function) will call the
        !          3202: editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the
        !          3203: file which contains the definition of the lisp function, positioning
        !          3204: the editor at the point in the file where the function is defined.  Upon
        !          3205: exiting the editor, it asks you if you want to reload the modified file.
        !          3206: To edit a function from a file this way, the file must have been load1'ed
        !          3207: previously so that the info on where the function is stored and what type
        !          3208: it is will have been saved.  Load1 will distinguish between different
        !          3209: types of functions, ie. defflavors, defmethods, defmacros, defuns etc.
        !          3210: and will search for the correct definition in the file.  Is this what
        !          3211: you mean?  If you like I can send you the four or five files necessary.
        !          3212: - Bruce
        !          3213: 
        !          3214: 
        !          3215: ------- Message 4
        !          3216: 
        !          3217: Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983
        !          3218: Date: 27 Jan 1983 09:44-EST
        !          3219: From: Carl.Ebeling@CMU-CS-VLSI
        !          3220: Subject: Re: emacs interface to franz?
        !          3221: To: mike@RAND-UNIX
        !          3222: Message-Id: <412526661/ce@CMU-CS-VLSI>
        !          3223: In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14    
        !          3224: 
        !          3225: I have an electric lisp package and process package for emacs.  It
        !          3226: includes 'zap-function-to-lisp' among other things.  It is for
        !          3227: Gosling's emacs and uses the subprocess facility.  I can mail them to
        !          3228: you if you like.
        !          3229:        Carl
        !          3230: 
        !          3231: 
        !          3232: ------- End of Forwarded Messages
        !          3233: 
        !          3234: From UCBKIM:jkf  Wed Feb  2 08:19:19 1983
        !          3235: Date: 2-Feb-83 08:14:21-PST (Wed)
        !          3236: From: UCBKIM:jkf (John Foderaro)
        !          3237: Subject: multiple messages fixed?
        !          3238: Message-Id: <[email protected]>
        !          3239: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3240:        id AA25937; 2-Feb-83 08:14:21-PST (Wed)
        !          3241: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3242:        id AA00384; 2 Feb 83 08:10:26 PST (Wed)
        !          3243: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3244:        id AA00477; 2 Feb 83 08:14:35 PST (Wed)
        !          3245: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3246:        id AA26020; 2-Feb-83 08:19:19-PST (Wed)
        !          3247: To: franz-friends@ucbvax
        !          3248: Status: RO
        !          3249: 
        !          3250:  I've broken the franz-friends mailing list over two machines.  I hope that
        !          3251: this will fix the problem of mail to franz-friends crashing ucbvax every
        !          3252: thirty minutes.   If you get multiple copies of this message, please do not
        !          3253: tell me about it, I will already know.
        !          3254: 
        !          3255: 
        !          3256: 
        !          3257: 
        !          3258: From jkf  Thu Feb 10 21:45:17 1983
        !          3259: Date: 10-Feb-83 21:45:17-PST (Thu)
        !          3260: From: jkf (John Foderaro)
        !          3261: Subject: liszt 8.21
        !          3262: Message-Id: <[email protected]>
        !          3263: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3264:        id AA16021; 10-Feb-83 21:45:17-PST (Thu)
        !          3265: To: local-lisp
        !          3266: Status: O
        !          3267: 
        !          3268:   more functions open coded: vsize, vsize-byte, vsize-word,
        !          3269:        vectorp, vectorip
        !          3270:        
        !          3271: 
        !          3272: 
        !          3273: From PSI.KROHNFELDT@UTAH-20  Fri Feb 11 15:09:11 1983
        !          3274: Date: 11 Feb 1983 1601-MST
        !          3275: From: Jed Krohnfeldt <PSI.KROHNFELDT@UTAH-20>
        !          3276: Subject: cfasl
        !          3277: Message-Id: <[email protected]>
        !          3278: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3279:        id AA07475; 11 Feb 83 15:02:05 PST (Fri)
        !          3280: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3281:        id AA07565; 11 Feb 83 15:06:37 PST (Fri)
        !          3282: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
        !          3283:        id AA14422; 11-Feb-83 15:09:11-PST (Fri)
        !          3284: To: Franz-friends@UCBVAX
        !          3285: Status: O
        !          3286: 
        !          3287: I am having trouble using cfasl in franz 38.04.  I keep getting the
        !          3288: message "ld: /usr/ucb/lisp : no namelist".  Can anyone decipher this
        !          3289: for me?  Thanks...
        !          3290: -------
        !          3291: 
        !          3292: From apm@cmu-ri-isl  Mon Feb 14 07:31:54 1983
        !          3293: Date: 14 Feb 1983 10:24:21-EST
        !          3294: From: Andrew.Mendler@CMU-RI-ISL
        !          3295: Subject: franz lisp under5 vms 3.0
        !          3296: Message-Id: <[email protected]>
        !          3297: Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3)
        !          3298:        id AA27879; 14 Feb 83 07:31:54 PST (Mon)
        !          3299: Received: by UCBKIM.ARPA (3.310/3.3)
        !          3300:        id AA01172; 14 Feb 83 15:50:41 PST (Mon)
        !          3301: To: [email protected]
        !          3302: Status: O
        !          3303: 
        !          3304: Does anyone have a copy of Franz Lisp and the compiler that works under
        !          3305: VMS version 3.0?  
        !          3306: 
        !          3307: From @udel-relay:tim.unc@UDel-Relay  Mon Feb 14 02:52:18 1983
        !          3308: Date:     13 Feb 83 14:34:48 EST  (Sun)
        !          3309: From: Tim Maroney <tim.unc@UDel-Relay>
        !          3310: Subject:  cfasl: no namelist
        !          3311: Return-Path: <tim.unc@UDel-Relay>
        !          3312: Message-Id: <[email protected]>
        !          3313: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3)
        !          3314:        id AA25792; 14 Feb 83 02:52:18 PST (Mon)
        !          3315: Received: by UCBKIM.ARPA (3.310/3.3)
        !          3316:        id AA02234; 14 Feb 83 16:18:42 PST (Mon)
        !          3317: To: [email protected]
        !          3318: Via:  UNC; 14 Feb 83 5:43-EST
        !          3319: Status: O
        !          3320: 
        !          3321: I don't seem to be able to write Jed Krohnfeldt, and this
        !          3322: answer is probably of general interest anyway. The message
        !          3323: "ld: no namelist" means that some well-meaning system admin
        !          3324: has stripped the lisp executable file to save space;
        !          3325: unfortunately, this makes the dynamic loading used by cfasl
        !          3326: impossible. Lisp will have to be recompiled (groan). No Franz
        !          3327: Lisp executable file should EVER be stripped.
        !          3328: 
        !          3329: Tim Maroney
        !          3330: tim.unc@udel-relay
        !          3331: decvax!duke!unc!tim
        !          3332: 
        !          3333: From Mark.Sherman@CMU-CS-A  Sat Feb 12 21:38:46 1983
        !          3334: Date: 13 February 1983 0034-EST (Sunday)
        !          3335: From: Mark.Sherman@CMU-CS-A
        !          3336: Subject: Space and Leakage
        !          3337: Message-Id: <13Feb83 003422 MS40@CMU-CS-A>
        !          3338: Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
        !          3339:        id AA07842; 12 Feb 83 21:38:46 PST (Sat)
        !          3340: Received: by UCBKIM.ARPA (3.310/3.3)
        !          3341:        id AA02341; 14 Feb 83 16:21:29 PST (Mon)
        !          3342: To: franz-friends@UCB-VAX
        !          3343: Status: O
        !          3344: 
        !          3345: Can someone tell me how the maximum amount of storage that franz
        !          3346: lisp uses is decided? I can force the size up to (about) 3050
        !          3347: pages (according to "ps") and then get the message "storage exhausted".
        !          3348: I have been told (and have seen) other jobs get substantially more
        !          3349: space; can franz get more pages as well? (I am using the cshell
        !          3350: and have already used the limit command to raise my process
        !          3351: size up to 32 megabytes, or so I think.)
        !          3352:  
        !          3353: I have also been told that the garbage collector leaks, that is,
        !          3354: not all of the garbage is really collected. Does anyone have good
        !          3355: ideas about how much (or fast) this happens, or if there is some way
        !          3356: to minimize the lost space?
        !          3357:  
        !          3358: (Please send responses directly to me as I am not on this list.)
        !          3359:                         -Mark Sherman (Sherman@CMU-CS-A)
        !          3360: 
        !          3361: From @udel-relay:Mac.uvacs.Virginia@UDel-Relay  Fri Feb 18 21:04:31 1983
        !          3362: Date:     18 Feb 83 12:42:40-EST (Fri)
        !          3363: From: Mac.uvacs@UDel-Relay
        !          3364: Subject:  global nonspecial variables
        !          3365: Return-Path: <Mac.uvacs.Virginia@UDel-Relay>
        !          3366: Message-Id: <[email protected]>
        !          3367: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5)
        !          3368:        id AA26020; 18 Feb 83 21:04:31 PST (Fri)
        !          3369: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3370:        id AA00656; 21 Feb 83 01:59:26 PST (Mon)
        !          3371: To: [email protected]
        !          3372: Via:  Virginia; 18 Feb 83 23:58-EST
        !          3373: Status: O
        !          3374: 
        !          3375: Does the Liszt compiler have any notion of global variables --
        !          3376: free variables with fast access, without any rebinding?
        !          3377: 
        !          3378: I think the MACLISP compiler has something like this for variables
        !          3379: beginning "**".
        !          3380: 
        !          3381:                                Alex Colvin
        !          3382: 
        !          3383:                                uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac
        !          3384:                                csnet:mac@virginia
        !          3385:                                arpa: mac.uvacs@udel-relay
        !          3386: 
        !          3387: From jkf@UCBKIM  Mon Feb 21 09:19:56 1983
        !          3388: Date: 21 Feb 83 09:19:43 PST (Mon)
        !          3389: From: jkf@UCBKIM (John Foderaro)
        !          3390: Subject: Re:  global nonspecial variables
        !          3391: Message-Id: <[email protected]>
        !          3392: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3393:        id AA02798; 21 Feb 83 09:19:43 PST (Mon)
        !          3394: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
        !          3395:        id AA13982; 21 Feb 83 09:11:52 PST (Mon)
        !          3396: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3397:        id AA02805; 21 Feb 83 09:19:56 PST (Mon)
        !          3398: To: Mac.uvacs@UDel-Relay, [email protected]
        !          3399: In-Reply-To: Your message of     18 Feb 83 12:42:40-EST (Fri)
        !          3400: Status: O
        !          3401: 
        !          3402:   I don't understand the distinction between what you call a global variable
        !          3403: and a special variable.   A special variable in Franz Lisp (and any other
        !          3404: shallow bound lisp) can be accessed rapidly and is only rebound if you
        !          3405: put it in a lambda, prog or do variable list.
        !          3406: 
        !          3407: 
        !          3408: 
        !          3409: From jkf@UCBKIM  Fri Feb 25 08:29:01 1983
        !          3410: Date: 25 Feb 83 08:28:45 PST (Fri)
        !          3411: From: jkf@UCBKIM (John Foderaro)
        !          3412: Subject: research position at edinburgh
        !          3413: Message-Id: <[email protected]>
        !          3414: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3415:        id AA00528; 25 Feb 83 08:28:45 PST (Fri)
        !          3416: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
        !          3417:        id AA00867; 25 Feb 83 08:18:48 PST (Fri)
        !          3418: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3419:        id AA00537; 25 Feb 83 08:29:01 PST (Fri)
        !          3420: To: [email protected]
        !          3421: Status: O
        !          3422: 
        !          3423: 
        !          3424:                     DEPARTMENT OF ARTIFICIAL INTELLIGENCE
        !          3425:                            UNIVERSITY OF EDINBURGH
        !          3426: 
        !          3427:                               RESEARCH FELLOW
        !          3428: 
        !          3429: A Research Fellowship is available within the Programming Systems Development
        !          3430: Group.  The post has been created specifically to provide a modern LISP system
        !          3431: for the Perq computer running under ICL MicroCode UNIX, and is funded by the
        !          3432: Science and Engineering Research Council.
        !          3433: 
        !          3434: Experience in implementing systems would be advantageous, as would be a
        !          3435: knowledge of LISP and C.  Access will be available to an SERC DECsystem-10
        !          3436: running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as
        !          3437: to Perqs.
        !          3438: 
        !          3439: The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds
        !          3440: sterling, according to age and experience.  The post is funded for a period of
        !          3441: two years from the date of appointment.
        !          3442: 
        !          3443: Further particulars of the post can be obtained from:
        !          3444: 
        !          3445:        Administrative Assistant
        !          3446:        Department of Artificial Intelligence
        !          3447:        University of Edinburgh
        !          3448:        Forrest Hill
        !          3449:        Edinburgh  EH1 2QL
        !          3450:        SCOTLAND
        !          3451: phone
        !          3452:        031-667-1011 x2554
        !          3453: 
        !          3454: or by contacting
        !          3455: 
        !          3456:        RAE%EDXA%UCL-CS@ISID            (Networks permitting)
        !          3457: 
        !          3458: Applications should be made by March 17th, 1983.
        !          3459: 
        !          3460: 
        !          3461: 
        !          3462: 
        !          3463: From layer  Sat Mar  5 20:12:57 1983
        !          3464: Date: 5 Mar 83 20:12:57 PST (Sat)
        !          3465: From: layer (Kevin Layer)
        !          3466: Subject: process function
        !          3467: Message-Id: <[email protected]>
        !          3468: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3469:        id AA18927; 5 Mar 83 20:12:57 PST (Sat)
        !          3470: Phone: (415) 652-2405
        !          3471: To: local-lisp
        !          3472: Status: O
        !          3473: 
        !          3474: The process function now looks in the environment at the SHELL variable.
        !          3475: If present, it will use this as the default shell to execute your command.
        !          3476: If not present, csh and then sh are tried (in that order).
        !          3477: 
        !          3478: 
        !          3479: From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay  Tue Mar  8 06:04:10 1983
        !          3480: Date:  8 Mar 1983  2:32-EST
        !          3481: From: Susan Pintzuk <Pintzuk.UPenn@UDel-Relay>
        !          3482: Subject: lisp statistical packages
        !          3483: Return-Path: <Pintzuk.UPenn.UPenn@UDel-Relay>
        !          3484: Message-Id: <[email protected]>
        !          3485: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14)
        !          3486:        id AA13004; 8 Mar 83 06:01:54 PST (Tue)
        !          3487: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3488:        id AA08297; 8 Mar 83 06:04:10 PST (Tue)
        !          3489: To: [email protected]
        !          3490: Via:  UPenn; 8 Mar 83 3:49-EST
        !          3491: Status: O
        !          3492: 
        !          3493: do any franz-lisp packages exist which calculate mean, standard deviation,
        !          3494: %n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.?  if so, how
        !          3495: do i obtain a copy?
        !          3496: 
        !          3497: From jkf  Tue Mar  8 09:10:46 1983
        !          3498: Date: 8 Mar 83 09:10:46 PST (Tue)
        !          3499: From: jkf (John Foderaro)
        !          3500: Subject: opus38.56
        !          3501: Message-Id: <[email protected]>
        !          3502: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3503:        id AA09423; 8 Mar 83 09:10:46 PST (Tue)
        !          3504: To: local-lisp
        !          3505: Status: O
        !          3506: 
        !          3507:   If $gcprint is set to a non nil value, then just before a garbage
        !          3508: collection is begun, the message 'gc:' will be printed on the tty.
        !          3509: As before, after the garbage collection is finished, the statistics
        !          3510: message in square brackets will be printed.
        !          3511: 
        !          3512: 
        !          3513: 
        !          3514: From fateman  Wed Mar  9 09:54:31 1983
        !          3515: Date: 9 Mar 83 09:54:31 PST (Wed)
        !          3516: From: fateman (Richard Fateman)
        !          3517: Subject: need a job 
        !          3518: Message-Id: <[email protected]>
        !          3519: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3520:        id AA14754; 9 Mar 83 09:54:31 PST (Wed)
        !          3521: To: local-lisp
        !          3522: Status: O
        !          3523: 
        !          3524: porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP
        !          3525: computer?  Wanna live in Denver?  There is a recruiter in
        !          3526: town from Denelcor at Marriot Inn, Jim Holly.  There is an
        !          3527: ad posted on 5th floor bulletin board.
        !          3528: 
        !          3529: From jkf  Sat Mar 19 17:44:33 1983
        !          3530: Date: 19 Mar 83 17:44:33 PST (Sat)
        !          3531: From: jkf (John Foderaro)
        !          3532: Subject: liszt 8.24
        !          3533: Message-Id: <[email protected]>
        !          3534: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3535:        id AA25091; 19 Mar 83 17:44:33 PST (Sat)
        !          3536: To: local-lisp
        !          3537: Status: O
        !          3538: 
        !          3539:   The vax and 68k versions of liszt have been combined into one set of
        !          3540: source files.  This is mainly a textual change, but some functions
        !          3541: in the compiler have been modified in reduce the machine dependent code.
        !          3542: Be on the lookout for strange errors.
        !          3543: 
        !          3544: 
        !          3545: 
        !          3546: From fateman  Tue Mar 22 20:52:11 1983
        !          3547: Date: 22 Mar 83 20:52:11 PST (Tue)
        !          3548: From: fateman (Richard Fateman)
        !          3549: Subject: T Lisp
        !          3550: Message-Id: <[email protected]>
        !          3551: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3552:        id AA05935; 22 Mar 83 20:52:11 PST (Tue)
        !          3553: To: local-lisp
        !          3554: Status: RO
        !          3555: 
        !          3556: I have a preliminary manual for the T dialect of Lisp, created
        !          3557: at Yale.  It is being offered for sale by Cognitive Systems, Inc.
        !          3558: for $1000/CPU (educational price).  It offers features from Lisp
        !          3559: and Scheme.  It runs on VAX and Apollo 68000 systems.  
        !          3560: 
        !          3561: From jkf  Thu Mar 24 08:29:31 1983
        !          3562: Date: 24 Mar 83 08:29:31 PST (Thu)
        !          3563: From: jkf (John Foderaro)
        !          3564: Subject: liszt 8.25
        !          3565: Message-Id: <[email protected]>
        !          3566: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3567:        id AA06735; 24 Mar 83 08:29:31 PST (Thu)
        !          3568: To: local-lisp
        !          3569: Status: O
        !          3570: 
        !          3571: 
        !          3572:   If you do this:
        !          3573: 
        !          3574:   liszt -x a/b/c.l -o x/y/z.o
        !          3575: 
        !          3576:   then the cross reference file will be put in x/y/z.x 
        !          3577:   Before this version, it would have gone into a/b/c.x
        !          3578:   
        !          3579: 
        !          3580: 
        !          3581: From jkf  Thu Mar 24 15:00:37 1983
        !          3582: Date: 24 Mar 83 15:00:37 PST (Thu)
        !          3583: From: jkf (John Foderaro)
        !          3584: Subject: liszt 8.26
        !          3585: Message-Id: <[email protected]>
        !          3586: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3587:        id AA11144; 24 Mar 83 15:00:37 PST (Thu)
        !          3588: To: local-lisp
        !          3589: Status: O
        !          3590: 
        !          3591:   liszt will now pass the assembler the -V switch.  This tells the assembler
        !          3592: to keep its intermediate file in core rather than putting it in /tmp.
        !          3593: This should make assembly slightly faster and also permit large lisp files to
        !          3594: be compiled on systems with small /tmp's.
        !          3595: 
        !          3596: 
        !          3597: 
        !          3598: From @udel-relay.ARPA:tim.unc@UDel-Relay  Sat Mar 26 03:41:05 1983
        !          3599: Date:     25 Mar 83 15:03:29 EST  (Fri)
        !          3600: From: Tim Maroney <tim.unc@UDel-Relay>
        !          3601: Subject:  open coding of (function (lambda ...))
        !          3602: Return-Path: <tim.unc@UDel-Relay>
        !          3603: Message-Id: <[email protected]>
        !          3604: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17)
        !          3605:        id AB02371; 26 Mar 83 03:37:13 PST (Sat)
        !          3606: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3607:        id AA00854; 26 Mar 83 03:41:05 PST (Sat)
        !          3608: To: [email protected]
        !          3609: Via:  UNC; 25 Mar 83 19:43-EST
        !          3610: Status: O
        !          3611: 
        !          3612: This doesn't seem to work. I'm using Liszt version 8.10, University
        !          3613: of Maryland distribution. The documentation in the file "lispnews"
        !          3614: is sketchy, but it seems that compiling and loading the file:
        !          3615: 
        !          3616: (setq appsum (function (lambda (x) (apply 'sum x))))
        !          3617: 
        !          3618: should leave a bcd object in appsum's value, but it doesn't. It
        !          3619: leaves the uncompiled lambda. Am I doing something wrong? 
        !          3620: 
        !          3621: Tim Maroney
        !          3622: decvax!duke!unc!tim
        !          3623: tim.unc@udel-relay
        !          3624: 
        !          3625: From jkf@UCBKIM  Sat Mar 26 08:46:44 1983
        !          3626: Date: 26 Mar 83 08:46:28 PST (Sat)
        !          3627: From: jkf@UCBKIM (John Foderaro)
        !          3628: Subject: Re:  open coding of (function (lambda ...))
        !          3629: Message-Id: <[email protected]>
        !          3630: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3631:        id AA02453; 26 Mar 83 08:46:28 PST (Sat)
        !          3632: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17)
        !          3633:        id AA05012; 26 Mar 83 08:42:50 PST (Sat)
        !          3634: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3635:        id AA02462; 26 Mar 83 08:46:44 PST (Sat)
        !          3636: To: tim.unc@UDel-Relay
        !          3637: Cc: [email protected]
        !          3638: In-Reply-To: Your message of     25 Mar 83 15:03:29 EST  (Fri)
        !          3639: Status: O
        !          3640: 
        !          3641: 
        !          3642:    Liszt only compiles functions, not literals it finds in files.
        !          3643: To make this statement be compiled:
        !          3644: (setq appsum (function (lambda (x) (apply 'sum x))))
        !          3645: 
        !          3646: you should surround it with a function defintion:
        !          3647: (defun junk ()
        !          3648:        (setq appsum (function (lambda (x) (apply 'sum x)))))
        !          3649: 
        !          3650: 
        !          3651: 
        !          3652: From CARR@UTAH-20  Mon Apr  4 14:53:09 1983
        !          3653: Date:  4 Apr 1983 0922-MST
        !          3654: From: Harold Carr <CARR@UTAH-20>
        !          3655: Subject: Franz/Common lisp
        !          3656: Message-Id: <[email protected]>
        !          3657: Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20)
        !          3658:        id AA07020; 4 Apr 83 09:11:40 PST (Mon)
        !          3659: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3660:        id AA01683; 4 Apr 83 14:53:09 PST (Mon)
        !          3661: To: [email protected]
        !          3662: Cc: KROHNFELDT@UTAH-20
        !          3663: Status: O
        !          3664: 
        !          3665: Does anyone have any sort of Common Lisp compatibility package for Franz?
        !          3666: If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20).
        !          3667: -------
        !          3668: 
        !          3669: From jeff@aids-unix  Tue Apr  5 12:42:46 1983
        !          3670: Date:  4 Apr 1983 11:06:49 PST (Monday)
        !          3671: From: Jeff Dean <jeff@aids-unix>
        !          3672: Subject: knowledge representation language
        !          3673: Message-Id: <[email protected]>
        !          3674: Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20)
        !          3675:        id AA26557; 5 Apr 83 12:42:11 PST (Tue)
        !          3676: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3677:        id AA16443; 5 Apr 83 12:42:46 PST (Tue)
        !          3678: To: [email protected]
        !          3679: Status: O
        !          3680: 
        !          3681: Does anyone have a knowledge representation language (such as FRL or
        !          3682: KL-ONE) available under Franz Lisp?
        !          3683: 
        !          3684:        Jeff Dean
        !          3685:        arpa: jeff@aids-unix
        !          3686:        uucp: ...ucbvax!jeff@aids-unix
        !          3687: 
        !          3688: 
        !          3689: From jkf  Tue Apr  5 13:08:06 1983
        !          3690: Date: 5 Apr 83 13:08:06 PST (Tue)
        !          3691: From: jkf (John Foderaro)
        !          3692: Subject: lisp opus 38.57
        !          3693: Message-Id: <[email protected]>
        !          3694: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3695:        id AA16969; 5 Apr 83 13:08:06 PST (Tue)
        !          3696: To: local-lisp
        !          3697: Status: RO
        !          3698: 
        !          3699:   This version has a number of internal changes to make it compilable
        !          3700: on 68k.  If you notice it acting abnormally, let me know.
        !          3701: 
        !          3702: 
        !          3703: 
        !          3704: From FAHLMAN@CMU-CS-C  Thu Apr  7 07:50:06 1983
        !          3705: Date: Thu, 7 Apr 1983  10:46 EST
        !          3706: From: Scott E. Fahlman <Fahlman@CMU-CS-C>
        !          3707: Subject: Franz/Common lisp
        !          3708: Message-Id: <[email protected]>
        !          3709: Received: ID <FAHLMAN@CMU-CS-C>; 7 Apr 83 10:46:59 EST
        !          3710: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20)
        !          3711:        id AA13873; 7 Apr 83 07:49:42 PST (Thu)
        !          3712: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3713:        id AA18082; 7 Apr 83 07:50:06 PST (Thu)
        !          3714: To: Harold Carr <CARR@UTAH-20>
        !          3715: Cc: [email protected]
        !          3716: In-Reply-To: Msg of 4 Apr 1983  11:22-EST from Harold Carr <CARR at UTAH-20>
        !          3717: Status: RO
        !          3718: 
        !          3719: 
        !          3720: Harold,
        !          3721: 
        !          3722: A couple of things make it seem unlikely that anyone would have such a
        !          3723: package right now.  First, we don't even have a final Common Lisp manual
        !          3724: yet -- Guy's next draft is due very soon, but there will be some tuning
        !          3725: and hassling after that.  Second, there are things in Common Lisp that
        !          3726: would be very tough to fake on Franz: lexical binding, generic
        !          3727: sequences, some of the hairy number types, character objects, etc.
        !          3728: Common Lisp is pretty close to being a superset of Franz, so I would
        !          3729: expect to see Franz compatibility packages in Common Lisp, but not vice
        !          3730: versa.  Third, if anyone were writing such a package, they would be
        !          3731: crazy not to have arranged for access to our code that implements all of
        !          3732: the hairy functions, and nobody has done this to my knowledge.
        !          3733: 
        !          3734: My standard advice is for people to continue to code in Franz with the
        !          3735: knowledge that they can easily convert their code to Common Lisp
        !          3736: whenever the DEC Common Lisp is available to them.  This should be a
        !          3737: one-time conversion, since moving the other way after "going native" in
        !          3738: Common Lisp would be very tough.
        !          3739: 
        !          3740: If someone does pop up with a compatibility package -- even a partial
        !          3741: one -- I would be interested in hearing about it.
        !          3742: 
        !          3743: -- Scott
        !          3744: 
        !          3745: From fateman@UCBKIM  Sun Apr 10 19:52:14 1983
        !          3746: Date: 10 Apr 83 19:50:59 PST (Sun)
        !          3747: From: fateman@UCBKIM (Richard Fateman)
        !          3748: Subject: Re:  Franz/Common lisp
        !          3749: Message-Id: <[email protected]>
        !          3750: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3751:        id AA06176; 10 Apr 83 19:50:59 PST (Sun)
        !          3752: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
        !          3753:        id AA10019; 10 Apr 83 19:49:55 PST (Sun)
        !          3754: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3755:        id AA06192; 10 Apr 83 19:52:14 PST (Sun)
        !          3756: To: carr@utah-20, fahlman@cmu-cs-c
        !          3757: Cc: [email protected]
        !          3758: Status: RO
        !          3759: 
        !          3760: I think that a common-lisp-compatibility package written
        !          3761: in Franz would not be as difficult as all that. 
        !          3762: 
        !          3763: If Common Lisp (TM of DEC?) were available on all the same
        !          3764: machines at the same price, (appx. $0.) and CL were
        !          3765: in fact a superset of Franz for all practical purposes, and
        !          3766: with similar or better efficiency, etc. Why would anyone bother?
        !          3767: 
        !          3768: Of course if CL does not meet all of the objectives (e.g. price, machines),
        !          3769: then a CL-to-Franz "translator" might make sense.
        !          3770: 
        !          3771: With that in mind,
        !          3772: I would like to officially request a copy of the Common Lisp
        !          3773: language (as implemented in CL, presumably), as soon as it
        !          3774: becomes available (i.e. no later than when it is a "product"
        !          3775: of DEC, and probably at "beta" test time).
        !          3776: I agree fully with Scott that trying to do this with an incomplete
        !          3777: language specification is unwise.
        !          3778: 
        !          3779: I am also not making any commitment to do anything with CL at
        !          3780: Berkeley, but since we are building tools for our own applications,
        !          3781: and CL might be useful, we might consider an efficient merge of
        !          3782: ideas.
        !          3783: 
        !          3784: From jkf@UCBKIM  Mon Apr 11 08:07:39 1983
        !          3785: Date: 11 Apr 83 06:42:43 PST (Mon)
        !          3786: From: jkf@UCBKIM (John Foderaro)
        !          3787: Subject: mail to this mailing list
        !          3788: Message-Id: <[email protected]>
        !          3789: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3790:        id AA11378; 11 Apr 83 06:42:43 PST (Mon)
        !          3791: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
        !          3792:        id AA07288; 11 Apr 83 08:05:32 PST (Mon)
        !          3793: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
        !          3794:        id AA11949; 11 Apr 83 08:07:39 PST (Mon)
        !          3795: To: [email protected]
        !          3796: Status: RO
        !          3797: 
        !          3798:   I'm sorry that people who mail to this mailing list must put up with lots
        !          3799:  of mail errors from our local mailer.   The problem is not that we have a
        !          3800:  lot of illegal addresses, but that over the three day period that the
        !          3801:  mailer tries to deliver the mail, some of the destination sites never
        !          3802:  respond.  I think that this is due primarily to the fact that many sites
        !          3803:  are running new mail and networking software.   Hopefully this will
        !          3804:  improve over time.
        !          3805:                                        john foderaro
        !          3806:                                        
        !          3807: 
        !          3808: 
        !          3809: 
        !          3810: From jkf  Fri Apr 22 09:59:09 1983
        !          3811: Date: 22 Apr 83 09:59:09 PST (Fri)
        !          3812: From: jkf (John Foderaro)
        !          3813: Subject: lisp opus 38.59
        !          3814: Message-Id: <[email protected]>
        !          3815: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3816:        id AA20996; 22 Apr 83 09:59:09 PST (Fri)
        !          3817: To: local-lisp
        !          3818: Status: RO
        !          3819: 
        !          3820:   Input like 1.2.3 and 1..2  will now be read as single symbols rather
        !          3821: than two consecutive numbers.
        !          3822: 
        !          3823: 
        !          3824: 
        !          3825: From jkf  Sun May  8 00:02:54 1983
        !          3826: Date: 8 May 83 00:02:54 PDT (Sun)
        !          3827: From: jkf (John Foderaro)
        !          3828: Subject: opus 38.60
        !          3829: Message-Id: <[email protected]>
        !          3830: Received: by UCBKIM.ARPA (3.310/3.5)
        !          3831:        id AA22344; 8 May 83 00:02:54 PDT (Sun)
        !          3832: To: local-lisp
        !          3833: Cc: rms
        !          3834: Status: RO
        !          3835: 
        !          3836:  Thanks to some suggestions from rms we are now one step closer to
        !          3837: full closures.   fclosures will now work if called recursively.
        !          3838: It is still true that the only way to make fclosures share variables
        !          3839: is to use fclosure-list.
        !          3840: 
        !          3841:  symeval-in-fclosure may return the wrong value if the closure is 
        !          3842: 'active'.  This will be fixed eventually.
        !          3843: 
        !          3844: 
        !          3845: 
        !          3846: From mbr@nprdc  Sat May 21 07:37:23 1983
        !          3847: Date: 20 May 1983 14:57:55-PDT
        !          3848: From: mbr@NPRDC
        !          3849: Subject: lam9.c and curses
        !          3850: Message-Id: <[email protected]>
        !          3851: Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29)
        !          3852:        id AA16172; 21 May 83 07:34:43 PDT (Sat)
        !          3853: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          3854:        id AA08856; 21 May 83 07:37:23 PDT (Sat)
        !          3855: Reply-To: mbr <mbr@NPRDC>
        !          3856: To: [email protected]
        !          3857: Cc: mbr@NPRDC
        !          3858: Status: O
        !          3859: 
        !          3860: When we attempted to cfasl a file that used the curses package
        !          3861: of screen control routines into Franz 38.40, we got the message
        !          3862: _ospeed: /usr/libcurses.a (cr_tty.o) multiply defined.
        !          3863: The apparent cause of this cryptic remark is that in lam9.c
        !          3864: there is an extern variable ospeed. There are a number of
        !          3865: tantalizing routines in this source file dealing with termcaps that
        !          3866: are apparently not called by anyone. Are there plans for these
        !          3867: routines? Does anyone use them (heaven forbid they should be
        !          3868: documented!). Our current fix is to just change ospeed to ospiid
        !          3869: which so far has had no dire effects, but I am interested in others
        !          3870: experience. The curses stuff seems to work fine after this
        !          3871: modification.
        !          3872:                        Mark Rosenstein
        !          3873: 
        !          3874: 
        !          3875: From jkf  Wed May 25 12:15:54 1983
        !          3876: Date: 25 May 83 12:15:54 PDT (Wed)
        !          3877: From: jkf (John Foderaro)
        !          3878: Subject: opus 38.61
        !          3879: Message-Id: <[email protected]>
        !          3880: Received: by UCBKIM.ARPA (3.340/3.5)
        !          3881:        id AA01144; 25 May 83 12:15:54 PDT (Wed)
        !          3882: To: local-lisp
        !          3883: Status: O
        !          3884: 
        !          3885:   symeval-in-fclosure and set-in-fclosure now work (thanks to keith).
        !          3886: 
        !          3887:   selectq is now a part of standard franz.  selectq is just like
        !          3888:  caseq except it allows 'otherwise' as well as 't' for the
        !          3889:  key which means 'if nothing else matches, use this clause'.
        !          3890:  
        !          3891:  
        !          3892: 
        !          3893: 
        !          3894: From cornwell@nrl-css  Wed May 25 12:51:17 1983
        !          3895: Date: Wed, 25 May 83 15:14:19 EDT
        !          3896: From: Mark Cornwell <cornwell@NRL-CSS>
        !          3897: Subject: Franz on the Sun
        !          3898: Message-Id: <[email protected]>
        !          3899: Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29)
        !          3900:        id AA02600; 25 May 83 12:50:26 PDT (Wed)
        !          3901: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          3902:        id AA01878; 25 May 83 12:51:17 PDT (Wed)
        !          3903: To: [email protected]
        !          3904: Cc: cornwell@NRL-CSS
        !          3905: Status: O
        !          3906: 
        !          3907: 
        !          3908:   Our group at NRL is planning to purchase Sun workstations. I
        !          3909: currently have a substantial amount of code written in Franz Lisp that
        !          3910: I want to run on the Sun. 
        !          3911:  
        !          3912:   What is the status of the Berkeley group porting Franz to the Sun?   
        !          3913: How do I get a copy?
        !          3914: 
        !          3915:   Also, I have a few concerns about configuring a Sun to run Franz well.  
        !          3916: The basic desktop Sun workstation provides 1 Mbyte of physical memory.   
        !          3917: This can be extended to 2 Mbyte or one can add an Ethernet interface
        !          3918: *but not both*.  Since I am unwilling to give up my Ethernet
        !          3919: interface I may be forced to run Franz in 1 Mbyte and contend with
        !          3920: the added paging overhead (using a 68010 running 4.2bsd and a local disk).
        !          3921: 
        !          3922:   Has anyone out there had experience running Franz Lisp on a Sun in
        !          3923: such a configuration?  Can I get away without the 2 Mbyte extension?
        !          3924: I think your answers would be of general interest. 
        !          3925: 
        !          3926: -- Mark (caught between a rock and a hard place?) Cornwell
        !          3927: 
        !          3928:  
        !          3929: 
        !          3930: From baden@UCBKIM  Wed May 25 13:51:39 1983
        !          3931: Date: 25 May 83 13:32:01 PDT (Wed)
        !          3932: From: baden@UCBKIM (Scott B. Baden)
        !          3933: Subject: Re:  Franz on the Sun
        !          3934: Message-Id: <[email protected]>
        !          3935: Received: by UCBKIM.ARPA (3.340/3.5)
        !          3936:        id AA02716; 25 May 83 13:32:01 PDT (Wed)
        !          3937: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29)
        !          3938:        id AA03753; 25 May 83 13:50:52 PDT (Wed)
        !          3939: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          3940:        id AA03002; 25 May 83 13:51:39 PDT (Wed)
        !          3941: To: [email protected]
        !          3942: Cc: cornwell@NRL-CSS
        !          3943: Status: O
        !          3944: 
        !          3945: Which sun are you using?  My office mate says that
        !          3946: he has seen a sun configured with 2MB of memory AND
        !          3947: an Ethernet board.
        !          3948: 
        !          3949: From mike%Rice.Rice@Rand-Relay  Fri May 27 19:51:33 1983
        !          3950: Date:     Fri, 27 May 83 18:18:47 CDT
        !          3951: From: Mike.Caplinger <mike.rice@Rand-Relay>
        !          3952: Subject:  Re:  Franz on the Sun
        !          3953: Return-Path: <mike%Rice.Rice@Rand-Relay>
        !          3954: Message-Id:  <[email protected]>
        !          3955: Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29)
        !          3956:        id AA19088; 27 May 83 19:50:15 PDT (Fri)
        !          3957: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          3958:        id AA02221; 27 May 83 19:51:33 PDT (Fri)
        !          3959: To: [email protected]
        !          3960: In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed)
        !          3961: Via:  Rice; 27 May 83 19:14-PDT
        !          3962: Status: RO
        !          3963: 
        !          3964: As I type I'm bringing up the 68K version of Opus 38 (now FTPable from
        !          3965: UCB-VAX) on a SUN running 4.1c.  There don't seem to be any major
        !          3966: problems so far, but the compiler doesn't run on a system with all the
        !          3967: net servers on it because it runs out of memory.  I've been told this
        !          3968: is because there's a bug in 4.1c that forces it to only use 1/2 of the
        !          3969: swap partition.  I'm having to run standalone to compile the compiler;
        !          3970: I don't yet know whether I'll be able to compile other stuff without
        !          3971: this rather extreme fix.
        !          3972: 
        !          3973: As I use the system more I will post more info to this group.
        !          3974: 
        !          3975: From narain@rand-unix  Tue May 31 10:49:00 1983
        !          3976: Date: Tuesday, 31 May 1983 10:45-PDT
        !          3977: From: narain@rand-unix
        !          3978: Subject: Interrupt question
        !          3979: Message-Id: <[email protected]>
        !          3980: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29)
        !          3981:        id AA10893; 31 May 83 10:47:26 PDT (Tue)
        !          3982: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          3983:        id AA13428; 31 May 83 10:49:00 PDT (Tue)
        !          3984: To: [email protected]
        !          3985: Cc: narain@rand-unix
        !          3986: Status: O
        !          3987: 
        !          3988: 
        !          3989: Hi, I would be grateful if you could tell me  what  is  the  equivalent  of
        !          3990: Interlisp's  control-h  (followed  by  OK) in Franzlisp.  In other words, I
        !          3991: wish to interrupt a Franzlisp program, from time to time, examine its state
        !          3992: and allow it to continue from the interrupted point.
        !          3993: 
        !          3994: -- Sanjai
        !          3995: 
        !          3996: From [email protected]  Tue May 31 19:31:04 1983
        !          3997: Date: 31 May 83 17:28:35 PDT (Tue)
        !          3998: From: [email protected]
        !          3999: Subject: packages
        !          4000: Message-Id: <[email protected]>
        !          4001: Received: by LBL-CSAM.ARPA (3.320/3.21)
        !          4002:        id AA16451; 31 May 83 17:28:35 PDT (Tue)
        !          4003: Received: by UCBVAX.ARPA (3.341/3.31)
        !          4004:        id AA02877; 31 May 83 19:30:00 PDT (Tue)
        !          4005: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4006:        id AA22745; 31 May 83 19:31:04 PDT (Tue)
        !          4007: To: [email protected]
        !          4008: Status: O
        !          4009: 
        !          4010: 
        !          4011: Does a version of LispMachine ``packages'' or some similar oblist partitioning
        !          4012: scheme exist for franz?  Having just integrated several independently coded
        !          4013: modules, I think something like that would be very useful.
        !          4014:                                        -thanks
        !          4015:        Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve
        !          4016: 
        !          4017: 
        !          4018: From fateman  Tue Jun 14 11:48:32 1983
        !          4019: Date: 14 Jun 83 11:48:32 PDT (Tue)
        !          4020: From: fateman (Richard Fateman)
        !          4021: Subject: "macsyma on a chip?"
        !          4022: Message-Id: <[email protected]>
        !          4023: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4024:        id AA06756; 14 Jun 83 11:48:32 PDT (Tue)
        !          4025: To: macsyma-i@mit-mc
        !          4026: Cc: franz-friends
        !          4027: Status: O
        !          4028: 
        !          4029: Well, sort of. We now have Macsyma running on a Motorola 68000 - based
        !          4030: system with 6 megabytes of real memory. The operating system is a 
        !          4031: Unisoft UNIX system, which has been ported to some large number (>65) boxes.  
        !          4032: The Pixel people were kind enough to lend us a machine with enough 
        !          4033: real memory to make virtual memory unnecessary.
        !          4034: 
        !          4035: It takes a long time to load up, but once running, it is quite responsive,
        !          4036: and appears to be about 60% of a VAX 11/780 in terms of CPU time. 
        !          4037: 
        !          4038: We have not shaken down everything, but since the source code is unchanged
        !          4039: from the VAX, we expect the bugs to be limited to lisp compilation
        !          4040: glitches, or differences between versions of the UNIX system.
        !          4041: 
        !          4042: 
        !          4043: From jkf  Wed Jun 15 10:42:05 1983
        !          4044: Date: 15 Jun 83 10:42:05 PDT (Wed)
        !          4045: From: jkf (John Foderaro)
        !          4046: Subject: Opus 38.62
        !          4047: Message-Id: <[email protected]>
        !          4048: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4049:        id AA20591; 15 Jun 83 10:42:05 PDT (Wed)
        !          4050: To: local-lisp
        !          4051: Status: O
        !          4052: 
        !          4053:   There is no longer a limit on the size of bignums, strings or
        !          4054: symbol names which can be read by the reader [other than the size of
        !          4055: virtual memory].
        !          4056: 
        !          4057:   The value of lisp-library-directory will determine where cfasl finds
        !          4058: its private version of the loader.
        !          4059: 
        !          4060:  (changes by sklower)
        !          4061: 
        !          4062: 
        !          4063: From @CMU-CS-C:UI.TYJ@CU20D  Wed Jun 15 18:22:55 1983
        !          4064: Date: 14 Jun 1983 1812-EDT
        !          4065: From: Tai Jin <UI.TYJ@CU20D>
        !          4066: Subject: franz mailing liszt
        !          4067: Message-Id: <[email protected]>
        !          4068: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
        !          4069:        id AA16599; 14 Jun 83 15:14:36 PDT (Tue)
        !          4070: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4071:        id AA28806; 15 Jun 83 18:22:55 PDT (Wed)
        !          4072: To: franz-friends%berkeley@CMCSC
        !          4073: Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC
        !          4074: Status: O
        !          4075: 
        !          4076: 
        !          4077: Hi, we would like to be added to your mailing list.
        !          4078: 
        !          4079: We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS)
        !          4080: running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center
        !          4081: for Computing Activities).
        !          4082: 
        !          4083: Is anyone out there working on an UTS/IBM implementation?  Any information will
        !          4084: be greatly appreciated.
        !          4085: 
        !          4086: 
        !          4087: Thanks,
        !          4088: 
        !          4089: Tai Jin <UI.TYJ%CU20D@CMCSC>
        !          4090: Travis Winfrey <UI.TRAVIS%CU20D@CMCSC>
        !          4091: -------
        !          4092: 
        !          4093: From @CMU-CS-C:Ui.Travis@CU20D  Thu Jun 16 09:47:39 1983
        !          4094: Date: 16 Jun 1983 1243-EDT
        !          4095: From: Travis Lee Winfrey <Ui.Travis@CU20D>
        !          4096: Subject: Porting Franz lisp to Amdahl Unix
        !          4097: Message-Id: <[email protected]>
        !          4098: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
        !          4099:        id AA25470; 16 Jun 83 09:46:15 PDT (Thu)
        !          4100: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4101:        id AA06352; 16 Jun 83 09:47:39 PDT (Thu)
        !          4102: To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC
        !          4103: Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D,
        !          4104:         kim.fateman%berkeley@CMCSC
        !          4105: Status: O
        !          4106: 
        !          4107: Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's
        !          4108: Unix running on a IBM 4341.  We are working from a copy that runs on the VAX.
        !          4109: 
        !          4110: We would be very interested in seeing any versions that runs both on the VAX
        !          4111: and some other machine, such as the 68000.  We are also interested in seeing
        !          4112: any documentation on other porting efforts, regardless of what machine.
        !          4113: 
        !          4114: Thanks,
        !          4115: 
        !          4116: Tai Jin  <ui.tyj%cu20d@cmu-cs-c>
        !          4117: Travis Winfrey <ui.travis%cu20d@cmu-cs-c>
        !          4118: -------
        !          4119: 
        !          4120: From jkf  Sun Jun 19 15:43:34 1983
        !          4121: Date: 19 Jun 83 15:43:34 PDT (Sun)
        !          4122: From: jkf (John Foderaro)
        !          4123: Subject: opus 38.63
        !          4124: Message-Id: <[email protected]>
        !          4125: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4126:        id AA19626; 19 Jun 83 15:43:34 PDT (Sun)
        !          4127: To: local-lisp
        !          4128: Status: O
        !          4129: 
        !          4130:  Added functions:
        !          4131:    (vputprop 'Vv_vector 'g_value 'g_indicator)
        !          4132:    (vget  'Vv_vector 'g_indicator)
        !          4133: 
        !          4134:   work just like putprop and get, but modify the vector property list.
        !          4135: 
        !          4136:  Also:
        !          4137:    you can determine which function is called by lisp to print a vector
        !          4138:  by placing the function to call on the vector's property list under
        !          4139:  indicator 'print'.  The  print function is called with two arguments:
        !          4140:  the vector and the port.
        !          4141:  
        !          4142:  For example:
        !          4143: => (defun printv (v port)
        !          4144:       (patom "A vector of size " port)
        !          4145:       (print (vsize v) port))
        !          4146: printv
        !          4147: => (setq xx (new-vector 10))
        !          4148: vector[40]
        !          4149: => (vputprop xx 'printv 'print)
        !          4150: printv
        !          4151: => xx
        !          4152: A vector of size 10
        !          4153: =>
        !          4154: 
        !          4155: 
        !          4156: 
        !          4157: From jkf  Sun Jun 19 22:47:42 1983
        !          4158: Date: 19 Jun 83 22:47:42 PDT (Sun)
        !          4159: From: jkf (John Foderaro)
        !          4160: Subject: opus 38.64
        !          4161: Message-Id: <[email protected]>
        !          4162: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4163:        id AA23164; 19 Jun 83 22:47:42 PDT (Sun)
        !          4164: To: local-lisp
        !          4165: Cc: jpg@Mit-mc
        !          4166: Status: O
        !          4167: 
        !          4168: 
        !          4169:   added the function (^ 'x_a 'x_b)  which computes  x_a to the x_b
        !          4170: power and always returns a fixnum result (it currently wraps around
        !          4171: on overflow).
        !          4172: 
        !          4173: 
        !          4174: 
        !          4175: From JPG@MIT-MC  Sun Jun 19 22:54:00 1983
        !          4176: Date: 20 June 1983 01:53 EDT
        !          4177: From: Jeffrey P. Golden <JPG@MIT-MC>
        !          4178: Subject: ^
        !          4179: Message-Id: <[email protected]>
        !          4180: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33)
        !          4181:        id AA15160; 19 Jun 83 22:53:57 PDT (Sun)
        !          4182: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4183:        id AA23228; 19 Jun 83 22:54:00 PDT (Sun)
        !          4184: To: jkf@UCBKIM
        !          4185: Cc: JPG@MIT-MC, local-lisp@UCBKIM
        !          4186: Status: O
        !          4187: 
        !          4188:    Date: 19 Jun 83 22:47:42 PDT 
        !          4189:    From: jkf%UCBKIM@Berkeley 
        !          4190:    Subject: opus 38.64
        !          4191:    To: local-lisp%UCBKIM@Berkeley
        !          4192:    Cc: jpg@Mit-mc
        !          4193:    added the function (^ 'x_a 'x_b)  which computes  x_a to the x_b
        !          4194:    power and always returns a fixnum result (it currently wraps around
        !          4195:    on overflow).
        !          4196: The Maclisp ^ errors out in this case with the message:
        !          4197: ;RESULT LARGER THAN FIXNUM - ^
        !          4198: 
        !          4199: 
        !          4200: From narain@rand-unix  Mon Jun 20 22:09:31 1983
        !          4201: Date: Monday, 20 Jun 1983 22:00-PDT
        !          4202: From: narain@rand-unix
        !          4203: Subject: Re: Interrrupt question
        !          4204: Message-Id: <[email protected]>
        !          4205: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
        !          4206:        id AA00276; 20 Jun 83 22:09:20 PDT (Mon)
        !          4207: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4208:        id AA09633; 20 Jun 83 22:09:31 PDT (Mon)
        !          4209: To: [email protected]
        !          4210: Cc: narain@rand-unix
        !          4211: Status: O
        !          4212: 
        !          4213: 
        !          4214:                                   TWIMC
        !          4215:                                   -----
        !          4216: 
        !          4217: Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp:
        !          4218: i.e. if you wish to interrupt a Franzlisp computation, browse around the state
        !          4219: and resume computation:
        !          4220: 
        !          4221: Hit DEL;
        !          4222: Browse;
        !          4223: (return t)
        !          4224: 
        !          4225: This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay).
        !          4226: 
        !          4227: -- Sanjai
        !          4228: 
        !          4229: From Tim%UPenn.UPenn@UDel-Relay  Tue Jun 21 14:52:53 1983
        !          4230: Date: Tue, 21 Jun 83 10:33 EDT
        !          4231: From: Tim Finin <Tim.UPenn@UDel-Relay>
        !          4232: Subject: interrupting Franz
        !          4233: Return-Path: <Tim%UPenn.UPenn@UDel-Relay>
        !          4234: Message-Id: <[email protected]>
        !          4235: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
        !          4236:        id AA12930; 21 Jun 83 14:52:36 PDT (Tue)
        !          4237: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4238:        id AA21097; 21 Jun 83 14:52:53 PDT (Tue)
        !          4239: To: [email protected]
        !          4240: Via:  UPenn; 21 Jun 83 17:40-EDT
        !          4241: Status: O
        !          4242: 
        !          4243: 
        !          4244: Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.
        !          4245: 
        !          4246: From jkf  Sat Jun 25 13:49:37 1983
        !          4247: Date: 25 Jun 83 13:49:37 PDT (Sat)
        !          4248: From: jkf (John Foderaro)
        !          4249: Subject: opus 38.65
        !          4250: Message-Id: <[email protected]>
        !          4251: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4252:        id AA25527; 25 Jun 83 13:49:37 PDT (Sat)
        !          4253: To: local-lisp
        !          4254: Status: O
        !          4255: 
        !          4256:   If you have automatic case conversion set (i.e. (sstatus uctolc t)),
        !          4257: then symbols with lower case letters will be escaped by print.
        !          4258: 
        !          4259: 
        !          4260: 
        !          4261: From layer  Tue Jul  5 00:26:29 1983
        !          4262: Date:  5 Jul 1983 0026-PDT (Tuesday)
        !          4263: From: layer (Kevin Layer)
        !          4264: Subject: lisp opus 38.67
        !          4265: Message-Id: <5390.30.426237985@ucbkim>
        !          4266: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4267:        id AA05911; 5 Jul 83 00:26:29 PDT (Tue)
        !          4268: Phone: (415) 652-2405
        !          4269: To: local-lisp
        !          4270: Cc: layer
        !          4271: Status: O
        !          4272: 
        !          4273:   The function 'sortcar' has been slightly changed: if the second
        !          4274: arg is nil, then the ordering function 'alphalessp' is assumed
        !          4275: ('sort' does it this way).
        !          4276: 
        !          4277:        Kevin
        !          4278: 
        !          4279: From layer  Wed Jul  6 00:02:33 1983
        !          4280: Date: 6 Jul 83 00:02:33 PDT (Wed)
        !          4281: From: layer (Kevin Layer)
        !          4282: Subject: liszt opus 8.30
        !          4283: Message-Id: <[email protected]>
        !          4284: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4285:        id AA24776; 6 Jul 83 00:02:33 PDT (Wed)
        !          4286: Phone: (415) 652-2405
        !          4287: To: local-lisp
        !          4288: Cc: sklower, jkf
        !          4289: Status: O
        !          4290: 
        !          4291:   All modifications should be transparent, but if there are problems
        !          4292: relating to the autorun feature (-r flag), please let me know.
        !          4293: 
        !          4294:        Kevin
        !          4295: 
        !          4296: 
        !          4297: 
        !          4298: From sklower  Thu Jul  7 00:27:52 1983
        !          4299: Date: 7 Jul 83 00:27:52 PDT (Thu)
        !          4300: From: sklower (Keith Sklower)
        !          4301: Subject: Franz, opus38.68
        !          4302: Message-Id: <[email protected]>
        !          4303: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4304:        id AA10697; 7 Jul 83 00:27:52 PDT (Thu)
        !          4305: To: local-lisp
        !          4306: Status: O
        !          4307: 
        !          4308: Franz now escapes UPPER case letters instead of lower case letters when
        !          4309: (status uctolc) is enabled, so that (read (print x)) is an identity operation
        !          4310: on atom printnames.  Also, we made (explode) conform to what maclisp does
        !          4311: with opposite-than-normal character-cases.
        !          4312: 
        !          4313: From Ira%UPenn.UPenn@UDel-Relay  Fri Jul  8 01:46:25 1983
        !          4314: Date: Thu, 7 Jul 83 22:13 EDT
        !          4315: From: Ira Winston <Ira.UPenn@UDel-Relay>
        !          4316: Subject: Eliza
        !          4317: Return-Path: <Ira%UPenn.UPenn@UDel-Relay>
        !          4318: Message-Id: <[email protected]>
        !          4319: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
        !          4320:        id AA16294; 8 Jul 83 01:45:43 PDT (Fri)
        !          4321: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4322:        id AA01687; 8 Jul 83 01:46:25 PDT (Fri)
        !          4323: To: [email protected]
        !          4324: Via:  UPenn; 8 Jul 83 3:07-EDT
        !          4325: Status: O
        !          4326: 
        !          4327: Does anyone have a version of Eliza that runs under Franz Lisp?
        !          4328: 
        !          4329: From layer  Fri Jul  8 18:04:10 1983
        !          4330: Date:  8 Jul 1983 1804-PDT (Friday)
        !          4331: From: layer (Kevin Layer)
        !          4332: Subject: lisp opus 38.69
        !          4333: Message-Id: <7031.30.426560643@ucbkim>
        !          4334: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4335:        id AA07142; 8 Jul 83 18:04:10 PDT (Fri)
        !          4336: Phone: (415) 652-2405
        !          4337: To: local-lisp
        !          4338: Cc: layer
        !          4339: Status: O
        !          4340: 
        !          4341:   'setf' now knows about 'nthelem', and there are two new functions:
        !          4342: 
        !          4343:        (readdir 's_direct)
        !          4344:                returns a list of the contents of the directory s_direct.
        !          4345: 
        !          4346:        (dirp 's_name)
        !          4347:                returns s_name if s_name is a directory.  This doesn't
        !          4348:                insure that you can read the directory, though (only
        !          4349:                uses stat(2)).
        !          4350: 
        !          4351:                                        Kevin
        !          4352: 
        !          4353: From layer  Fri Jul  8 20:57:13 1983
        !          4354: Date:  8 Jul 1983 2057-PDT (Friday)
        !          4355: From: layer (Kevin Layer)
        !          4356: Subject: new function readdir
        !          4357: Message-Id: <465.30.426571029@ucbkim>
        !          4358: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4359:        id AA00480; 8 Jul 83 20:57:13 PDT (Fri)
        !          4360: Phone: (415) 652-2405
        !          4361: To: local-lisp
        !          4362: Fcc: record
        !          4363: Status: O
        !          4364: 
        !          4365:   The function 'readdir' and 'dirp' should not be relied on yet, since
        !          4366: they are provisional, because they are implemented with C library
        !          4367: functions only available on 4.1+ systems.
        !          4368: 
        !          4369:        Kevin
        !          4370: 
        !          4371: From Pwh%GaTech.GATech@UDel-Relay  Tue Jul 12 18:08:46 1983
        !          4372: Date:     11 Jul 83 20:36:32-EDT (Mon)
        !          4373: From: <pwh.gatech@UDel-Relay>
        !          4374: Subject:  Franz flavors?
        !          4375: Return-Path: <Pwh%GaTech.GATech@UDel-Relay>
        !          4376: Message-Id: <[email protected]>
        !          4377: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
        !          4378:        id AA03336; 12 Jul 83 18:07:40 PDT (Tue)
        !          4379: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4380:        id AA20140; 12 Jul 83 18:08:46 PDT (Tue)
        !          4381: To: [email protected]
        !          4382: Cc: jlk.Gatech@UDel-Relay
        !          4383: Via:  GATech; 12 Jul 83 2:43-EDT
        !          4384: Status: O
        !          4385: 
        !          4386: We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our
        !          4387: long awaited Symbolics Lisp Machine up and running and are trying to establish
        !          4388: some measure of compatability between Franz and Zeta Lisp (as appropriate).
        !          4389: Janet seems to recall some mention of a flavor package for Franz. Is this
        !          4390: Berkley based or can anyone provide some clues as to where to check next?
        !          4391: 
        !          4392: Also, when is the next release of Franz scheduled and what features will it
        !          4393: incorporate?
        !          4394: 
        !          4395: If the flavor package is non-existent, we will probably be forced to develop
        !          4396: one here and will, of course, be glad to pass anything useful along.
        !          4397: 
        !          4398: phil hutto
        !          4399: 
        !          4400: From narain@rand-unix  Tue Jul 12 20:10:42 1983
        !          4401: Date: Tuesday, 12 Jul 1983 19:49-PDT
        !          4402: From: narain@rand-unix
        !          4403: Subject: Re:  Franz flavors?
        !          4404: Message-Id: <[email protected]>
        !          4405: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
        !          4406:        id AA05908; 12 Jul 83 20:09:41 PDT (Tue)
        !          4407: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4408:        id AA21387; 12 Jul 83 20:10:42 PDT (Tue)
        !          4409: To: <pwh.gatech@UDEL-RELAY>
        !          4410: Cc: [email protected], jlk.Gatech@UDEL-RELAY
        !          4411: In-Reply-To: Your message of     11 Jul 83 20:36:32-EDT (Mon).
        !          4412:              <[email protected]>
        !          4413: Status: O
        !          4414: 
        !          4415: 
        !          4416: We at Rand are interested in developing a set of guidelines for writing
        !          4417: code that will be compatible with each of Zeta- Franz- and PSL Lisps. I
        !          4418: would be grateful if you could tell us of what your experiences have been with
        !          4419: making Franzlisp code work on the Symbolics machine. We would gladly share
        !          4420: our own with you if you wish; incidentally we also have an IJCAI paper on a
        !          4421: related issue.
        !          4422: 
        !          4423: -- Sanjai Narain
        !          4424: 
        !          4425: From liz.umcp-cs@UDel-Relay  Wed Jul 13 00:55:26 1983
        !          4426: Date:     13 Jul 83 03:09:39 EDT  (Wed)
        !          4427: From: Liz Allen <liz.umcp-cs@UDel-Relay>
        !          4428: Subject:  Re:  Franz flavors?
        !          4429: Return-Path: <liz.umcp-cs@UDel-Relay>
        !          4430: Message-Id: <[email protected]>
        !          4431: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
        !          4432:        id AA10367; 13 Jul 83 00:54:32 PDT (Wed)
        !          4433: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4434:        id AA24477; 13 Jul 83 00:55:26 PDT (Wed)
        !          4435: To: pwh.gatech@UDel-Relay, [email protected]
        !          4436: Cc: jlk.Gatech@UDel-Relay
        !          4437: Via:  UMCP-CS; 13 Jul 83 3:23-EDT
        !          4438: Status: O
        !          4439: 
        !          4440: Here at the Univ of Maryland, we do have an implementation of
        !          4441: flavors in Franz Lisp and have used it successfully in several
        !          4442: large systems.  It doesn't contain all the features of the Lisp
        !          4443: Machine Flavors, but it does implement all the major ones.  It is
        !          4444: also different in a few ways that are necessitated by the limitations
        !          4445: of Franz Lisp (shallow binding without invisible pointers or true
        !          4446: closures -- though closures may be in the very newest versions of
        !          4447: Franz -- we have opus 38.26).  The package uses a hashing scheme
        !          4448: for looking up methods, and the function <- which is used to send
        !          4449: a message to an object is written in C.  Together, this makes it
        !          4450: an efficient implementation.
        !          4451: 
        !          4452: We are currently working on a new policy for distributing flavors,
        !          4453: our other lisp packages and our window package.  When we have worked
        !          4454: it out, I will announce the details here.
        !          4455: 
        !          4456:                                -Liz
        !          4457: 
        !          4458: From @MIT-MC:mdm@cmu-ri-isl  Thu Jul 14 11:07:57 1983
        !          4459: Date: 14 Jul 1983 14:03:01-EDT
        !          4460: From: Malcolm.McRoberts@CMU-RI-ISL
        !          4461: Subject: random numbers
        !          4462: Message-Id: <[email protected]>
        !          4463: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35)
        !          4464:        id AA05735; Thu, 14 Jul 83 11:06:45 PDT
        !          4465: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4466:        id AA13687; 14 Jul 83 11:07:57 PDT (Thu)
        !          4467: Apparently-To: <franz-friends@UCB-VAX>
        !          4468: Status: O
        !          4469: 
        !          4470: I am interested in obtaining a GOOD random number generator that is callable
        !          4471: from Franz.  My only real requirements are that it accept a seed (so that I
        !          4472: can duplicate the same series), is fairly good (try doing several (random
        !          4473: 4)'s in Franz and see what you get), and is of intermediate speed.  If you
        !          4474: know of such an animal please send me mail telling me how to get it.
        !          4475:                                                        thanks
        !          4476: 
        !          4477: 
        !          4478: From kanderso@bbn-vax  Thu Jul 14 12:49:58 1983
        !          4479: Date: 14 Jul 1983 15:47:19 EDT (Thursday)
        !          4480: From: Ken Anderson <kanderso@bbn-vax>
        !          4481: Subject: Random numbers
        !          4482: Message-Id: <[email protected]>
        !          4483: Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35)
        !          4484:        id AA06936; Thu, 14 Jul 83 12:48:49 PDT
        !          4485: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
        !          4486:        id AA15607; 14 Jul 83 12:49:58 PDT (Thu)
        !          4487: To: [email protected]
        !          4488: Cc: Malcolm.McRoberts@CMU-RI-ISL
        !          4489: Status: O
        !          4490: 
        !          4491: Here is a random number generator i use.  It seems to work fairly well, but i have
        !          4492: not looked to closely at the statistics.  Since it will occasionally require
        !          4493: bignums, it is probably not the fastest either.  I was just looking for something
        !          4494: that was likely to be portable between LISP's.
        !          4495: I would be very interested in hearing your evaluation of it.
        !          4496: 
        !          4497: k
        !          4498: 
        !          4499: ;;; RANDOM NUMBERS
        !          4500: (declare (macros t))
        !          4501: (include math.h)
        !          4502: 
        !          4503: (defvar $uniform-a 16807) ; = 7^5
        !          4504: (defvar $mersenne-prime 2147483647) ; = 2^31 - 1
        !          4505: (defvar $mersenne-prime-1 (- $mersenne-prime 1))
        !          4506: 
        !          4507: (defmacro with-seed (s-newseed . body)
        !          4508:   ; evaluates body with the seed of the random numbers set to s-newseed.
        !          4509:   ; the value of s-newseed is updated.  Thus this is a way of
        !          4510:   ; Keepining several sequences of random numbers with their own seeds
        !          4511:   `(let (($uniform-seed ,s-newseed))
        !          4512:        (prog1 (progn ,@body) 
        !          4513:               (setq ,s-newseed $uniform-seed))))
        !          4514: 
        !          4515: (defun uniform-basic (previous-fixnum)
        !          4516:   ; -> a fixnum 0 < fixnum < 2^31 - 1
        !          4517:   ; Repeated calls will generate fixnums in the range
        !          4518:   ; 1 -> 2^31 - 2.
        !          4519: 
        !          4520:   ; The basic idea is new = A^k * old (mod p)
        !          4521:   ; where A is a primitive root of p, k is not a factor of  p-1
        !          4522:   ; and p is a large prime.
        !          4523: 
        !          4524:   ; This is a good random number generator but is not be the fastest!
        !          4525:   ; On FRANZ LISP, and LISP MACHINE it will require bignums since
        !          4526:   ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder
        !          4527:   ; can be done more efficiently.
        !          4528:   ; See: Linus Schrage, A More Portable Fortran Random Number Generator,
        !          4529:   ;      ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979.
        !          4530:   (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime))
        !          4531: 
        !          4532: (defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1
        !          4533: 
        !          4534: (defun uniform ()
        !          4535:   ; -> the next uniform random number in the sequence
        !          4536:   ; To have your own sequence, rebind $uniform-seed.
        !          4537:   (setq $uniform-seed (uniform-basic $uniform-seed)))
        !          4538: 
        !          4539: (defun uniform-between (low-num high-num)
        !          4540:   ; -> a uniform random  number, x, low-num <= x <= high-num
        !          4541:   ; If low-num and high-num are fixnums, a fixnum is returned.
        !          4542:   (cond ((not (and (fixp low-num) (fixp high-num)))
        !          4543:         (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1))
        !          4544:                       (-$ high-num low-num))))
        !          4545:        (t (+ low-num (// (uniform)
        !          4546:                          (// $mersenne-prime-1 (max 1 (- high-num low-num -1))))))))
        !          4547: 
        !          4548: (defun gaussian-random-1 ()
        !          4549:   ; -> a gaussian random variable with mean 0.0 and
        !          4550:   ; standard deviation 1.0.
        !          4551:   ; Good tails.
        !          4552:   (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0))))
        !          4553:      (sin (*$ $2pi (uniform-between 0.0 1.0)))))
        !          4554: 
        !          4555: (defun gaussian-random (mean standard-deviation)
        !          4556:   (+$ mean (*$ (gaussian-random-1) standard-deviation)))
        !          4557: 
        !          4558: ;;(defun gaussian (x)
        !          4559: ;;  (* (sqrt $2pi) 
        !          4560: ;;     (exp (minus (// (square x) 2.0)))))
        !          4561: 
        !          4562: (defun random-yes-no (fraction-yes)
        !          4563:     (<= (uniform-between 0.0 1.0) fraction-yes))
        !          4564: 
        !          4565: 
        !          4566: From layer  Sat Jul 30 15:46:42 1983
        !          4567: Date: 30 Jul 1983 1546-PDT (Saturday)
        !          4568: From: layer (Kevin Layer)
        !          4569: Subject: liszt opus 8.33
        !          4570: Message-Id: <19472.30.428453197@ucbkim>
        !          4571: Received: by UCBKIM.ARPA (3.340/3.5)
        !          4572:        id AA19498; 30 Jul 83 15:46:42 PDT (Sat)
        !          4573: Phone: (415) 652-2405
        !          4574: To: local-lisp
        !          4575: Status: O
        !          4576: 
        !          4577:   Vset is now open coded.  There should be no visible change in the
        !          4578: behaviour of vectors, except in speed (greater, that is), and 
        !          4579: vsize-{byte,word} work properly now.
        !          4580: 
        !          4581:   Bugs to me.
        !          4582: 
        !          4583:        Kevin
        !          4584: 
        !          4585: From jkf  Mon Aug  1 14:41:28 1983
        !          4586: Received: by ucbkim.ARPA (4.2/4.2)
        !          4587:        id AA03743; Mon, 1 Aug 83 14:41:28 PDT
        !          4588: Date: Mon, 1 Aug 83 14:41:28 PDT
        !          4589: From: jkf (John Foderaro)
        !          4590: Message-Id: <[email protected]>
        !          4591: To: local-lisp
        !          4592: Subject: defstruct
        !          4593: Status: O
        !          4594: 
        !          4595:   defstruct now understands two more types of structures:
        !          4596:        :vector
        !          4597:        :named-vector
        !          4598: 
        !          4599:   A named vector has the defstruct structure name on the vector property
        !          4600: list, thus an instance of the foo structure would print as 'foo[8]'.
        !          4601: 
        !          4602: 
        !          4603:   :named-vector is now the default structure type (instead of :hunk).
        !          4604: 
        !          4605: 
        !          4606: 
        !          4607: 
        !          4608: From jkf  Tue Aug  2 15:20:04 1983
        !          4609: Received: by ucbkim.ARPA (4.2/4.2)
        !          4610:        id AA26686; Tue, 2 Aug 83 15:20:04 PDT
        !          4611: Date: Tue, 2 Aug 83 15:20:04 PDT
        !          4612: From: jkf (John Foderaro)
        !          4613: Message-Id: <[email protected]>
        !          4614: To: local-lisp
        !          4615: Subject: lisp opus 38.70
        !          4616: Status: RO
        !          4617: 
        !          4618:   When a vector is printed, the size in square brackets will be the number
        !          4619: of entries (not the number of bytes).  The size printed for vectori
        !          4620: objects will continue to be the number of bytes.
        !          4621: 
        !          4622:   Also, if the property of a vector is a list with the car being a non nil
        !          4623: symbol, and if that list doesn't have a print property, then that
        !          4624: symbol will be printed rather than 'vector' or 'vectori'.
        !          4625: 
        !          4626: 
        !          4627: 
        !          4628: From layer  Thu Aug  4 02:10:12 1983
        !          4629: Received: by ucbkim.ARPA (4.2/4.2)
        !          4630:        id AA11660; Thu, 4 Aug 83 02:10:12 PDT
        !          4631: From: layer (Kevin Layer)
        !          4632: Phone: (415) 652-2405
        !          4633: Date:  4 Aug 1983 0210-PDT (Thursday)
        !          4634: Message-Id: <11649.30.428836207@ucbkim>
        !          4635: To: local-lisp
        !          4636: Subject: liszt opus 8.34
        !          4637: Status: RO
        !          4638: 
        !          4639:   I just installed a new compiler.  For the vax, there shouldn't be
        !          4640: any visible changes, though a couple of vector bugs were fixed.  For
        !          4641: the 68000, the vector access functions are now open coded, and the
        !          4642: new one was installed on mike, rob, and chip in /usr/ucb.
        !          4643: 
        !          4644:        Kevin
        !          4645: 
        !          4646: From FRD@SU-AI  Fri Aug  5 15:57:17 1983
        !          4647: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
        !          4648:        id AA10610; Fri, 5 Aug 83 15:57:17 PDT
        !          4649: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
        !          4650:        id AA10357; Fri, 5 Aug 83 15:54:22 PDT
        !          4651: Message-Id: <[email protected]>
        !          4652: Date: 05 Aug 83  1353 PDT
        !          4653: From: Fred Lakin <FRD@SU-AI>
        !          4654: Subject: Franz & SUNs  
        !          4655: To: franz-friends@BERKELEY
        !          4656: Status: RO
        !          4657: 
        !          4658: I am interested in connectons between Franz and SUN workstations.
        !          4659: Like how far along is Franz on the SUN?  Is there some package
        !          4660: which allows Franz on a VAX to use a SUN as a display device?
        !          4661: 
        !          4662: Any info on this matter would be appreciated.
        !          4663: Thnaks, Fred Lakin
        !          4664: 
        !          4665: 
        !          4666: From tektronix!ogcvax!metheus!tombl  Sat Aug  6 09:49:57 1983
        !          4667: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
        !          4668:        id AA21229; Sat, 6 Aug 83 09:49:57 PDT
        !          4669: Received: by UCBVAX.ARPA (3.347/3.35)
        !          4670:        id AA13549; Sat, 6 Aug 83 09:40:11 PDT
        !          4671: Message-Id: <[email protected]>
        !          4672: From: ogcvax!metheus!tombl
        !          4673: To: ogcvax!tektronix!ucbvax!franz-friends
        !          4674: Cc: ogcvax!tektronix!ucbvax!sklower
        !          4675: Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT
        !          4676: Subject: bug in Opus 38.66
        !          4677: Date: Fri Aug  5 20:46:56 1983
        !          4678: Status: O
        !          4679: 
        !          4680: 
        !          4681: A bug present in previous versions is also present in 38.66 of Franz.
        !          4682: cfasl fails (in most cases) to close the file it reads from.
        !          4683: Consequently, mysterious events occur when the maximum number of open
        !          4684: file descriptors is reached.
        !          4685: 
        !          4686: The fix is made in the file ffasl.c. "close(fildes)" should be
        !          4687: prepended to the two return sequences from (the Unix code for)
        !          4688: Lcfasl:
        !          4689: 
        !          4690: ------------------------------------------------------------------
        !          4691: Old:   146c146
        !          4692:        <               {Restorestack(); return(nil);}
        !          4693:        ---
        !          4694: Fixed: >               {close(fildes); Restorestack(); return(nil);}
        !          4695:        149a150
        !          4696:        >       close(fildes);
        !          4697: ------------------------------------------------------------------
        !          4698: 
        !          4699: 
        !          4700:        Tom Blenko
        !          4701:        Metheus Corp.
        !          4702:        ucbvax!tektronix!ogcvax!metheus!tombl
        !          4703:        allegra!ogcvax!metheus!tombl
        !          4704: 
        !          4705: 
        !          4706: 
        !          4707: From FRD@SU-AI  Sun Aug  7 12:34:43 1983
        !          4708: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
        !          4709:        id AA10610; Fri, 5 Aug 83 15:57:17 PDT
        !          4710: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
        !          4711:        id AA10357; Fri, 5 Aug 83 15:54:22 PDT
        !          4712: Message-Id: <[email protected]>
        !          4713: Date: 05 Aug 83  1353 PDT
        !          4714: From: Fred Lakin <FRD@SU-AI>
        !          4715: Subject: Franz & SUNs  
        !          4716: To: franz-friends@BERKELEY
        !          4717: Status: O
        !          4718: 
        !          4719: I am interested in connectons between Franz and SUN workstations.
        !          4720: Like how far along is Franz on the SUN?  Is there some package
        !          4721: which allows Franz on a VAX to use a SUN as a display device?
        !          4722: 
        !          4723: Any info on this matter would be appreciated.
        !          4724: Thnaks, Fred Lakin
        !          4725: 
        !          4726: 
        !          4727: From jkf  Mon Aug  8 09:06:49 1983
        !          4728: Received: by ucbkim.ARPA (4.2/4.2)
        !          4729:        id AA06584; Mon, 8 Aug 83 09:06:49 PDT
        !          4730: Date: Mon, 8 Aug 83 09:06:49 PDT
        !          4731: From: jkf (John Foderaro)
        !          4732: Message-Id: <[email protected]>
        !          4733: To: local-lisp
        !          4734: Subject: opus 38.72
        !          4735: Status: O
        !          4736: 
        !          4737:   A bug was fixed in defmacro which caused the &protect option and
        !          4738: displace-macros to interact poorly.
        !          4739: 
        !          4740: 
        !          4741: 
        !          4742: From jkf  Fri Aug 12 22:11:13 1983
        !          4743: Received: by ucbkim.ARPA (4.2/4.2)
        !          4744:        id AA25610; Fri, 12 Aug 83 22:11:13 PDT
        !          4745: Date: Fri, 12 Aug 83 22:11:13 PDT
        !          4746: From: jkf (John Foderaro)
        !          4747: Message-Id: <[email protected]>
        !          4748: To: local-lisp
        !          4749: Subject: opus 38.73
        !          4750: Status: O
        !          4751: 
        !          4752:  'equal' will now compare all types of vectors for equality.
        !          4753: 
        !          4754:  'copy' will now copy all types of vectors.
        !          4755: 
        !          4756:  
        !          4757: 
        !          4758: 
        !          4759: From layer  Mon Aug 15 20:03:53 1983
        !          4760: Received: by ucbkim.ARPA (4.2/4.2)
        !          4761:        id AA03597; Mon, 15 Aug 83 20:03:53 PDT
        !          4762: From: layer (Kevin Layer)
        !          4763: Phone: (415) 652-2405
        !          4764: Date: 15 Aug 1983 2003-PDT (Monday)
        !          4765: Message-Id: <3556.30.429851029@ucbkim>
        !          4766: To: local-lisp
        !          4767: Subject: liszt opus 8.35
        !          4768: Fcc: record
        !          4769: Status: RO
        !          4770: 
        !          4771:   Several things have changed:
        !          4772: 
        !          4773: 1) Bugs in the open coding of vectors have been fixed.
        !          4774: 
        !          4775: 2) Minor re-organization of the compiler source code.
        !          4776: 
        !          4777: 3) The routine to determine whether or not tail merging is
        !          4778:    possible underwent major modification.
        !          4779: 
        !          4780: 4) Lexpr's are compiled differently, or rather the way lexpr args
        !          4781:    are accessed has changed.  For those that want to know, here is
        !          4782:    the nitty gritty:
        !          4783: 
        !          4784:      Consider a the following lexpr: (defun test nargs ...).
        !          4785:      The arguments to the lexpr are stacked on the name stack
        !          4786:      (low to high number), and then nargs is stacked.  The user
        !          4787:      is allowed to change the binding of 'nargs' to anything
        !          4788:      he likes, so we have to have another way to access the arguments
        !          4789:      on the name stack (i.e., other than an offset from nargs).
        !          4790:      Before, a pointer to the argument base was pushed on the 
        !          4791:      C stack, so that indexing could be done from there.
        !          4792:      The addressing modes used to do this are not available
        !          4793:      on the MC68000 (something like *n(fp)[Rx]), so now
        !          4794:      nargs is pushed on the name stack twice, and the location
        !          4795:      of an argument can be easily calculated as an offset from nargs.
        !          4796: 
        !          4797: In short, lots of thing changed.  The SUN's should be updated
        !          4798: in the next couple of days (after I test it out).  Bugs to me...
        !          4799: 
        !          4800:        Kevin
        !          4801: 
        !          4802: From jkf  Mon Aug 15 23:11:08 1983
        !          4803: Received: by ucbkim.ARPA (4.2/4.2)
        !          4804:        id AA05928; Mon, 15 Aug 83 23:11:08 PDT
        !          4805: Date: Mon, 15 Aug 83 23:11:08 PDT
        !          4806: From: jkf (John Foderaro)
        !          4807: Message-Id: <[email protected]>
        !          4808: To: local-lisp
        !          4809: Subject:  opus 38.74
        !          4810: Status: O
        !          4811: 
        !          4812: 
        !          4813:   If a vector has a 'unique' property on it's property list, then it will
        !          4814: not be copied by 'copy'.
        !          4815: 
        !          4816:   'untrace' will now autoload /usr/lib/lisp/trace.
        !          4817: 
        !          4818:   A number of functions and macros were contributed by the bair group:
        !          4819: 
        !          4820:  
        !          4821: 
        !          4822: 
        !          4823: 
        !          4824: 
        !          4825: 
        !          4826: 
        !          4827: (<= 'fx_arg1 'fx_arg2 ...)
        !          4828: (<=& 'x_arg1 'x_arg2)
        !          4829: 
        !          4830:      RETURNS: t iff (> 'fx_arg1 'fx_arg2)  [or  (>&  'x_arg1
        !          4831:               'x_arg2)]  is nil, otherwise nil.  The general
        !          4832:               function, <=, can take  more  than  two  argu-
        !          4833:               ments.
        !          4834: 
        !          4835: (>= 'fx_arg1 'fx_arg2)
        !          4836: (>=& 'x_arg1 'x_arg2)
        !          4837: 
        !          4838:      RETURNS: t  iff  (<  'fx_arg1  'fx_arg2  ...)  [or  (<&
        !          4839:               'x_arg1 'x_arg2)] is nil, otherwise nil.
        !          4840: 
        !          4841:      NOTE: The general function, >=, can take more than  two
        !          4842:            arguments.
        !          4843: 
        !          4844: (litatom 'g_arg)
        !          4845: 
        !          4846:      RETURNS: t iff g_arg is an atom, but not a number.
        !          4847: 
        !          4848: (nequal 'g_x 'g_y)
        !          4849: 
        !          4850:      RETURNS: t iff g_x is not equal to g_y, otherwise nil.
        !          4851: 
        !          4852: (lineread [['p_port] ['s_flag]])
        !          4853: 
        !          4854:      RETURNS: a list consisting of s-expressions on  a  line
        !          4855:               from  the  port p_port (or piport if p_port is
        !          4856:               not given).  If an s-expression (e.g., a list)
        !          4857:               takes more than one line, or a line terminates
        !          4858:               in a space or  tab,  then  lineread  continues
        !          4859:               reading until an expression ends at the end of
        !          4860:               a line.
        !          4861: 
        !          4862:      NOTE: If s_flag is t, then if the first character on  a
        !          4863:            line  is  a  newline, lineread performs a tyi and
        !          4864:            returns nil.  If s_flag is nil  or  not  present,
        !          4865:            lineread  does  a  read  skipping  over any blank
        !          4866:            lines to make sure that an s-expression is  actu-
        !          4867:            ally read.
        !          4868: 
        !          4869:      SIDE EFFECT: lineread uses  read,  advancing  the  port
        !          4870:                   character pointer.
        !          4871: 
        !          4872: 
        !          4873: 
        !          4874: 
        !          4875: 
        !          4876: 
        !          4877: 
        !          4878: 
        !          4879: 9
        !          4880: 
        !          4881: 9
        !          4882: 
        !          4883: 
        !          4884: 
        !          4885: 
        !          4886: 
        !          4887: 
        !          4888: 
        !          4889: 
        !          4890: 
        !          4891: 
        !          4892: (defv g_arg1 g_arg2)
        !          4893: 
        !          4894:      EQUIVALENT TO: (set g_arg1 g_arg2)
        !          4895: 
        !          4896: (pp-form 'g_form ['p_port] ['n_lmar])
        !          4897: 
        !          4898:      RETURNS: nil
        !          4899: 
        !          4900:      SIDE EFFECT: g_form  is  pretty-printed  to  the   port
        !          4901:                   p_port (or poport if p_port is not given).
        !          4902:                   If  pp-form  is  also  supplied  with   an
        !          4903:                   integer  (n_lmar),  that  integer  will be
        !          4904:                   used as a left margin setting  (0  is  the
        !          4905:                   default).   This is the  function which pp
        !          4906:                   uses (n_lmar = 0). pp-form does  not  look
        !          4907:                   for  function  definitions  or  values  of
        !          4908:                   variables, it just prints out the form  it
        !          4909:                   is given.
        !          4910: 
        !          4911:      NOTE: This is useful as a top-level-printer, c.f.  top-
        !          4912:            level in Chapter 6.
        !          4913: 
        !          4914: (sload 's_file1 ...)
        !          4915: 
        !          4916:      SIDE EFFECT: The files named are opened for reading and
        !          4917:                   each form is read, optionally printed, and
        !          4918:                   evaluated.
        !          4919: 
        !          4920:      NOTE: What sload prints is controlled  by  the  special
        !          4921:            atom  $sldprint.   If  $sldprint  is t (default),
        !          4922:            then if a form  is  recognizable  as  a  function
        !          4923:            definition,  only  the  function name is printed,
        !          4924:            otherwise  the  whole  form   is   printed.    If
        !          4925:            $sldprint is eq to value, then the result of each
        !          4926:            form's evaluation will also be printed.  Printing
        !          4927:            the  forms'  values  can be controlled by setting
        !          4928:            sload-print equal to the name of the function  to
        !          4929:            be  called.   sload recognizes named functions by
        !          4930:            looking at  the  sloadprintarg  property  of  the
        !          4931:            function  name.   The  value of the sloadprintarg
        !          4932:            property should be the  argument  number  of  the
        !          4933:            function name.  For the standard Franz Lisp func-
        !          4934:            tions, the properties are already set.
        !          4935: 
        !          4936:      EXAMPLE: (defprop def 1 sloadprintarg)   ; This is  the
        !          4937:               default--declaring that
        !          4938:                                               ; the name  of
        !          4939:               the function definition is the
        !          4940:                                               ; first  argu-
        !          4941:               ment.
        !          4942: 
        !          4943: 
        !          4944: 9
        !          4945: 
        !          4946: 9
        !          4947: 
        !          4948: 
        !          4949: 
        !          4950: 
        !          4951: 
        !          4952: 
        !          4953: 
        !          4954: 
        !          4955: 
        !          4956: 
        !          4957:           The functions described below are  an  alternative
        !          4958:      to  the  gensym facility.  They generate new symbols by
        !          4959:      attaching counter numbers to the ends of  the  symbols'
        !          4960:      names.   An  example  follows  of how the functions are
        !          4961:      used.
        !          4962: 
        !          4963: 
        !          4964:     ____________________________________________________
        !          4965: 
        !          4966:     -> (initsym joe (john 5))       ; initializing new symbol counters
        !          4967:     (joe0 john5)
        !          4968:     -> (newsym john)                ; create a new symbol
        !          4969:     john6
        !          4970:     -> (newsym chuck)               ; symbol need not be initsym'ed
        !          4971:     chuck0
        !          4972:     -> (oldsym john)                ; get current symbol
        !          4973:     john6
        !          4974:     -> (allsym john)                ; get all symbols between 0 and counter
        !          4975:     (john0 john1 john2 john3 john4 john5 john6)
        !          4976:     -> (allsym (john 5))            ; get all symbols between 5 and counter
        !          4977:     (john5 john6)
        !          4978:     -> (remsym joe (john 4))        ; remob all interned symbols
        !          4979:                                     ; associated with joe and from
        !          4980:                                     ; john4 to the current john
        !          4981:                                     ; symbol--returns symbols with symbol counters
        !          4982:                                     ; before doing remsym
        !          4983:     (joe0 john6)
        !          4984:     -> (symstat joe john)
        !          4985:     ((joe nil) (john 3))
        !          4986:     ____________________________________________________
        !          4987: 
        !          4988: 
        !          4989: 
        !          4990: 
        !          4991: (initsym g_arg1 ...)
        !          4992: 
        !          4993:      WHERE:   g_argi is a  list  (n_counteri  s_argi)  or  a
        !          4994:               string  s_argi  (which  is  equivalent  to  (0
        !          4995:               s_argi)).
        !          4996: 
        !          4997:      RETURNS: a list of interned identifiers using the  sym-
        !          4998:               bol  counters  n_counteri, i.e., the result of
        !          4999:               concatenating s_argi to n_counteri.
        !          5000: 
        !          5001:      EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5)
        !          5002: 
        !          5003:      NOTE: See also newsym, oldsym, allsym, remsym, and sym-
        !          5004:            stat functions.
        !          5005: 
        !          5006: 
        !          5007: 
        !          5008: 
        !          5009: 9
        !          5010: 
        !          5011: 9
        !          5012: 
        !          5013: 
        !          5014: 
        !          5015: 
        !          5016: 
        !          5017: 
        !          5018: 
        !          5019: 
        !          5020: 
        !          5021: 
        !          5022: (newsym s_arg)
        !          5023: 
        !          5024:      RETURNS: an interned identifier formed by concatenating
        !          5025:               the  name  s_arg  to  the  symbol  counter for
        !          5026:               s_arg.  The symbol counter is  stored  on  the
        !          5027:               property list of s_arg under symctr.  If there
        !          5028:               is no counter, a counter  of  0  is  used  and
        !          5029:               added  to  the  property list.  Thus, a symbol
        !          5030:               need not be initsymed.
        !          5031: 
        !          5032:      EXAMPLE: (initsym joe (john5)) ==> (joe0 john5)
        !          5033:               (newsym john) ==> john6
        !          5034:               (newsym joe) ==> joe1
        !          5035: 
        !          5036:      NOTE: See also initsym,  oldsym,  allsym,  remsym,  and
        !          5037:            symstat functions.
        !          5038: 
        !          5039: (oldsym s_arg)
        !          5040: 
        !          5041:      RETURNS: the  identifier  using  the   current   symbol
        !          5042:               counter  for s_arg, rather than creating a new
        !          5043:               identifier.  If no symbol counter  exists  for
        !          5044:               s_arg, then s_arg is returned.
        !          5045: 
        !          5046:      NOTE: See also initsym,  newsym,  allsym,  remsym,  and
        !          5047:            symstat functions.
        !          5048: 
        !          5049: (allsym g_arg)
        !          5050: 
        !          5051:      WHERE:   g_arg is a list (s_arg n_counter) or a  string
        !          5052:               s_arg (equivalent to (s_arg 0)).
        !          5053: 
        !          5054:      RETURNS: a list of all the created identifiers  between
        !          5055:               n_counter  and  the current symbol counter for
        !          5056:               s_arg.
        !          5057: 
        !          5058:      EXAMPLE: (allsym john) ==> (john0 john1 john2)
        !          5059: 
        !          5060:      NOTE: See also initsym,  newsym,  oldsym,  remsym,  and
        !          5061:            symstat functions.
        !          5062: 
        !          5063: (remsym g_arg1 ...)
        !          5064: 
        !          5065:      WHERE:   g_argi is a  list  (s_argi  n_counteri)  or  a
        !          5066:               string  s_argi (which is equivalent to (s_argi
        !          5067:               0)).
        !          5068: 
        !          5069:      RETURNS: a list of symbols s_argi with the current sym-
        !          5070:               bol counters.
        !          5071: 
        !          5072:      SIDE EFFECT: remsym remob's all the created identifiers
        !          5073:                   between   zero   and  the  current  symbol
        !          5074:                   counter for s_argi.
        !          5075: 
        !          5076: 
        !          5077: 
        !          5078: 
        !          5079: 
        !          5080: 
        !          5081: 
        !          5082: 
        !          5083: 
        !          5084: 
        !          5085: 
        !          5086: 
        !          5087: 
        !          5088:      NOTE: See also initsym, newsym oldsym, allsym, and sym-
        !          5089:            stat functions.
        !          5090: 
        !          5091: (symstat s_arg1 ...)
        !          5092: 
        !          5093:      RETURNS: a list of pairs consisting of (s_argi symctri)
        !          5094:               where   symctri  is  s_argi's  current  symbol
        !          5095:               counter.
        !          5096: 
        !          5097:      NOTE: See also initsym,  newsym,  oldsym,  allsym,  and
        !          5098:            remsym functions.
        !          5099: 
        !          5100: 
        !          5101: 
        !          5102: 
        !          5103: 
        !          5104: 
        !          5105: 
        !          5106: 
        !          5107: 
        !          5108: 
        !          5109: 
        !          5110: 
        !          5111: 
        !          5112: 
        !          5113: 
        !          5114: 
        !          5115: 
        !          5116: 
        !          5117: 
        !          5118: 
        !          5119: 
        !          5120: 
        !          5121: 
        !          5122: 
        !          5123: 
        !          5124: 
        !          5125: 
        !          5126: 
        !          5127: 
        !          5128: 
        !          5129: 
        !          5130: 
        !          5131: 
        !          5132: 
        !          5133: 
        !          5134: 
        !          5135: 
        !          5136: 
        !          5137: 
        !          5138: 
        !          5139: 
        !          5140: 9
        !          5141: 
        !          5142: 9
        !          5143: 
        !          5144: 
        !          5145: 
        !          5146: 
        !          5147: 
        !          5148: 
        !          5149: From jkf  Thu Aug 18 19:25:45 1983
        !          5150: Received: by ucbkim.ARPA (4.2/4.2)
        !          5151:        id AA09885; Thu, 18 Aug 83 19:25:45 PDT
        !          5152: Date: Thu, 18 Aug 83 19:25:45 PDT
        !          5153: From: jkf (John Foderaro)
        !          5154: Message-Id: <[email protected]>
        !          5155: To: local-lisp
        !          5156: Subject: opus 38.75
        !          5157: Status: O
        !          5158: 
        !          5159:   evalhook and funcallhook can now be executed without setting (*rset t)
        !          5160: and (sstatus evalhook t).   Although they can be executed, they won't
        !          5161: have any effect unless and until (*rset t) and (sstatus evalhook t) are
        !          5162: done.
        !          5163:   The reason for this change is that now one can turn off stepping
        !          5164: by (sstatus evalhook nil) and then continue the evaluation with
        !          5165: evalhook and funcallhook.
        !          5166: 
        !          5167:   Those who use the new top-level 'tpl' will notice a few new commands
        !          5168: dealing with stepping when you type '?help'.   These new commands
        !          5169: are ?step, ?soff, and ?sc. Details of the commands are available
        !          5170: using the help mechanism (e.g. '?help step').
        !          5171: 
        !          5172: 
        !          5173: 
        !          5174: 
        !          5175: From jkf  Fri Aug 19 13:54:26 1983
        !          5176: Received: by ucbkim.ARPA (4.2/4.2)
        !          5177:        id AA20017; Fri, 19 Aug 83 13:54:26 PDT
        !          5178: Date: Fri, 19 Aug 83 13:54:26 PDT
        !          5179: From: jkf (John Foderaro)
        !          5180: Message-Id: <[email protected]>
        !          5181: To: local-lisp
        !          5182: Subject: liszt 8.36
        !          5183: Status: O
        !          5184: 
        !          5185:  The compiler will now compile the form
        !          5186:        (*no-macroexpand* <form>)
        !          5187:  in a special way: if <form> is a function call, e.g. (name arg1 ...),
        !          5188:  then any macro properties of 'name' will be ignored for this
        !          5189:  invocation.  This permits one to write macros which attempt
        !          5190:  an optimization, and if that fails, then call the standard
        !          5191:  function.  *no-macroexpand* is not a function that can be called,
        !          5192:  thus forms with *no-macroexpand* are likely to be 'cmacros'.
        !          5193:  Here is an example:
        !          5194: 
        !          5195:    (defcmacro length (x &protect (x))
        !          5196:        `(if (null ,x)
        !          5197:           then 0
        !          5198:         elseif (null (cdr ,x))
        !          5199:          then 1
        !          5200:         else (*no-macroexpand* (length ,x))))
        !          5201: 
        !          5202: 
        !          5203:  [in case you are wondering, the `&protect (x)' means that
        !          5204:   should the actual argument to 'length' be a non atom, defcmacro
        !          5205:   will lambda bind the value, insuring that it is only evaluated
        !          5206:   once]
        !          5207:  
        !          5208:  
        !          5209: 
        !          5210: 
        !          5211: From layer  Wed Aug 24 22:18:34 1983
        !          5212: Received: by ucbkim.ARPA (4.6/4.2)
        !          5213:        id AA12256; Wed, 24 Aug 83 22:18:34 PDT
        !          5214: From: layer (Kevin Layer)
        !          5215: Phone: (415) 652-2405
        !          5216: Date: 24 Aug 1983 2218-PDT (Wednesday)
        !          5217: Message-Id: <12219.30.430636709@ucbkim>
        !          5218: To: local-lisp
        !          5219: Subject: liszt on kim
        !          5220: Status: O
        !          5221: 
        !          5222:   The liszt that I installed on kim yesterday, compiled eq's wrong
        !          5223: in some rare cases.  I installed a new one this evening that fixes
        !          5224: this, but if you compiled any programs with the bad one, you might
        !          5225: consider re-compiling them...
        !          5226: 
        !          5227:        Kevin
        !          5228: 
        !          5229: From fateman  Thu Aug 25 13:58:59 1983
        !          5230: Received: by ucbkim.ARPA (4.6/4.2)
        !          5231:        id AA21033; Thu, 25 Aug 83 13:58:59 PDT
        !          5232: Date: Thu, 25 Aug 83 13:58:59 PDT
        !          5233: From: fateman (Richard Fateman)
        !          5234: Message-Id: <[email protected]>
        !          5235: To: local-lisp
        !          5236: Status: O
        !          5237: 
        !          5238: I have a copy of the latest Common Lisp manual... the Excelsior Edition.
        !          5239: 
        !          5240: From patel@UCLA-LOCUS  Tue Aug 30 21:58:38 1983
        !          5241: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5242:        id AA29417; Tue, 30 Aug 83 21:58:38 PDT
        !          5243: Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4)
        !          5244:        id AA06203; Tue, 30 Aug 83 21:50:26 PDT
        !          5245: Message-Id: <[email protected]>
        !          5246: Date:           Tue, 30 Aug 83 21:44:13 PDT
        !          5247: From: Dorab Patel <patel@UCLA-LOCUS>
        !          5248: To: franz-friends@BERKELEY
        !          5249: Subject:        bug fix for 'insert' in opus 38.50
        !          5250: Status: O
        !          5251: 
        !          5252: The function 'insert' in Opus 38.50 does not perform as advertised in 
        !          5253: the manual if the last argument is non-nil (i.e. if no duplicates are allowed.
        !          5254: It still insists on putting the duplicate element into the list. The
        !          5255: fix is in /usr/lib/lisp/common2.l. Just change the default setting
        !          5256: of the 'comparefn' to that given below instead of 
        !          5257: (function alphalessp). Here is an excerpt from the modified file.
        !          5258: 
        !          5259: 
        !          5260:   [.....]
        !          5261: (def insert
        !          5262:      (lambda (x l comparefn nodups)
        !          5263:       (cond ((null l) (list x))
        !          5264:             ((atom l)
        !          5265:              (error "an atom, can't be inserted into" l))
        !          5266:             (t (cond
        !          5267:                 ((null comparefn) (setq comparefn 
        !          5268:                                        (function
        !          5269:                                         (lambda (x y) 
        !          5270:                                                 (or (alphalessp x y) 
        !          5271:                                                     (equal x y)))))))
        !          5272:                (prog (l1 n n1 y)
        !          5273:                      (setq l1 l)
        !          5274:                      (setq n (length l))
        !          5275:                 a    (setq n1 (/ (add1 n) 2))
        !          5276:                      (setq y (Cnth l1 n1))
        !          5277:                     [..........]
        !          5278: 
        !          5279: From jkf  Sun Sep  4 09:59:01 1983
        !          5280: Received: by ucbkim.ARPA (4.6/4.2)
        !          5281:        id AA03721; Sun, 4 Sep 83 09:59:01 PDT
        !          5282: Date: Sun, 4 Sep 83 09:59:01 PDT
        !          5283: From: jkf (John Foderaro)
        !          5284: Message-Id: <[email protected]>
        !          5285: To: local-lisp
        !          5286: Subject: opus 38.77
        !          5287: Status: O
        !          5288: 
        !          5289:   The 'error' function used to print its arguments and then call 'err' to
        !          5290: cause the familar 'call to err' error.  The problem with this is that
        !          5291: even if you wrap your compuatation with (errset ... nil), the error message
        !          5292: will still be printed.   In opus 38.77, this problem has been fixed.
        !          5293: 
        !          5294: A new function was added:
        !          5295:        (err-with-message 'st_message ['g_value])
        !          5296:  This causes an error to be signaled with the given message.   The message
        !          5297: will only be printed if an '(errset ... nil)' isn't being executed.
        !          5298: Normally nil is returned from an errset if an error occured.  If you provide
        !          5299: g_value, then it will be returned from the errset.
        !          5300: [Not surprisingly, 'error' now uses 'err-with-message']
        !          5301: 
        !          5302: 
        !          5303: Also, 'error' now takes any number of arguments.  In concatenates them,
        !          5304: separated by spaces, and this is the error message passed to
        !          5305: err-with-message.
        !          5306: 
        !          5307: 
        !          5308: 
        !          5309: 
        !          5310: From narain@rand-unix  Fri Sep  9 13:32:24 1983
        !          5311: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5312:        id AA16481; Fri, 9 Sep 83 13:32:24 PDT
        !          5313: Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7)
        !          5314:        id AA11010; Fri, 9 Sep 83 13:31:58 PDT
        !          5315: Message-Id: <[email protected]>
        !          5316: Date: Friday,  9 Sep 1983 10:55-PDT
        !          5317: To: franz-friends@BERKELEY
        !          5318: Cc: narain@rand-unix
        !          5319: Subject: Franzlisp Question
        !          5320: From: narain@rand-unix
        !          5321: Status: O
        !          5322: 
        !          5323: 
        !          5324: Hello all:
        !          5325: 
        !          5326: I would be grateful if you could answer another question regarding Franzlisp.
        !          5327: How does one make Franzlisp continue from an error? For example when Lisp
        !          5328: gives an error message like "x unbound variable", is it possible to
        !          5329: bind x to a value and make Lisp continue from that point? Right now we have
        !          5330: to start over again and it is very time consuming.
        !          5331: 
        !          5332: -- Sanjai
        !          5333: 
        !          5334: From [email protected]  Fri Sep  9 13:46:45 1983
        !          5335: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5336:        id AA16843; Fri, 9 Sep 83 13:46:45 PDT
        !          5337: Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7)
        !          5338:        id AA11248; Fri, 9 Sep 83 13:46:26 PDT
        !          5339: Date: 9 Sep 1983 1427-EDT
        !          5340: From: AUSTIN@DEC-MARLBORO
        !          5341: To: FRANZ-FRIENDS@BERKELEY
        !          5342: Subject: LIST MEMBERSHIP
        !          5343: Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO>
        !          5344: Status: O
        !          5345: 
        !          5346: PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION.
        !          5347: 
        !          5348: MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO.
        !          5349: 
        !          5350: THANKS!
        !          5351:    --------
        !          5352: 
        !          5353: From jkf  Sat Sep 10 12:34:14 1983
        !          5354: Received: by ucbkim.ARPA (4.6/4.2)
        !          5355:        id AA28421; Sat, 10 Sep 83 12:34:14 PDT
        !          5356: Date: Sat, 10 Sep 83 12:34:14 PDT
        !          5357: From: jkf (John Foderaro)
        !          5358: Message-Id: <[email protected]>
        !          5359: To: local-lisp
        !          5360: Subject: opus 38.78
        !          5361: Status: O
        !          5362: 
        !          5363:  The new functions contributed by the bair group dealing with symbol
        !          5364: creation have been changed from fexprs to exprs (lambdas) and lexprs.
        !          5365: 
        !          5366: The new documentation follows:
        !          5367: 
        !          5368: 
        !          5369: 
        !          5370: 
        !          5371: 
        !          5372: 
        !          5373: 
        !          5374:      The functions described below are an alternative to the
        !          5375: gensym  facility.   They  generate  new symbols by attaching
        !          5376: counter numbers to the ends of the symbols' names.  An exam-
        !          5377: ple follows of how the functions are used.
        !          5378: 
        !          5379: 
        !          5380:     ____________________________________________________
        !          5381: 
        !          5382:     -> (initsym 'joe '(john 5))     ; initializing new symbol counters
        !          5383:     (joe0 john5)
        !          5384:     -> (newsym 'john)               ; create a new symbol
        !          5385:     john6
        !          5386:     -> (newsym 'chuck)              ; symbol need not be initsym'ed
        !          5387:     chuck0
        !          5388:     -> (oldsym 'john)               ; get current symbol
        !          5389:     john6
        !          5390:     -> (allsym 'john)               ; get all symbols between 0 and counter
        !          5391:     (john0 john1 john2 john3 john4 john5 john6)
        !          5392:     -> (allsym '(john 5))           ; get all symbols between 5 and counter
        !          5393:     (john5 john6)
        !          5394:     -> (remsym 'joe '(john 4))      ; remob all interned symbols
        !          5395:                                     ; associated with joe and from
        !          5396:                                     ; john4 to the current john
        !          5397:                                     ; symbol--returns symbols with symbol counters
        !          5398:                                     ; before doing remsym
        !          5399:     (joe0 john6)
        !          5400:     -> (symstat 'joe 'john)
        !          5401:     ((joe nil) (john 3))
        !          5402:     ____________________________________________________
        !          5403: 
        !          5404: 
        !          5405: 
        !          5406: 
        !          5407: (initsym 'g_arg1 ...)
        !          5408: 
        !          5409:      WHERE:   g_argi is a  list  (n_counteri  s_argi)  or  a
        !          5410:               string  s_argi  (which  is  equivalent  to  (0
        !          5411:               s_argi)).
        !          5412: 
        !          5413:      RETURNS: a list of interned identifiers using the  sym-
        !          5414:               bol  counters  n_counteri, i.e., the result of
        !          5415:               concatenating s_argi to n_counteri.
        !          5416: 
        !          5417:      EXAMPLE: (initsym 'joe '(john 5)) ==> (joe0 john5)
        !          5418: 
        !          5419:      NOTE: See also newsym, oldsym, allsym, remsym, and sym-
        !          5420:            stat functions.
        !          5421: 
        !          5422: 
        !          5423: 
        !          5424: 
        !          5425: 
        !          5426: 
        !          5427: 
        !          5428: 
        !          5429: 
        !          5430: 
        !          5431: 
        !          5432: 
        !          5433: 
        !          5434: 
        !          5435: 
        !          5436: 
        !          5437: 
        !          5438: 
        !          5439: 
        !          5440: (newsym 's_arg)
        !          5441: 
        !          5442:      RETURNS: an interned identifier formed by concatenating
        !          5443:               the  name  s_arg  to  the  symbol  counter for
        !          5444:               s_arg.  The symbol counter is  stored  on  the
        !          5445:               property list of s_arg under symctr.  If there
        !          5446:               is no counter, a counter  of  0  is  used  and
        !          5447:               added  to  the  property list.  Thus, a symbol
        !          5448:               need not be initsymed.
        !          5449: 
        !          5450:      EXAMPLE: (initsym 'joe '(john5)) ==> (joe0 john5)
        !          5451:               (newsym 'john) ==> john6
        !          5452:               (newsym 'joe) ==> joe1
        !          5453: 
        !          5454:      NOTE: See also initsym,  oldsym,  allsym,  remsym,  and
        !          5455:            symstat functions.
        !          5456: 
        !          5457: (oldsym 's_arg)
        !          5458: 
        !          5459:      RETURNS: the  identifier  using  the   current   symbol
        !          5460:               counter  for s_arg, rather than creating a new
        !          5461:               identifier.  If no symbol counter  exists  for
        !          5462:               s_arg, then s_arg is returned.
        !          5463: 
        !          5464:      NOTE: See also initsym,  newsym,  allsym,  remsym,  and
        !          5465:            symstat functions.
        !          5466: 
        !          5467: (allsym 'g_arg)
        !          5468: 
        !          5469:      WHERE:   g_arg is a list (s_arg n_counter) or a  string
        !          5470:               s_arg (equivalent to (s_arg 0)).
        !          5471: 
        !          5472:      RETURNS: a list of all the created identifiers  between
        !          5473:               n_counter  and  the current symbol counter for
        !          5474:               s_arg.
        !          5475: 
        !          5476:      EXAMPLE: (allsym 'john) ==> (john0 john1 john2)
        !          5477: 
        !          5478:      NOTE: See also initsym,  newsym,  oldsym,  remsym,  and
        !          5479:            symstat functions.
        !          5480: 
        !          5481: (remsym 'g_arg1 ...)
        !          5482: 
        !          5483:      WHERE:   g_argi is a  list  (s_argi  n_counteri)  or  a
        !          5484:               string  s_argi (which is equivalent to (s_argi
        !          5485:               0)).
        !          5486: 
        !          5487:      RETURNS: a list of symbols s_argi with the current sym-
        !          5488:               bol counters.
        !          5489: 
        !          5490:      SIDE EFFECT: remsym remob's all the created identifiers
        !          5491:                   between   zero   and  the  current  symbol
        !          5492:                   counter for s_argi.
        !          5493: 
        !          5494: 
        !          5495: 
        !          5496: 
        !          5497: 
        !          5498: 
        !          5499: 
        !          5500: 
        !          5501: 
        !          5502: 
        !          5503: 
        !          5504: 
        !          5505: 
        !          5506:      NOTE: See also initsym, newsym oldsym, allsym, and sym-
        !          5507:            stat functions.
        !          5508: 
        !          5509: (symstat 's_arg1 ...)
        !          5510: 
        !          5511:      RETURNS: a list of pairs consisting of (s_argi symctri)
        !          5512:               where   symctri  is  s_argi's  current  symbol
        !          5513:               counter.
        !          5514: 
        !          5515:      NOTE: See also initsym,  newsym,  oldsym,  allsym,  and
        !          5516:            remsym functions.
        !          5517: 
        !          5518: 
        !          5519: 
        !          5520: 
        !          5521: 
        !          5522: 
        !          5523: 
        !          5524: 
        !          5525: 
        !          5526: 
        !          5527: 
        !          5528: 
        !          5529: 
        !          5530: 
        !          5531: 
        !          5532: 
        !          5533: 
        !          5534: 
        !          5535: 
        !          5536: 
        !          5537: 
        !          5538: 
        !          5539: 
        !          5540: 
        !          5541: 
        !          5542: 
        !          5543: 
        !          5544: 
        !          5545: 
        !          5546: 
        !          5547: 
        !          5548: 
        !          5549: 
        !          5550: 
        !          5551: 
        !          5552: 
        !          5553: 
        !          5554: 
        !          5555: 
        !          5556: 
        !          5557: 
        !          5558: 
        !          5559: 
        !          5560: 
        !          5561: 
        !          5562: 
        !          5563: 
        !          5564: 
        !          5565: 
        !          5566: 
        !          5567: 
        !          5568: From jkf@ucbkim  Wed Sep 14 08:04:14 1983
        !          5569: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5570:        id AA14801; Wed, 14 Sep 83 08:04:14 PDT
        !          5571: Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7)
        !          5572:        id AA04212; Wed, 14 Sep 83 08:03:58 PDT
        !          5573: Received: by ucbkim.ARPA (4.6/4.2)
        !          5574:        id AA14786; Wed, 14 Sep 83 08:03:43 PDT
        !          5575: Date: Wed, 14 Sep 83 08:03:43 PDT
        !          5576: From: jkf@ucbkim (John Foderaro)
        !          5577: Message-Id: <[email protected]>
        !          5578: To: franz-friends@BERKELEY
        !          5579: Subject: lisp distribution
        !          5580: Status: O
        !          5581: 
        !          5582:   A number of you have noticed that ftp'ing the lisp distribution from
        !          5583: ucb-vax can be slow at times.    As a result, we've made 'ucb-arpa' the
        !          5584: primary distribution machine.  You can ftp from ucb-arpa using an anonymous
        !          5585: login (with your name as password).   The files are in the pub/lisp
        !          5586: subdirectory.
        !          5587:                                        john foderaro
        !          5588:                                        
        !          5589: 
        !          5590: 
        !          5591: 
        !          5592: From liz%umcp-cs@UDel-Relay  Mon Sep 26 19:41:37 1983
        !          5593: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5594:        id AA24055; Mon, 26 Sep 83 19:41:37 PDT
        !          5595: Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7)
        !          5596:        id AA07367; Mon, 26 Sep 83 16:28:58 PDT
        !          5597: Message-Id: <[email protected]>
        !          5598: Date:     26 Sep 83 15:22:00 EDT  (Mon)
        !          5599: From: Liz Allen <liz%umcp-cs@UDel-Relay>
        !          5600: Return-Path: <liz%umcp-cs@UDel-Relay>
        !          5601: Subject:  Maryland software distribution
        !          5602: To: franz-friends@BERKELEY
        !          5603: Via:  UMCP-CS; 26 Sep 83 17:46-EDT
        !          5604: Status: O
        !          5605: 
        !          5606: This is to announce the availability of the Univ of Maryland software
        !          5607: distribution.  This includes source code for the following:
        !          5608: 
        !          5609: 1.  The flavors package written in Franz Lisp.  This package has
        !          5610:     been used successfully in a number of large systems at Maryland,
        !          5611:     and while it does not implement all the features of Lisp Machine
        !          5612:     Flavors, the features present are as close to the Lisp Machine
        !          5613:     version as possible within the constraints of Franz Lisp.
        !          5614:     (Note that Maryland flavors code *can* be compiled.)
        !          5615: 2.  Other Maryland Franz hacks including the INTERLISP-like top
        !          5616:     level, the lispbreak error handling package, the for macro and
        !          5617:     the new loader package.
        !          5618: 3.  The YAPS production system written in Franz Lisp.  This is
        !          5619:     similar to OPS5 but more flexible in the kinds of lisp expressions
        !          5620:     that may appear as facts and patterns (sublists are allowed
        !          5621:     and flavor objects are treated atomically), the variety of
        !          5622:     tests that may appear in the left hand sides of rules and the
        !          5623:     kinds of actions may appear in the right hand sides of rules.
        !          5624:     In addition, YAPS allows multiple data bases which are flavor
        !          5625:     objects and may be sent messages such as "fact" and "goal".
        !          5626: 4.  The windows package in the form of a C loadable library.  This
        !          5627:     flexible package allows convenient management of multiple
        !          5628:     contexts on the screen and runs on ordinary character display
        !          5629:     terminals as well as bit-mapped displays.  Included is a Franz
        !          5630:     lisp interface to the window library, a window shell for
        !          5631:     executing shell processes in windows, and a menu package (also
        !          5632:     a C loadable library).
        !          5633: 
        !          5634: You should be aware of the fact that the lisp software is based on
        !          5635: Franz Opus 38.26 and that we will be switching to the newer version
        !          5636: of lisp that comes with Berkeley 4.2 whenever that comes out.
        !          5637: 
        !          5638: ---------------------------------------------------------------------
        !          5639: 
        !          5640: To obtain the Univ of Maryland distribution tape:
        !          5641: 
        !          5642: 1.  Fill in the form below, make a hard copy of it and sign it.
        !          5643: 2.  Make out a check to University of Maryland Foundation for $100,
        !          5644:     mail it and the form to:
        !          5645: 
        !          5646:                Liz Allen
        !          5647:                Univ of Maryland
        !          5648:                Dept of Computer Science
        !          5649:                College Park MD 20742
        !          5650: 
        !          5651: 3.  If you need an invoice, send me mail, and I will get one to you.
        !          5652:     Don't forget to include your US Mail address.
        !          5653: 
        !          5654: Upon receipt of the money, we will mail you a tape containing our
        !          5655: software and the technical reports describing the software.  We
        !          5656: will also keep you informed of bug fixes via electronic mail.
        !          5657: 
        !          5658: ---------------------------------------------------------------------
        !          5659: 
        !          5660: The form to mail to us is:
        !          5661: 
        !          5662: 
        !          5663: In exchange for the Maryland software tape, I certify to the
        !          5664: following:
        !          5665: 
        !          5666: a.  I will not use any of the Maryland software distribution in a
        !          5667:     commercial product without obtaining permission from Maryland
        !          5668:     first.
        !          5669: b.  I will keep the Maryland copyright notices in the source code,
        !          5670:     and acknowledge the source of the software in any use I make of
        !          5671:     it.
        !          5672: c.  I will not redistribute this software to anyone without permission
        !          5673:     from Maryland first.
        !          5674: d.  I will keep Maryland informed of any bug fixes.
        !          5675: e.  I am the appropriate person at my site who can make guarantees a-d.
        !          5676: 
        !          5677:                                Your signature, name, position,
        !          5678:                                phone number, U.S. and electronic
        !          5679:                                mail addresses.
        !          5680: 
        !          5681: ---------------------------------------------------------------------
        !          5682: 
        !          5683: If you have any questions, etc, send mail to me:
        !          5684: 
        !          5685:                                -Liz Allen, U of Maryland, College Park MD
        !          5686:                                 Usenet:   ...!seismo!umcp-cs!liz
        !          5687:                                 Arpanet:  liz%umcp-cs@Udel-Relay
        !          5688: 
        !          5689: 
        !          5690: From fateman  Thu Sep 29 14:50:17 1983
        !          5691: Received: by ucbkim.ARPA (4.6/4.2)
        !          5692:        id AA10806; Thu, 29 Sep 83 14:50:17 PDT
        !          5693: Date: Thu, 29 Sep 83 14:50:17 PDT
        !          5694: From: fateman (Richard Fateman)
        !          5695: Message-Id: <[email protected]>
        !          5696: To: franz-friends
        !          5697: Subject: survey
        !          5698: Cc: fateman
        !          5699: Status: O
        !          5700: 
        !          5701: I am trying to collect some statistics on usage of Franz.
        !          5702: I would like to get answers to these questions:
        !          5703: (1) Your location:
        !          5704: (2) The number of computers at your location (actively) running Franz:
        !          5705: (3) Have you produced a locally modified manual? (y/n)
        !          5706: (4) Are other Lisps in use there? (names?)
        !          5707: (5) Do you use Franz for instruction? research?
        !          5708: (6) Are you distributing or selling packages "on top of" Franz?
        !          5709: 
        !          5710: (You may also send comments you wish; I will compile results and
        !          5711: redistribute, so please do not respond to "franz-friends", but to me.)
        !          5712: Thanks.
        !          5713: 
        !          5714: From jkf  Thu Sep 29 23:04:29 1983
        !          5715: Received: by ucbkim.ARPA (4.6/4.2)
        !          5716:        id AA04355; Thu, 29 Sep 83 23:04:29 PDT
        !          5717: Date: Thu, 29 Sep 83 23:04:29 PDT
        !          5718: From: jkf (John Foderaro)
        !          5719: Message-Id: <[email protected]>
        !          5720: To: local-lisp
        !          5721: Subject: opus 38.80
        !          5722: Status: O
        !          5723: 
        !          5724:   Two new functions:
        !          5725: 
        !          5726:     (character-index 'st_string 'xst_char)
        !          5727: 
        !          5728:     returns the position of the character xst_char in the string
        !          5729:     st_string.  The position of the first character is '1'
        !          5730:     (1-based indexing was chosen because substring also uses
        !          5731:      1-based indexing).
        !          5732:     If the character is not in the string, nil is returned.
        !          5733: 
        !          5734:      xst_char, as its prefix implies, can either be the fixnum
        !          5735:      value of a character (commonly written #/x), or a symbol
        !          5736:      or string, in which case the first character is used.
        !          5737: 
        !          5738: 
        !          5739:   (sleep 'x_seconds)
        !          5740:     sleep for x_seconds.
        !          5741: 
        !          5742:   
        !          5743: 
        !          5744: 
        !          5745: From jkf  Sat Oct  1 21:42:29 1983
        !          5746: Received: by ucbkim.ARPA (4.6/4.2)
        !          5747:        id AA16280; Sat, 1 Oct 83 21:42:29 PDT
        !          5748: Date: Sat, 1 Oct 83 21:42:29 PDT
        !          5749: From: jkf (John Foderaro)
        !          5750: Message-Id: <[email protected]>
        !          5751: To: local-lisp
        !          5752: Subject: opus 38.81
        !          5753: Status: O
        !          5754: 
        !          5755:  new function  (sys:nice 'x_delta-priority)
        !          5756: this increments your nice value (decrements your process priority)
        !          5757: by x_delta-priority.    x_delta-priority can only be negative
        !          5758: if you are root, of course.
        !          5759: 
        !          5760: 
        !          5761: 
        !          5762: 
        !          5763: From unmvax!gatech!pwh  Tue Oct  4 08:35:04 1983
        !          5764: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5765:        id AA23488; Tue, 4 Oct 83 08:35:04 PDT
        !          5766: Received: by ucbvax.ARPA (4.12/4.7)
        !          5767:        id AA07616; Tue, 4 Oct 83 08:05:43 PDT
        !          5768: From: unmvax!gatech!pwh
        !          5769: Message-Id: <[email protected]>
        !          5770: Date:     1 Oct 83 19:44:56-EDT (Sat)
        !          5771: Original-From:      <pwh@gatech>
        !          5772: To: franz-friends@BERKELEY
        !          5773: Subject:  why a HOLE (duck) ?
        !          5774: Status: RO
        !          5775: 
        !          5776: 
        !          5777: Could someone explain to me what HOLE is all about in the vax dependent 
        !          5778: Franz code? I've scrutinized the code and read the preliminary Franz 
        !          5779: implementation manual too many times and still can't figure it...
        !          5780: 
        !          5781: phil hutto
        !          5782: 
        !          5783: 
        !          5784: 
        !          5785: 
        !          5786: From mbr@nprdc  Sat Oct  8 15:59:38 1983
        !          5787: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5788:        id AA08262; Sat, 8 Oct 83 15:59:38 PDT
        !          5789: Received: from nprdc (nprdc.ARPA) by ucbvax.ARPA (4.12/4.7)
        !          5790:        id AA23633; Sat, 8 Oct 83 15:58:02 PDT
        !          5791: Message-Id: <[email protected]>
        !          5792: Date: 8 Oct 1983 15:52:17-PDT
        !          5793: From: Mark Rosenstein <mbr@NPRDC>
        !          5794: Reply-To: mbr@NPRDC
        !          5795: To: franz-friends@BERKELEY
        !          5796: Subject: bugs in liszt 8.36
        !          5797: Status: RO
        !          5798: 
        !          5799: Problem:
        !          5800:    -I flag doesn't work
        !          5801: Solution??
        !          5802:    in file tlev.l change 'i to 'I in line 127
        !          5803:    (notice that -i flag includes files and it is imposible to get
        !          5804:     into uci mode)
        !          5805: 
        !          5806: Problem:
        !          5807:    while compiling get message:
        !          5808:      Undefined function called from compiled code   e-sub2
        !          5809: Solution??
        !          5810:    in file tlev.l change e-sub2 to e-sub in line 298
        !          5811:    (I don't swear by this solution--my stuff seems to compile ok
        !          5812:     but no promises)
        !          5813: 
        !          5814: From jkf  Wed Oct 12 06:11:15 1983
        !          5815: Received: by ucbkim.ARPA (4.6/4.2)
        !          5816:        id AA29652; Wed, 12 Oct 83 06:11:15 PDT
        !          5817: Date: Wed, 12 Oct 83 06:11:15 PDT
        !          5818: From: John Foderaro (on an h19-u) <jkf>
        !          5819: Message-Id: <[email protected]>
        !          5820: To: local-lisp
        !          5821: Subject: New AI language in the works
        !          5822: Cc: 
        !          5823: Status: RO
        !          5824: 
        !          5825: 
        !          5826: From: Skef Wholey <[email protected]>
        !          5827: 
        !          5828: >From an article "Computing Women" in a shoddy little pseudo-magazine
        !          5829: called "Ampersand" that was stuck inside CMU's student newspaper this
        !          5830: week:
        !          5831: 
        !          5832:        Our final tip involves a different kind of research.  Is a
        !          5833:        breakthough in computing happening right on your own
        !          5834:        campus?  MIT and Carnegie-Mellon University, for example,
        !          5835:        are busy developing a brainchild called Lisp.  If
        !          5836:        successful, Lisp may become the standard language of
        !          5837:        ``artificially intelligent'' computers that ``think''
        !          5838:        within a limited sphere on their own.  Imagine your
        !          5839:        marketability if you've worked with a poineer in this
        !          5840:        field.  Skip a football game some Saturday afternoon and
        !          5841:        see what the Prof is doing with HIS spare time.  It could
        !          5842:        be profitable to you.
        !          5843: 
        !          5844: 
        !          5845: 
        !          5846: 
        !          5847: 
        !          5848: From @MIT-MC:apm@cmu-ri-isl1  Fri Oct 14 09:27:56 1983
        !          5849: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5850:        id AA14501; Fri, 14 Oct 83 09:27:56 PDT
        !          5851: Received: from MIT-MC (mit-mc.ARPA) by ucbvax.ARPA (4.12/4.7)
        !          5852:        id AA00195; Fri, 14 Oct 83 09:26:15 PDT
        !          5853: Message-Id: <[email protected]>
        !          5854: Date: 14 Oct 1983 12:22:28-EDT
        !          5855: From: Andrew.Mendler@CMU-RI-ISL1
        !          5856: Subject: eunice version of franz
        !          5857: Apparently-To: <franz-friends@UCB-VAX>
        !          5858: Status: RO
        !          5859: 
        !          5860: What is the most recent version of franz lisp that is available under eunice?
        !          5861: In particular is opus38.55 available?
        !          5862: 
        !          5863: Thanks in advance.
        !          5864: 
        !          5865: 
        !          5866: From sklower  Fri Oct 14 09:45:15 1983
        !          5867: Received: by ucbkim.ARPA (4.6/4.2)
        !          5868:        id AA14694; Fri, 14 Oct 83 09:45:15 PDT
        !          5869: Date: Fri, 14 Oct 83 09:45:15 PDT
        !          5870: From: sklower (Keith Sklower)
        !          5871: Message-Id: <[email protected]>
        !          5872: To: franz-friends
        !          5873: Subject: eunice version of franz
        !          5874: Status: RO
        !          5875: 
        !          5876: We have opus38.79 working on David Kashtan's machine.  The source
        !          5877: is integrated with the vax-unix and 68000 versions, all available
        !          5878: by anonymous ftp, or as the regular tape distribution.  I have had
        !          5879: one report from a eunice user that the installation didn't get past
        !          5880: construction the kernel, but it could be due to insufficient quota.
        !          5881: 
        !          5882: From jkf  Sun Oct 16 16:39:35 1983
        !          5883: Received: by ucbkim.ARPA (4.6/4.2)
        !          5884:        id AA03935; Sun, 16 Oct 83 16:39:35 PDT
        !          5885: Date: Sun, 16 Oct 83 16:39:35 PDT
        !          5886: From: John Foderaro (on an aaa-60-s) <jkf>
        !          5887: Message-Id: <[email protected]>
        !          5888: To: local-lisp
        !          5889: Subject: opus 38.82
        !          5890: Cc: 
        !          5891: Status: RO
        !          5892: 
        !          5893:   I'm working on a simple record (destruct-like) package. Consequently,
        !          5894: I've made 'defrecord' autoload my record package.  This will cause
        !          5895: problems if there are people who use the name 'defrecord' as a
        !          5896: non-macro function.   If this will cause you problems, please speak up.
        !          5897: 
        !          5898: 
        !          5899: 
        !          5900: From procter@UCBMIRO  Mon Oct 17 08:59:02 1983
        !          5901: Received: from UCBMIRO.ARPA by ucbkim.ARPA (4.6/4.2)
        !          5902:        id AA01206; Mon, 17 Oct 83 08:59:02 PDT
        !          5903: Date: 16 Oct 83 22:56:00 PDT (Sun)
        !          5904: From: procter@UCBMIRO (Steve Procter)
        !          5905: Subject: cfasl
        !          5906: Message-Id: <[email protected]>
        !          5907: Received: by UCBMIRO.ARPA (3.340/3.29)
        !          5908:        id AA01323; 16 Oct 83 22:56:00 PDT (Sun)
        !          5909: To: local-lisp@ucbkim
        !          5910: Status: O
        !          5911: 
        !          5912:        How are arguements passed from lisp to the C routines?
        !          5913: I wrote a program which just printed the arguements passed to it, 
        !          5914: and when I cfasl'd it and used it, I got argc > 500000...
        !          5915: 
        !          5916:                                                steve procter
        !          5917:                                                procter@ucbmiro
        !          5918: 
        !          5919: From jkf  Mon Oct 17 10:08:37 1983
        !          5920: Received: by ucbkim.ARPA (4.6/4.2)
        !          5921:        id AA02418; Mon, 17 Oct 83 10:08:37 PDT
        !          5922: Date: Mon, 17 Oct 83 10:08:37 PDT
        !          5923: From: John Foderaro (on an h19-u) <jkf>
        !          5924: Message-Id: <[email protected]>
        !          5925: To: procter@UCBMIRO
        !          5926: Subject: Re: cfasl
        !          5927: Cc: local-lisp
        !          5928: In-Reply-To: Your message of 16 Oct 83 22:56:00 PDT (Sun)
        !          5929: Status: O
        !          5930: 
        !          5931:   Arguments are passed to C functions in the normal C way (on the stack
        !          5932: not as strings on the command line).   There are examples in the
        !          5933: lisp manual (in the section on foreign functions).
        !          5934: 
        !          5935: 
        !          5936: 
        !          5937: From whm.Arizona@Rand-Relay  Fri Oct 28 05:44:39 1983
        !          5938: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
        !          5939:        id AA20395; Fri, 28 Oct 83 05:44:39 pdt
        !          5940: Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
        !          5941:        id AA14289; Fri, 28 Oct 83 05:43:48 pdt
        !          5942: Message-Id: <[email protected]>
        !          5943: Date: 28 Oct 1983 01:12:45-PST
        !          5944: From: whm.arizona@Rand-Relay
        !          5945: Return-Path: <whm.Arizona@Rand-Relay>
        !          5946: Subject:  Memory management in Franz
        !          5947: Date-Sent: 28 Oct 83 01:12:42 MST  (Fri)
        !          5948: To: franz-friends@BERKELEY
        !          5949: Via:  Arizona; 28 Oct 83 2:37-PDT
        !          5950: Status: O
        !          5951: 
        !          5952: I've got a couple of questions about Franz Lisp storage management that
        !          5953: I wondering if somebody "in the know" might be able to answer.  I tried
        !          5954: this on net.lang.lisp, but didn't get any answers.
        !          5955: 
        !          5956: First, Franz seems to support non-relocatable data objects such as
        !          5957: external functions.  Are such objects managed by having two logical
        !          5958: regions in managed memory, one for relocatable objects and one for
        !          5959: non-relocatable objects?  Such a scheme has been used in other systems
        !          5960: that require garbage collection and I was wondering if Franz uses
        !          5961: this or some other scheme.
        !          5962: 
        !          5963: Second, I've heard (but not tried) that Franz allows non-relocatable
        !          5964: data to be allocated via brk/sbrk.  Is this true?
        !          5965: 
        !          5966: (Actually, I suppose I'd like information on any storage management
        !          5967: implementations for any languages (w/ automatic storage management)
        !          5968: that allow non-relocatable data to be dynamically allocated that don't
        !          5969: use the aforementioned scheme.)
        !          5970: 
        !          5971:                                        Thanks,
        !          5972:                                        Bill Mitchell
        !          5973:                                        whm.arizona@rand-relay
        !          5974: p.s.
        !          5975: I'm not on the Franz-Friends list, so if you would, please mail me
        !          5976: any replies.
        !          5977: 
        !          5978: From whm.Arizona@Rand-Relay  Mon Oct 31 04:55:33 1983
        !          5979: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
        !          5980:        id AA29912; Mon, 31 Oct 83 04:55:33 pst
        !          5981: Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
        !          5982:        id AA08771; Mon, 31 Oct 83 04:54:49 pst
        !          5983: Message-Id: <[email protected]>
        !          5984: Date: 31 Oct 1983 00:41:38-PST
        !          5985: From: whm.arizona@Rand-Relay
        !          5986: Return-Path: <whm.Arizona@Rand-Relay>
        !          5987: Subject:  Memory management in Franz
        !          5988: Date-Sent: 31 Oct 83 00:41:36 MST  (Mon)
        !          5989: To: franz-friends@BERKELEY
        !          5990: Via:  Arizona; 31 Oct 83 1:36-PST
        !          5991: Status: O
        !          5992: 
        !          5993: [My apologies if this is a repeat; I got some very wierd messages back
        !          5994: from the Berkeley mailer on my first attempt to send this.]
        !          5995: 
        !          5996: I've got a couple of questions about Franz Lisp storage management that
        !          5997: I wondering if somebody "in the know" might be able to answer.  I tried
        !          5998: this on net.lang.lisp, but didn't get any answers.
        !          5999: 
        !          6000: First, Franz seems to support non-relocatable data objects such as
        !          6001: external functions.  Are such objects managed by having two logical
        !          6002: regions in managed memory, one for relocatable objects and one for
        !          6003: non-relocatable objects?  Such a scheme has been used in other systems
        !          6004: that require garbage collection and I was wondering if Franz uses
        !          6005: this or some other scheme.
        !          6006: 
        !          6007: Second, I've heard (but not tried) that Franz allows non-relocatable
        !          6008: data to be allocated via brk/sbrk.  Is this true?
        !          6009: 
        !          6010: (Actually, I suppose I'd like information on any storage management
        !          6011: implementations for any languages (w/ automatic storage management)
        !          6012: that allow non-relocatable data to be dynamically allocated that don't
        !          6013: use the aforementioned scheme.)
        !          6014: 
        !          6015:                                        Thanks,
        !          6016:                                        Bill Mitchell
        !          6017:                                        whm.arizona@rand-relay
        !          6018: p.s.
        !          6019: I'm not on the Franz-Friends list, so if you would, please mail me
        !          6020: any replies.
        !          6021: 
        !          6022: From pjt@brl-voc  Tue Nov  1 06:52:11 1983
        !          6023: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
        !          6024:        id AA03145; Tue, 1 Nov 83 06:52:11 pst
        !          6025: Received: from BRL-VOC (brl-voc.ARPA) by ucbvax.ARPA (4.16/4.13)
        !          6026:        id AA01150; Tue, 1 Nov 83 06:51:14 pst
        !          6027: Message-Id: <[email protected]>
        !          6028: Date:     Tue, 1 Nov 83 9:44:54 EST
        !          6029: From: Paul Tanenbaum <pjt@brl-voc>
        !          6030: To: Ailist-requests@sri-ai, Franz-Friends@BERKELEY
        !          6031: Cc: pjt@brl-voc
        !          6032: Subject:  mailing list
        !          6033: Status: O
        !          6034: 
        !          6035: Please cons me onto your mailing list
        !          6036:      Thanks,
        !          6037:      paul   <pjt@brl-voc>
        !          6038: 
        !          6039: 
        !          6040: From norvig  Fri Nov  4 14:14:16 1983
        !          6041: Received: by ucbkim.ARPA (4.16/4.13)
        !          6042:        id AA20986; Fri, 4 Nov 83 14:14:16 pst
        !          6043: Date: Fri, 4 Nov 83 14:14:16 pst
        !          6044: From: norvig (Peter Norvig)
        !          6045: Message-Id: <[email protected]>
        !          6046: To: mills@ernie
        !          6047: Subject: Graphics on Suns
        !          6048: Cc: local-lisp
        !          6049: Status: O
        !          6050: 
        !          6051: I want a lisp-callable package to display trees and graphs on the suns.
        !          6052: This is for showing semantic nets, and it would also be useful for showing
        !          6053: how procedures call each other, like Interlisp's masterscope. Does anyone
        !          6054: know of such a package?
        !          6055: 
        !          6056: From kanderso@bbn-vax  Fri Nov  4 19:55:59 1983
        !          6057: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
        !          6058:        id AA26540; Fri, 4 Nov 83 19:55:59 pst
        !          6059: Received: from bbn-vax (bbn-vax.ARPA) by ucbvax.ARPA (4.16/4.13)
        !          6060:        id AA03738; Fri, 4 Nov 83 19:55:52 pst
        !          6061: Message-Id: <[email protected]>
        !          6062: Date: Fri, 4 Nov 83 22:55 EST
        !          6063: From: Ken Anderson <kanderso@BBN-Vax>
        !          6064: Subject: Why no &keywords in local functions?
        !          6065: To: franz-friends@BERKELEY
        !          6066: Status: O
        !          6067: 
        !          6068: With liszt version 8.29 (Opus 38.66 of Franz) I get the following message:
        !          6069: 
        !          6070: ?Error: save.l: save-install: local functions can't use &keyword's save-install
        !          6071: 
        !          6072: When compiling the function (declared as a localf):
        !          6073: 
        !          6074: (defun save-install (thing table &aux type handler)
        !          6075:     ; Install thing in hash table, and recursively install its parts.
        !          6076:     (cond ((memq (setq type (save-type thing))
        !          6077:                 '(symbol number)))     ; Needn't install
        !          6078:          (t (cond ((zerop (save-count++ thing))
        !          6079:                    ; Increment access count, and install parts of thing if it
        !          6080:                    ; is being installe
        !          6081:                    (cond ((setq handler (get type 'save-install-parts))
        !          6082:                           (funcall handler thing table))
        !          6083:                          (t (ferror "Don't Know how to save ~S~%" thing))))))))
        !          6084: 
        !          6085: This used to work in earlier Opuses (like 38.44).  Can you explain the
        !          6086: change.
        !          6087: 
        !          6088: From norvig  Tue Nov  8 01:51:03 1983
        !          6089: Received: by ucbkim.ARPA (4.16/4.13)
        !          6090:        id AA20986; Fri, 4 Nov 83 14:14:16 pst
        !          6091: Date: Fri, 4 Nov 83 14:14:16 pst
        !          6092: From: norvig (Peter Norvig)
        !          6093: Message-Id: <[email protected]>
        !          6094: To: mills@ernie
        !          6095: Subject: Graphics on Suns
        !          6096: Cc: local-lisp
        !          6097: Status: O
        !          6098: 
        !          6099: I want a lisp-callable package to display trees and graphs on the suns.
        !          6100: This is for showing semantic nets, and it would also be useful for showing
        !          6101: how procedures call each other, like Interlisp's masterscope. Does anyone
        !          6102: know of such a package?
        !          6103: 
        !          6104: From norvig  Tue Nov  8 02:03:27 1983
        !          6105: Received: by ucbkim.ARPA (4.16/4.13)
        !          6106:        id AA20986; Fri, 4 Nov 83 14:14:16 pst
        !          6107: Date: Fri, 4 Nov 83 14:14:16 pst
        !          6108: From: norvig (Peter Norvig)
        !          6109: Message-Id: <[email protected]>
        !          6110: To: mills@ernie
        !          6111: Subject: Graphics on Suns
        !          6112: Cc: local-lisp
        !          6113: Status: O
        !          6114: 
        !          6115: I want a lisp-callable package to display trees and graphs on the suns.
        !          6116: This is for showing semantic nets, and it would also be useful for showing
        !          6117: how procedures call each other, like Interlisp's masterscope. Does anyone
        !          6118: know of such a package?
        !          6119: 
        !          6120: From sklower  Thu Nov 17 17:03:27 1983
        !          6121: Received: by ucbkim.ARPA (4.16/4.13)
        !          6122:        id AA01897; Thu, 17 Nov 83 17:03:27 pst
        !          6123: Date: Thu, 17 Nov 83 17:03:27 pst
        !          6124: From: sklower (Keith Sklower)
        !          6125: Message-Id: <[email protected]>
        !          6126: To: local-lisp
        !          6127: Subject: lisp sources
        !          6128: Status: O
        !          6129: 
        !          6130: Franz now resides in /usr/franz.
        !          6131: 
        !          6132: From jkf  Tue Nov 22 09:33:32 1983
        !          6133: Received: by ucbkim.ARPA (4.16/4.13)
        !          6134:        id AA15675; Tue, 22 Nov 83 09:33:32 pst
        !          6135: Date: Tue, 22 Nov 83 09:33:32 pst
        !          6136: From: John Foderaro (on an h19-u) <jkf>
        !          6137: Message-Id: <[email protected]>
        !          6138: To: local-lisp
        !          6139: Subject: liszt 8.39
        !          6140: Cc: 
        !          6141: Status: O
        !          6142: 
        !          6143:   The -W switch has been added to liszt.  When specified, if a compilation
        !          6144: causes any warning messages to given (such as a symbol declared special),
        !          6145: then the compiler will not perform the assembly and will return a non-zero
        !          6146: exit status (for 'make's benefit).   Liszt will continue to compile after it
        !          6147: has seen a warning, even if -W is given, to permit as many warnings as
        !          6148: possible to be made in each compile.
        !          6149: 
        !          6150: 
        !          6151: 
        !          6152: 
        !          6153: From barry%umcp-cs@CSNet-Relay  Tue Nov 22 17:14:09 1983
        !          6154: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6155:        id AA23508; Tue, 22 Nov 83 17:14:09 pst
        !          6156: Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.21/4.15)
        !          6157:        id AA06655; Tue, 22 Nov 83 17:13:29 pst
        !          6158: Message-Id: <[email protected]>
        !          6159: Date:     22 Nov 83 12:48:01 EST  (Tue)
        !          6160: From: Barry Perricone <barry%umcp-cs@CSNet-Relay>
        !          6161: Return-Path: <barry%umcp-cs@CSNet-Relay>
        !          6162: Subject:  Franz for VMS
        !          6163: To: franz-friends@BERKELEY
        !          6164: Via:  UMCP-CS; 22 Nov 83 19:25-EST
        !          6165: Status: O
        !          6166: 
        !          6167: 
        !          6168:   I need to know if anybody has a version of Franz for the Vax series
        !          6169: under VMS which includes 'liszt'.  Also one which when a 'dumplisp'
        !          6170: is performed will output a file which can execute as a stand-alone
        !          6171: (i.e., does not need to be "restored").  I would appreciate
        !          6172: any information on this matter, and if one exists information
        !          6173: on how I could obtain a copy of it.
        !          6174: 
        !          6175: Thanks in advance,
        !          6176: Barry P.
        !          6177: 
        !          6178: From alfred.ct@Rand-Relay  Sat Dec  3 22:40:07 1983
        !          6179: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6180:        id AA12594; Sat, 3 Dec 83 22:40:07 pst
        !          6181: Received: from rand-relay.ARPA by UCB-VAX.ARPA (4.22/4.16)
        !          6182:        id AA06631; Sat, 3 Dec 83 21:43:27 pst
        !          6183: Message-Id: <[email protected]>
        !          6184: Date: 3 Dec 1983 11:58:11-PST
        !          6185: From: alfred.ct@Rand-Relay
        !          6186: Return-Path: <alfred.ct@Rand-Relay>
        !          6187: Subject: Deficiency in Franz GC
        !          6188: To: franz-friends@BERKELEY
        !          6189: Via:  ct; 3 Dec 83 12:46-PST
        !          6190: Status: RO
        !          6191: 
        !          6192: This really isn't a bug so much as a deficiency
        !          6193: in the code.  We are running Opus 38.26 and recently
        !          6194: had need to increase the constant TTSIZE (in config.h)
        !          6195: above the default 10216.  It turns out that this
        !          6196: breaks the garbage collector which will fail
        !          6197: to completely clear the array bitmapi
        !          6198: if given a TTSIZE greater 10216 (during the
        !          6199: clearing out of bit maps).  The offending code
        !          6200: is in Talloc.c (or alloc.c, depending on your Opus).
        !          6201: The old code is:
        !          6202: 
        !          6203:        /* try the movc5 to clear the bit maps */
        !          6204:        /* the maximum number of bytes we can clear in one sweep is
        !          6205:         * 2^16 (or 1<<16 in the C lingo)
        !          6206:         */
        !          6207:        bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; 
        !          6208:        if(bytestoclear > MAXCLEAR)
        !          6209:        { 
        !          6210:           blzero(((int) &bitmapi[((int)beginsweep>>7)]) + MAXCLEAR, 
        !          6211:                            bytestoclear - MAXCLEAR);
        !          6212:           bytestoclear = MAXCLEAR;
        !          6213:        }
        !          6214:        blzero((int)&bitmapi[((int)beginsweep)>>7],bytestoclear);
        !          6215: 
        !          6216: and the fixed version that we have been running for several weeks
        !          6217: now is:
        !          6218: 
        !          6219:        /* try the movc5 to clear the bit maps */
        !          6220:        /* the maximum number of bytes we can clear in one sweep is
        !          6221:         * 2^16 (or 1<<16 in the C lingo)
        !          6222:         */
        !          6223:        bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16;
        !          6224:        {int count = 0; 
        !          6225:        while (bytestoclear > 0) {
        !          6226:            if(bytestoclear > MAXCLEAR)
        !          6227:            { 
        !          6228:                blzero(((int) &bitmapi[((int)beginsweep>>7)])+count*MAXCLEAR, 
        !          6229:                            MAXCLEAR);
        !          6230:                ++count;
        !          6231:            }
        !          6232:            else
        !          6233:                blzero(((int)&bitmapi[((int)beginsweep)>>7]+count*MAXCLEAR),
        !          6234:                        bytestoclear);
        !          6235:            bytestoclear -= MAXCLEAR;
        !          6236:            }
        !          6237:        }
        !          6238: 
        !          6239: The old code is still present in Opus 38.56.
        !          6240: 
        !          6241: Alfred Correira
        !          6242: Paul Robertson
        !          6243: ...ucbvax!nbires!ctvax!alfred (UUCP)
        !          6244: alfred.ct@Rand-Relay (CSNET)
        !          6245: 
        !          6246: From fateman  Tue Dec 13 09:11:00 1983
        !          6247: Received: by ucbkim.ARPA (4.16/4.13)
        !          6248:        id AA03666; Tue, 13 Dec 83 08:31:30 pst
        !          6249: Date: Tue, 13 Dec 83 08:31:30 pst
        !          6250: From: fateman (Richard Fateman)
        !          6251: Message-Id: <[email protected]>
        !          6252: To: local-lisp
        !          6253: Cc: pattrsn
        !          6254: Status: O
        !          6255: 
        !          6256: I have just received a copy of the new Common Lisp Reference Manual
        !          6257: (The Mary Poppins Edition ... Practically Perfect in Every Way)
        !          6258: ... it is 385 pages long.
        !          6259: 
        !          6260: From hoey@nrl-aic  Wed Jan 11 12:58:53 1984
        !          6261: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6262:        id AA06395; Wed, 11 Jan 84 12:58:53 pst
        !          6263: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
        !          6264:        id AA03955; Wed, 11 Jan 84 12:58:55 pst
        !          6265: Message-Id: <[email protected]>
        !          6266: Date: 11 Jan 1984 14:43-EST
        !          6267: From: Dan Hoey <hoey@NRL-AIC>
        !          6268: Subject: Problems with arrays in Franz
        !          6269: Apparently-To: <FRANZ-FRIENDS@berkeley>
        !          6270: Status: O
        !          6271: 
        !          6272: 
        !          6273: 
        !          6274: From hoey@nrl-aic  Wed Jan 11 13:10:01 1984
        !          6275: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6276:        id AA06529; Wed, 11 Jan 84 13:10:01 pst
        !          6277: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
        !          6278:        id AA04150; Wed, 11 Jan 84 13:09:46 pst
        !          6279: Message-Id: <[email protected]>
        !          6280: Date: 11 Jan 1984 14:43-EST
        !          6281: From: Dan Hoey <hoey@NRL-AIC>
        !          6282: Subject: Problems with arrays in Franz
        !          6283: To: FRANZ-FRIENDS@BERKELEY
        !          6284: Status: O
        !          6285: 
        !          6286: Hard to believe but it was less than two and a half years ago that
        !          6287: someone was having trouble using Franz arrays...
        !          6288: 
        !          6289:     Date: 17 Jul 1981 17:06:22-PDT
        !          6290:     From: CSVAX.jkf at Berkeley
        !          6291:     To: FININ@WHARTON-10
        !          6292:     cc: franz-friends at MIT-MC
        !          6293:     Subject: Re: ... the maclisp-style array package.
        !          6294:     In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday).
        !          6295: 
        !          6296:         From: FININ@WHARTON-10
        !          6297:         Subject: ... the maclisp-style array package.
        !          6298: 
        !          6299:         ...
        !          6300:         [3] We've been having problems with the MacLisp compatable array
        !          6301:             package - it doesn't work!  Does anyone have a debugged version?
        !          6302: 
        !          6303:     Can you be more specific? We use it in Vax Macsyma without any problems.
        !          6304:     Personally I feel that Maclisp arrays were invented by a madman and no new
        !          6305:     code should be written using them.  
        !          6306: 
        !          6307:     -- john foderaro
        !          6308: 
        !          6309: Well, I used the Maclisp array package because I didn't want to waste
        !          6310: time writing my own.  Instead I spent hours looking for the bug in this
        !          6311: code:
        !          6312: 
        !          6313:     -> (let ((factorial (*array () () 100.)))
        !          6314:             (store (factorial 0) 1)
        !          6315:            (do ((i 1 (1+ i)))
        !          6316:                ((= i 100.))
        !          6317:                 (store (factorial i) (times i (factorial (1- i)))))
        !          6318:             (factorial 10.))
        !          6319:     285656
        !          6320: 
        !          6321: To make a long story short, this lossage is because the second argument
        !          6322: to *array being nil tells the garbage collector not to scan the
        !          6323: array.  The factorial of ten gets tossed in the bit bucket, where it
        !          6324: unfortunately looks like a fixnum.  To fix the example, change the
        !          6325: first line of the example to
        !          6326: 
        !          6327:     -> (let ((factorial (*array () t 100.)))
        !          6328: 
        !          6329: To save someone else from excruciatingly wrong answers, change the
        !          6330: documentation in Section 2.
        !          6331: 
        !          6332:     (*array 's_name 's_type 'x_dim1 ... 'x_dimn)
        !          6333:     (array s_name s_type x_dim1 ... x_dimn)
        !          6334: 
        !          6335:          WHERE:   s_type may be one of t, nil,  fixnum,  flonum,
        !          6336:                   fixnum-block and flonum-block.
        !          6337:            ...
        !          6338: <                  In FRANZ LISP arrays of type t, nil, fix-
        !          6339: <          num and flonum are equivalent and the elements of
        !          6340: <          these  arrays  can  be  any  type of lisp object.
        !          6341: ---
        !          6342: >                  In  FRANZ  LISP arrays of type t, fixnum,
        !          6343: >          and  flonum  are  equivalent  and the elements of
        !          6344: >          these arrays can  be  any  type  of  lisp object.
        !          6345: >          Type nil arrays may also contain any type of lisp
        !          6346: >          object,  but  they are not marked  by the garbage
        !          6347: >          collector  (see 9.2.2)  and can lose data if used
        !          6348: >          incorrectly.
        !          6349:            Fixnum-block and  flonum-block  arrays  are  res-
        !          6350:            tricted  to  fixnums and flonums respectively and
        !          6351:            are used mainly to communicate with foreign func-
        !          6352:            tions (see 8.4).
        !          6353: 
        !          6354: Dan
        !          6355: 
        !          6356: From hoey@nrl-aic  Wed Jan 11 16:23:56 1984
        !          6357: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6358:        id AA06395; Wed, 11 Jan 84 12:58:53 pst
        !          6359: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
        !          6360:        id AA03955; Wed, 11 Jan 84 12:58:55 pst
        !          6361: Message-Id: <[email protected]>
        !          6362: Date: 11 Jan 1984 14:43-EST
        !          6363: From: Dan Hoey <hoey@NRL-AIC>
        !          6364: Subject: Problems with arrays in Franz
        !          6365: Apparently-To: <FRANZ-FRIENDS@berkeley>
        !          6366: Status: O
        !          6367: 
        !          6368: 
        !          6369: 
        !          6370: From fateman@ucbdali  Sun Jan 15 14:58:17 1984
        !          6371: Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13)
        !          6372:        id AA00458; Sun, 15 Jan 84 14:58:17 pst
        !          6373: Received: by ucbdali.ARPA (4.22/4.18)
        !          6374:        id AA02865; Sun, 15 Jan 84 14:58:51 pst
        !          6375: Date: Sun, 15 Jan 84 14:58:51 pst
        !          6376: From: fateman@ucbdali (Richard Fateman)
        !          6377: Message-Id: <[email protected]>
        !          6378: To: franz-friends@ucbdali
        !          6379: Subject: FUGUE.3
        !          6380: Status: O
        !          6381: 
        !          6382: 
        !          6383: 
        !          6384: 
        !          6385: 
        !          6386: 
        !          6387: 
        !          6388: 
        !          6389:                         FUGUE Notes
        !          6390: 
        !          6391:                An occasional publication of the
        !          6392:     Franz Lisp User Group under Unix and Eunice (FUGUE)
        !          6393: 
        !          6394:                   Number 3 (January, 1984)
        !          6395:                 edited by Richard J. Fateman
        !          6396:                   University of California
        !          6397:                      Berkeley CA 94720
        !          6398:                             USA
        !          6399:                       fateman@berkeley
        !          6400: 
        !          6401: _1.  _W_e_l_c_o_m_e!
        !          6402: 
        !          6403:      It seems about time  to  publish  the  third  of  these
        !          6404: newsletters,  since  we  have  accumulated  a  number of new
        !          6405: items.  We would also like to relay to others such  informa-
        !          6406: tion as has been forwarded to us. The reports of projects at
        !          6407: Berkeley (and elsewhere) may strike sympathetic chords  with
        !          6408: other research.
        !          6409: 
        !          6410: _2.  _N_e_w _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s
        !          6411: 
        !          6412:      Franz now runs on a number of Motorola 68000 and  68010
        !          6413: systems,  including  DUAL,  PIXEL,  Apple-LISA  (UNIX),  and
        !          6414: undoubtedly a large number of other UNISOFT Inc. UNIX ports.
        !          6415: (The  LISA  has  only  a 1 megabyte address space, and hence
        !          6416: cannot run the compiler.  It can  load  cross-compiled  pro-
        !          6417: grams.)  Non-UNISOFT  UNIX  systems we have Franz running on
        !          6418: include the 4.2BSD" Sun Microsystems operating system.
        !          6419: 
        !          6420:      Some work is beginning on  high-speed  VLSI  chips  for
        !          6421: Lisp, using the reduced instruction set technology which has
        !          6422: been successfully used at UCB in the past.  More information
        !          6423: on this will be available in the near future.
        !          6424: 
        !          6425: _3.  _N_e_w _p_r_o_g_r_a_m_s
        !          6426: 
        !          6427: _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
        !          6428: 
        !          6429:      Macsyma runs on the 68000 workstations with  sufficient
        !          6430: memory  both virtual and real.  At least 4 megabytes of vir-
        !          6431: tual is needed, but benchmarks suggest  that  anything  less
        !          6432: than  2 megabytes of real memory is painful.  We recommend 4
        !          6433: or more real megabytes.  The PIXEL machine with 6  megabytes
        !          6434: (unpaged) is our fastest real-time Macsyma system, (CPU-time
        !          6435: is about 25% longer than reported VAX-780 CPU time, but more
        !          6436: to the point, CPU-time is equal to real-time).  Distribution
        !          6437: ____________________
        !          6438: 9   UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
        !          6439: SRI Int'l, and Univ. of Calif.
        !          6440: 
        !          6441: 
        !          6442: 
        !          6443: 9
        !          6444: 
        !          6445: 
        !          6446: 
        !          6447: 
        !          6448: 
        !          6449: 
        !          6450: 
        !          6451: 
        !          6452: 
        !          6453: 
        !          6454: of 68000 Macsyma will presumably be done by Symbolics, (con-
        !          6455: tact  RP@mit-mc,  with  a  cc to fateman@berkeley if you are
        !          6456: interested).
        !          6457: 
        !          6458:      Development of a new algebra system and  user  applica-
        !          6459: tion  modules  is  proceeding,  and  a  programming language
        !          6460: called Newspeak, initially implemented on top of  Franz,  is
        !          6461: the  principal vehicle. This is described in John Foderaro's
        !          6462: PhD dissertation, available from the  CS  Division  at  UCB.
        !          6463: (Newspeak  is  hierarchical,  object-oriented,  and strongly
        !          6464: typed;  is  compiler-based,  and  should  provide  efficient
        !          6465: access  to  machine  resources).   While the algebra code is
        !          6466: progressing well, we are not yet ready to set a release date
        !          6467: for the user-end of the system, tentatively named Xi.
        !          6468: 
        !          6469: _4.  _N_e_w _f_e_a_t_u_r_e_s
        !          6470: 
        !          6471:      As usual,  various  performance  enhancements  and  bug
        !          6472: fixes  have  been  incorporated in versions of Franz (now on
        !          6473: Opus 38.87 and the compiler, Liszt 8.39) Most  changes  made
        !          6474: it  into  the  recent Berkeley 4.2BSD UNIX distribution, and
        !          6475: reported alterations will not be repeated here.
        !          6476: 
        !          6477: _5.  _O_t_h_e_r _L_i_s_p_s
        !          6478: 
        !          6479:      We understand that a version of PSL will  be  supported
        !          6480: by  Hewlett  Packard,  on  its workstations, and that Common
        !          6481: Lisp, from DEC will  have  initial  field-test  in  January,
        !          6482: 1984.   We  believe  PSL  should be available from Utah in a
        !          6483: form for running on 4.2BSD VAX UNIX; similarly for "T"  from
        !          6484: Cognitive  Systems.   We  believe that a Common-Lisp support
        !          6485: package for Franz may be constructed, but probably not at UC
        !          6486: under current funding. (see Business news below, though).
        !          6487: 
        !          6488: _6.  _W_o_r_k _i_n _P_r_o_g_r_e_s_s
        !          6489: 
        !          6490: _6._1.  _G_r_a_p_h_i_c_s
        !          6491: 
        !          6492:      Gregg Foster has  constructed  a  graphics  Franz  Lisp
        !          6493: which  includes  the  full Sun Microsystems Graphics package
        !          6494: for Sun-2 systems, and Keith Sklower has  constructed  a  C-
        !          6495: structure  package  in  Franz  to enable programmers to more
        !          6496: easily construct arbitrary C-structures in Lisp, to pass  to
        !          6497: C.  Various  demonstration  programs  have  been  written to
        !          6498: access the smooth-curve plotting capabilities, variable-size
        !          6499: fonts, etc.
        !          6500: 
        !          6501: _6._2.  _I_B_M _F_r_a_n_z
        !          6502: 
        !          6503:      Still more nibbles on this one, but not yet. We heard a
        !          6504: rumor  of  work  at  Columbia University. (also see the next
        !          6505: item.)
        !          6506: 9
        !          6507: 
        !          6508: 9
        !          6509: 
        !          6510: 
        !          6511: 
        !          6512: 
        !          6513: 
        !          6514: 
        !          6515: 
        !          6516: 
        !          6517: 
        !          6518: 
        !          6519: _7.  _B_u_s_i_n_e_s_s _N_e_w_s
        !          6520: 
        !          6521: _7._1.  _F_r_a_n_z _I_n_c
        !          6522: 
        !          6523:      A new software company has been formed to support Franz
        !          6524: and  application  programs,  and  is  seeking customers in 3
        !          6525: categories: (a) manufacturers of hardware wishing to  obtain
        !          6526: a  Lisp  system  and/or Lisp support; (b) software producers
        !          6527: who wish to have reliable access to experts  in  Franz,  for
        !          6528: enhancement,  support, training or porting of existing code.
        !          6529: (c) end-users who are using Franz or applications written in
        !          6530: Franz and need help in customizing, debugging, conversion to
        !          6531: or from other dialects, etc.
        !          6532: 
        !          6533:      The University of California will continue  to  distri-
        !          6534: bute  Franz  Lisp  on  its current basis, but your questions
        !          6535: about support in any of these categories,  or  about  future
        !          6536: plans,  can be directed to Franz Inc. Most of the principals
        !          6537: at UC will be participating in this venture.  Contact  Franz
        !          6538: Inc. via fkunze@berkeley, or (to avoid abuse of various net-
        !          6539: work privileges), Fritz Kunze, President, Franz  Inc.,  6321
        !          6540: Thornhill Drive, Oakland, Ca 94611 (415) 339-1481.
        !          6541: 
        !          6542: 
        !          6543: 
        !          6544: 
        !          6545: 
        !          6546: 
        !          6547: 
        !          6548: 
        !          6549: 
        !          6550: 
        !          6551: 
        !          6552: 
        !          6553: 
        !          6554: 
        !          6555: 
        !          6556: 
        !          6557: 
        !          6558: 
        !          6559: 
        !          6560: 
        !          6561: 
        !          6562: 
        !          6563: 
        !          6564: 
        !          6565: 
        !          6566: 
        !          6567: 
        !          6568: 
        !          6569: 
        !          6570: 
        !          6571: 9
        !          6572: 
        !          6573: 9
        !          6574: 
        !          6575: 
        !          6576: 
        !          6577: 
        !          6578: From cowan@AEROSPACE  Thu Jan 19 09:56:25 1984
        !          6579: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6580:        id AA14836; Thu, 19 Jan 84 09:56:25 pst
        !          6581: Received: from aerospace.ARPA by UCB-VAX.ARPA (4.22/4.19)
        !          6582:        id AA02684; Thu, 19 Jan 84 09:55:33 pst
        !          6583: Message-Id: <[email protected]>
        !          6584: Date:           Thu, 19 Jan 84 09:55:01 PST
        !          6585: From: Ric Cowan <cowan@AEROSPACE>
        !          6586: To: franz-friends@BERKELEY
        !          6587: Subject:        Help
        !          6588: Status: O
        !          6589: 
        !          6590: Hi, 
        !          6591: 
        !          6592: I'm starting a new project and would like to use Franz lisp. It is a large
        !          6593: application that needs to:
        !          6594: 
        !          6595:        (1) Run on a VAX 11/780 under VMS.
        !          6596:        (2) Interface with INGRESS.
        !          6597:        (3) Support a menu driven interface with VT100 type terminals.
        !          6598: 
        !          6599: Is Franz lisp a viable language to use? 
        !          6600: 
        !          6601: Thanks in advance,
        !          6602: 
        !          6603: Ric Cowan
        !          6604: 
        !          6605: From levitt@aids-unix  Thu Jan 26 17:44:03 1984
        !          6606: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6607:        id AA10074; Thu, 26 Jan 84 17:44:03 pst
        !          6608: Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.19)
        !          6609:        id AA02121; Thu, 26 Jan 84 17:01:25 pst
        !          6610: Message-Id: <[email protected]>
        !          6611: Date: 26 Jan 1984 16:25:55-PST
        !          6612: From: Tod Levitt <levitt@aids-unix>
        !          6613: To: franz-friends@BERKELEY
        !          6614: Subject: report PAM 124, "Parlez vous Franz..." by James Larus
        !          6615: Cc: levitt@aids-unix
        !          6616: Status: O
        !          6617: 
        !          6618: I am trying to obtain a copy of PAM report 124 which discusses
        !          6619: interfacing foreign functions to Franzlisp. Can someone please
        !          6620: point me at a source for this document? Thanks...
        !          6621:                             Tod Levitt (levitt@aids-unix)
        !          6622: 
        !          6623: From jkf@ucbmike  Fri Jan 27 08:44:54 1984
        !          6624: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
        !          6625:        id AA15308; Fri, 27 Jan 84 08:44:54 pst
        !          6626: Date: Fri, 27 Jan 84 08:44:40 pst
        !          6627: From: John Foderaro (on an h19-u) <jkf@ucbmike>
        !          6628: Message-Id: <[email protected]>
        !          6629: Received: by ucbmike.ARPA (4.17/3.5)
        !          6630:        id AA02469; Fri, 27 Jan 84 08:44:40 pst
        !          6631: To: local-lisp@kim
        !          6632: Subject: lisp 38.88
        !          6633: Cc: 
        !          6634: Status: O
        !          6635: 
        !          6636:  The 'msg' macro now accepts the special form (T 'x_column), and it
        !          6637: spaces over to that column (plus 1).
        !          6638: 
        !          6639: -> (msg "foo" (T 10) "bar" N "baz" (T 11) "bof" N)
        !          6640: foo       bar
        !          6641: baz        bof
        !          6642: nil
        !          6643: ->
        !          6644: 
        !          6645: Note that the method used to locate the column only works if nothing
        !          6646: has yet been actually written on the line.  Problems will occur if you drain
        !          6647: the port in the middle of the line.
        !          6648: 
        !          6649: For example:
        !          6650: -> (msg "foo" D (T 10) "bar" N         << here we drain after "foo"
        !          6651:         "foo"   (T 10) "bar" N)
        !          6652: foo          bar               << thus column 11 turns out to be column 14
        !          6653: foo       bar
        !          6654: nil
        !          6655: ->
        !          6656: 
        !          6657: 
        !          6658: From jkf@ucbmike  Tue Jan 31 10:55:51 1984
        !          6659: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
        !          6660:        id AA20759; Tue, 31 Jan 84 10:55:51 pst
        !          6661: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21)
        !          6662:        id AA12296; Tue, 31 Jan 84 10:51:34 pst
        !          6663: Date: Tue, 31 Jan 84 10:51:33 pst
        !          6664: From: John Foderaro (on an sun-e) <jkf@ucbmike>
        !          6665: Message-Id: <[email protected]>
        !          6666: Received: by ucbmike.ARPA (4.17/3.5)
        !          6667:        id AA01218; Tue, 31 Jan 84 10:51:33 pst
        !          6668: To: franz-friends@BERKELEY
        !          6669: Subject: LISPcraft, a book on Lisp and Franz.
        !          6670: Cc: 
        !          6671: Status: O
        !          6672: 
        !          6673:   A new Lisp book is due out March 23rd which may be especially interesting 
        !          6674: to Franz Lisp users or potential Franz Lisp users.   The title
        !          6675: is `LISPcraft' and it was written by Robert Wilensky, a Computer Science
        !          6676: professor at Berkeley who teaches AI programming courses.
        !          6677:   The book starts at first principles and teaches Lisp programming, and then 
        !          6678: goes on to Franz-specific topics such as debugging, read macros, error 
        !          6679: handling, and compilation.   Then there are chapters on Lisp 
        !          6680: applications: pattern matching and databases.  Finally it contains 
        !          6681: a complete description of all Franz functions.
        !          6682: 
        !          6683: details:
        !          6684: LISPcraft, by Robert Wilensky    385 pages, $19.95
        !          6685: publisher: W. W. Norton, 500 5th Avenue, N.Y. N.Y.  10110
        !          6686:            800-223-2584
        !          6687: 
        !          6688: 
        !          6689: 
        !          6690: 
        !          6691: From jkf@ucbmike  Fri Feb  3 08:03:58 1984
        !          6692: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
        !          6693:        id AA19272; Fri, 3 Feb 84 08:03:58 pst
        !          6694: Date: Fri, 3 Feb 84 08:04:17 pst
        !          6695: From: John Foderaro (on an h19-u) <jkf@ucbmike>
        !          6696: Message-Id: <[email protected]>
        !          6697: Received: by ucbmike.ARPA (4.17/3.5)
        !          6698:        id AA02117; Fri, 3 Feb 84 08:04:17 pst
        !          6699: To: local-lisp@kim
        !          6700: Subject: opus 38.89
        !          6701: Cc: 
        !          6702: Status: O
        !          6703: 
        !          6704:  In opus 38.88 the msg macro was extended to make (T n) put the cursor
        !          6705: on column n+1.   Others had extended the msg macro in a conflicting way,
        !          6706: so we decided to convert over to their extensions.  So forget what
        !          6707: you read in the opus38.88 message, and remember this:
        !          6708:        (C n)   go to column n.  The first column on the line is column 1.
        !          6709:                If the cursor is beyond column n, then go to the next line
        !          6710:                and go to column n.
        !          6711:        (T m)   print m tab characters
        !          6712:        
        !          6713:        
        !          6714:        
        !          6715: 
        !          6716: 
        !          6717: From jkf  Thu Feb 16 10:32:03 1984
        !          6718: Received: by ucbkim.ARPA (4.16/4.22)
        !          6719:        id AA16308; Thu, 16 Feb 84 10:32:03 pst
        !          6720: Date: Thu, 16 Feb 84 10:32:03 pst
        !          6721: From: John Foderaro (on an sun-e) <jkf>
        !          6722: Message-Id: <[email protected]>
        !          6723: To: local-lisp
        !          6724: Subject: opus 38.90
        !          6725: Cc: 
        !          6726: Status: O
        !          6727: 
        !          6728:  For those of you using the 'tpl' toplevel, the new command ?fast
        !          6729: will set all switches for maximum speed:
        !          6730:        (*rset nil)
        !          6731:        (sstatus translink on)
        !          6732:        (setq displace-macros t)
        !          6733:        
        !          6734: 
        !          6735: 
        !          6736: From wilensky@ucbdali  Wed Feb 22 09:58:43 1984
        !          6737: Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22)
        !          6738:        id AA16486; Wed, 22 Feb 84 09:58:43 pst
        !          6739: Received: by ucbdali.ARPA (4.22/4.22)
        !          6740:        id AA06784; Wed, 22 Feb 84 09:57:21 pst
        !          6741: Date: Wed, 22 Feb 84 09:57:21 pst
        !          6742: From: wilensky@ucbdali (Robert Wilensky)
        !          6743: Message-Id: <[email protected]>
        !          6744: To: andy@aids-unix, franz-friends@ucbdali
        !          6745: Subject: Re: Franz Flavors & software copyright
        !          6746: In-Reply-To: Your message of 21 Feb 1984 16:29-PST
        !          6747: Status: O
        !          6748: 
        !          6749: 
        !          6750: Thanks for your clarification.  Everything you said is consistent with my
        !          6751: understanding of the situation.  And you are correct in emphasizing the
        !          6752: complexity of the issue.  But I want to stress my main point.  This is
        !          6753: that the ``author'' holds the copyright.  It may be unclear who the author
        !          6754: is, but it is clearly NOT the university. 
        !          6755: 
        !          6756: In addition, many pieces of ``university-developed'' software have
        !          6757: contributions by unfunded students, and by faculty, whose salary is not paid
        !          6758: by the gov't (except maybe during the summer).  Furthermore, it would seem
        !          6759: to be unclear who the author is if it is, say, a student working as a gov't
        !          6760: sponsored r. a.  For example, the student's thesis is presumably his to
        !          6761: copyright, even if the student were paid by the gov't because it was not
        !          6762: part of what he was paid to do.  One could argue that a concommitant program
        !          6763: has the same status unless it were specifically contracted for.
        !          6764: 
        !          6765: Let me state that my main purpose was not to promote people selling their
        !          6766: code, but rather, to stop the universities from impeding its distribution.
        !          6767: As far as I know, the gov't hasn't tried to prevent us from giving each
        !          6768: other our software, but many universities have.  Therefore, we are better
        !          6769: off leaving them out of the picture entirely - legally this seems to be a
        !          6770: sound position.
        !          6771: 
        !          6772: 
        !          6773: From jkf@ucbmike  Wed Mar 14 09:04:55 1984
        !          6774: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
        !          6775:        id AA00884; Wed, 14 Mar 84 09:04:55 pst
        !          6776: Date: Wed, 14 Mar 84 08:58:51 pst
        !          6777: From: John Foderaro (on an h19-u) <jkf@ucbmike>
        !          6778: Message-Id: <[email protected]>
        !          6779: Received: by ucbmike.ARPA (4.17/3.5)
        !          6780:        id AA03782; Wed, 14 Mar 84 08:58:51 pst
        !          6781: To: fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
        !          6782: Subject: lisps running wild 
        !          6783: Cc: local-lisp@kim
        !          6784: In-Reply-To: Your message of Tue, 13 Mar 84 21:45:25 pst
        !          6785: Status: O
        !          6786: 
        !          6787: re:    
        !          6788:        From: chris@ucbcory (Chris Guthrie)
        !          6789:        We are having a good deal
        !          6790:        of trouble with them being left running instead of dying and killing
        !          6791:        the load here.
        !          6792: 
        !          6793: The problem is that people are setting a flag in their lisp init files
        !          6794: which instruct lisp to ignore 'end of file' (much like the c shell).
        !          6795: If a connection is broken (ipc connection breaks or modem hangs up), then
        !          6796: lisp is sent a hangup signal (which it ignores) and then a continuous
        !          6797: sequence of 'end of files' which it ignores after a bit of processing.
        !          6798: The solution is this:
        !          6799:   If you have something in your init file which instructs lisp to ignore
        !          6800: end of files  (such as (sstatus ignoreeof t)), then you should also
        !          6801: have   (signal 1 'exit)   in the init file so lisp will exit upon a hangup.
        !          6802: 
        !          6803: 
        !          6804: 
        !          6805: 
        !          6806: From mcgeer  Wed Mar 14 09:37:45 1984
        !          6807: Received: by ucbkim.ARPA (4.16/4.22)
        !          6808:        id AA01437; Wed, 14 Mar 84 09:37:45 pst
        !          6809: Date: Wed, 14 Mar 84 09:37:45 pst
        !          6810: From: Rick McGeer (on an aaa-60-s) <mcgeer>
        !          6811: Message-Id: <[email protected]>
        !          6812: To: jkf@ucbmike, chris@cory, layer@ucbdali, sklower@ucbdali, fateman@ucbdali
        !          6813: Subject: Re: lisps running wild 
        !          6814: Cc: local-lisp
        !          6815: In-Reply-To: Your message of Wed, 14 Mar 84 08:58:51 pst
        !          6816: Status: O
        !          6817: 
        !          6818:        John, your top level sets the ignoreeof flag.  Does it also set the
        !          6819: appropriate signal, or should your users do that themselves?
        !          6820: 
        !          6821: 
        !          6822: From jkf@ucbmike  Wed Mar 14 09:48:04 1984
        !          6823: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
        !          6824:        id AA01603; Wed, 14 Mar 84 09:48:04 pst
        !          6825: Date: Wed, 14 Mar 84 09:42:15 pst
        !          6826: From: John Foderaro (on an h19-u) <jkf@ucbmike>
        !          6827: Message-Id: <[email protected]>
        !          6828: Received: by ucbmike.ARPA (4.17/3.5)
        !          6829:        id AA03833; Wed, 14 Mar 84 09:42:15 pst
        !          6830: To: mcgeer@ucbkim, fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
        !          6831: Subject: Re: lisps running wild 
        !          6832: Cc: local-lisp@ucbkim
        !          6833: In-Reply-To: Your message of Wed, 14 Mar 84 09:37:45 pst
        !          6834: Status: O
        !          6835: 
        !          6836:  Since ignoreeof is always set in the new top level, I'll make 'exit on
        !          6837: hangup' the default if you use the new top level.
        !          6838: 
        !          6839:   
        !          6840: 
        !          6841: 
        !          6842: From [email protected]  Sat Mar 17 13:45:58 1984
        !          6843: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22)
        !          6844:        id AA05623; Sat, 17 Mar 84 13:45:58 pst
        !          6845: Received: from SU-AI.ARPA by UCB-VAX.ARPA (4.24/4.25)
        !          6846:        id AA12441; Sat, 17 Mar 84 13:47:35 pst
        !          6847: Message-Id: <[email protected]>
        !          6848: Date: 17 Mar 84  1347 PST
        !          6849: From: Rod Brooks <[email protected]>
        !          6850: Subject: Don't use Franz sortcar!
        !          6851: To: franz-friends@BERKELEY
        !          6852: Status: O
        !          6853: 
        !          6854: 
        !          6855: Somewhat bizzarely it seems that Franz Lisp sort and sortcar have
        !          6856: different time complexities. sort is good and sortcar is bad so
        !          6857: I suggest you convert your sortcar's to sort's until someone sorts
        !          6858: this out. The code and transcript below use both sort and sortcar
        !          6859: to sort a list of length n (the list happens to start in precisely
        !          6860: reverse order). A count of the number of calls to the comparison
        !          6861: function is kept. The results show that sort takes n*log(n)
        !          6862: comparisons while sortcar takes n*n. The problem should
        !          6863: be fixable by throwing out code as there must be two sorters lurking
        !          6864: in there!
        !          6865: 
        !          6866: ;;;;;;;;;;;;;;;
        !          6867: 
        !          6868: (defun gen (n)
        !          6869:     (do ((i 0 (1+ i))
        !          6870:         (l () (cons (cons i ()) l)))
        !          6871:        ((= i n)
        !          6872:         l)))
        !          6873: 
        !          6874: (defun compare (x y)
        !          6875:     (setq *count* (1+ *count*))
        !          6876:     (< x y))
        !          6877: 
        !          6878: (defun compare-cars (x y) (compare (car x) (car y)))
        !          6879: 
        !          6880: (defun count-sort (n)
        !          6881:     (let ((*count* 0))
        !          6882:         (sort (gen n) #'compare-cars)
        !          6883:         *count*))
        !          6884: 
        !          6885: (defun count-sortcar (n)
        !          6886:     (let ((*count* 0))
        !          6887:         (sortcar (gen n) #'compare)
        !          6888:         *count*))
        !          6889: 
        !          6890: (defun test (n)
        !          6891:     (let ((csort (count-sort n))
        !          6892:          (csortcar (count-sortcar n)))
        !          6893:         (list n
        !          6894:               csort
        !          6895:               csortcar
        !          6896:               (/$ (float csort) (*$ (float n) (log n)))
        !          6897:               (/$ (float csortcar) (float (* n n))))))
        !          6898: 
        !          6899: ;;;;;;;;;;;;;;;
        !          6900: 
        !          6901: Here's the transcript. The lists of 5 elements are:
        !          6902:        n
        !          6903:        compares for sort
        !          6904:        compares for sortcar
        !          6905:        compares for sort / n*log(n)
        !          6906:        compares for sortcar / n*n
        !          6907: 
        !          6908: 
        !          6909: Franz Lisp, Opus 38
        !          6910: -> (load 'test)
        !          6911: t
        !          6912: -> (test 3)
        !          6913: (3 3 6 0.910239226626837 0.6666666666666667)
        !          6914: -> (test 100)
        !          6915: (100 460 9900 0.9988773083774791 0.99)
        !          6916: -> (test 200)
        !          6917: (200 1020 39800 0.9625697456705496 0.995)
        !          6918: -> (test 300)
        !          6919: (300 1440 89700 0.8415468193831012 0.9966666666666667)
        !          6920: -> (test 400)
        !          6921: (400 2240 159600 0.9346629619469353 0.9975)
        !          6922: -> 
        !          6923: 
        !          6924: 
        !          6925: From @MIT-MC:smh@MIT-EMS  Wed Mar 28 06:11:15 1984
        !          6926: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
        !          6927:        id AA06408; Wed, 28 Mar 84 06:11:15 pst
        !          6928: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
        !          6929:        id AA23759; Wed, 28 Mar 84 06:10:43 pst
        !          6930: Message-Id: <[email protected]>
        !          6931: Date: 28 Mar 1984 09:09:38-EST
        !          6932: From: <smh@mit-ems@mit-mc>
        !          6933: To: franz-friends@BERKELEY
        !          6934: Subject: Fixes for setf return value problem
        !          6935: Status: O
        !          6936: 
        !          6937: As FranzFriends readers will know, my message several days ago
        !          6938: generated a number of comments.  The clear consensus was that setf
        !          6939: should be fixed, not the documentation.  This was obvious.  The reason
        !          6940: I didn't suggest the fix myself was that I felt it was far more
        !          6941: important to preserve compatibility between Franz and the various other
        !          6942: more-or-less-source-compatible Lisps (aka Common Lisps).  It was my
        !          6943: impression that code relying on the value returned by setf would not
        !          6944: be portable.
        !          6945: 
        !          6946: I have since learned that Common Lisp does indeed define setf to return
        !          6947: the new value (its second argument), and that other implementations
        !          6948: (i.e. MIT and Symbolics Lisp Machines) indeed work this way.  (Mind
        !          6949: you, I haven't checked this myself -- the information is second hand.)
        !          6950: The fixes to setf are quite straightforward and are brief enough that I
        !          6951: am including them below.  For each case that the setf macro evaluates
        !          6952: to a {rplaca, rplacd, rplacx} the corresponding {car, cdr, cxr} is now
        !          6953: wrapped around it.  The Liszt compiler seems smart enough to remove the
        !          6954: extra reference if the value is ignored.
        !          6955: 
        !          6956: The new setf functions follow.  The starting version is the Opus 38.69
        !          6957: common2 identified by:
        !          6958: ;; common2.l                           -[Fri Jul  8 17:46:13 1983 by layer]-
        !          6959: (Although only two lines of setf-check-car+d were changed, the entire
        !          6960: function is included because the change is difficult to locate by
        !          6961: context.)  I suggest these changes be made in the official sources.
        !          6962: Whoever wants to install them should edit common2.l and remake the
        !          6963: Franz interpreter.  The Liszt compiler does not need to be changed.
        !          6964: ====================
        !          6965: 
        !          6966: ; modified 27Mar84 SMH@MIT-EMS@MT-MC (see comment below)
        !          6967: ;
        !          6968: (defun setf-check-cad+r (name)
        !          6969:  (if (eq (getcharn name 1) #/c)
        !          6970:      then (let
        !          6971:           ((letters (nreverse (cdr (exploden name)))))
        !          6972:           (if (eq (car letters) #/r)
        !          6973:               then (do ((xx (cdr letters) (cdr xx)))
        !          6974:                        ((null xx)
        !          6975:                         ;; form is c{ad}+r, setf form is
        !          6976:                         ;; (rplac<first a or d> (c<rest of a's + d's>r x))
        !          6977:                         (setq letters (nreverse letters))
        !          6978:                         (eval
        !          6979:                          `(defsetf ,name (e v)
        !          6980:                                        ; SMH@MIT-EMS@MIT-MC    
        !          6981:                                        ; added next line and matching rparen.
        !          6982:                                    (list ',(implode `(#/c ,(car letters) #/r))
        !          6983:                                     (list
        !          6984:                                      ',(concat "rplac" (ascii (car letters)))
        !          6985:                                      (list
        !          6986:                                       ',(implode `(#/c ,@(cdr letters)))
        !          6987:                                       (cadr e))
        !          6988:                                      v))))     ; SMH@MIT-EMS@MIT-MC
        !          6989:                         t)
        !          6990:                        (if (not (memq (car xx) '(#/a #/d)))
        !          6991:                            then (return nil)))))))
        !          6992: 
        !          6993: . . .
        !          6994: 
        !          6995: ;--- other setf's for car's and cdr's are generated automatically
        !          6996: ;
        !          6997: ; modified 27Mar84 SMH@MIT-EMS@MIT-MC
        !          6998: ; Now whenever setf macro expands to a rplac[adx], the corresponding c[adx]r
        !          6999: ; is now wrapped around it so that setf consistently returns its second arg.
        !          7000: ; The compiler is smart enough to remove the extra operation if the value
        !          7001: ; is not used.
        !          7002: ;
        !          7003: (defsetf car (e v) `(car (rplaca ,(cadr e) ,v)))
        !          7004: (defsetf caar (e v) `(car (rplaca (car ,(cadr e)) ,v)))
        !          7005: (defsetf cadr (e v) `(car (rplaca (cdr ,(cadr e)) ,v)))
        !          7006: (defsetf cdr (e v) `(cdr (rplacd ,(cadr e) ,v)))
        !          7007: (defsetf cdar (e v) `(cdr (rplacd (car ,(cadr e)) ,v)))
        !          7008: (defsetf cddr (e v) `(cdr (rplacd (cdr ,(cadr e)) ,v)))
        !          7009: (defsetf cxr (e v) `(cxr ,(cadr e) (rplacx ,(cadr e) ,(caddr e) ,v)))
        !          7010: 
        !          7011: . . .
        !          7012: 
        !          7013: (defsetf nth (e v) `(car (rplaca (nthcdr ,(cadr e) ,(caddr e)) ,v)))
        !          7014: (defsetf nthelem (e v) `(car (rplaca (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))
        !          7015: (defsetf nthcdr (e v) `(cdr (rplacd (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))
        !          7016: 
        !          7017: . . .
        !          7018: 
        !          7019: ; (defsetf args (e v) `(args ,(cadr e) ,v))    ; no longer implemented?
        !          7020: 
        !          7021: ====================
        !          7022: 
        !          7023: Steven Haflich
        !          7024: MIT Experimental Music Studio
        !          7025: (617)253-7441
        !          7026: smh@mit-ems@mit-mc
        !          7027: decvax!genrad!mit-ems!smh
        !          7028: 
        !          7029: 
        !          7030: From fateman@ucbdali  Thu Mar 29 12:07:33 1984
        !          7031: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
        !          7032:        id AA20323; Thu, 29 Mar 84 12:07:33 pst
        !          7033: Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.25)
        !          7034:        id AA22790; Thu, 29 Mar 84 12:07:08 pst
        !          7035: Received: by ucbdali.ARPA (4.24/4.22)
        !          7036:        id AA04139; Thu, 29 Mar 84 12:07:10 pst
        !          7037: Date: Thu, 29 Mar 84 12:07:10 pst
        !          7038: From: fateman@ucbdali (Richard Fateman)
        !          7039: Message-Id: <[email protected]>
        !          7040: To: franz-friends@BERKELEY
        !          7041: Subject: commercialization of Franz
        !          7042: Status: O
        !          7043: 
        !          7044: 
        !          7045: Some people may have gotten the incorrect impression that 
        !          7046: the University of California will cease sending out 
        !          7047: tapes of Franz Lisp.  We intend to continue distribution
        !          7048: of the latest version which is the property of UCB.  This is
        !          7049: currently opus 38.91.  This distribution works, so far as we know,
        !          7050: on SUN releases (0.4, 1.0, 1.1) and Masscomp, and VAX 4.2BSD.
        !          7051: Such distributions will continue, and will continue to be unsupported.
        !          7052: Although we have made reasonable efforts to provide a useful,
        !          7053: portable, efficient, and complete system, we have spent too much of
        !          7054: our time and our sponsors' money in answering
        !          7055: questions about installation-dependent difficulties or 
        !          7056: (what USUALLY turns out to be non-existent) bugs.
        !          7057: I might point out that many of the questions come from commercial users.
        !          7058: 
        !          7059: Franz Inc. was formed to provide a mechanism for support, transportation
        !          7060: of Franz Lisp to new architectures, enhancements, documentation, etc.
        !          7061: It has the (non-exclusive) right to use, distribute, (etc) Franz Lisp,
        !          7062: and intends to produce enhancements that the University does not
        !          7063: have funding for. I expect that if enhancements of Franz Lisp at UCB 
        !          7064: are produced, these will next be made available on 4.3 BSD tapes. Earlier
        !          7065: distributions of contributed software or locally produced software
        !          7066: MAY occur, but cannot be promised.
        !          7067: 
        !          7068: I expect that there will continue to be a large number of Franz Lisp
        !          7069: users who are satisfied with the university distribution (on 4.2BSD)
        !          7070: or on the separate tapes (e.g. after opus 38.79) that UCB is sending out.
        !          7071: Others will want the enhanced, supported, version from Franz Inc.
        !          7072: 
        !          7073: The divergence of versions,
        !          7074: some of which has already occurred with local variants of older
        !          7075: systems being redistributed, seems inevitable regardless of Franz Inc.
        !          7076: 
        !          7077: I hope this clarifies UCB's position.
        !          7078: 
        !          7079: 
        !          7080: 
        !          7081: From @MIT-MC:smh@MIT-EMS  Wed Apr  4 15:44:42 1984
        !          7082: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
        !          7083:        id AA07196; Wed, 4 Apr 84 15:44:42 pst
        !          7084: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
        !          7085:        id AA01892; Wed, 4 Apr 84 15:14:05 pst
        !          7086: Message-Id: <[email protected]>
        !          7087: Date: 4 Apr 1984 16:44:49-EST
        !          7088: From: <smh@mit-ems@mit-mc>
        !          7089: To: franz-friends@BERKELEY
        !          7090: Subject: Re: recent suggested fix to setf
        !          7091: Status: O
        !          7092: 
        !          7093: There was one mistake in my recent posting with fixes for the Franz
        !          7094: setf function.  I said that it was not necessary to remake liszt (the
        !          7095: compiler).  This was wrong:  code compiled with an old copy of liszt
        !          7096: will not use the modified setf definitions.
        !          7097: 
        !          7098: The fix is simply to remake liszt after the new Franz interpreter has
        !          7099: been generated.
        !          7100: 
        !          7101: Sorry about any confusion.
        !          7102: 
        !          7103: Steve Haflich
        !          7104: MIT Experimental Music Studio
        !          7105: decvax!genrad!mit-ems!smh
        !          7106: smh@mit-ems@mit-mc
        !          7107: 
        !          7108: 
        !          7109: From [email protected]  Wed Apr 18 20:37:26 1984
        !          7110: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
        !          7111:        id AA16547; Wed, 18 Apr 84 20:37:26 pst
        !          7112: Received: from RUTGERS.ARPA (rutgers.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
        !          7113:        id AA29663; Wed, 18 Apr 84 20:36:21 pst
        !          7114: Message-Id: <[email protected]>
        !          7115: Date: 18 Apr 84 23:37:14 EST
        !          7116: From: Sean McLinden  <[email protected]>
        !          7117: Subject: [Sean McLinden  <[email protected]>: Re: Franz on Suns under 4.2?]
        !          7118: To: franz-friends@BERKELEY
        !          7119: Status: O
        !          7120: 
        !          7121: Mail-From: MCLINDEN created at 18-Apr-84 23:33:56
        !          7122: Date: 18 Apr 84 23:33:56 EST
        !          7123: From: Sean McLinden  <[email protected]>
        !          7124: Subject: Re: Franz on Suns under 4.2?
        !          7125: To: [email protected]
        !          7126: cc: [email protected]
        !          7127: In-Reply-To: Message from "allegra!jdd@Berkeley (John DeTreville)" of 18 Apr 84 13:10:10 EST
        !          7128: 
        !          7129: 
        !          7130: 
        !          7131:  I must be missing something with all of this discussion of Franz
        !          7132:  Lisp on Suns. We have had no trouble at all running the current
        !          7133:  (opus 38.91?) Berkeley release on Suns and have been running Sun
        !          7134:  Franz Lisp for nearly a year now.
        !          7135: 
        !          7136:  The only serious problem that I can recall happened a few sub versions
        !          7137:  ago and was due to a logical error in the C-coded algorithm which
        !          7138:  determined when to garbage collect (as things would have it, it
        !          7139:  never did). The result was that liszt was unable to compile some
        !          7140:  of the lisp coded sources due to the 2 Meg/process limit imposed
        !          7141:  by the Sun operating system (the bug existed in the Vax version as
        !          7142:  well but one would only see it if the lisp image exceeded 6 megs
        !          7143:  which is rare for a compiler run).
        !          7144: 
        !          7145:  Perhaps you could be more explicit in describing what, exactly,
        !          7146:  the problem is. The people at Berkeley most probably have Suns
        !          7147:  and I am sure that they don't release Sun versions without testing
        !          7148:  them.
        !          7149: 
        !          7150:  Sean McLinden
        !          7151:  Decision Systems Lab
        !          7152:  University of Pittsburgh
        !          7153:  School of Medicine
        !          7154: -------
        !          7155: -------
        !          7156: 
        !          7157: From varghese%[email protected]  Fri May 25 18:47:11 1984
        !          7158: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          7159:        id AA20472; Fri, 25 May 84 18:47:11 pdt
        !          7160: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.27)
        !          7161:        id AA23631; Fri, 25 May 84 18:45:35 pdt
        !          7162: Message-Id: <[email protected]>
        !          7163: Received: From colostate.csnet by csnet-relay;  25 May 84 21:17 EDT
        !          7164: Date: Fri, 25 May 84 13:47:24 mdt
        !          7165: From: varghese%[email protected]
        !          7166: Received: by csu-cs.UUCP (4.12/3.14)
        !          7167:        id AA11606; Fri, 25 May 84 13:47:24 mdt
        !          7168: To: [email protected]
        !          7169: Subject: Addition to mailing list
        !          7170: 
        !          7171: 
        !          7172: 
        !          7173: 
        !          7174: Please add us to the mailing list. Since there will be more than one 
        !          7175: person at this site who wants to be on the mailing list we decided to 
        !          7176: get everything mailed to one central mailbox. 
        !          7177: The mailbox address for this mailing list is 
        !          7178: 
        !          7179:        frnzlist@colostate
        !          7180: 
        !          7181: Please note that this is a CSnet address. Thank you,
        !          7182: 
        !          7183:                                                    Joe Varghese
        !          7184:                                                    varghese@colostate
        !          7185: 
        !          7186: 
        !          7187: From [email protected]  Sun Jun  3 19:15:03 1984
        !          7188: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7189:        id AA07648; Sun, 3 Jun 84 19:15:03 pdt
        !          7190: Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
        !          7191:        id AA24832; Sun, 3 Jun 84 19:13:42 pdt
        !          7192: Date: 3 Jun 1984 22:02-EST
        !          7193: From: [email protected]
        !          7194: Subject: Please add my name to the list
        !          7195: To: FRANZ-FRIENDS@BERKELEY
        !          7196: Message-Id: <455162572/trk@CMU-CS-G>
        !          7197: 
        !          7198: Please add my name to the FRANZ-FRIENDS list.
        !          7199:                                                        -Todd K.
        !          7200: 
        !          7201: From [email protected]  Sun Jun  3 23:24:19 1984
        !          7202: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7203:        id AA09575; Sun, 3 Jun 84 23:24:19 pdt
        !          7204: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
        !          7205:        id AA27487; Sun, 3 Jun 84 23:22:53 pdt
        !          7206: Message-Id: <[email protected]>
        !          7207: Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT
        !          7208: Date: 3 Jun 84 23:22 PDT
        !          7209: From: [email protected]
        !          7210: Subject: This is a test
        !          7211: To: Franz-Friends@BERKELEY
        !          7212: 
        !          7213: Sorry to bother you -- this is only a test of correct forwarding on this mailing list.
        !          7214: 
        !          7215: 
        !          7216: From @MIT-MC:[email protected]  Mon Jun 18 17:09:37 1984
        !          7217: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7218:        id AA21265; Mon, 18 Jun 84 17:09:37 pdt
        !          7219: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7220:        id AA19453; Mon, 18 Jun 84 17:07:25 pdt
        !          7221: Message-Id: <[email protected]>
        !          7222: Date: 18 Jun 1984 12:48:57-EDT
        !          7223: From: Simon.Lowenfeld@CMU-RI-ISL1
        !          7224: Subject: old messages
        !          7225: Apparently-To: <franz-friends@UCB-VAX>
        !          7226: 
        !          7227: Is there some kind of archive for old postings?
        !          7228: I am interested in the Franz/T argument
        !          7229: from earlier this year.
        !          7230: 
        !          7231: 
        !          7232: From [email protected]  Tue Jun 19 07:36:37 1984
        !          7233: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7234:        id AA01983; Tue, 19 Jun 84 07:36:37 pdt
        !          7235: Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7236:        id AA01762; Tue, 19 Jun 84 07:34:31 pdt
        !          7237: Message-Id: <[email protected]>
        !          7238: Date:     Tue, 19 Jun 84 10:31:27 EDT
        !          7239: From: William K. Cadwallender (LCWSL) <[email protected]>
        !          7240: To: franz-friends@BERKELEY
        !          7241: Subject:  Franz for VAX730
        !          7242: 
        !          7243:        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.
        !          7244:                        Bill Cadwallender (wkc@ARDC)
        !          7245: 
        !          7246: From RZ@MIT-MC  Thu Jun 21 19:26:57 1984
        !          7247: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7248:        id AA08546; Thu, 21 Jun 84 19:26:57 pdt
        !          7249: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7250:        id AA27996; Thu, 21 Jun 84 19:24:37 pdt
        !          7251: Message-Id: <[email protected]>
        !          7252: Date: 21 June 1984 22:28-EDT
        !          7253: From: Richard E. Zippel <RZ@MIT-MC>
        !          7254: Subject:  MIT flavors
        !          7255: To: franz-friends@BERKELEY
        !          7256: Cc: zymelman@MITRE, smh@MIT-VAX
        !          7257: In-Reply-To: Msg of 21 Jun 1984  9:19:16 EDT () from Ari Zymelman <m13676 at mitre>
        !          7258: 
        !          7259: I am happy to report than the MIT flavor system is finally available.  I
        !          7260: won't try to correct the numerous bits of misinformation that have been
        !          7261: spread about this other than to say that the MIT flavor system can now be
        !          7262: freely distributed, if it is not used for profit, and the MIT copyrights are
        !          7263: maintained in the sources.  Berkeley has a copy of the most recent version
        !          7264: of the code and should include it in their standard distributions shortly.
        !          7265: 
        !          7266: 
        !          7267: From hoey@nrl-aic  Wed Jun 27 14:24:24 1984
        !          7268: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7269:        id AA19372; Wed, 27 Jun 84 14:24:24 pdt
        !          7270: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7271:        id AA13744; Wed, 27 Jun 84 14:21:16 pdt
        !          7272: Message-Id: <[email protected]>
        !          7273: Date: 27 Jun 1984 16:42-EDT
        !          7274: From: Dan Hoey <hoey@NRL-AIC>
        !          7275: Subject: Incorrect "make fromasm" in 68k franz 38.91
        !          7276: To: franz-friends@BERKELEY
        !          7277: Cc: dejong@nrl-aic, franz-bugs@BERKELEY
        !          7278: 
        !          7279: Problem:
        !          7280: The "make fromasm" option for franz installation on a 68k does not work
        !          7281: as distributed.
        !          7282: 
        !          7283: Diagnosis:
        !          7284: The assembler is used to convert *.s files into *.o.  But the output of
        !          7285: as defaults to "a.out" and is not overridden, so no *.o files are
        !          7286: produced.
        !          7287: 
        !          7288: Fixes:
        !          7289: Specify the output file in the fromasm: option in lisplib/Makefile and
        !          7290: liszt/68k/Makefile.
        !          7291: 
        !          7292: In lisplib/Makefile, and (if make copylibrary has been done) in
        !          7293: /usr/lib/lisp/Makefile, change
        !          7294: 
        !          7295: <      for i in *.s; do echo $$i; ${LibDir}/as $$i; done
        !          7296: ----
        !          7297: >      for i in *.s; do echo $$i; \
        !          7298: >      ${LibDir}/as $$i -o `basename $$i .s`.o; done
        !          7299: 
        !          7300: In liszt/68k/Makefile, change
        !          7301: 
        !          7302: <      for i in *.s; do echo $$i; as $$i; done
        !          7303: ----
        !          7304: >      for i in *.s; do echo $$i; \
        !          7305: >      as $$i -o `basename $$i .s`.o; done
        !          7306: 
        !          7307: Bugs:
        !          7308: 1.  One version specifies ${LibDir}/as, the other uses vanilla as.  I
        !          7309:     didn't change it, but perhaps the liszt/68k/Makefile should also
        !          7310:     specify ${LibDir}/as.
        !          7311: 
        !          7312: 2.  Isn't there a cleaner way of doing this?  Can a ".s.o:" rule be
        !          7313:     specified?
        !          7314: 
        !          7315: Dan
        !          7316: 
        !          7317: From @MIT-MC:[email protected]  Mon Jul  9 22:06:26 1984
        !          7318: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7319:        id AA17486; Mon, 9 Jul 84 22:06:26 pdt
        !          7320: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7321:        id AA24170; Mon, 9 Jul 84 22:05:52 pdt
        !          7322: Message-Id: <[email protected]>
        !          7323: Date: 9 Jul 1984 21:10:53-EDT
        !          7324: From: Richard.Wallace@CMU-CS-H
        !          7325: Subject: Bell quote
        !          7326: Apparently-To: <franz-friends@UCB-VAX>
        !          7327: 
        !          7328: Lisp, designed about 1960 by John McCarthy, impressed me so 
        !          7329: much that I included the critcal data access primitives
        !          7330: in the architecture of the DEC System 10 in 1965 (still
        !          7331: about the fastest Lisp computer).
        !          7332: 
        !          7333:                         - C. Gordon Bell
        !          7334:                           IEEE Computer
        !          7335:                           June, 1984
        !          7336: 
        !          7337: 
        !          7338: 
        !          7339: From kanderso@bbn-vax  Tue Jul 10 11:41:39 1984
        !          7340: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7341:        id AA25755; Tue, 10 Jul 84 11:41:39 pdt
        !          7342: Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7343:        id AA06454; Tue, 10 Jul 84 11:29:28 pdt
        !          7344: Message-Id: <[email protected]>
        !          7345: Date: Tue, 10 Jul 84 14:28 EDT
        !          7346: From: Ken Anderson <kanderso@bbn-vax>
        !          7347: Subject: Problem compiling flavors in Opus 83.79
        !          7348: To: franz-friends@BERKELEY
        !          7349: Cc: franz-composers@BERKELEY, lbagnall@bbn, jchung@bbn
        !          7350: 
        !          7351: When trying to make flavors from the version in pub/lib on ucbkim,
        !          7352: liszt complains about calling an undefined function e-sub2.  Here is
        !          7353: the output of my makefile.  Any suggestions?
        !          7354: 
        !          7355: liszt -a flavorm
        !          7356: Compilation begins with Liszt vax version 8.36
        !          7357: source: flavorm.l, result: flavorm.o
        !          7358: [fasl /usr/lib/lisp/machacks.o]
        !          7359: [autoload /usr/lib/lisp/struct]
        !          7360: [fasl /usr/lib/lisp/struct.o]
        !          7361: flavor-plist
        !          7362: flavor-init-keywords
        !          7363: flavor-initable-instance-variables
        !          7364: flavor-settable-instance-variables
        !          7365: flavor-gettable-instance-variables
        !          7366: flavor-default-handler
        !          7367: flavor-which-operations
        !          7368: flavor-depends-on-all
        !          7369: flavor-includes
        !          7370: flavor-depended-on-by
        !          7371: flavor-depends-on
        !          7372: flavor-method-table
        !          7373: flavor-all-instance-variables
        !          7374: flavor-local-instance-variables
        !          7375: flavor-name
        !          7376: flavor-method-hash-table
        !          7377: flavor-bindings
        !          7378: make-flavor
        !          7379: alter-flavor
        !          7380: instancep
        !          7381: instancep::cmacro:g00079
        !          7382: send
        !          7383: lexpr-send
        !          7384: send-self
        !          7385: lexpr-send-self
        !          7386: g00100::send
        !          7387: %Note: flavorm.l: Compilation complete
        !          7388: %Note: flavorm.l:  Time: Real: 0:32, CPU: 0:11.10, GC: 0:0.00 for 0 gcs
        !          7389: %Note: flavorm.l: Assembly begins
        !          7390: %Note: flavorm.l: Assembly completed successfully
        !          7391: liszt -a flavors
        !          7392: Compilation begins with Liszt vax version 8.36
        !          7393: source: flavors.l, result: flavors.o
        !          7394: [fasl /usr/lib/lisp/machacks.o]
        !          7395: [fasl /usr/lib/lisp/lmhacks.o]
        !          7396: [fasl flavorm.o]
        !          7397: defflavor
        !          7398: defun-method
        !          7399: [autoload /usr/lib/lisp/struct]
        !          7400: [fasl /usr/lib/lisp/struct.o]
        !          7401: instance-variable-boundp
        !          7402: instance-flavor
        !          7403: instance-flavor::cmacro:g00068
        !          7404: instance-function
        !          7405: instance-function::cmacro:g00075
        !          7406: get-flavor
        !          7407: instance-typep
        !          7408: flavor-additional-instance-variables
        !          7409: flavor-additional-instance-variables::cmacro:g00101
        !          7410: flavor-instance-variable-initializations
        !          7411: flavor-instance-variable-initializations::cmacro:g00108
        !          7412: flavor-remaining-default-plist
        !          7413: flavor-remaining-default-plist::cmacro:g00115
        !          7414: flavor-remaining-init-keywords
        !          7415: flavor-remaining-init-keywords::cmacro:g00122
        !          7416: flavor-all-initable-instance-variables
        !          7417: flavor-all-initable-instance-variables::cmacro:g00129
        !          7418: g00133::flavor
        !          7419: Undefined function called from compiled code   e-sub2
        !          7420: ?Error: flavors.l: : Lisp error during compilation
        !          7421: make: *** Error code 1 ***
        !          7422: 
        !          7423: From jkf@ucbmike  Tue Jul 10 12:18:28 1984
        !          7424: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7425:        id AA27111; Tue, 10 Jul 84 12:18:28 pdt
        !          7426: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
        !          7427:        id AA07135; Tue, 10 Jul 84 12:06:28 pdt
        !          7428: Date: Tue, 10 Jul 84 12:07:07 pdt
        !          7429: From: John Foderaro (on an sun) <jkf@ucbmike>
        !          7430: Message-Id: <[email protected]>
        !          7431: Received: by ucbmike.ARPA (4.24ucb/3.5)
        !          7432:        id AA03780; Tue, 10 Jul 84 12:07:07 pdt
        !          7433: To: kanderso@bbn-vax, franz-friends@BERKELEY
        !          7434: Subject: Re: Problem compiling flavors in Opus 83.79
        !          7435: Cc: jchung@bbn, lbagnall@bbn, franz-composers@BERKELEY
        !          7436: In-Reply-To: Your message of Tue, 10 Jul 84 14:28 EDT
        !          7437: 
        !          7438:  This bug was fixed a while back, but apparently after you got your lisp
        !          7439: distribution.  You should get the latest lisp distribution.
        !          7440: 
        !          7441: 
        !          7442: 
        !          7443: From @MIT-MC:[email protected]  Tue Jul 10 13:29:15 1984
        !          7444: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7445:        id AA28822; Tue, 10 Jul 84 13:29:15 pdt
        !          7446: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7447:        id AA08350; Tue, 10 Jul 84 13:28:25 pdt
        !          7448: Message-Id: <[email protected]>
        !          7449: Date: 10 Jul 1984 13:46:05-EDT
        !          7450: From: Suzanne.Woolf@CMU-CS-SPICE
        !          7451: Subject: pretty printer
        !          7452: Apparently-To: <franz-friends@UCB-VAX>
        !          7453: 
        !          7454: Does anyone out there know of a well-documented pretty printer for lisp?  A
        !          7455: friend of mine needs one that can be hacked up.  Franz Lisp would be ideal,
        !          7456: but anything similar is fine.
        !          7457: 
        !          7458: Please send replies to:
        !          7459: Jaffe@cmu-psy-a
        !          7460: 
        !          7461: Thanks.
        !          7462: 
        !          7463: 
        !          7464: 
        !          7465: From @MIT-MC:smh@MIT-EMS  Tue Jul 10 15:29:20 1984
        !          7466: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7467:        id AA02481; Tue, 10 Jul 84 15:29:20 pdt
        !          7468: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7469:        id AA10890; Tue, 10 Jul 84 15:28:30 pdt
        !          7470: Message-Id: <[email protected]>
        !          7471: Date: 10 Jul 1984 18:24:02-EDT
        !          7472: From: <smh@mit-ems@mit-mc>
        !          7473: To: franz-friends@BERKELEY, kanderso@bbnvax
        !          7474: Subject: Re: Problem compiling flavors in Opus 83.79
        !          7475: 
        !          7476: A very quick check reveals the following suspiciousness:  The function
        !          7477: in flavors.l being compiled when the failure occurs is apparently:
        !          7478: 
        !          7479: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS)
        !          7480:   (SELECTQ OPERATION
        !          7481:           (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE))
        !          7482:           (:PRINT-SELF
        !          7483:            (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS))
        !          7484:               (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF))))
        !          7485:           (:DESCRIBE (DESCRIBE-FLAVOR SELF))
        !          7486:           (OTHERWISE
        !          7487:            (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION))))
        !          7488: 
        !          7489: This is the first appearance in the file of defun with a "function
        !          7490: spec" instead of a symbol as the first argument.  This is a Lisp
        !          7491: Machine hack which basically means to squirrel the functional object
        !          7492: away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR.
        !          7493: (More precisely, the first arg is the Maclisp compatability syntax for
        !          7494: (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...)
        !          7495: 
        !          7496: Liszt could be choking as it tries to store into the
        !          7497: function-definition slot of something other than a symbol.  Such
        !          7498: abilities of defun are not documented in Franz, and it might be that
        !          7499: your defun macro in common0.l has not been extended for such usage.
        !          7500: Locally it is defined as follows:
        !          7501: 
        !          7502: ;--- defun
        !          7503: ; maclisp style function defintion
        !          7504: ;
        !          7505: (def defun
        !          7506:    (macro (l)
        !          7507:       (prog (name type arglist body specind specnam)
        !          7508:         (setq name (cadr l) l (cddr l))
        !          7509:         (cond ((dtpr name)
        !          7510:                (cond ((memq (cadr name) '(macro expr fexpr lexpr))
        !          7511:                       (setq l (cons (cadr name) l)
        !          7512:                             name (car name)))
        !          7513:                      (t (setq specnam (car name)
        !          7514:                               specind (cadr name)
        !          7515:                               name (concat (gensym) "::" specnam))))))
        !          7516:         (cond ((null (car l)) (setq type 'lambda))
        !          7517:               ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l)))
        !          7518:               ((eq 'expr (car l))  (setq type 'lambda l (cdr l)))
        !          7519:               ((eq 'macro (car l)) (setq type 'macro l (cdr l)))
        !          7520:               ((atom (car l))
        !          7521:                (setq type 'lexpr
        !          7522:                      l (nconc (list (list (car l)))
        !          7523:                               (cdr l))))
        !          7524:               (t (setq type 'lambda)))
        !          7525:         (setq body (list 'def name (cons type l)))
        !          7526:         (cond (specnam
        !          7527:                  (return (list 'progn ''compile
        !          7528:                                body
        !          7529:                                (list 'putprop
        !          7530:                                      (list 'quote specnam)
        !          7531:                                      (list 'getd
        !          7532:                                            (list 'quote name))
        !          7533:                                      (list 'quote specind)))))
        !          7534:               (t (return body))))))
        !          7535: 
        !          7536: You could also check by invoking liszt without arguments and then
        !          7537: asking it
        !          7538:        (testmac '(defun (foo bar) () (hello goodbye)))
        !          7539: and seeing if it properly generates
        !          7540:        (progn 'compile (defun ... ) (putprop ... ))
        !          7541: 
        !          7542: On another matter, I have recently been making a number of minor
        !          7543: bugfixes to the flavor and various other MIT compatibility packages.
        !          7544: These files come indirecly from Maclisp or Lisp Machines, and the ports
        !          7545: have generally never been exercised sufficiently to check all the
        !          7546: obscure features.  These fixes postdate the versions Rich Zippel
        !          7547: recently transmitted to Berkeley.  I will shortly distribute the
        !          7548: new versions to Berkeley.
        !          7549: 
        !          7550: Believe it or not, the flavor system really does work under Franz.
        !          7551: So do hash tables, defstruct, format, etc.  I use them every day.
        !          7552: 
        !          7553: Steve Haflich, MIT Experimental Music Studio
        !          7554: smh@mit-ems@mit-mc
        !          7555: {decvax!genrad, ihnp4}!mit-eddie!smh
        !          7556: 
        !          7557: 
        !          7558: From abar@ucbernie  Tue Jul 10 23:04:16 1984
        !          7559: Received: from ucbernie.ARPA by ucbkim.ARPA (4.28/4.27)
        !          7560:        id AA08764; Tue, 10 Jul 84 23:04:16 pdt
        !          7561: Received: by ucbernie.ARPA (4.28/4.30)
        !          7562:        id AA06176; Tue, 10 Jul 84 23:02:56 pdt
        !          7563: Date: Tue, 10 Jul 84 23:02:56 pdt
        !          7564: From: abar@ucbernie (Robert Abarbanel)
        !          7565: Message-Id: <[email protected]>
        !          7566: To: franz-friends@ucbernie
        !          7567: Subject: &optional, &rest, &aux
        !          7568: 
        !          7569: Any way to get these &args to work without compilation... that is, when
        !          7570: a function is working interpreted?
        !          7571: 
        !          7572: From kanderso@bbn-vax  Wed Jul 11 12:25:52 1984
        !          7573: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7574:        id AA17391; Wed, 11 Jul 84 12:25:52 pdt
        !          7575: Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7576:        id AA19991; Wed, 11 Jul 84 12:24:54 pdt
        !          7577: Message-Id: <[email protected]>
        !          7578: Date: Wed, 11 Jul 84 15:24 EDT
        !          7579: From: Ken Anderson <kanderso@bbn-vax>
        !          7580: Subject: bugs in hash.l and array.l
        !          7581: To: franz-friends@BERKELEY
        !          7582: Cc: lbagnall@bbn, jchung@bbn
        !          7583: 
        !          7584: To get Flavors working in Opus 38.91 you will need to fix a bug in
        !          7585: lisplib/hash.l.  Change all occurances of "getlength" to "vsize".
        !          7586: 
        !          7587: Although unrelated to Flavors, there are several problems with
        !          7588: the functions, fillarray fillarrayarray and listarray in
        !          7589: lisplib/array.l.  Here is an ed script produced by diff:
        !          7590: 
        !          7591: 285,286c
        !          7592:               (cond ((or (arrayp arr)          ; KRA
        !          7593:                          (and (symbolp arr) (arrayp (setq arr (getd arr))))))
        !          7594: .
        !          7595: 282,283c
        !          7596:     (lexpr (n)
        !          7597:           (prog (arr size typ ret newv)
        !          7598: .
        !          7599: 280a
        !          7600: ; KRA 83-11-2:  Arrays need not be symbols.
        !          7601: .
        !          7602: 279c
        !          7603:                    (replace (arrayref arrto i) (arrayref arrfrom i)))
        !          7604:                (return arrto))))       ; KRA
        !          7605: .
        !          7606: 270c
        !          7607:                    (cond ((cdr ls) (setq ls (cdr ls)))))
        !          7608:                (return arr))))         ; KRA
        !          7609: .
        !          7610: 244a
        !          7611: ; KRA 83-11-2:  Fillarray  and fillarrayarray should return the array!
        !          7612: .
        !          7613: 
        !          7614: From jkf@ucbmike  Wed Jul 11 13:43:49 1984
        !          7615: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7616:        id AA20014; Wed, 11 Jul 84 13:43:49 pdt
        !          7617: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
        !          7618:        id AA21120; Wed, 11 Jul 84 13:32:32 pdt
        !          7619: Date: Wed, 11 Jul 84 13:32:52 pdt
        !          7620: From: John Foderaro (on an sun) <jkf@ucbmike>
        !          7621: Message-Id: <[email protected]>
        !          7622: Received: by ucbmike.ARPA (4.24ucb/3.5)
        !          7623:        id AA05402; Wed, 11 Jul 84 13:32:52 pdt
        !          7624: To: franz-friends@BERKELEY
        !          7625: Subject: Re: &optional, &rest, &aux
        !          7626: Cc: franz-composers@BERKELEY
        !          7627: In-Reply-To: Your message of 11 Jul 1984 15:12:07-EDT
        !          7628: 
        !          7629:  The problem with the &optional and &rest was due to abar using the
        !          7630: cmufile package, which redefines 'def' and doesn't look for those
        !          7631: keywords.
        !          7632: 
        !          7633: 
        !          7634: 
        !          7635: From [email protected]  Wed Jul 11 20:29:28 1984
        !          7636: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7637:        id AA25212; Wed, 11 Jul 84 20:29:28 pdt
        !          7638: Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7639:        id AA28089; Wed, 11 Jul 84 20:28:27 pdt
        !          7640: Reply-To: [email protected]
        !          7641: Received: by cadre.UUCP (4.12/3.14)
        !          7642:        id AA22394; Wed, 11 Jul 84 23:22:09 edt
        !          7643: Date: Wed, 11 Jul 84 23:22:09 edt
        !          7644: From: cadre!sm (Sean McLinden)
        !          7645: Message-Id: <[email protected]>
        !          7646: To: [email protected]
        !          7647: Subject: redefinition of existing flavors
        !          7648: Cc: franz-friends@BERKELEY
        !          7649: 
        !          7650: 
        !          7651:  As distributed by Berkeley, the flavors package on Opus 38.89
        !          7652:  appears to work in all cases except when a flavor is redefined
        !          7653:  and perform-flavor-redefinition is invoked. The problem, I
        !          7654:  thought, was in copy-hunk-contents, since the default structures
        !          7655:  (and therefore flavors), in Opus 38.89, are VECTORS, not HUNKS.
        !          7656:  However, modifying copy-hunk-contents to copy VECTORS did not,
        !          7657:  completely, fix the problem (i.e, the first modification after
        !          7658:  redefinition of copy-hunk-contents caused an error, the second
        !          7659:  worked but then describe did not work for old instances of the
        !          7660:  flavor).
        !          7661: 
        !          7662:  Before delving into code with which I am unfamiliar are there
        !          7663:  any differences between Opus 38.89 and 38.91 which might explain
        !          7664:  this?
        !          7665: 
        !          7666:  Sean McLinden
        !          7667:  Decision Systems Lab
        !          7668:  University of Pittsburgh
        !          7669: 
        !          7670: 
        !          7671: From harrison@nrl-aic  Thu Jul 12 07:15:39 1984
        !          7672: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7673:        id AA28967; Thu, 12 Jul 84 07:15:39 pdt
        !          7674: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7675:        id AA07280; Thu, 12 Jul 84 07:14:50 pdt
        !          7676: Date: 12 Jul 1984 10:08-EDT
        !          7677: From: Patrick Harrison <harrison@NRL-AIC>
        !          7678: Subject: Lisp for Honeywell 6060 DPS-8
        !          7679: To: ailist@sri-ai
        !          7680: Cc: franz-friends@BERKELEY
        !          7681: Message-Id: <84/07/12 1008.550@NRL-AIC>
        !          7682: 
        !          7683: 
        !          7684:      Am looking for information on current versions of LISP (FranzLisp,
        !          7685: MacLisp) running in a Honeywell 6060, DPS-8 environment. Would also
        !          7686: like to implement OPS5 on same.  Address:
        !          7687:    
        !          7688:                         Dr. Patrick Harrison
        !          7689:                         Computer Science Department
        !          7690:                         U.S. Naval Academy
        !          7691:                         Annapolis, Maryland 21402.
        !          7692:  
        !          7693: Responses to above address or <harrison@nrl-aic>
        !          7694: 
        !          7695: From @MIT-MC:mhs@MIT-HTVAX  Tue Jul 17 12:45:10 1984
        !          7696: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7697:        id AA00659; Tue, 17 Jul 84 12:45:10 pdt
        !          7698: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7699:        id AA02214; Mon, 16 Jul 84 16:28:19 pdt
        !          7700: Message-Id: <[email protected]>
        !          7701: Date: 16 Jul 1984 16:32:48-EDT
        !          7702: From: mhs@mit-htvax@mit-mc
        !          7703: To: franz-friends@berkeley@mit-mc
        !          7704: Subject: Small bug in flavors.l
        !          7705: Cc: mhs@mit-htvax@mit-mc
        !          7706: 
        !          7707:     The following test demonstrates a problem with flavors.l as it is
        !          7708: distributed with Release 38.91.  (The "a" after the minor number indicates a
        !          7709: couple of changes made locally - mostly involving preloading struct, loop and
        !          7710: such.  flavors.l wasn't touched.)
        !          7711: 
        !          7712:     The problem is that simple method combination doesn't work for trivial
        !          7713: reasons.  A fix is suggested below.  As the example shows, the combined method
        !          7714: for :PROGN combination is wrong. (:OR, :LIST ... all have the same problem).
        !          7715: 
        !          7716: Franz Lisp, Opus 38.91a (with Zetalisp compatability package)
        !          7717: -> (defflavor object
        !          7718:      (color)
        !          7719:      ()
        !          7720:      :gettable-instance-variables
        !          7721:      :settable-instance-variables
        !          7722:      :initable-instance-variables
        !          7723:      (:method-combination (:progn :base-flavor-last :test1)))
        !          7724: object
        !          7725: -> (defmethod (object :test1) ()
        !          7726:      (format t "~&object :test1~%"))
        !          7727: (:method object :test1)
        !          7728: -> (defflavor car
        !          7729:      (price)
        !          7730:      (object)
        !          7731:      :gettable-instance-variables
        !          7732:      :settable-instance-variables
        !          7733:      :initable-instance-variables)
        !          7734: car
        !          7735: -> (defmethod (car :test1) ()
        !          7736:      (format t "~&car :test1~%"))
        !          7737: (:method car :test1)
        !          7738: -> (setq car (make-instance 'car))
        !          7739: #<car 591928>
        !          7740: -> (send car ':test1)
        !          7741: |Error:| eval: Undefined function  :progn
        !          7742: <1>: (debug)
        !          7743: 
        !          7744: <------debug------>
        !          7745: 
        !          7746: :bk
        !          7747: 
        !          7748: <------debug------>   <--- you are here
        !          7749: (eval (debug))
        !          7750: (break-err-handler (|ER%undef| 0 t |eval: Undefined function | :progn))
        !          7751: (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.))
        !          7752: ((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)))
        !          7753: ,
        !          7754: ,
        !          7755: ,
        !          7756: (send car (quote :test1))
        !          7757: (eval (send car (quote :test1)))
        !          7758: <bottom of stack>
        !          7759: 
        !          7760:     Look at the combined method:
        !          7761: 
        !          7762: (:progn
        !          7763:      (lexpr-funcall (function car-test1-method) .daemon-caller-args.)
        !          7764:      (lexpr-funcall (function object-test1-method) .daemon-caller-args.))
        !          7765: 
        !          7766:     I think the problem is caused by the fact that in the older package system,
        !          7767: the keyword package inherited from the global package.  Thus :PROGN (in the
        !          7768: keyword package) was the same atom as PROGN (in global).  However, this isn't
        !          7769: true in Franz.  :PROGN isn't EQ to PROGN, and it shouldn't be.  (The same
        !          7770: problem occurs for all of the other simple method combination types too, e.g.
        !          7771: :OR, :LIST ...).  One possible fix is to add an alist
        !          7772: (SIMPLE-METHOD-COMBINATION-TYPE-ALIST) to store the correspondence between
        !          7773: :PROGN and PROGN, like so:  (I just tested this code locally and it seemed to
        !          7774: work.)
        !          7775: 
        !          7776: #+franz
        !          7777: (DEFCONST SIMPLE-METHOD-COMBINATION-TYPE-ALIST
        !          7778:         '((:PROGN . PROGN)
        !          7779:           (:AND . AND)
        !          7780:           (:OR . OR)
        !          7781:           (:MAX . MAX)
        !          7782:           (:MIN . MIN)
        !          7783:           (:+ . +)
        !          7784:           (:APPEND . APPEND)
        !          7785:           (:NCONC . NCONC)))
        !          7786: 
        !          7787: (DEFUN SIMPLE-METHOD-COMBINATION (FL MAGIC-LIST-ENTRY)
        !          7788:   (LET ((METHODS (GET-CERTAIN-METHODS MAGIC-LIST-ENTRY NIL NIL NIL NIL))
        !          7789:        (WRAPPERS-P (SPECIALLY-COMBINED-METHODS-PRESENT MAGIC-LIST-ENTRY)))
        !          7790:     (OR (AND (NOT WRAPPERS-P) (NULL (CDR METHODS)) (CAR METHODS))
        !          7791:        (HAVE-COMBINED-METHOD FL MAGIC-LIST-ENTRY)
        !          7792:        (MAKE-COMBINED-METHOD FL MAGIC-LIST-ENTRY
        !          7793:            ;; In the old package system, :progn maps to progn trivially
        !          7794:            ;; via package inheritance (keyword inherits from global).
        !          7795:            ;; In Franz, we use an alist to implement the mapping.
        !          7796:           (CONS #-franz (CADR MAGIC-LIST-ENTRY)
        !          7797:                  #+franz (CDR (ASSQ (CADR MAGIC-LIST-ENTRY) 
        !          7798:                                  SIMPLE-METHOD-COMBINATION-TYPE-ALIST))
        !          7799:                         (MAPCAR 'METHOD-CALL
        !          7800:                                 METHODS))))))
        !          7801: 
        !          7802: 
        !          7803: From "Gladd Tom"@LLL-MFE.ARPA  Wed Jul 18 10:44:03 1984
        !          7804: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7805:        id AA00765; Wed, 18 Jul 84 10:44:03 pdt
        !          7806: Received: from LLL-MFE.ARPA (lll-mfe.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
        !          7807:        id AA01412; Wed, 18 Jul 84 10:42:20 pdt
        !          7808: Message-Id: <[email protected]>
        !          7809: Date: Wed, 18 Jul 84 10:35 PDT
        !          7810: From: "Gladd Tom"@LLL-MFE.ARPA
        !          7811: Subject: join list 619-453-6580
        !          7812: To: franz-friends@BERKELEY
        !          7813: 
        !          7814: i would like to join your list. i am very interested in list in general
        !          7815: and have been trying to learn it in a near vacuum (small hi-tech company
        !          7816: in sandiego. i am especially interested in advanced coding techniques
        !          7817: (at least beyond the standard texts). my background is theoretical
        !          7818: plasma physics. i have used and am very interested in macsyma.
        !          7819: my address is "gladd tom%cma"@lll-mfe.arpa
        !          7820: 
        !          7821: From @MIT-MC:[email protected]  Wed Jul 25 10:06:41 1984
        !          7822: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7823:        id AA08698; Wed, 25 Jul 84 10:06:41 pdt
        !          7824: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7825:        id AA19747; Wed, 25 Jul 84 10:05:06 pdt
        !          7826: Message-Id: <[email protected]>
        !          7827: Date: 25 Jul 1984 12:30:25-EDT
        !          7828: From: Philip.Kasprzyk@CMU-RI-ISL2
        !          7829: Subject: Lisp Speed Benchmarks
        !          7830: Apparently-To: <franz-friends@UCB-VAX>
        !          7831: 
        !          7832: ~v
        !          7833: I am interested in determining the absolute speed of execution of a lisp
        !          7834: system. I realize that this is a complicated task that is application
        !          7835: and implementation dependant. Nevertheless I am seeking the following:
        !          7836: 
        !          7837: 1) A "gibson mix" style benchmark for lisp based systems.
        !          7838: 
        !          7839: 2) Any data that experienced users of lisp may have regarding performance.
        !          7840:     (I don't care what machine or dialect of lisp is reported)
        !          7841: 
        !          7842: 3) Any method or program which translates a lisp program into another
        !          7843:     target high level language with execution speed as its objective.
        !          7844:        (I don't mean a normal lisp compiler)
        !          7845: 
        !          7846: Can anyone out there help me? 
        !          7847: 
        !          7848: If so send mail to pmk@isl2.
        !          7849: 
        !          7850: 
        !          7851: 
        !          7852: From mab@aids-unix  Fri Jul 27 14:35:21 1984
        !          7853: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7854:        id AA29865; Fri, 27 Jul 84 14:35:21 pdt
        !          7855: Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7856:        id AA04068; Fri, 27 Jul 84 14:33:40 pdt
        !          7857: Message-Id: <[email protected]>
        !          7858: Date: 27 Jul 84 14:23:47 PDT (Fri)
        !          7859: From: Mike Brzustowicz <mab@aids-unix>
        !          7860: Subject: Benchmarks
        !          7861: To: franz-friends@BERKELEY
        !          7862: 
        !          7863: Does anyone have any small LISP programs that can be abused as benchmarks?
        !          7864: (They need to be small is source only.)  I need some very soon.  Thanks!
        !          7865: 
        !          7866: -Mike
        !          7867: <mab@aids-unix>
        !          7868: 
        !          7869: From [email protected]  Fri Jul 27 15:15:06 1984
        !          7870: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7871:        id AA01124; Fri, 27 Jul 84 15:15:06 pdt
        !          7872: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7873:        id AA04900; Fri, 27 Jul 84 15:13:09 pdt
        !          7874: Message-Id: <[email protected]>
        !          7875: Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT
        !          7876: Date: 27 Jul 84 15:14 PDT
        !          7877: From: [email protected]
        !          7878: Subject: Re: Benchmarks
        !          7879: In-Reply-To: Mike Brzustowicz <[email protected]>'s message of 27 Jul
        !          7880:  84 14:23:47 PDT (Fri)
        !          7881: To: [email protected]
        !          7882: Cc: franz-friends@BERKELEY
        !          7883: 
        !          7884: Here's a good benchmark:
        !          7885: 
        !          7886: (defun nilret () nil)
        !          7887: 
        !          7888: this is a good test of how fast your lisp returns NIL.
        !          7889: 
        !          7890: I also like
        !          7891: 
        !          7892: (defun retjunk (x) (cond((junkp x)  'junk)
        !          7893:                                 ((cdr x) (retjunk (car x)))
        !          7894:                                 ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x))))
        !          7895:                                 (t (retjunk (cons 'junk x))))
        !          7896: 
        !          7897: (defun junkp (x) (equal (reverse (explode x)) (reverse (explode
        !          7898: 'junk))))
        !          7899: 
        !          7900: 
        !          7901: This benchmark measures how fast your lisp can return junk, executing
        !          7902: the retjunk function.
        !          7903: 
        !          7904: Both of the benchmarks have the adavantage that they are small and can
        !          7905: be abused as benchmarks.
        !          7906: 
        !          7907: From @USC-ECL.ARPA:BENSON@ECLD  Tue Jul 31 20:02:20 1984
        !          7908: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
        !          7909:        id AA21521; Tue, 31 Jul 84 20:02:20 pdt
        !          7910: Received: from USC-ECL.ARPA (usc-ecl.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7911:        id AA02839; Tue, 31 Jul 84 20:00:29 pdt
        !          7912: Message-Id: <[email protected]>
        !          7913: Received: from ECLD by ECLA with ECLnet; Tue 31 Jul 84 19:56:31-PDT
        !          7914: Date: Tue 31 Jul 84 19:33:52-PDT
        !          7915: From: Eric Benson <BENSON@ECLD.#ECLnet>
        !          7916: Subject: Re: Lisp Speed Benchmarks
        !          7917: To: [email protected]
        !          7918: Cc: BENSON@ECLD.#ECLnet, Franz-Friends@BERKELEY
        !          7919: In-Reply-To: Message from "Philip.Kasprzyk@CMU-RI-ISL2" of Wed 25 Jul 84 09:30:25-PDT
        !          7920: 
        !          7921: There is a set of benchmarks which have been run on a variety of Lisp
        !          7922: systems which have been compiled by Richard Gabriel at Stanford.  You
        !          7923: should contact Paul Wieneke (PW@SU-AI) for more information.
        !          7924: -------
        !          7925: 
        !          7926: From narain@rand-unix  Wed Aug  1 12:31:21 1984
        !          7927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          7928:        id AA00623; Wed, 1 Aug 84 12:31:21 pdt
        !          7929: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7930:        id AA00567; Wed, 1 Aug 84 12:29:40 pdt
        !          7931: Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt
        !          7932: From: Sanjai Narain <narain@rand-unix>
        !          7933: Message-Id: <[email protected]>
        !          7934: Date: 01 Aug 84 11:04:25 PDT (Wed)
        !          7935: To: franz-friends@BERKELEY
        !          7936: Subject: Fast recompiling
        !          7937: 
        !          7938: 
        !          7939: Often we have files consisting of large numbers of functions which are
        !          7940: compiled. Sometimes, just one of these functions needs to be changed. It
        !          7941: would be nice to recompile just this function, and copy already compiled
        !          7942: functions to produce a fresh version of the compiled file. Is there any
        !          7943: quick method of doing this in Franz Lisp i.e. is there an equivalent of
        !          7944: Interlisp's "recompile" function.
        !          7945: 
        !          7946: I would be grateful for your response.
        !          7947: 
        !          7948: -- Sanjai Narain
        !          7949: 
        !          7950: From fateman@ucbdali  Wed Aug  1 13:24:30 1984
        !          7951: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          7952:        id AA03438; Wed, 1 Aug 84 13:24:30 pdt
        !          7953: Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33)
        !          7954:        id AA01542; Wed, 1 Aug 84 13:06:01 pdt
        !          7955: Received: by ucbdali.ARPA (4.24/4.27)
        !          7956:        id AA00994; Wed, 1 Aug 84 13:07:35 pdt
        !          7957: Date: Wed, 1 Aug 84 13:07:35 pdt
        !          7958: From: fateman@ucbdali (Richard Fateman)
        !          7959: Message-Id: <[email protected]>
        !          7960: To: franz-friends@BERKELEY, narain@rand-unix
        !          7961: Subject: Re:  Fast recompiling
        !          7962: 
        !          7963: This would be an interesting feature, but it is complicated by the
        !          7964: possibility that the compilation environment is built up in a typical
        !          7965: large Franz system, by processing the whole file.  I think that the
        !          7966: interlisp situation is usually simpler.  
        !          7967:   For example, in recompiling Macsyma, sometimes a file itself or
        !          7968: function definitions in it do not change at all. A "macro definition"
        !          7969: file which is included in the compilation environment can, however, change
        !          7970: the generated code, substantially.
        !          7971:   Something like UNIX's "make" might be needed.
        !          7972: 
        !          7973: Alternatively, you can use smaller files...
        !          7974: 
        !          7975: From jkf@ucbmike  Thu Aug  2 16:10:04 1984
        !          7976: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          7977:        id AA16097; Thu, 2 Aug 84 16:10:04 pdt
        !          7978: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33)
        !          7979:        id AA00501; Thu, 2 Aug 84 16:08:09 pdt
        !          7980: Date: Thu, 2 Aug 84 16:09:45 pdt
        !          7981: From: John Foderaro (on an sun) <jkf@ucbmike>
        !          7982: Message-Id: <[email protected]>
        !          7983: Received: by ucbmike.ARPA (4.24ucb/3.5)
        !          7984:        id AA01757; Thu, 2 Aug 84 16:09:45 pdt
        !          7985: To: franz-friends@BERKELEY
        !          7986: Subject: repeated messages
        !          7987: Cc: 
        !          7988: 
        !          7989:   I'm sorry about the repeated messages.  Our mailing machine got a bit
        !          7990: overloaded.  I've modified the organization of the list to try to
        !          7991: fix the problem.
        !          7992: 
        !          7993: 
        !          7994: 
        !          7995: From NET-ORIGIN@MIT-MC  Fri Aug  3 15:15:44 1984
        !          7996: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          7997:        id AA26463; Fri, 3 Aug 84 15:15:44 pdt
        !          7998: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          7999:        id AA04086; Fri, 3 Aug 84 15:13:41 pdt
        !          8000: Received: from mit-heracles (mit-heracles.ARPA) by mit-charon (4.12/4.7)
        !          8001:        id AA13781; Fri, 3 Aug 84 14:32:51 edt
        !          8002: Received: by mit-heracles (4.12/4.7)
        !          8003:        id AA20045; Fri, 3 Aug 84 14:35:30 edt
        !          8004: From: yba@mit-heracles (Mark H Levine)
        !          8005: Message-Id: <8408031835.AA20045@mit-heracles>
        !          8006: Date:  3 Aug 1984 1435-EDT (Friday)
        !          8007: To: franz-friends@BERKELEY
        !          8008: Subject: Opus 37.79 building from source
        !          8009: 
        !          8010: 
        !          8011: Has anyone published a fix to the bug that causes "rawlisp" to take a
        !          8012: memory fault when built from vanilla 4.2bsd sources?
        !          8013: 
        !          8014: It seems that the routine "getatom" in franz/alloc.c calls strcmp
        !          8015: with "name" equal to "mod" and "aptr -> a.pname" equal to CNIL (-4).
        !          8016: 
        !          8017: This is presumably a side effect of some other error; it still causes
        !          8018: a memory fault in strcmp and prevents building from source.  The sources
        !          8019: have some Sept. '83 changes to the library code, but are otherwise con-
        !          8020: sistent with all the 4.2 code I have seen.
        !          8021: 
        !          8022: Got a fix handy?
        !          8023: 
        !          8024: 
        !          8025: 
        !          8026: From liz@maryland  Mon Aug  6 07:41:41 1984
        !          8027: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8028:        id AA16830; Mon, 6 Aug 84 07:41:41 pdt
        !          8029: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
        !          8030:        id AA06949; Mon, 6 Aug 84 07:39:52 pdt
        !          8031: Received: by maryland.ARPA (4.12/4.7)
        !          8032:        id AA01505; Mon, 6 Aug 84 10:40:52 edt
        !          8033: Date: Mon, 6 Aug 84 10:40:52 edt
        !          8034: From: liz@maryland (Liz Allen)
        !          8035: Message-Id: <[email protected]>
        !          8036: To: franz-friends@BERKELEY, yba%[email protected]
        !          8037: Subject: Re:  Opus 37.79 building from source
        !          8038: 
        !          8039: That sounds like an error I ran into recently -- only it was with Opus
        !          8040: 38.91 and it was also because I was adding more strings to rawlisp.
        !          8041: Anyway, the fix was easy and is probably worth trying.  Go into
        !          8042: franz/data.c and change the size of i_strbuf and make it bigger.  Ours
        !          8043: was 600, and I made it 1000.  You'll also need to change the
        !          8044: initialization for i_strbuf; I changed ours from "i_strbuf + 599" to
        !          8045: "i_strbuf + 999".
        !          8046: 
        !          8047: Hope this helps!
        !          8048: 
        !          8049:                                -Liz
        !          8050: 
        !          8051: From smotroff@bbncct  Wed Aug  8 14:39:03 1984
        !          8052: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8053:        id AA23393; Wed, 8 Aug 84 14:39:03 pdt
        !          8054: Received: from bbncct (bbncct.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8055:        id AA21105; Wed, 8 Aug 84 14:39:58 pdt
        !          8056: Message-Id: <[email protected]>
        !          8057: Date: Wed, 8 Aug 84 17:28:58 EDT
        !          8058: From: Ira Smotroff <[email protected]>
        !          8059: Subject: add me to the list
        !          8060: To: franz-friends@BERKELEY
        !          8061: 
        !          8062: please add my name to the franz-friends list
        !          8063: 
        !          8064: 
        !          8065: smotroff at bbn
        !          8066: 
        !          8067: 
        !          8068: From booker@nrl-aic  Fri Aug 10 06:18:45 1984
        !          8069: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8070:        id AA13113; Fri, 10 Aug 84 06:18:45 pdt
        !          8071: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8072:        id AA14441; Fri, 10 Aug 84 06:19:43 pdt
        !          8073: Message-Id: <[email protected]>
        !          8074: Date: 10 Aug 1984 09:09:24-PDT
        !          8075: From: Lashon Booker <booker@NRL-AIC>
        !          8076: To: franz-friends@BERKELEY
        !          8077: Subject: Interlisp Compatibility Package?
        !          8078: 
        !          8079: Has anyone written an Interlisp compatibility package
        !          8080: for Franz?  Thanks.
        !          8081: 
        !          8082: Lashon Booker
        !          8083: booker@nrl-aic
        !          8084: 
        !          8085: From @MIT-MC:smh@MIT-EMS  Fri Aug 10 13:14:44 1984
        !          8086: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8087:        id AA01017; Fri, 10 Aug 84 13:14:44 pdt
        !          8088: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8089:        id AA21922; Fri, 10 Aug 84 13:15:43 pdt
        !          8090: Message-Id: <[email protected]>
        !          8091: Date: 10 Aug 1984 16:06:48-EDT
        !          8092: From: smh@mit-ems@mit-mc
        !          8093: To: franz-friends@BERKELEY
        !          8094: Subject: (atom VECTOR): franz vs liszt
        !          8095: 
        !          8096: Versions: Franz 38.91, Liszt 8.39, and probably most others.
        !          8097: 
        !          8098: Description:
        !          8099:        The atom predicate operates inconsistently between compiled and
        !          8100:        interpreted code when passed a vector or vectori.
        !          8101: 
        !          8102: Repeat-by:
        !          8103:        Create and compile a file containing the following definition:
        !          8104:                (defun atum(x) (atom x))
        !          8105:        After loading it into the interpreter the following results can
        !          8106:        be obtained:
        !          8107:                (setq v (vector 1 2 3))
        !          8108:                (atom v)                ===> t
        !          8109:                (atum v)                ===> nil
        !          8110: 
        !          8111: Discussion:
        !          8112:        According to the manual, atom returns "t iff g_arg is not a list or
        !          8113:        hunk object."  By this definition, the interpreter is correct and the
        !          8114:        compiler incorrect.  However, one can make a strong argument that
        !          8115:        vectors, analogously to hunks, should not be considered atoms.
        !          8116:        Therefore, the both the documentation and interpreter should be
        !          8117:        changed.  (It is doubtful very much existing code depends on this.)
        !          8118: 
        !          8119: Suggested fix:
        !          8120:        Change the definition of atom section 2 of the manual to read:
        !          8121:                "t iff g_arg is not a list, hunk, vector, or vectori object."
        !          8122:        Add the following definition to franz/h/global.h, after the existing
        !          8123:        definition of HUNKP:
        !          8124:                #define HUNKORVECP(a1)  ((TYPE(a1) >= 11) & (TYPE(a1) <= 19))
        !          8125:        Change the definition of Latom in franz/lam1.c:
        !          8126:                lispval
        !          8127:                Latom()
        !          8128:                {
        !          8129:                        register struct argent *lb = lbot;
        !          8130:                        chkarg(1,"atom");
        !          8131:        ==>             if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val)))
        !          8132:                                return(nil);
        !          8133:                        else
        !          8134:                                return(tatom);
        !          8135:                }
        !          8136: 
        !          8137: Alternative suggested fix:
        !          8138:        If franz-composers really feel that atom ought to treat hunks
        !          8139:        and vectors differently (sigh?), then fix the compiler instead
        !          8140:        of the interpreter and documentation.  The most important thing
        !          8141:        is that interpreted and compiler do the same thing!
        !          8142:        In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition
        !          8143:        of the mask constant.
        !          8144: 
        !          8145: Random (constructive) flame:
        !          8146:        The interpreter definition above has to lookup the type of its
        !          8147:        argument expensively in the typetable *three* times, to wit:
        !          8148:                #define ATOX(a1)        ((((int)(a1)) - OFFSET) >> 9)
        !          8149:                #define TYPE(a1)        ((typetable+1)[ATOX(a1)])
        !          8150:        While compiled code is admirably streamlined, the interpreter
        !          8151:        could be made significantly faster here and elsewhere if TYPE
        !          8152:        were evaluated only once and held for examination in a
        !          8153:        temporary.  This would require a bunch more type predicate
        !          8154:        DEFINEs operating on TYPE values instead of object addresses.
        !          8155: 
        !          8156: Steve Haflich
        !          8157: smh%mit-ems@mit-mc
        !          8158: {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh
        !          8159: 
        !          8160: 
        !          8161: From [email protected]  Mon Aug 13 13:25:44 1984
        !          8162: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8163:        id AA03640; Mon, 13 Aug 84 13:25:44 pdt
        !          8164: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8165:        id AA05890; Mon, 13 Aug 84 13:26:52 pdt
        !          8166: Message-Id: <[email protected]>
        !          8167: Received: from Semillon.ms by ArpaGateway.ms ; 13 AUG 84 13:24:39 PDT
        !          8168: Date: 13 Aug 84 13:24 PDT
        !          8169: From: [email protected]
        !          8170: Subject: Re: (atom VECTOR): franz vs liszt
        !          8171: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 10 Aug 84 16:06:48
        !          8172:  EDT
        !          8173: To: "smh@mit-ems"@MIT-MC.ARPA
        !          8174: Cc: franz-friends@BERKELEY, [email protected], [email protected]
        !          8175: 
        !          8176: Perhaps this bug should be forwarded to BUG-LISP@MIT-MC, since the
        !          8177: original design flaw is in MacLisp.  The problem is that when Hunks were
        !          8178: first invented, there where some who wanted them as "annotated" list
        !          8179: cells (hence, they weren't ATOMs) while other wanted them as small
        !          8180: VECTORs (hence there should be ATOMs).  The resolution was some awful
        !          8181: switch setting for whether or not to treat them as ATOMs, but I don't
        !          8182: remember the default setting, nor the final results.
        !          8183: 
        !          8184: -- JonL --
        !          8185: 
        !          8186: 
        !          8187: 
        !          8188: 
        !          8189: From ALAN@MIT-MC  Mon Aug 13 17:15:11 1984
        !          8190: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8191:        id AA07443; Mon, 13 Aug 84 17:15:11 pdt
        !          8192: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8193:        id AA10564; Mon, 13 Aug 84 17:16:03 pdt
        !          8194: Message-Id: <[email protected]>
        !          8195: Date: 13 August 1984 20:08-EDT
        !          8196: From: Alan Bawden <ALAN@MIT-MC>
        !          8197: Subject:  (atom VECTOR): franz vs liszt
        !          8198: To: JonL.pa@XEROX
        !          8199: Cc: GSB@MIT-MC, franz-friends@BERKELEY, smh@MIT-EMS
        !          8200: In-Reply-To: Msg of 13 Aug 84 13:24 PDT from JonL.pa at XEROX.ARPA
        !          8201: 
        !          8202:     Date: 13 Aug 84 13:24 PDT
        !          8203:     From: JonL.pa at XEROX
        !          8204:     ...  The resolution was some awful switch setting for whether or not to
        !          8205:     treat them as ATOMs, but I don't remember the default setting, nor the
        !          8206:     final results.
        !          8207: 
        !          8208: There are indeed a couple of switches that control various random aspects
        !          8209: of hunks, but none of them have any effect on their atomic or non-atomic
        !          8210: nature.  Hunks are never atoms in MacLisp.  Everybody agrees that this is a
        !          8211: loss, but at this point it is rather deeply ingrained into things to think
        !          8212: about changing it.
        !          8213: 
        !          8214: 
        !          8215: From [email protected]  Tue Aug 14 01:53:12 1984
        !          8216: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8217:        id AA13476; Tue, 14 Aug 84 01:53:12 pdt
        !          8218: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8219:        id AA23091; Tue, 14 Aug 84 01:54:22 pdt
        !          8220: Message-Id: <[email protected]>
        !          8221: Received: From ct.csnet by csnet-relay;  14 Aug 84 4:31 EDT
        !          8222: Date: 13 Aug 1984 20:46:42-PST
        !          8223: From: jmiller%[email protected]
        !          8224: To: franz-friends@BERKELEY
        !          8225: Subject: bug in assoc
        !          8226: 
        !          8227: The following illustrates a rather unpleasant bug in Franz's ASSOC (as
        !          8228: of 38.26, anyhow).  Be forewarned....
        !          8229: 
        !          8230: ------------------------------------------------------------------------------
        !          8231: 
        !          8232: 8_(setq l '((a 1) (b 2) (c 3)))               ;;set up an a-list
        !          8233: ((a 1) (b 2) (c 3))
        !          8234: 
        !          8235: 9_(setq foo 'l)                               ;;FOO points to the NAME of the a-list
        !          8236: l
        !          8237: 
        !          8238: 10_(setq bar 'foo)                    ;;BAR points to the NAME of the NAME of
        !          8239: foo                                   ;;the a-list
        !          8240: 
        !          8241: 11_(assoc 'b l)                               ;;This does the right thing
        !          8242: (b 2)
        !          8243: 
        !          8244: 12_(assoc 'b foo)                     ;;Gag me with a mouse -- should err
        !          8245: (b 2)                                 ;;with "bad arg to <something>"
        !          8246: 
        !          8247: 13_(assoc 'b bar)                     ;;Double gag me with a mouse!!
        !          8248: (b 2)
        !          8249: 
        !          8250: ------------------------------------------------------------------------
        !          8251: 
        !          8252: For the record, ASSQ is flawed in the same way.
        !          8253: 
        !          8254: 
        !          8255: Jim Miller
        !          8256: Computer Thought, Dallas
        !          8257: [email protected]
        !          8258: ...!convex!ctvax!jmiller
        !          8259: 
        !          8260: From @MIT-MC:smh@MIT-EMS  Tue Aug 14 07:35:27 1984
        !          8261: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8262:        id AA14507; Tue, 14 Aug 84 07:35:27 pdt
        !          8263: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8264:        id AA26447; Tue, 14 Aug 84 07:36:36 pdt
        !          8265: Message-Id: <[email protected]>
        !          8266: Date: 14 Aug 1984 08:40:00-EDT
        !          8267: From: smh@mit-ems@mit-mc
        !          8268: To: ALAN@mit-mc, GSB@mit-mc, JonL.pa@parc-maxc
        !          8269: Subject: (atom VECTOR): franz vs liszt
        !          8270: Cc: franz-friends@BERKELEY
        !          8271: 
        !          8272: Gentlemen, I think we are losing grasp on the original bug report.
        !          8273: This is probably my fault for including a discourse on the philosophy
        !          8274: of hunks (:-) in the bug report.
        !          8275: 
        !          8276: Maclisp ain't gonna change about hunks, and it would be a poor idea for
        !          8277: Franz to change.  Anyway, the bug is with vectors.  In Franz, compiled
        !          8278: and interpreted code disagree whether a vector is an atom.  Certainly
        !          8279: no one can defend this!
        !          8280: 
        !          8281: Maclisp doesn't *have* vectors, does it?
        !          8282: 
        !          8283: Steve Haflich
        !          8284: smh%mit-ems@mit-mc
        !          8285: 
        !          8286: 
        !          8287: From mcgeer  Tue Aug 14 11:03:10 1984
        !          8288: Received: by ucbkim.ARPA (4.24/4.27)
        !          8289:        id AA17397; Tue, 14 Aug 84 11:03:10 pdt
        !          8290: Date: Tue, 14 Aug 84 11:03:10 pdt
        !          8291: From: Rick McGeer (on an h19-u) <mcgeer>
        !          8292: Message-Id: <[email protected]>
        !          8293: Phone: (415) 236-8262
        !          8294: To: ALAN@MIT-MC, JonL.pa@XEROX
        !          8295: Subject: Re:  (atom VECTOR): franz vs liszt
        !          8296: Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC
        !          8297: In-Reply-To: Your message of 13 August 1984 20:08-EDT
        !          8298: 
        !          8299:        The predicate atom in Franz appears to be:
        !          8300:        
        !          8301: (defun atom(foo)
        !          8302:    (if foo
        !          8303:       then (not (or (hunkp foo) (dtpr foo)))
        !          8304:       else t))
        !          8305: 
        !          8306: whereas a more natural implementation, it seems to me, is:
        !          8307: 
        !          8308: (defun atom(foo)
        !          8309:    (or (symbolp foo) (numberp foo)))
        !          8310: 
        !          8311: Since it seems to me that:
        !          8312: 
        !          8313: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))
        !          8314: 
        !          8315: should always be non-nil for non-nil objects.  Or, better put, that vectors,
        !          8316: hunks, dtprs, atoms, and arrays should partition the data space.  No?
        !          8317: 
        !          8318:                                        Rick.
        !          8319: 
        !          8320: 
        !          8321: 
        !          8322: From mcgeer  Tue Aug 14 11:53:28 1984
        !          8323: Received: by ucbkim.ARPA (4.24/4.27)
        !          8324:        id AA18832; Tue, 14 Aug 84 11:53:28 pdt
        !          8325: Date: Tue, 14 Aug 84 11:53:28 pdt
        !          8326: From: Rick McGeer (on an h19-u) <mcgeer>
        !          8327: Message-Id: <[email protected]>
        !          8328: Phone: (415) 236-8262
        !          8329: To: jmiller%[email protected], franz-friends
        !          8330: Subject: Re: bug in assoc
        !          8331: Cc: 
        !          8332: In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST
        !          8333: 
        !          8334:        "'Curiouser and curiouser', said Alice".  I dug out the source for
        !          8335: assoc (38.79), and here it is:
        !          8336: 
        !          8337: (def assoc
        !          8338:   (lambda (val alist)
        !          8339:          (do ((al alist (cdr al)))
        !          8340:              ((null al) nil)
        !          8341:              (cond ((null (car al)))
        !          8342:                    ((not (dtpr (car al)))
        !          8343:                     (error "bad arg to assoc" al))
        !          8344:                    ((equal val (caar al)) (return (car al)))))))
        !          8345: 
        !          8346: So nothing particularly screwy is going on here.  However, when I do the
        !          8347: traces (after setting up stuff the way you did), I get:
        !          8348: => (assoc 'b 'l)
        !          8349: 1 <Enter> assoc (b l)
        !          8350: 1 <EXIT>  assoc  (b 2)
        !          8351: (b 2)
        !          8352: => (assoc 'b ''l)
        !          8353: 1 <Enter> assoc (b 'l)
        !          8354: Error: bad arg to assoc (quote l) 
        !          8355: Form: (assoc 'b ''l)
        !          8356: {1} bar
        !          8357: foo
        !          8358: {1} (assoc 'b 'foo)
        !          8359: |2 <Enter> assoc (b foo)
        !          8360: |2 <EXIT>  assoc  (b 2)
        !          8361: (b 2)
        !          8362: {1} foo
        !          8363: l
        !          8364: {1} bar
        !          8365: foo
        !          8366: {1} (assoc 'b bar)
        !          8367: |2 <Enter> assoc (b foo)
        !          8368: |2 <EXIT>  assoc  (b 2)
        !          8369: (b 2)
        !          8370: {1} (assoc 'b ''l)
        !          8371: |2 <Enter> assoc (b 'l)
        !          8372: Error: bad arg to assoc (quote l) 
        !          8373: Form: (assoc 'b ''l)
        !          8374: {2}
        !          8375: 
        !          8376: Which is certainly *very* odd...
        !          8377: 
        !          8378: 
        !          8379: From mcgeer  Tue Aug 14 12:06:20 1984
        !          8380: Received: by ucbkim.ARPA (4.24/4.27)
        !          8381:        id AA19018; Tue, 14 Aug 84 12:06:20 pdt
        !          8382: Date: Tue, 14 Aug 84 12:06:20 pdt
        !          8383: From: Rick McGeer (on an h19-u) <mcgeer>
        !          8384: Message-Id: <[email protected]>
        !          8385: Phone: (415) 236-8262
        !          8386: To: ALAN@MIT-MC, JonL.pa@XEROX
        !          8387: Subject: Re:  (atom VECTOR): franz vs liszt
        !          8388: Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC
        !          8389: 
        !          8390:        Sorry to anyone who's getting this twice: I can't figure out from
        !          8391: the mailer error message who got it and who didn't...
        !          8392: 
        !          8393: 
        !          8394:        The predicate atom in Franz appears to be:
        !          8395:        
        !          8396: (defun atom(foo)
        !          8397:    (if foo
        !          8398:       then (not (or (hunkp foo) (dtpr foo)))
        !          8399:       else t))
        !          8400: 
        !          8401: whereas a more natural implementation, it seems to me, is:
        !          8402: 
        !          8403: (defun atom(foo)
        !          8404:    (or (symbolp foo) (numberp foo)))
        !          8405: 
        !          8406: Since it seems to me that:
        !          8407: 
        !          8408: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))
        !          8409: 
        !          8410: should always be non-nil for non-nil objects.  Or, better put, that vectors,
        !          8411: hunks, dtprs, atoms, and arrays should partition the data space.  No?
        !          8412: 
        !          8413:                                        Rick.
        !          8414: 
        !          8415: 
        !          8416: 
        !          8417: 
        !          8418: 
        !          8419: 
        !          8420: From PSZ@MIT-MC  Tue Aug 14 13:53:19 1984
        !          8421: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8422:        id AA20310; Tue, 14 Aug 84 13:53:19 pdt
        !          8423: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8424:        id AA03508; Tue, 14 Aug 84 13:54:23 pdt
        !          8425: Message-Id: <[email protected]>
        !          8426: Date: 14 August 1984 16:37-EDT
        !          8427: From: Peter Szolovits <PSZ@MIT-MC>
        !          8428: Subject:  on the issue of the "ATOMness" of hunks
        !          8429: To: ALAN@MIT-MC
        !          8430: Cc: GSB@MIT-MC, PSZ@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY, smh@MIT-EMS
        !          8431: In-Reply-To: Msg of 13 Aug 1984 20:08-EDT from Alan Bawden <ALAN>
        !          8432: 
        !          8433: I have a small quarrel with Alan Bawden's statement that "hunks never
        !          8434: being atoms in Maclisp" is a universally-agreed bug.  There are indeed
        !          8435: useful structures that one would like to build in Lisp that act as CONS
        !          8436: cells (i.e., CAR and CDR are applicable), but that can have further
        !          8437: structure.  I have sorely missed such objects in Lisp Machine Lisp and
        !          8438: NIL, where flavor-instances are always atomic, when I wanted to build
        !          8439: Brand X (interned "list structure" and universal property lists).  In
        !          8440: Maclisp, I could do this using hunks, though even that was not
        !          8441: completely right because I wanted to be able to disallow RPLACA and
        !          8442: RPLACD while allowing CAR and CDR, and this was hard, given the hunk
        !          8443: abstraction.  I would, however, love to have non-atomic flavor-instances 
        !          8444: 
        !          8445: 
        !          8446: From @MIT-MC:smh@MIT-EMS  Tue Aug 14 14:28:47 1984
        !          8447: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8448:        id AA20792; Tue, 14 Aug 84 14:28:47 pdt
        !          8449: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8450:        id AA04288; Tue, 14 Aug 84 14:29:41 pdt
        !          8451: Message-Id: <[email protected]>
        !          8452: Date: 14 Aug 1984 17:13:29-EDT
        !          8453: From: smh@mit-ems@mit-mc
        !          8454: To: mcgeer@ucbkim@BERKELEY
        !          8455: Subject: Re: bug in assoc
        !          8456: Cc: franz-friends@BERKELEY, [email protected]@udel-relay@mit-mc
        !          8457: 
        !          8458: As McGeer@ucbkim points out, the code for assoc is (in common0.l):
        !          8459: 
        !          8460: (def assoc
        !          8461:   (lambda (val alist)
        !          8462:          (do ((al alist (cdr al)))
        !          8463:              ((null al) nil)
        !          8464:              (cond ((null (car al)))
        !          8465:                    ((not (dtpr (car al)))
        !          8466:                     (error "bad arg to assoc" al))
        !          8467:                    ((equal val (caar al)) (return (car al)))))))
        !          8468: 
        !          8469: The reason for the reported strange behavior of assoc is as simple as
        !          8470: it is obscure!  First a couple hints:
        !          8471:  - This code is inside the executable franz interpreter and therefore
        !          8472:    runs compiled.
        !          8473:  - The same strangeness is exhibited by assq, which is C-coded inside
        !          8474:    the Franz kernel.
        !          8475:  - Both the cdr of a dtpr and the value of an atom are stored at offset
        !          8476:    zero within their respective structures.  The car and plist
        !          8477:    similarly share the same offset within their structures.
        !          8478:  - If you try to run the above assoc definition interpreted, it will
        !          8479:    properly fail to work, or rather, it will complain about a bad arg
        !          8480:    to car.
        !          8481:  - Of course, c[ad]r in the interpreter carfully check their arguments;
        !          8482:    In the compiler, they simple indirect through pointers for maximum
        !          8483:    speed.
        !          8484: 
        !          8485: Finally, in case by now it isn't absolutely clear to everyone what is
        !          8486: going on, assoc is (sort of) comparing val against the plist of bar and
        !          8487: subsequently foo, and then each time automagically effectively doing a
        !          8488: symeval on the atom to continue scanning down the "cdr" of the alist.
        !          8489: 
        !          8490: Moral:  Although the interpreter tries pretty hard to do the dynamic
        !          8491: typing and implied typechecking for which lisp is famous, type checking
        !          8492: in compiled code is often a myth.  Correct code only necessarily works
        !          8493: correctly when given corrent arguments.
        !          8494: 
        !          8495: Steve Haflich
        !          8496: MIT Experimental Music Studio
        !          8497: smh%mit-ems@mit-mc
        !          8498: {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh
        !          8499: 
        !          8500: 
        !          8501: From [email protected]  Wed Aug 15 16:33:44 1984
        !          8502: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8503:        id AA00784; Wed, 15 Aug 84 16:33:44 pdt
        !          8504: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8505:        id AA05115; Wed, 15 Aug 84 14:20:30 pdt
        !          8506: Message-Id: <[email protected]>
        !          8507: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 14:19:35 PDT
        !          8508: Date: 15 Aug 84 14:18 PDT
        !          8509: From: [email protected]
        !          8510: Subject: Re: (atom VECTOR): franz vs liszt
        !          8511: In-Reply-To: Alan Bawden <[email protected]>'s message of 13 Aug 84 20:08
        !          8512:  EDT
        !          8513: To: [email protected]
        !          8514: Cc: [email protected], [email protected], franz-friends@BERKELEY,
        !          8515:         [email protected]
        !          8516: 
        !          8517: [Ah, confusion with Interlisp here].  
        !          8518: 
        !          8519: I meant to say "The resolution was some awful switch setting for whether
        !          8520: or not to treat them as LISTs" rather than "to treat them as ATOMs".
        !          8521: The switch name is HUNKP.
        !          8522: 
        !          8523: Interlisp's ATOM predicate is defined simply as (NOT (LISTP x)), and
        !          8524: LISTP is true only of cons cells [thus (LISTP NIL) is false].
        !          8525: 
        !          8526: -- JonL --
        !          8527: 
        !          8528: 
        !          8529: 
        !          8530: From [email protected]  Wed Aug 15 18:21:08 1984
        !          8531: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8532:        id AA02292; Wed, 15 Aug 84 18:21:08 pdt
        !          8533: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8534:        id AA09647; Wed, 15 Aug 84 18:21:57 pdt
        !          8535: Message-Id: <[email protected]>
        !          8536: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT
        !          8537: Date: 15 Aug 84 18:18 PDT
        !          8538: From: [email protected]
        !          8539: Subject: Re: bug in assoc
        !          8540: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29
        !          8541:  EDT
        !          8542: To: "smh@mit-ems"@MIT-MC.ARPA
        !          8543: Cc: "mcgeer@ucbkim"@BERKELEY, franz-friends@BERKELEY,
        !          8544:         "[email protected]@udel-relay"@MIT-MC.ARPA, [email protected]
        !          8545: 
        !          8546: Common Lisp also faces the possibility of inconsistent system code due
        !          8547: to the handling of cases marked "is an error" (see Manual, sec. 1.2.4);
        !          8548: that is, it is undefined as to what happens if you apply CAR to a
        !          8549: non-LISTP.  All portable system code should therefore certify the type
        !          8550: of a datum before taking car or cdr.  ASSOC (and ASSQ) from the Franz
        !          8551: sources clearly doesn't check the type of the arguments before carcdring
        !          8552: away on them.
        !          8553: 
        !          8554: Well, why not "all system code should certify the type before taking
        !          8555: car/cdr . . . " -- it certainly can't hurt to "signal an error" rather
        !          8556: than fall into some undefined morass.
        !          8557: 
        !          8558: -- JonL --
        !          8559: 
        !          8560: 
        !          8561: From [email protected]  Wed Aug 15 19:49:22 1984
        !          8562: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8563:        id AA02844; Wed, 15 Aug 84 19:49:22 pdt
        !          8564: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8565:        id AA10989; Wed, 15 Aug 84 19:50:13 pdt
        !          8566: Message-Id: <[email protected]>
        !          8567: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 19:48:41 PDT
        !          8568: Date: 15 Aug 84 15:00 PDT
        !          8569: From: [email protected]
        !          8570: Subject: Re: (atom VECTOR): franz vs liszt
        !          8571: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 08:40:00
        !          8572:  EDT
        !          8573: To: "smh@mit-ems"@MIT-MC.ARPA
        !          8574: Cc: [email protected], [email protected], [email protected],
        !          8575:         franz-friends@BERKELEY
        !          8576: 
        !          8577: MacLisp indeed does have VECTORs, STRINGs, CLASSes, etc. in an extended
        !          8578: SmallTalk-like hierarchy, but they are not in the initial system.  Some
        !          8579: of these used to have autoload properties, but I'm not sure about the
        !          8580: state of things now.  None of the extended stuff got documented in the
        !          8581: 1983 MacLisp manual, mostly because of Pitman's personal preferences for
        !          8582: not using the extended stuff.
        !          8583: 
        !          8584: HUNKs are relevant, because the extended heirarchy uses the USRHUNK
        !          8585: feature in order to cause system functions to "trap out" on hunks,
        !          8586: thereby viewing them in an object-oriented way rather than as lists
        !          8587: (Glaaaag!) or as mere simple vectors.
        !          8588: 
        !          8589: -- JonL --
        !          8590: 
        !          8591: 
        !          8592: 
        !          8593: From MLY@MIT-MC  Wed Aug 15 22:49:17 1984
        !          8594: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8595:        id AA04730; Wed, 15 Aug 84 22:49:17 pdt
        !          8596: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8597:        id AA13406; Wed, 15 Aug 84 22:49:59 pdt
        !          8598: Message-Id: <[email protected]>
        !          8599: Date: 16 August 1984 01:49-EDT
        !          8600: From: Richard Mlynarik <MLY@MIT-MC>
        !          8601: Subject:  on the issue of the "ATOMness" of hunks
        !          8602: To: PSZ@MIT-MC
        !          8603: Cc: ALAN@MIT-MC, GSB@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY,
        !          8604:         smh@MIT-EMS
        !          8605: In-Reply-To: Msg of 14 Aug 1984 16:37-EDT from Peter Szolovits <PSZ>
        !          8606: 
        !          8607:     From: Peter Szolovits <PSZ>
        !          8608: 
        !          8609:     I have a small quarrel with Alan Bawden's statement that "hunks never
        !          8610:     being atoms in Maclisp" is a universally-agreed bug.  There are indeed
        !          8611:     useful structures that one would like to build in Lisp that act as CONS
        !          8612:     cells (i.e., CAR and CDR are applicable), but that can have further
        !          8613:     structure.  I have sorely missed such objects in Lisp Machine Lisp and
        !          8614:     NIL, where flavor-instances are always atomic, when I wanted to build
        !          8615:     Brand X (interned "list structure" and universal property lists).  In
        !          8616:     Maclisp, I could do this using hunks, though even that was not
        !          8617:     completely right because I wanted to be able to disallow RPLACA and
        !          8618:     RPLACD while allowing CAR and CDR, and this was hard, given the hunk
        !          8619:     abstraction.  I would, however, love to have non-atomic flavor-instances 
        !          8620: 
        !          8621: The MIT lisp machine system makes some attempt to "support" this sort
        !          8622: of thing, by sending :CAR, :CDR, etc messages to instances. The result
        !          8623: is that you get an error about an unclaimed message, rather than one
        !          8624: about an attempt to take the car of a non-nil atom. LISTP and CONSP
        !          8625: both still return NIL when applied to an instance. The way to get RPLACA
        !          8626: (or SETF of CAR), etc to not work is simply to not define methods for doing
        !          8627: these operations...
        !          8628: 
        !          8629: Is is not really clear to me what the value of such is, unless you get tired
        !          8630: of typing too many "(SEND"'s.
        !          8631: 
        !          8632: 
        !          8633: From goldfarb%[email protected]  Fri Aug 17 16:44:40 1984
        !          8634: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8635:        id AA00202; Fri, 17 Aug 84 16:44:40 pdt
        !          8636: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8637:        id AA01032; Fri, 17 Aug 84 16:45:24 pdt
        !          8638: Received: From ucf.csnet by csnet-relay;  17 Aug 84 19:26 EDT
        !          8639: Received: by ucf-cs.UUCP (4.12/4.7)
        !          8640:        id AA00852; Fri, 17 Aug 84 15:29:05 edt
        !          8641: Date: Fri, 17 Aug 84 15:29:05 edt
        !          8642: From: Ben Goldfarb <goldfarb%[email protected]>
        !          8643: Message-Id: <[email protected]>
        !          8644: To: franz-friends@BERKELEY
        !          8645: Subject: ChangeLog
        !          8646: 
        !          8647: The ReadMe file in /usr/src/cmd/ucb/lisp states that there are ChangeLog
        !          8648: files in the subdirectories franz and liszt.  We got no such files on
        !          8649: our distribution tape (Berkeley 4.2bsd).  I'd appreciate receiving copies
        !          8650: of these files, along with any other documentation of differences between
        !          8651: the 4.2 version and prior versions of Franz Lisp.  
        !          8652: 
        !          8653: Thanks,
        !          8654: 
        !          8655: Ben Goldfarb
        !          8656: University of Central Florida
        !          8657: uucp: {duke,decvax,princeton}!ucf-cs!goldfarb
        !          8658: ARPA: [email protected]
        !          8659: csnet: goldfarb@ucf
        !          8660: 
        !          8661: From [email protected]  Sun Aug 26 20:48:24 1984
        !          8662: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8663:        id AA11969; Sun, 26 Aug 84 20:48:24 pdt
        !          8664: Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8665:        id AA18166; Sun, 26 Aug 84 20:46:52 pdt
        !          8666: Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
        !          8667:        id AA16455; Sun, 26 Aug 84 23:48:12 edt
        !          8668: Date: Sun, 26 Aug 84 23:45:55 edt
        !          8669: From: [email protected] (Mark Bromley)
        !          8670: Message-Id: <[email protected]>
        !          8671: Received: by CORNELL-GVAX.ARPA (4.30/4.30)
        !          8672:        id AA14288; Sun, 26 Aug 84 23:45:55 edt
        !          8673: To: [email protected]
        !          8674: Subject: Bug in open coding of vseti in Liszt 8.36
        !          8675: 
        !          8676: 
        !          8677: If (vseti vector index expression) gets open coded by the compiler,
        !          8678: the resulting value is the value of index, not the value of expression.
        !          8679: This also holds for vseti-byte and vseti-word.
        !          8680: 
        !          8681: The problem is in d_vset in vector.l.  The code which builds the return
        !          8682: value for immediate vectors assumes that the value of expression is in
        !          8683: index-reg, but it never gets put there.
        !          8684: 
        !          8685: One solution would be to change the lines
        !          8686: 
        !          8687:          (if g-loc
        !          8688:              then  (if (eq type 'byte)
        !          8689: 
        !          8690: (occuring about 3/4 of the way through d_vset) to
        !          8691:          (if g-loc
        !          8692:              then (setq temp (cadr (assq type '((byte cvtbl)
        !          8693:                                                 (word cvtwl)
        !          8694:                                                 (long movl)))))
        !          8695:                   (e-write3 temp vect-val index-reg)
        !          8696: 
        !          8697:                   (if (eq type 'byte)
        !          8698: 
        !          8699: Mark Bromley
        !          8700: bromley@cornell
        !          8701: 
        !          8702: 
        !          8703: From forwarder@UWVAX  Mon Aug 27 14:25:15 1984
        !          8704: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8705:        id AA19881; Mon, 27 Aug 84 14:25:15 pdt
        !          8706: Received: from wisc-rsch.arpa (wisc-rsch.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8707:        id AA05251; Mon, 27 Aug 84 14:23:30 pdt
        !          8708: Date: Mon, 27 Aug 84 16:26:07 cdt
        !          8709: Message-Id: <[email protected]>
        !          8710: Received: by wisc-rsch.arpa; Mon, 27 Aug 84 16:26:07 cdt
        !          8711: To: franz-friends@BERKELEY
        !          8712: Subject: FRANZ to VI and back
        !          8713: Cc: [email protected]
        !          8714: Sender: forwarder@UWVAX
        !          8715: From: [email protected]
        !          8716: 
        !          8717: Escuse me if this is a simple question, but i am a Unix novice.
        !          8718: What is the best way to go between VI & Franz when debugging a
        !          8719: program?  The way I currently do it is to ctrl-Z out of Franz,
        !          8720: FG to my VI process, correct my code, FG back to FRANZ, load the
        !          8721: corrected code.  Is there a better way (do not tell me about
        !          8722: Emacs because that is not an option)?
        !          8723: -thanks, david
        !          8724: 
        !          8725: From rad@mitre-bedford  Mon Aug 27 14:52:55 1984
        !          8726: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8727:        id AA20435; Mon, 27 Aug 84 14:52:55 pdt
        !          8728: Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8729:        id AA05840; Mon, 27 Aug 84 14:51:11 pdt
        !          8730: Message-Id: <[email protected]>
        !          8731: Date: Monday, 27 Aug 1984 17:45-EDT
        !          8732: From: rad@Mitre-Bedford
        !          8733: To: [email protected]
        !          8734: Cc: franz-friends@BERKELEY, [email protected]
        !          8735: Subject: Re: FRANZ to VI and back
        !          8736: In-Reply-To: Your message of Monday, 27 Aug 1984 17:26-EDT.
        !          8737:              <[email protected]>
        !          8738: 
        !          8739: 
        !          8740: >>Escuse me if this is a simple question, but i am a Unix novice.
        !          8741: >>What is the best way to go between VI & Franz when debugging a
        !          8742: >>program?  The way I currently do it is to ctrl-Z out of Franz,
        !          8743: >>FG to my VI process, correct my code, FG back to FRANZ, load the
        !          8744: >>corrected code.  Is there a better way (do not tell me about
        !          8745: >>Emacs because that is not an option)?
        !          8746: 
        !          8747: It's undocumented in the franz opus 37 manual, but may be in the opus
        !          8748: 38:  In franz, type (vi foo) and lisp will spin up vi.  If it can't
        !          8749: find the file foo, it tries for foo.l before creating a new file.  If
        !          8750: you invoke it as (vil foo), it will load foo back in after you exit
        !          8751: from vi.  There are similar functions called ex and exl.  
        !          8752: 
        !          8753: If you're using BSD4.2, you probably have opus 38.  A new book is out
        !          8754: called Lispcraft.  It is based on franz, opus 38 in particular.  You
        !          8755: might want to pick that up.  The old standby, Lisp, by Winston and
        !          8756: Horn, documented Maclisp which is close to franz.  Their new, 2nd
        !          8757: edition is based on Common Lisp, however, which is different, so watch 
        !          8758: out!
        !          8759: 
        !          8760: If you don't like ex or vi (say you're an ed-masochist), there are hooks
        !          8761: for other editors.  Put the following in the .lisprc file in your home
        !          8762: directory:
        !          8763: 
        !          8764: (def ed (nlambda (x)
        !          8765:                   (exvi 'ed x nil)))
        !          8766: (def edl (nlambda (x)
        !          8767:                    (exvi 'ed x t)))
        !          8768: 
        !          8769: These will give you the same function as ex/vi and exl/vil except
        !          8770: using ed.  These functions are found in /usr/lib/lisp/auxfns0.l (opus
        !          8771: 37, anyway).
        !          8772: 
        !          8773: Dick Dramstad
        !          8774: rad@mitre-bedford
        !          8775: 
        !          8776: 
        !          8777: From liz@maryland  Tue Aug 28 10:17:28 1984
        !          8778: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8779:        id AA28395; Tue, 28 Aug 84 10:17:28 pdt
        !          8780: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8781:        id AA24861; Tue, 28 Aug 84 10:15:46 pdt
        !          8782: Received: by maryland.ARPA (4.12/4.7)
        !          8783:        id AA20274; Tue, 28 Aug 84 10:59:06 edt
        !          8784: Date: Tue, 28 Aug 84 10:59:06 edt
        !          8785: From: liz@maryland (Liz Allen)
        !          8786: Message-Id: <[email protected]>
        !          8787: To: [email protected], rad@Mitre-Bedford
        !          8788: Subject: Re: FRANZ to VI and back
        !          8789: Cc: franz-friends@BERKELEY
        !          8790: 
        !          8791: One feature of our vi functions is to ask (after returning from vi)
        !          8792: whether or not you want to load the file.  This gives you the freedom
        !          8793: to decide later when you know if you modified the file.  To implement
        !          8794: this, you could change the last line of exvi from:
        !          8795: 
        !          8796:        (cond (doload (load edit_file)))
        !          8797: 
        !          8798: to:
        !          8799: 
        !          8800:        (cond ((or doload (query "Load " edit_file "? "))
        !          8801:               (load edit_file)))
        !          8802: 
        !          8803: and define query:
        !          8804: 
        !          8805:        (defmacro (&rest prompt)
        !          8806:          `(progn (msg ,@prompt) (yesp (read))))
        !          8807: 
        !          8808: (or something like that).  Exvi is defined in common1.l.
        !          8809: 
        !          8810: Enjoy!
        !          8811: 
        !          8812:                                -Liz
        !          8813: 
        !          8814: PS  You could also send me mail asking about getting our software!
        !          8815: 
        !          8816: 
        !          8817: From @MIT-MC:[email protected]  Wed Aug 29 08:09:14 1984
        !          8818: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8819:        id AA09035; Wed, 29 Aug 84 08:09:14 pdt
        !          8820: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8821:        id AA15198; Wed, 29 Aug 84 08:09:05 pdt
        !          8822: Message-Id: <[email protected]>
        !          8823: Date: 29 Aug 1984 11:06:09-EDT
        !          8824: From: Ingemar.Hulthage@CMU-RI-ISL2
        !          8825: Subject: Vector algebra
        !          8826: Apparently-To: <franz-friends@UCB-VAX>
        !          8827: 
        !          8828: 
        !          8829: I am writing a package of functions for vector algebra in arbitrary (finite)
        !          8830: dimensions and it occured to me that I ought to post a message to find
        !          8831: out if something like this is alredy available. 
        !          8832: 
        !          8833: I am looking forward to the replies
        !          8834: 
        !          8835: 
        !          8836: From @MIT-MC:[email protected]  Fri Aug 31 10:16:03 1984
        !          8837: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8838:        id AA04497; Fri, 31 Aug 84 10:16:03 pdt
        !          8839: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8840:        id AA03527; Fri, 31 Aug 84 10:15:41 pdt
        !          8841: Message-Id: <[email protected]>
        !          8842: Date: 31 Aug 1984 13:15:27-EDT
        !          8843: From: Ingemar.Hulthage@CMU-RI-ISL2
        !          8844: Subject: matrix inversion
        !          8845: Apparently-To: <franz-friends@UCB-VAX>
        !          8846: 
        !          8847: 
        !          8848: I need to numerically invert matrices of varying sizes and I would
        !          8849: appreciate pointers to any lisp functions that can do that.
        !          8850: 
        !          8851: 
        !          8852: From mccune@aids-unix  Fri Aug 31 10:42:29 1984
        !          8853: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8854:        id AA05060; Fri, 31 Aug 84 10:42:29 pdt
        !          8855: Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8856:        id AA04133; Fri, 31 Aug 84 10:41:52 pdt
        !          8857: Message-Id: <[email protected]>
        !          8858: Date: 31 Aug 84 10:40:13 PDT (Fri)
        !          8859: From: Brian McCune <mccune@aids-unix>
        !          8860: Subject: Mailing list
        !          8861: To: franz-friends@BERKELEY
        !          8862: 
        !          8863: Please remove my name from franz-friends.  Thanks.  
        !          8864: 
        !          8865:        Brian McCune
        !          8866:        MCCUNE@AIDS-UNIX
        !          8867: 
        !          8868: From ucsbcsl!dave@engrvax  Tue Sep  4 11:22:20 1984
        !          8869: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8870:        id AA10583; Tue, 4 Sep 84 11:22:20 pdt
        !          8871: Received: by UCB-VAX.ARPA (4.24/4.33)
        !          8872:        id AA26490; Tue, 4 Sep 84 11:22:10 pdt
        !          8873: From: ucsbcsl!dave@engrvax
        !          8874: Received: from engrvax.UCSB (engrvax.ARPA) by ucsbcsl.UCSB (4.12/3.14.ucsb)
        !          8875:        id AA27209; Tue, 4 Sep 84 10:55:08 pdt
        !          8876: Date: Tue, 4 Sep 84 10:55:52 pdt
        !          8877: Message-Id: <[email protected]>
        !          8878: Received: by engrvax.UCSB (4.12/3.14.ucsb)
        !          8879:        id AA20764; Tue, 4 Sep 84 10:55:52 pdt
        !          8880: To: franz-friends@BERKELEY
        !          8881: Subject: I have moved.
        !          8882: 
        !          8883: Please change my mailing address to be 'ucsbcsl!chi!dave' from 'ucsbcsl!dave'.
        !          8884: Thanks.
        !          8885: 
        !          8886: From liz@maryland  Wed Sep  5 08:34:45 1984
        !          8887: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          8888:        id AA19892; Wed, 5 Sep 84 08:34:45 pdt
        !          8889: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          8890:        id AA14415; Wed, 5 Sep 84 08:34:27 pdt
        !          8891: Received: by maryland.ARPA (4.12/4.7)
        !          8892:        id AA09320; Wed, 5 Sep 84 11:33:56 edt
        !          8893: Date: Wed, 5 Sep 84 11:33:56 edt
        !          8894: From: liz@maryland (Liz Allen)
        !          8895: Message-Id: <[email protected]>
        !          8896: To: franz-friends@BERKELEY
        !          8897: Subject: Maryland software
        !          8898: 
        !          8899: I'm mailing the announcement here again since a few things have
        !          8900: changed since I last sent it out here and I have had requests for
        !          8901: it.  Currently, we are completing the 4.2 switchover and will
        !          8902: (hopefully) be starting to distribute it by the end of September.
        !          8903: 
        !          8904:                                -Liz Allen
        !          8905: 
        !          8906: -----------------------------------------------------------------
        !          8907: 
        !          8908: Greetings:
        !          8909: 
        !          8910: 
        !          8911:      This is to announce the availability of the Univ of Maryland
        !          8912: software distribution.  This includes source code for the follow-
        !          8913: ing packages which are currently running on a  VAX  11/780  under
        !          8914: Berkeley UNIX(tm) 4.1:
        !          8915: 
        !          8916: (1)  The flavors package written in Franz Lisp.  This package has
        !          8917:      been used successfully in a number of large systems at Mary-
        !          8918:      land, and while it does not implement all  the  features  of
        !          8919:      Lisp  Machine  Flavors, the features present are as close to
        !          8920:      the Lisp Machine version as possible within the  constraints
        !          8921:      of  Franz  Lisp.   (Note that Maryland flavors code *can* be
        !          8922:      compiled.)
        !          8923: 
        !          8924: (2)  Other Maryland Franz hacks including the INTERLISP-like  top
        !          8925:      level,  the  lispbreak error handling package, the for macro
        !          8926:      and the new loader package.
        !          8927: 
        !          8928: (3)  The YAPS production system written in Franz Lisp.   This  is
        !          8929:      similar  to  OPS5  but  more  flexible  in the kinds of lisp
        !          8930:      expressions that may appear as facts and patterns  (sublists
        !          8931:      are  allowed and flavor objects are treated atomically), the
        !          8932:      variety of tests that may appear in the left hand  sides  of
        !          8933:      rules  and the kinds of actions may appear in the right hand
        !          8934:      sides of rules.  In  addition,  YAPS  allows  multiple  data
        !          8935:      bases which are flavor objects and may be sent messages such
        !          8936:      as "fact" and "goal".
        !          8937: 
        !          8938: (4)  The windows package in the form of  a  C  loadable  library.
        !          8939:      This flexible package allows convenient management of multi-
        !          8940:      ple contexts on the screen and runs  on  ordinary  character
        !          8941:      display  terminals as well as bit-mapped displays.  Included
        !          8942:      is a Franz lisp interface to the window  library,  a  window
        !          8943:      shell  for  executing shell processes in windows, and a menu
        !          8944:      package (also a C loadable library).
        !          8945: 
        !          8946: (5)  The phone program.  This is a facility to allow two or  more
        !          8947:      users  to type messages to each other in separate windows on
        !          8948:      a tty screen.  It uses the Maryland window package and CMU's
        !          8949:      IPC facility.
        !          8950: 
        !          8951: (6)  The calend program, an appointment calendar maintainer.   It
        !          8952:      uses a user file of reminding messages and dates for remind-
        !          8953:      ing, and can notify a user by messages printed to his termi-
        !          8954:      nal,  sending them mail, or nagging them to get off the ter-
        !          8955:      minal at a certain time of day.  It  allows  one-time  only,
        !          8956:      weekly,  biweekly, monthly, yearly and other similar methods
        !          8957:      for being reminded.
        !          8958: 
        !          8959: (7)  The bbd program, a multiple bulletin  board  system  loosely
        !          8960:      based  on the 'msgs' program.  It accepts character-oriented
        !          8961:      commands and allows user-definable bulletin-boards.
        !          8962: 
        !          8963: (8)  Rzasm, a relocating Z80 cross-assembler.  Running on the vax
        !          8964:      it  puts  out  ld-style object files.  Its features include,
        !          8965:      among others: free-form input;  (very)  long  variable/label
        !          8966:      names;  conditional assembly; macros (in 'm4' format); digit
        !          8967:      labels; global, external, common and local  common  declara-
        !          8968:      tions; data and text segments; support of the "undocumented"
        !          8969:      Z80 instructions (that work on high and  low  bytes  of  the
        !          8970:      index registers separately); expressions using C syntax; and
        !          8971:      string constants.
        !          8972: 
        !          8973: (9)  Zrun, a z80 microprocessor simulator.   Zrun  simulates  the
        !          8974:      execution  of  a  z80 with 64k RAM, as directed by user com-
        !          8975:      mands.  In addition to the essential commands that cause  an
        !          8976:      rzasm  object  program  to be loaded and executed, there are
        !          8977:      commands to examine and set  registers,  flags,  and  memory
        !          8978:      locations,  to  set  a  breakpoint, to single-step through a
        !          8979:      program, to re-direct the  flow  of  data  through  the  z80
        !          8980:      ports, etc.
        !          8981: 
        !          8982: The distribution currently runs under Berkeley Unix 4.1,  but  we
        !          8983: will  be upgrading to 4.2 in early July and the upgrade should be
        !          8984: ready for distribution in September.  At that time, we will begin
        !          8985: to put both the 4.1 and 4.2 sources on the distribution tape.  If
        !          8986: you are running 4.2 or plan to be running 4.2 in the near future,
        !          8987: it  is  probably  worth  your while to wait for it.  Also at that
        !          8988: time, the fee for the distribution will go up from $100 to $250.
        !          8989: 
        !          8990:      We also include Franz Lisp in the distribution since  it  is
        !          8991: easier  to do that than to describe all the small changes that we
        !          8992: have made to the Franz sources.  For  the  4.1  distribution,  we
        !          8993: send  Franz  Opus 38.26.  For the 4.2 distribution, we do not yet
        !          8994: know which Franz we will be mailing, but it will be whichever  we
        !          8995: get with our 4.2 Berkeley Unix.
        !          8996: 
        !          8997: 
        !          8998: How to obtain a tape:
        !          8999: 
        !          9000:      To obtain the Univ of Maryland distribution tape:
        !          9001: 
        !          9002: (1)  Fill in the form below and sign it.  Please indicate whether
        !          9003:      you  want  just  the  4.1 distribution, both the 4.1 and 4.2
        !          9004:      distributions or if you will be obtaining  the  distribution
        !          9005:      via a third party or via the Arpanet.
        !          9006: 
        !          9007: (2)  Make out a check to "University of Maryland Foundation"  for
        !          9008:      $100  (US  dollars) or for $250 (US dollars) if you want the
        !          9009:      4.2 distribution.  Mail the check and form to:
        !          9010: 
        !          9011:                   Liz Allen
        !          9012:                   Univ of Maryland
        !          9013:                   Dept of Computer Science
        !          9014:                   College Park MD 20742
        !          9015: 
        !          9016: 
        !          9017: (3)  If you need an invoice,  send  me  mail.   Don't  forget  to
        !          9018:      include your non-electronic mailing address.
        !          9019: 
        !          9020: Upon receipt of the money, we will mail you a tape containing our
        !          9021: software  and  the technical reports describing the software.  We
        !          9022: will also keep you informed of bug fixes via electronic mail.  We
        !          9023: have  an  electronic  mailing address for this kind of thing.  It
        !          9024: is:
        !          9025: 
        !          9026:          Usenet:      ...!seismo!umcp-cs!um-software
        !          9027:          Arpanet:     um-software@maryland
        !          9028: 
        !          9029: Please note that bug fixes will be done  only  insofar  they  are
        !          9030: consistent  with the research purposes of the University of Mary-
        !          9031: land.
        !          9032: 
        !          9033:      If you have any technical questions, etc, send mail  to  the
        !          9034: above  mailing  list.   If you have any administrative questions,
        !          9035: contact Diane Miller via electronic mail:
        !          9036: 
        !          9037:            Usenet:      ...!seismo!umcp-cs!despina
        !          9038:            Arpanet:     despina@maryland
        !          9039: 
        !          9040: or via phone at (301) 454-4251.
        !          9041: 
        !          9042: 
        !          9043:                          Liz Allen
        !          9044: 
        !          9045:                          Usenet:      ...!seismo!umcp-cs!liz
        !          9046:                          Arpanet:     liz@maryland
        !          9047: 
        !          9048: -----------------------------------------------------------------
        !          9049: 
        !          9050: In exchange for the Maryland software tape, I certify to the fol-
        !          9051: lowing:
        !          9052: 
        !          9053: a.   I will not use any of the Maryland software distribution  in
        !          9054:      a commercial product without obtaining permission from Mary-
        !          9055:      land first.
        !          9056: 
        !          9057: b.   I will keep the Maryland copyright  notices  in  the  source
        !          9058:      code,  and acknowledge the source of the software in any use
        !          9059:      I make of it.
        !          9060: 
        !          9061: c.   I will not redistribute this software to anyone without per-
        !          9062:      mission from Maryland first.
        !          9063: 
        !          9064: d.   I will keep Maryland informed of any bug fixes.
        !          9065: 
        !          9066: e.   I understand that the software I will be receiving has  been
        !          9067:      developed  for  research  purposes  only and may be good for
        !          9068:      absolutely nothing.  The University of  Maryland  offers  no
        !          9069:      warranties of any kind.  Bug fixes will be done only insofar
        !          9070:      they are  consistent  with  the  research  purposes  of  the
        !          9071:      University of Maryland.
        !          9072: 
        !          9073: f.   I am the appropriate person at my  site  who  can  make  the
        !          9074:      guarantees in parts a through e.
        !          9075: 
        !          9076: g.   I would like the package indicated below:
        !          9077: 
        !          9078: 
        !          9079:      ___  4.1 distribution only.  I have  enclosed  a  check  for
        !          9080:           $100.
        !          9081: 
        !          9082: 
        !          9083:      ___  4.1 and 4.2 distribution.  I have enclosed a check  for
        !          9084:           $250.   I  also understand that the 4.2 distribution is
        !          9085:           not yet ready and that there will be a delay  until  at
        !          9086:           least August or September before my tape arrives.
        !          9087: 
        !          9088:      ___  License and technical reports only.  I have enclosed  a
        !          9089:           check  for $100 and will obtain the distribution from a
        !          9090:           site that already has the distribtution or will get  it
        !          9091:           from  Maryland via the Arpanet.  (Please note specifics
        !          9092:           at the bottom of the form.)
        !          9093: 
        !          9094: 
        !          9095: 
        !          9096: 
        !          9097: Signature:                  ______________________________
        !          9098: 
        !          9099: Name:                       ______________________________
        !          9100: 
        !          9101: Position:                   ______________________________
        !          9102: 
        !          9103: Company or Organization:    ______________________________
        !          9104: 
        !          9105: Address:                    ______________________________
        !          9106: 
        !          9107:                             ______________________________
        !          9108: 
        !          9109: Phone number:               ______________________________
        !          9110: 
        !          9111: Electronic mail address:    ______________________________
        !          9112: 
        !          9113: 
        !          9114: From [email protected]  Wed Sep  5 16:11:17 1984
        !          9115: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9116:        id AA25823; Wed, 5 Sep 84 16:11:17 pdt
        !          9117: Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
        !          9118:        id AA21315; Wed, 5 Sep 84 16:10:58 pdt
        !          9119: Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
        !          9120:        id AA15943; Wed, 5 Sep 84 19:11:13 edt
        !          9121: Date: Wed, 5 Sep 84 19:06:27 edt
        !          9122: From: [email protected] (Mark Bromley)
        !          9123: Message-Id: <[email protected]>
        !          9124: Received: by CORNELL-GVAX.ARPA (4.30/4.30)
        !          9125:        id AA19770; Wed, 5 Sep 84 19:06:27 edt
        !          9126: To: franz-friends@BERKELEY
        !          9127: Subject: Bug in open coding of vseti in Liszt 8.36
        !          9128: 
        !          9129: There is a mistake in the open coding of (vseti vector index expression).
        !          9130: When the generated code is executed it returns the value of the index expression
        !          9131: and not the value of expression.  The problem is in d_vset in liszt/vector.l.
        !          9132: The code in d_vset that generates the assembler code to compute the
        !          9133: return value assumes that code has been generated to put the value of
        !          9134: expression in index-reg.  This assumption is false.
        !          9135: 
        !          9136: I don't know the 68000 well enough to suggest a solution for it, but the
        !          9137: following should work for the VAX.  Change the lines
        !          9138: 
        !          9139:          (if g-loc
        !          9140:              then  (if (eq type 'byte)
        !          9141: 
        !          9142: (occuring about 3/4 of the way through d_vset) to
        !          9143: 
        !          9144:          (if g-loc
        !          9145:              then
        !          9146:                 #+for-vax
        !          9147:                 (progn
        !          9148:                      (setq temp (cadr (assq type '((byte cvtbl)
        !          9149:                                                    (word cvtwl)
        !          9150:                                                    (long movl)))))
        !          9151:                       (e-write3 temp vect-val index-reg)
        !          9152:                  )
        !          9153:                  
        !          9154:                  #+for-68k
        !          9155:                  (comment Do the same thing for the 68k)
        !          9156: 
        !          9157:                   (if (eq type 'byte)
        !          9158: 
        !          9159: Also, what is the current Berkeley distribution policy.  I tried ftp'ing
        !          9160: from ucbvax, but the pub/lisp directory there is empty.  I'd like to get my
        !          9161: hands on a distribution that has the flavors package in it.
        !          9162: 
        !          9163: Mark Bromley
        !          9164: bromley@cornell
        !          9165: 
        !          9166: 
        !          9167: 
        !          9168: 
        !          9169: From jkf@ucbmike  Tue Oct 30 12:19:45 1984
        !          9170: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9171:        id AA02909; Tue, 30 Oct 84 12:19:45 pst
        !          9172: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31)
        !          9173:        id AA23363; Tue, 30 Oct 84 11:43:13 pst
        !          9174: Received: by ucbmike.arpa (4.24ucb/4.33)
        !          9175:        id AA04265; Tue, 30 Oct 84 12:43:39 pst
        !          9176: Date: Tue, 30 Oct 84 12:43:39 pst
        !          9177: From: John Foderaro (on a sun) <jkf@ucbmike>
        !          9178: Message-Id: <[email protected]>
        !          9179: To: mrose%[email protected], franz-friends@BERKELEY
        !          9180: Subject: Re: Where is franz-friends-request
        !          9181: In-Reply-To: Your message of 28 Oct 84 10:04:05 EST (Sun)
        !          9182: 
        !          9183:  franz-friends-request@berkeley is valid.  occasionlly the mailer tries
        !          9184:  to look in the alias table while it is being updated.
        !          9185:  
        !          9186: 
        !          9187: 
        !          9188: From liz@tove  Tue Oct 30 13:18:32 1984
        !          9189: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9190:        id AA03406; Tue, 30 Oct 84 13:18:32 pst
        !          9191: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9192:        id AA24224; Tue, 30 Oct 84 12:15:01 pst
        !          9193: Received: by tove.ARPA (4.12/4.7)
        !          9194:        id AA09504; Thu, 25 Oct 84 16:46:39 edt
        !          9195: From: Liz Allen <liz@tove>
        !          9196: Message-Id: <[email protected]>
        !          9197: Date: 25 Oct 1984 1646-EDT (Thursday)
        !          9198: To: Rene Bach <BACH@su-score>
        !          9199: Cc: franz-friends@BERKELEY
        !          9200: Subject: Re: A question
        !          9201: In-Reply-To: Your message of Thu 25 Oct 84 09:31:09-PDT.
        !          9202:              <[email protected]>
        !          9203: 
        !          9204:        From: Rene Bach <BACH%[email protected]>
        !          9205: 
        !          9206:        I am new on this list and haven't seen any other messages.
        !          9207: 
        !          9208: There isn't too much mail here.
        !          9209: 
        !          9210:        Is there a way to find out what are all the atoms which
        !          9211:        have been defined in Franz (a la mapatoms of INterlisp) ??
        !          9212: 
        !          9213: The functions (oblist) returns a list of all the atoms.
        !          9214: 
        !          9215:                                -Liz
        !          9216: 
        !          9217: From neves%[email protected]  Tue Oct 30 14:38:15 1984
        !          9218: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9219:        id AA04963; Tue, 30 Oct 84 14:38:15 pst
        !          9220: Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9221:        id AA27563; Tue, 30 Oct 84 14:36:12 pst
        !          9222: Received: from wisc-ai.uwisc by wisc-crys.arpa; Tue, 30 Oct 84 16:35:00 cst
        !          9223: Date: Tue, 30 Oct 84 16:34:59 cst
        !          9224: From: neves%[email protected] (David Neves)
        !          9225: Message-Id: <[email protected]>
        !          9226: Received: by wisc-ai.uwisc; Tue, 30 Oct 84 16:34:59 cst
        !          9227: To: franz-friends@BERKELEY
        !          9228: Subject: vi/franz question
        !          9229: 
        !          9230: This is a vi/franz question.
        !          9231: I would like to use "=" in VI to indent my lisp code.  When I
        !          9232: type "=" in front of some lisp code I get
        !          9233: No alternate filename to substitute for #0
        !          9234: How do I indent Lisp code (besides using autoindent)?
        !          9235: -Thanks, David
        !          9236: 
        !          9237: From Johnson%[email protected]  Wed Oct 31 05:54:58 1984
        !          9238: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9239:        id AA04156; Wed, 31 Oct 84 05:54:58 pst
        !          9240: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9241:        id AA07029; Wed, 31 Oct 84 05:52:24 pst
        !          9242: Message-Id: <[email protected]>
        !          9243: Received: From udel-dewey.ARPA by udel-relay.ARPA id a018834 ;31 Oct 84 8:55 EST
        !          9244: Date:     Wed, 31 Oct 84 8:47:19 EST
        !          9245: From: johnson <johnson%[email protected]>
        !          9246: To: franz-friends@BERKELEY
        !          9247: Cc: johnson%[email protected]
        !          9248: Subject:  response to lisp/vi question
        !          9249: 
        !          9250: 
        !          9251: in response to:
        !          9252: 
        !          9253: >I would like to use "=" in VI to indent my lisp code.  When I
        !          9254: >type "=" in front of some lisp code I get
        !          9255: >No alternate filename to substitute for #0
        !          9256: >How do I indent Lisp code (besides using autoindent)?
        !          9257: 
        !          9258: 1. When I type "=" in vi (without :set lisp) I get no response at all.
        !          9259:        Is it possible that you defined a macro named "=" ?
        !          9260:        {
        !          9261:                check your ~/.exrc file for a line beginning:
        !          9262:                :map = <something-or-other>
        !          9263:        }
        !          9264: 
        !          9265: 2. Even after:
        !          9266:        :set lisp
        !          9267: 
        !          9268:        A single "=" does not seem to cause the correct action, however,
        !          9269:        two successive "="s do.  
        !          9270: 
        !          9271: to summarize:
        !          9272:        1. remove any mapping of "=" from ~/.exrc
        !          9273:        2. :set lisp
        !          9274:        3. use "==" rather than "="
        !          9275: 
        !          9276: - johnson@udel-ee
        !          9277: 
        !          9278: 
        !          9279: From raf%[email protected]  Wed Oct 31 11:35:57 1984
        !          9280: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9281:        id AA07802; Wed, 31 Oct 84 11:35:57 pst
        !          9282: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9283:        id AA13682; Wed, 31 Oct 84 11:33:13 pst
        !          9284: Received: from bostonu by csnet-relay.csnet id ac00303; 31 Oct 84 14:27 EST
        !          9285: Received: by csvaxa.ARPA (4.12/4.7)
        !          9286:        id AA14678; Wed, 31 Oct 84 13:53:18 est
        !          9287: Date: Wed, 31 Oct 84 13:53:18 est
        !          9288: From: Rafail Ostrovsky <raf%[email protected]>
        !          9289: Message-Id: <[email protected]>
        !          9290: To: FRANZ-FRIENDS%[email protected]
        !          9291: Subject: MAILING LIST
        !          9292: 
        !          9293: Hello.
        !          9294: I would like to subscribe to your mailing list. 
        !          9295: I am a grad. student at Boston U. My address is:
        !          9296: 
        !          9297: raf%[email protected]
        !          9298: 
        !          9299:                Thank you, -Raf
        !          9300: 
        !          9301: From neves%[email protected]  Wed Oct 31 12:40:33 1984
        !          9302: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9303:        id AA09034; Wed, 31 Oct 84 12:40:33 pst
        !          9304: Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9305:        id AA15180; Wed, 31 Oct 84 12:37:38 pst
        !          9306: Received: from wisc-ai.uwisc by wisc-crys.arpa; Wed, 31 Oct 84 14:35:47 cst
        !          9307: Date: Wed, 31 Oct 84 14:35:55 cst
        !          9308: From: neves%[email protected] (David Neves)
        !          9309: Message-Id: <[email protected]>
        !          9310: Received: by wisc-ai.uwisc; Wed, 31 Oct 84 14:35:55 cst
        !          9311: To: franz-friends@BERKELEY
        !          9312: Subject: re: Indenting lisp code in VI
        !          9313: 
        !          9314: Thanks for the response on indenting for Franz.  It seems as though
        !          9315: our systems people do not use Lisp and so have set up everyone's
        !          9316: .exrc file to map = to something else.  Your site might be doing the
        !          9317: same thing to this or other VI/Lisp features!  Stop them now.
        !          9318: 
        !          9319: From @MIT-MC:[email protected]  Wed Oct 31 17:37:36 1984
        !          9320: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9321:        id AA14939; Wed, 31 Oct 84 17:37:36 pst
        !          9322: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9323:        id AA02960; Wed, 31 Oct 84 17:14:37 pst
        !          9324: Message-Id: <[email protected]>
        !          9325: Date: 31 Oct 84 20:08:41 EST
        !          9326: From: Ingemar.Hulthage@CMU-RI-ISL2
        !          9327: Subject: Floating point division
        !          9328: To: BBoard.Maintainer@CMU-CS-A
        !          9329: 
        !          9330: 
        !          9331: Is there a pre-defined  function in Franz Lisp that never uses integer
        !          9332: division when it differs from floating point division ?  Obviously it is easy
        !          9333: to write (quotient (float a) b) or to write a function/macro with the same
        !          9334: effect. However, since Franz does a good job of dealing with different kinds
        !          9335: of numbers in other cases, it is inconvenient and inefficient if such a
        !          9336: function is not available in the system.
        !          9337: 
        !          9338: 
        !          9339: From eng20201%[email protected]  Thu Nov  1 16:02:58 1984
        !          9340: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9341:        id AA05698; Thu, 1 Nov 84 16:02:58 pst
        !          9342: Received: from WISCVM.ARPA (wiscvm.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9343:        id AA08850; Thu, 1 Nov 84 16:00:19 pst
        !          9344: Message-Id: <[email protected]>
        !          9345: Received: from [email protected] by WISCVM.ARPA on 11/01/84 at
        !          9346:    18:00:40 CST
        !          9347: Date:  1-Nov-84   18:58:53 EST
        !          9348: From: John Sutter               <eng20201%[email protected]>
        !          9349: Subject: Pretty typer
        !          9350: To: franz-friends@BERKELEY
        !          9351: Cc: eng20201%[email protected]
        !          9352: 
        !          9353: -----
        !          9354: 
        !          9355:   Does anyone know of a pretty typer for Franz Lisp?..
        !          9356: 
        !          9357:   If you do, please reply to me directly.
        !          9358: 
        !          9359:   Thanks
        !          9360: 
        !          9361:   ----  John
        !          9362: 
        !          9363: -----
        !          9364: 
        !          9365: From holtz%carleton.cdn%[email protected]  Sun Nov  4 14:39:06 1984
        !          9366: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9367:        id AA03203; Sun, 4 Nov 84 14:39:06 pst
        !          9368: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9369:        id AA04466; Sun, 4 Nov 84 14:36:25 pst
        !          9370: Received: from ubc by csnet-relay.csnet id a004399; 4 Nov 84 15:43 EST
        !          9371: Date: Sun, 4 Nov 84 12:37:03 pst
        !          9372: Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
        !          9373: From: Neal Holtz <holtz%carleton.cdn%[email protected]>
        !          9374: To: franz-friends%[email protected]
        !          9375: Mmdf-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
        !          9376: Message-Id: 133:[email protected]
        !          9377: Subject: Franz on Apollos (or, Fritz Kunze, where are you?)
        !          9378: 
        !          9379: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
        !          9380: for that matter) can tell me anything about the possibility of
        !          9381: having Franz run on Apollo workstations (under AEGIS) in the
        !          9382: near future, I would be most appreciative.
        !          9383: 
        !          9384: 
        !          9385: From holtz%carleton.cdn%[email protected]  Sun Nov  4 14:39:20 1984
        !          9386: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9387:        id AA03212; Sun, 4 Nov 84 14:39:20 pst
        !          9388: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9389:        id AA04473; Sun, 4 Nov 84 14:36:37 pst
        !          9390: Received: from ubc by csnet-relay.csnet id a004408; 4 Nov 84 15:45 EST
        !          9391: Date: Sun, 4 Nov 84 12:37:03 pst
        !          9392: Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
        !          9393: From: Neal Holtz <holtz%carleton.cdn%[email protected]>
        !          9394: To: franz-friends%[email protected]
        !          9395: Mmdf-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
        !          9396: Message-Id: 133:[email protected]
        !          9397: Subject: Franz on Apollos (or, Fritz Kunze, where are you?)
        !          9398: 
        !          9399: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
        !          9400: for that matter) can tell me anything about the possibility of
        !          9401: having Franz run on Apollo workstations (under AEGIS) in the
        !          9402: near future, I would be most appreciative.
        !          9403: 
        !          9404: 
        !          9405: From fkunze%ucbopal.CC%[email protected]  Sun Nov  4 23:25:12 1984
        !          9406: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9407:        id AA03125; Sun, 4 Nov 84 23:25:12 pst
        !          9408: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9409:        id AA04781; Sun, 4 Nov 84 23:22:27 pst
        !          9410: Received: from ucb-vax.arpa by csnet-relay.arpa id a006482; 5 Nov 84 2:21 EST
        !          9411: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9412:        id AA04236; Sun, 4 Nov 84 22:58:35 pst
        !          9413: Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
        !          9414:        by ucbjade.CC.Berkeley.ARPA (4.17/4.27.2)
        !          9415:        id AA14292; Sun, 4 Nov 84 22:59:18 pst
        !          9416: Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28)
        !          9417:        id AA03601; Sun, 4 Nov 84 22:59:26 pst
        !          9418: Date: Sun, 4 Nov 84 22:59:26 pst
        !          9419: From: Fritz Kunze <fkunze%ucbopal.CC%[email protected]>
        !          9420: Message-Id: <[email protected]>
        !          9421: To: franz-friends%ucb-vax.arpa%[email protected],
        !          9422:         holtz%carleton.cdn%ubc.csnet%[email protected]
        !          9423: Subject: Re: Franz on Apollos (or, Fritz Kunze, where are you?)
        !          9424: 
        !          9425: We are working on an Apollo port right now. Due to some
        !          9426: non-standard features in the Apollo operating system,
        !          9427: the port is requiring far more time than we originally
        !          9428: anticipated.  We are very close to a working interpreter,
        !          9429: but the compiler will require more time.  Are you interested
        !          9430: in the Interpreter first?
        !          9431: ---Fritz Kunze
        !          9432:    Franz Inc.
        !          9433:    2920 Domingo, suite 203
        !          9434:    Berkeley, CA 94705
        !          9435:    (415) 540-1224
        !          9436: 
        !          9437: 
        !          9438: 
        !          9439: From abrams@mitre  Mon Nov  5 11:41:38 1984
        !          9440: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9441:        id AA08762; Mon, 5 Nov 84 11:41:38 pst
        !          9442: Received: from mitre (mitre.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9443:        id AA06184; Mon, 5 Nov 84 11:38:18 pst
        !          9444: Message-Id: <[email protected]>
        !          9445: Date:  5 Nov 1984 14:17:36 EST (Monday)
        !          9446: From: Marshall Abrams <abrams@mitre>
        !          9447: Subject: Call for papers: Expert Systems Symposium
        !          9448: To: add1:@mitre
        !          9449: Cc: abrams@mitre
        !          9450: 
        !          9451: Call for Papers
        !          9452: 
        !          9453: Expert Systems in Government Conference
        !          9454: 
        !          9455: October 23-25, 1985
        !          9456: 
        !          9457: THE CONFERENCE objective is to allow the developers and implementers
        !          9458: of expert systems in goverenment agencies to exchange information and
        !          9459: ideas first hand for the purpose of improving the quality of
        !          9460: existing and future expert systems in the government sector. 
        !          9461: Artificial Intelligence (AI) has recently been maturing so rapidly
        !          9462: that interest in each of its various facets, e.g., robotics, vision,
        !          9463: natural language, supercomputing, and expert systems, has acquired
        !          9464: an increasing following and cadre of practitioners.
        !          9465: 
        !          9466: PAPERS are solicited which discuss the subject of the conference. 
        !          9467: Original research, analysis and approaches for defining  expert   
        !          9468: systems issues and problems such as those identified in the
        !          9469: anticipated session topics, methodological approaches for analyzing
        !          9470: the scope and nature of expert system issues, and potential
        !          9471: solutions are of particular interest.  Completed papers are to be no
        !          9472: longer than 20 pages including graphics and are due 1 May 1985.
        !          9473: Four copies of papers are to be sent to:
        !          9474: 
        !          9475: Dr. Kamal Karna, Program Chairman
        !          9476: MITRE Corporation W852
        !          9477: 1820 Dolley Madison Boulevard
        !          9478: McLean, Virginia  22102
        !          9479: Phone (703) 883-5866
        !          9480: ARPANET:  Karna @ Mitre
        !          9481: 
        !          9482: Notification of acceptance and manuscript preparation instructions
        !          9483: will be provided by 20 May 1985.
        !          9484: 
        !          9485: THE CONFERENCE is sponsored by the IEEE Computer Society and The
        !          9486: MITRE Corporation in cooperation with The Association for Computing
        !          9487: Machinery, The american Association for Artificial Intelligence and
        !          9488: The American Institute of Aeronautics and Astronautics National
        !          9489: Capital Section.  This conference will offer high quality technical
        !          9490: exchange and published proceedings.
        !          9491: 
        !          9492: It will be held at Tyson's Westpark Hotel, Tysons Corner, McLean,
        !          9493: VA, suburban Washington, D.C.
        !          9494: 
        !          9495: 
        !          9496: TOPICS OF INTEREST
        !          9497: 
        !          9498: The topics of interest include the expert systems in the following
        !          9499: applications domains (but are not limited to):
        !          9500: 
        !          9501:  1.  Professional:           Accounting, Consulting, Engineering,
        !          9502:                              Finance, Instruction, Law, Marketing,
        !          9503:                              Management, Medicine
        !          9504:                              Systems, Intelligent DBMS
        !          9505: 
        !          9506:  2.  Office Automation:      Text Understanding, Intelligent
        !          9507: 
        !          9508:  3.  Command & Control:      Intelligence Analysis, Planning,
        !          9509:                              Targeting, Communications, Air Traffic
        !          9510:                              Control
        !          9511: 
        !          9512:  4.  Exploration:            Space, Prospecting, Mineral, Oil
        !          9513: 
        !          9514:                              Archeology
        !          9515: 
        !          9516:  5.  Weapon Systems:         Adaptive Control, Electronic Warfare,
        !          9517:                              Star Wars, Target Identification
        !          9518: 
        !          9519:  6.  System Engineering:     Requirements, Preliminary Design,
        !          9520:                              Critical Design, Testing, and QA
        !          9521: 
        !          9522:  7.  Equipment:              Design Monitoring, Control, Diagnosis,  
        !          9523:                              Maintenance, Repair, Instruction
        !          9524: 
        !          9525:  8.  Project Management:     Planning, Scheduling, Control
        !          9526: 
        !          9527:  9.  Flexible Automation:    Factory and Plan Automation
        !          9528: 
        !          9529: 10.  Software:               Automatic Programming, Specifications,
        !          9530:                              Design, Production, Maintenance and
        !          9531:                              Verification and Validation
        !          9532: 
        !          9533: 11.  Architecture:           Single, Multiple, Distributed Problem
        !          9534:                              Solving Tools
        !          9535: 
        !          9536: 12.  Imagery:                Photo Interpretation, Mapping, etc.
        !          9537: 
        !          9538: 13.  Education:              Concept Formation, Tutoring, Testing,
        !          9539:                              Diagnosis, Learning
        !          9540: 
        !          9541: 14.  Entertainment and       Intelligent Games, Investment and
        !          9542:      Expert Advice Giving:   Finances, Retirement, Purchasing,
        !          9543:                              Shopping, Intelligent Information
        !          9544:                              Retrieval
        !          9545: 
        !          9546: 
        !          9547: 
        !          9548: From decvax!utzoo!dciem!nrcaero!clan.carleton!holtz  Mon Nov  5 17:32:56 1984
        !          9549: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9550:        id AA14064; Mon, 5 Nov 84 17:32:56 pst
        !          9551: Received: by UCB-VAX.ARPA (4.24/4.39)
        !          9552:        id AA14362; Mon, 5 Nov 84 17:30:11 pst
        !          9553: Return-Path: <decvax!utzoo!dciem!nrcaero!clan.carleton!holtz>
        !          9554: Received: by decvax.UUCP (4.12/1.0)
        !          9555:        id AA28321; Mon, 5 Nov 84 16:46:11 est
        !          9556: Date: Sun, 4 Nov 84 21:23:59 est
        !          9557: From: Neal Holtz <decvax!carleton!clan.carleton!holtz@clan.>
        !          9558: Message-Id: <8411050223.AA07104@clan. UUCP>
        !          9559: Received: by clan. UUCP (4.12/3.14)
        !          9560:        id AA07104; Sun, 4 Nov 84 21:23:59 est
        !          9561: To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends
        !          9562: Subject: Franz on Apollos (or -- Fritz Kunze, where are you?)
        !          9563: 
        !          9564: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
        !          9565: for that matter) can tell me anything about the possibility of
        !          9566: having Franz run on Apollo workstations (under AEGIS) in the
        !          9567: near future, I would be most appreciative.
        !          9568: 
        !          9569: 
        !          9570: 
        !          9571: 
        !          9572: 
        !          9573: 
        !          9574: 
        !          9575: From [email protected]  Tue Nov  6 16:15:33 1984
        !          9576: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9577:        id AA25403; Tue, 6 Nov 84 16:15:33 pst
        !          9578: Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9579:        id AA06061; Tue, 6 Nov 84 16:12:18 pst
        !          9580: Message-Id: <[email protected]>
        !          9581: Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 122057; Tue 6-Nov-84 19:13:41-EST
        !          9582: Date: Tue, 6 Nov 84 19:11 EST
        !          9583: From: Richard Brenner <[email protected]>
        !          9584: Subject: Job Opportunities
        !          9585: To: maple-sys@BERKELEY, symalg%rand-unix.arpa%[email protected],
        !          9586:         franz-friends@BERKELEY
        !          9587: In-Reply-To: The message of 6 Nov 84 15:51-EST from Richard Pavelle <RP at SCRC-TENEX>
        !          9588: 
        !          9589: 
        !          9590: Symbolics, Inc. of Cambridge is the acknowledged leader in the field of
        !          9591: Symbolic Processing, offering the premier LISP-based Symbolic Processor
        !          9592: for advanced problem-solving applications.  We are a fast-growing,
        !          9593: high-tech company with new, modern facilities right in Cambridge. Recent
        !          9594: expansion has created opportunities for the following experienced
        !          9595: professionals:
        !          9596: 
        !          9597: 
        !          9598: Member of Technical Staff
        !          9599: 
        !          9600: You will assist with maintenance and enhancement of MACSYMA, a large
        !          9601: Computer Algebra System written in LISP and used by engineers and
        !          9602: scientists for performing symbolic computations.  Immediate projects
        !          9603: could include design and implementation of tools for conversion to
        !          9604: Common LISP, improving modularity, modernizing the user interface,
        !          9605: improving performance, and design and implementation of new mathematical
        !          9606: packages based on the latest available algorithms.  Work will be
        !          9607: performed on all versions of MACSYMA using Symbolics 3600 Family Lisp
        !          9608: Machines.  A strong background in mathematics and Lisp programming is
        !          9609: preferred.  Experience with MACSYMA is desirable.
        !          9610: 
        !          9611: 
        !          9612: Technical Sales Support Engineer
        !          9613: 
        !          9614: You will provide technical support to our internal sales staff, to
        !          9615: customers and to prospective customers.  Responsibilities include
        !          9616: assistance at demonstration sites, installations on several kinds of
        !          9617: machines, and a full range of customer support activities.  This could
        !          9618: include design, development and delivery of a trainging course for
        !          9619: MACSYMA users.  Qualified applicants will have experience with a
        !          9620: high-level language, preferably MACSYMA.  Good written and verbal
        !          9621: communication skills and prior software project involvement are desired.
        !          9622: B.S. degree or equivalent and 2 years experience preferred.
        !          9623: 
        !          9624: 
        !          9625: Qualified candidates should send their resume,in strict confidence,
        !          9626: including salary history, to Gina Setteducati, Personnel Supervisor,
        !          9627: Symbolics, Inc., 11 Cambridge Center, Cambridge, MA 02142.  An equal
        !          9628: opportunity employer.
        !          9629: 
        !          9630: 
        !          9631: From [email protected]  Wed Nov  7 19:52:19 1984
        !          9632: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9633:        id AA08630; Wed, 7 Nov 84 19:52:19 pst
        !          9634: Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9635:        id AA05368; Wed, 7 Nov 84 18:51:47 pst
        !          9636: Received: by uw-beaver.arpa (4.12/2.2)
        !          9637:        id AA00936; Wed, 7 Nov 84 17:50:03 pst
        !          9638: Return-Path: <ssc-vax!steve>
        !          9639: Received: by ssc-vax (4.12/4.7)
        !          9640:        id AA06915; Wed, 7 Nov 84 17:24:40 pst
        !          9641: Date: Wed, 7 Nov 84 17:24:40 pst
        !          9642: From: [email protected] (Steve White)
        !          9643: Message-Id: <8411080124.AA06915@ssc-vax>
        !          9644: To: uw-beaver!franz-friends@BERKELEY
        !          9645: Subject: readtable within fasl
        !          9646: 
        !          9647: 
        !          9648: In "fasl.c" before the literals are read back out of the object file,
        !          9649: the readtable is rebound to the 'standard-readtable'. This short-circuits
        !          9650: any type of character macro expansion. Does anyone known a workaround
        !          9651: for this? In NIL you can specify the readtable associated with the object
        !          9652: code, I guess I'm wondering how to mimic this behavior in franz?
        !          9653:                        thanks
        !          9654:                                        steve white
        !          9655:                                (ssc-vax!steve@uw-beaver)
        !          9656: 
        !          9657: From @MIT-MC:smh@MIT-EDDIE  Thu Nov  8 07:49:13 1984
        !          9658: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9659:        id AA12925; Thu, 8 Nov 84 07:49:13 pst
        !          9660: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9661:        id AA17112; Thu, 8 Nov 84 07:46:31 pst
        !          9662: Message-Id: <[email protected]>
        !          9663: Received: by mit-eddie.Mit-chaos.Arpa id AA20888; Thu, 8 Nov 84 10:33:41 est
        !          9664: Date: Thu, 8 Nov 84 10:33:41 est
        !          9665: From: Steven M. Haflich <smh@mit-eddie>
        !          9666: To: franz-friends@BERKELEY
        !          9667: Subject: Re: readtable within fasl
        !          9668: 
        !          9669: I too was bothered by fasl's insistence on using the standard readtable
        !          9670: to process literals in liszt-compiled files until I realized the reason
        !          9671: for this limitation:
        !          9672: 
        !          9673: All source input to liszt is processed by `read' -- that is, the
        !          9674: compiler reads only forms, never ascii strings.  In order to place a
        !          9675: literal form in an object file, liszt must essentially convert the form
        !          9676: back into ASCII via `print'.  (Actually, a somewhat modified version
        !          9677: which knows how to wrap an assembler `.asciz' directive around the
        !          9678: printed representation of the form, etc.)  Unfortunately, liszt can make
        !          9679: no easy assumption about what strange readtable is likely to be active
        !          9680: at load time, so the only sane choice is to use the standard readtable.
        !          9681: 
        !          9682: In other words, you shouldn't think of literal forms stored in a fasl
        !          9683: object file as external (ASCII) representation of lisp data.  Rather,
        !          9684: liszt/fasl use ASCII as a convenient "position-independent" encoding of
        !          9685: a form which has already been processed by read at compile time.  This
        !          9686: is entirely analogous to what traditional compilers and assemblers do
        !          9687: with numeric constants represented in ASCII inside a program, except
        !          9688: their compiler-to-loader data format uses the native binary number
        !          9689: representation of the object machine.
        !          9690: 
        !          9691: One could argue that this isn't really a limitation provided one is
        !          9692: willing and able to provide the desired readtable at compile time.
        !          9693: Usually this isn't a problem, although I once I had a macro which wanted
        !          9694: to insert into a form a particular uninterned symbol which (obviously)
        !          9695: couldn't even exist until execution time.  I was forced to wrap the form
        !          9696: inside another function which would accomplish the substitution at load
        !          9697: time.
        !          9698: 
        !          9699: There is no reason liszt could not be made to copy ASCII forms into the
        !          9700: fasl file without read->print translation, but this would require
        !          9701: changes to the compiler and to fasl format, things not to be done
        !          9702: lightly.  If you *really* need the facility, and don't need to read huge
        !          9703: volumes of data, you could include ASCII forms inside a fasl file by
        !          9704: encoding them as lisp strings, and seeing that they get processed by an
        !          9705: appropriate function at load time, something like:
        !          9706: 
        !          9707:        (defun strange-read (str)
        !          9708:               (let ((readtable strange-readtable))
        !          9709:                    (readlist (explodec str))))
        !          9710: 
        !          9711: Then you can do things like:
        !          9712:        (setq foo (strange-read ") a b )c d( e (")
        !          9713: 
        !          9714: [What?  You don't like my readtable with the parens reversed?]  The
        !          9715: invocation of `strange-read' can, of course, be conveniently macrofied.
        !          9716: If appropriate, automatic printing of literal strings can also be
        !          9717: performed by compile time macros.  You will have to deal with the
        !          9718: problem of escaping quotes inside these forms, and you might want to
        !          9719: enable string garbage collection if you do a lot of this sort of thing.
        !          9720: 
        !          9721: I know it's ugly, but...
        !          9722: 
        !          9723: Steve Haflich
        !          9724: 
        !          9725: 
        !          9726: From @MIT-MC:smh@MIT-EDDIE  Thu Nov  8 12:17:02 1984
        !          9727: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9728:        id AA15294; Thu, 8 Nov 84 12:17:02 pst
        !          9729: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9730:        id AA22393; Thu, 8 Nov 84 11:59:13 pst
        !          9731: Message-Id: <[email protected]>
        !          9732: Received: by mit-eddie.Mit-chaos.Arpa id AA21531; Thu, 8 Nov 84 12:51:14 est
        !          9733: Date: Thu, 8 Nov 84 12:51:14 est
        !          9734: From: Steven M. Haflich <smh@mit-eddie>
        !          9735: To: franz-friends@BERKELEY
        !          9736: Subject: Re: Re: readtable within fasl
        !          9737: 
        !          9738: There was a typo in my previous mailing.  The function "explodec"
        !          9739: should have been "exploden".
        !          9740: 
        !          9741: 
        !          9742: From [email protected]  Thu Nov  8 14:24:38 1984
        !          9743: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9744:        id AA16474; Thu, 8 Nov 84 14:24:38 pst
        !          9745: Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9746:        id AA25584; Thu, 8 Nov 84 14:22:00 pst
        !          9747: Message-Id: <[email protected]>
        !          9748: Date: Thu 8 Nov 84 14:21:16-PST
        !          9749: From: Rene Bach <[email protected]>
        !          9750: Subject: printing delayed in Eunice
        !          9751: To: franz-friends@BERKELEY
        !          9752: Cc: [email protected]
        !          9753: 
        !          9754: It appears that printing gets delayed in Eunice. What I mean by that
        !          9755: is that I have a print statement which should indicate that the system
        !          9756: is progressing. However, the system is chugging along, nothing shows
        !          9757: for a long while and then the printing happens ALL at ONCE ! As if the
        !          9758: output was buffered and go printed when something else needed to be
        !          9759: printed.
        !          9760: 
        !          9761: As anyone run across this before ? Is there a flag one needs to set ?
        !          9762: 
        !          9763: Has it to do with Eunice ?  What I am printing is just an atom and a ", ".
        !          9764: When I print longer stuff, no buffering is noticed.
        !          9765: 
        !          9766: Thanks
        !          9767: Rene
        !          9768: -------
        !          9769: 
        !          9770: From [email protected]  Thu Nov  8 16:34:36 1984
        !          9771: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9772:        id AA17894; Thu, 8 Nov 84 16:34:36 pst
        !          9773: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
        !          9774:        id AA27172; Thu, 8 Nov 84 15:30:06 pst
        !          9775: Message-Id: <[email protected]>
        !          9776: Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 84 15:29:24 PST
        !          9777: Date: 8 Nov 84 15:22 PST
        !          9778: From: [email protected]
        !          9779: Subject: Re: readtable within fasl
        !          9780: In-Reply-To: Steven M. Haflich <[email protected]>'s message of Thu, 8
        !          9781:  Nov 84 10:33:41 est
        !          9782: To: [email protected]
        !          9783: Cc: franz-friends@BERKELEY
        !          9784: 
        !          9785: The problems with a user-tailorable READ is one of the reasons why, over
        !          9786: 12 years ago, we chose a format for MacLisp's FASL files that is
        !          9787: somewhat akin to a position-independent list encoding.  (But in fact, it
        !          9788: was primarily for speed that the READ-oriented option was abandoned).
        !          9789: 
        !          9790: However, there was still the need to introduce load-time evaluation, in
        !          9791: order to create structures that can't be known even faintly at compile
        !          9792: time; there is an "internal" marker, accessible to the MacLisp user as a
        !          9793: global variable (named SQUID, I believe), so that the portions of a
        !          9794: structure that need to be eval'd at load time could be marked.  E.g.
        !          9795:     (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE))))
        !          9796: and the #, signals a spot for load-time evaluation, even though the
        !          9797: overall structure is essentally a QUOTE form.  
        !          9798: 
        !          9799: One needn't imagine that #, is the only client of this "internal" marker
        !          9800: -- it provides the way to get all but the trivial datatypes into
        !          9801: quotified structures; for example, I may have an input syntax for
        !          9802: arrays, but still PRINT won't put them out (MacLisp PRINT won't, at
        !          9803: least), and certainly not every conceivable datatype needs a special
        !          9804: encoding for the FASL file format; merely a LIST, which is viewed as a
        !          9805: general program by EVAL, is satisfactory to create any createable
        !          9806: datatype instance.
        !          9807: 
        !          9808: Interlisp too has a loadtime evaluation construct, but it may only
        !          9809: replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such
        !          9810: as indicated by the #, above.  A primary reason for this limitation is
        !          9811: the similarity of Interlisp's and Franz's compiler output formats --
        !          9812: basically an ascii string to which READ is applied.   MacLisp's loader
        !          9813: is indeed quite more complex, but it results in a space savings for the
        !          9814: FASL files and a considerable time savings when loading them.
        !          9815: 
        !          9816: -- Jon L White --
        !          9817: 
        !          9818: 
        !          9819: 
        !          9820: From @MIT-MC:[email protected]  Fri Nov  9 12:09:40 1984
        !          9821: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9822:        id AA26238; Fri, 9 Nov 84 12:09:40 pst
        !          9823: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9824:        id AA04311; Fri, 9 Nov 84 12:06:51 pst
        !          9825: Message-Id: <[email protected]>
        !          9826: Date: 9 Nov 84 14:02:29 EST
        !          9827: From: Nancy.Skooglund@CMU-RI-ISL3
        !          9828: Subject: opening file for output, append
        !          9829: To: BBoard.Maintainer@CMU-CS-A
        !          9830: 
        !          9831: Does anyone know how to open a file for output in Franz lisp and
        !          9832: @i(append) to that file?  The function "outfile" always deletes the old
        !          9833: version first.
        !          9834: 
        !          9835: Thanks,
        !          9836: Nancy Skooglund
        !          9837: 
        !          9838: 
        !          9839: From @MIT-MC:[email protected]  Sun Nov 11 11:57:03 1984
        !          9840: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9841:        id AA16052; Sun, 11 Nov 84 11:57:03 pst
        !          9842: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9843:        id AA15747; Sun, 11 Nov 84 11:54:17 pst
        !          9844: Message-Id: <[email protected]>
        !          9845: Date: 11 Nov 84 00:15:49 EST
        !          9846: From: David.Yaskin@CMU-CS-H
        !          9847: Subject: Franz Question
        !          9848: To: BBoard.Maintainer@CMU-CS-A
        !          9849: 
        !          9850: 
        !          9851: How does one change the depth and length of list returned from functions.
        !          9852: While using CMULisp it keeps returning & instead of my list.
        !          9853: 
        !          9854:                David Yaskin   ( day@h)
        !          9855: 
        !          9856: 
        !          9857: From Johnson%[email protected]  Sun Nov 11 19:11:37 1984
        !          9858: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9859:        id AA19376; Sun, 11 Nov 84 19:11:37 pst
        !          9860: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9861:        id AA21463; Sun, 11 Nov 84 19:08:46 pst
        !          9862: Message-Id: <[email protected]>
        !          9863: Received: From udel-dewey.ARPA by udel-relay.ARPA id a010044
        !          9864:           ;11 Nov 84 22:09 EST
        !          9865: Date:     Sun, 11 Nov 84 22:07:41 EST
        !          9866: From: johnson <johnson%[email protected]>
        !          9867: To: [email protected]
        !          9868: Cc: franz-friends@BERKELEY, johnson%[email protected]
        !          9869: Subject:  Re:  Franz Question
        !          9870: 
        !          9871: --------------------  for franz -----------------------------
        !          9872: In franz lisp, 'prinlevel' is a variable controlling the
        !          9873: depth to which the top-level is to print lists, 'prinlength'
        !          9874: controls how many elements of a list are printed by the
        !          9875: top-level. For either variable, a value of 'nil' represents
        !          9876: infinite depth or length.
        !          9877: 
        !          9878: If franz is printing expressions as '&' then 
        !          9879: prinlevel has a value of 0.
        !          9880: 
        !          9881: you should
        !          9882: (setq prinlevel nil)
        !          9883: to print lists of arbitrary depth.
        !          9884: (see Appendix B of the Franz manual)
        !          9885: 
        !          9886: ----------------  for CMU --------------------
        !          9887: 
        !          9888: In CMULisp, tlprint does the top-level printing, and this is
        !          9889: defined, (in, at least the 2 systems that I use) as:
        !          9890: 
        !          9891:        '(lambda (x) (printlev x 4))
        !          9892: 
        !          9893: if your functions always return &, then perhaps someone has defined
        !          9894: it as '(lambda (x) (printlev x 0))
        !          9895: 
        !          9896: if you want to change it you may either:
        !          9897: 1.  (sstatus translink nil)
        !          9898:     (defun tlprint (x) (printlev x <some-large-number>))
        !          9899: 
        !          9900: OR,  the solution  I prefer:
        !          9901: 
        !          9902: 2.  (load 'toplevel)  ; unnecessary in some installations.
        !          9903:     (defun tlprint (x) (top-print x))
        !          9904:   
        !          9905: causing 'prinlevel' and 'prinlength' to have
        !          9906: the effect described above for the franz system.
        !          9907:  
        !          9908:  NB: the tempting solution:
        !          9909:  (defun tlprint (x) (printlev x prinlevel))
        !          9910:  FAILS in the case that prinlevel is nil
        !          9911: 
        !          9912: 
        !          9913: -johnson@udel-ee
        !          9914: 
        !          9915: From Johnson%[email protected]  Sun Nov 11 19:31:52 1984
        !          9916: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9917:        id AA19491; Sun, 11 Nov 84 19:31:52 pst
        !          9918: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9919:        id AA21770; Sun, 11 Nov 84 19:29:03 pst
        !          9920: Message-Id: <[email protected]>
        !          9921: Received: From udel-dewey.ARPA by udel-relay.ARPA id a010257
        !          9922:           ;11 Nov 84 22:29 EST
        !          9923: Date:     Sun, 11 Nov 84 22:21:49 EST
        !          9924: From: johnson <johnson%[email protected]>
        !          9925: To: [email protected]
        !          9926: Cc: franz-friends@BERKELEY, johnson%[email protected]
        !          9927: Subject:  Re:  opening file for output, append
        !          9928: 
        !          9929: In later versions of franz, 'outfile' takes a second argument;
        !          9930: to open a file for appending:
        !          9931: 
        !          9932:     (setq portname (outfile '<filename> 'a))
        !          9933: 
        !          9934: {try:
        !          9935:     (help outfile)
        !          9936: for a full description.}
        !          9937: 
        !          9938: If this does not work on your version, I have a hack that associates a port
        !          9939: with ANY open file descriptor, but it uses 4.x system calls, - so don't
        !          9940: request it unless the you can't use the new 'outfile' function.
        !          9941: 
        !          9942: -johnson@udel-ee
        !          9943: 
        !          9944: 
        !          9945: From @MIT-MC:[email protected]  Mon Nov 12 06:45:39 1984
        !          9946: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9947:        id AA22731; Mon, 12 Nov 84 06:45:39 pst
        !          9948: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9949:        id AA01316; Mon, 12 Nov 84 06:42:54 pst
        !          9950: Message-Id: <[email protected]>
        !          9951: Date: 12 Nov 84 09:34:14 EST
        !          9952: From: Nancy.Skooglund@CMU-RI-ISL1
        !          9953: Subject: append to file answer found
        !          9954: To: BBoard.Maintainer@CMU-CS-A
        !          9955: 
        !          9956: Thanks to all who responded to my Franz lisp question about opening a
        !          9957: file for output and appending to it.  Here's how it works:
        !          9958: 
        !          9959:        (outfile '<filename> 'a)
        !          9960: 
        !          9961: 'a may be replaced by any symbol or string whose name begins with a.
        !          9962: 
        !          9963: Nancy
        !          9964: 
        !          9965: 
        !          9966: From [email protected]  Tue Nov 13 04:26:24 1984
        !          9967: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          9968:        id AA04324; Tue, 13 Nov 84 04:26:24 pst
        !          9969: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          9970:        id AA20746; Tue, 13 Nov 84 04:25:59 pst
        !          9971: Received: from wisdom.BITNET
        !          9972:        by ucbjade.CC.Berkeley.ARPA (4.17/4.27.5)
        !          9973:        id AA10274; Tue, 13 Nov 84 04:24:53 pst
        !          9974: Received: by wisdom.BITNET (4.12/4.7)
        !          9975:         id AA01997; Tue, 13 Nov 84 11:29:45 -0200
        !          9976: Date: Tue, 13 Nov 84 11:29:45 -0200
        !          9977: From: [email protected] (Jacob Levy)
        !          9978: Message-Id: <[email protected]>
        !          9979: To: [email protected]
        !          9980: Subject: Announcement of new Lisp for UN*X 4.x VAXen
        !          9981: 
        !          9982: I don't know if this is the appropriate place for this announcement, but
        !          9983: here goes anyway :-
        !          9984: 
        !          9985: 
        !          9986:         YLISP, a Coroutine-based Lisp System for VAXen.
        !          9987:         -=============================================-
        !          9988: 
        !          9989:         A friend of  mine, Yitzhak  Dimitrovski, and  myself, wrote a Lisp
        !          9990: system for UN*X 4.x systems on VAXen. It has the following features :-
        !          9991: 
        !          9992:         o - Coroutines and  closures. The  system uses  these to implement
        !          9993:             the user-interface, single-stepping and  error-handling.  It's
        !          9994:             easy to write a scheduler and time-share YLISP between  two or
        !          9995:             more user programs.
        !          9996:         o - Multiple-dimension arrays.
        !          9997:         o - Multiple name  spaces (oblists) arranged  in a tree hierarchy.
        !          9998:             This is similar to the Lisp Machine facility.
        !          9999:         o - Defstruct structure definition package.
        !          10000:         o - Flavors object-oriented programming tools.
        !          10001:         o - User-extensible  evaluator (it is  possible to (re)define  the
        !          10002:             actions of 'eval', 'apply' and 'print'  relative to all  user-
        !          10003:             and pre-defined types).
        !          10004:         o - Integer arithmetic. No floating-point, sorry. don't think that
        !          10005:             that's  really  necessary, but *could*  be hacked. No  BIGNUMs
        !          10006:             either.
        !          10007:         o - Good user-interface with history, sophisticated error handling
        !          10008:             and function-call and variable-assignment tracing facilities.
        !          10009:         o - Extensive library of ported and user-contributed programs,such
        !          10010:             as a variant of the Interlisp  structure editor, 'loop' macro,
        !          10011:             'mlisp' Pascal-like embedded language, etc.
        !          10012:         o - Compiler  that  generates efficient native  assembler code for
        !          10013:             the VAXen. The  compiler is provided as a separate program,due
        !          10014:             to size  considerations. The compiler is  written entirely  in
        !          10015:             Lisp, of course.
        !          10016:         o - Extensive online documentation, as well as  a 400-page  manual
        !          10017:             describing the whole system from a programmer's point of view.
        !          10018: 
        !          10019:         The system is named  'YLISP', and was written for 4.1 when we were
        !          10020: students at the Hebrew University  at Jerusalem. Since  then, Yitzhak  has
        !          10021: left  for the  US and  is  currently a  Ph.D. student in  Prof. Schwartz's
        !          10022: Supercomputer group at Courant. I have continued to  develop the system on
        !          10023: my own, and have ported it to UN*X 4.2.
        !          10024: 
        !          10025:         I am looking for a site that is willing to handle the distribution
        !          10026: of this software from the US, by letting  one FTP it  from their computer.
        !          10027: Alternatively, I am also willing to supply people  with magtapes of YLISP,
        !          10028: for the cost of the tape and handling charges (about 70$ a piece).  If you
        !          10029: are interested, please respond by electronic mail to one of  the addresses
        !          10030: given below. I will be  ready  to  start distributing  the  system in  two
        !          10031: weeks' time.
        !          10032: 
        !          10033:         Rusty Red (AKA Jacob Levy)
        !          10034: 
        !          10035:         BITNET:                         jaakov@wisdom
        !          10036:         CSNET and ARPA:                 jaakov%[email protected]
        !          10037:         UUCP: (if all else fails..)     ..!decvax!humus!wisdom!jaakov
        !          10038: 
        !          10039: 
        !          10040: 
        !          10041: 
        !          10042: From [email protected]  Tue Nov 13 06:20:04 1984
        !          10043: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10044:        id AA04848; Tue, 13 Nov 84 06:20:04 pst
        !          10045: Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10046:        id AA05430; Mon, 12 Nov 84 15:45:22 pst
        !          10047: Received: by uw-beaver.arpa (4.12/2.2)
        !          10048:        id AA28549; Mon, 12 Nov 84 15:43:15 pst
        !          10049: Return-Path: <[email protected]>
        !          10050: Received: by ssc-vax (4.12/4.7)
        !          10051:        id AA03520; Mon, 12 Nov 84 09:58:10 pst
        !          10052: Date: Mon, 12 Nov 84 09:58:10 pst
        !          10053: From: [email protected] (Steve White)
        !          10054: Message-Id: <8411121758.AA03520@ssc-vax>
        !          10055: To: uw-beaver!JonL.pa@XEROX, uw-beaver!smh@mit-eddie
        !          10056: Subject: Re: readtable within fasl
        !          10057: Cc: uw-beaver!franz-friends@BERKELEY
        !          10058: 
        !          10059: My problem was a bit simplier then the general case you mention. In MRS
        !          10060: a 'variable' is really a reader-macro ($) that at read time assigns a special
        !          10061: value to each variable-base-name. Basically it does a
        !          10062:        (set (implode `(|$| . ,(explodec name))) 'bl).
        !          10063: for side-effects of marking the symbol as a variable.  When compiling files
        !          10064: containing MRS code the compiler would execute the call inside its environment,
        !          10065: placing the *unbound* literals (as .asciz) in the object file to be READ
        !          10066: in at load time... so MRS would get the symbols and treat them as symbols
        !          10067: not variables.
        !          10068: 
        !          10069: The only reason i mention this is that the workaround used might be useful
        !          10070: for others seeking side effects within macros etc.
        !          10071: My workaround (h.a.c.k) was to use a special variable
        !          10072:        liszt-eof-forms
        !          10073: as a queue of the above SET forms and to provide a different macro expansion
        !          10074: for compile-time.  So
        !          10075: 
        !          10076: (setsyntax '|$| 'macro
        !          10077:   #'(lambda nil (let ((varname (implode `(|$| ,@(explodec (read))))))
        !          10078:                     (addq `(setq ,varname 'bl) liszt-eof-forms)
        !          10079:                     varname)))         ;; return variable name to liszt!
        !          10080: 
        !          10081: [where ADDQ does the correct thing if the variable has already been seen],
        !          10082: adds the following to the object file
        !          10083:        .asciz "$xyz"
        !          10084:        .asciz "(setq $xyz 'bl)"
        !          10085: which basically works (don't gag!)
        !          10086:                                        steve white
        !          10087: 
        !          10088: YAP -- (yet another problem) : does anyone at MIT have a list of fixes
        !          10089: to franz 38.91 to make the zeta-lisp environment work :-) I started fixing
        !          10090: a few things but it looks like something that might MIT may have already
        !          10091: done. ((or any plans to put NIL under UNIX? 8-) ))
        !          10092: 
        !          10093: From [email protected]  Thu Nov 15 18:09:13 1984
        !          10094: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10095:        id AA12102; Thu, 15 Nov 84 18:09:13 pst
        !          10096: Received: by UCB-VAX.ARPA (4.24/4.39)
        !          10097:        id AA11658; Thu, 15 Nov 84 18:09:11 pst
        !          10098: Received: from ucscd.UCSC (ucscd.ARPA) by ucscc.UCSC (4.12/4.7)
        !          10099:        id AA23553; Thu, 15 Nov 84 10:48:02 pst
        !          10100: Received: by ucscd.UCSC (4.12/4.7)
        !          10101:        id AA04900; Thu, 15 Nov 84 10:45:19 pst
        !          10102: Date: Thu, 15 Nov 84 10:45:19 pst
        !          10103: From: [email protected] (05550000)
        !          10104: Message-Id: <[email protected]>
        !          10105: To: [email protected]
        !          10106: Subject: mailing list name change
        !          10107: 
        !          10108:                
        !          10109:        Please stop sending to
        !          10110:                ucscc!figgy
        !          10111:        
        !          10112:        instead add
        !          10113:                ucbvax!ucscc!lispers
        !          10114:        
        !          10115:        Thank you.
        !          10116: 
        !          10117: From [email protected]  Thu Nov 15 20:51:49 1984
        !          10118: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10119:        id AA13810; Thu, 15 Nov 84 20:51:49 pst
        !          10120: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10121:        id AA14507; Thu, 15 Nov 84 20:51:52 pst
        !          10122: Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
        !          10123:        by ucbjade.CC.Berkeley.ARPA (4.18/4.27.5)
        !          10124:        id AA01653; Thu, 15 Nov 84 20:51:05 pst
        !          10125: Received: by ucbruby.CC.Berkeley.ARPA (4.18/4.27.6)
        !          10126:        id AA02961; Thu, 15 Nov 84 20:50:39 pst
        !          10127: Date: Thu, 15 Nov 84 20:50:39 pst
        !          10128: From: [email protected] (Harry Weeks)
        !          10129: Message-Id: <[email protected]>
        !          10130: To: franz-friends@BERKELEY
        !          10131: Subject: Lisp implementation details.
        !          10132: 
        !          10133: Are there any technical reports or memoranda available which
        !          10134: describe the internal workings of Franz?
        !          10135:                                                -- Harry
        !          10136: 
        !          10137: From @MIT-MC:[email protected]  Wed Nov 28 11:32:50 1984
        !          10138: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10139:        id AA15208; Wed, 28 Nov 84 11:32:50 pst
        !          10140: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10141:        id AA14658; Wed, 28 Nov 84 11:32:04 pst
        !          10142: Message-Id: <[email protected]>
        !          10143: Date: 28 Nov 84 14:24:42 EST
        !          10144: From: Timothy.Glavin@CMU-CS-CAD
        !          10145: Subject: cmulisp docs
        !          10146: To: BBoard.Maintainer@CMU-CS-A
        !          10147: 
        !          10148: Does anyone know the location of on-line documentation for
        !          10149: cmulisp.  If not, is there a source for hard copy documentation?
        !          10150: I have the Foderaro Franz Lisp Manual, I only looking for info
        !          10151: on the CMU ideosyncracies.
        !          10152:                                        -- Tim (tg@cad)
        !          10153: 
        !          10154: 
        !          10155: From smith@nrl-aic  Fri Nov 30 09:17:53 1984
        !          10156: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10157:        id AA15087; Fri, 30 Nov 84 09:17:53 pst
        !          10158: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10159:        id AA24282; Fri, 30 Nov 84 09:15:33 pst
        !          10160: Date: 30 Nov 1984 11:50-EST
        !          10161: From: Russ Smith <[email protected]>
        !          10162: Subject: bugs using flavors (and more)
        !          10163: To: franz-friends@BERKELEY
        !          10164: Message-Id: <470681409/smith@nrl-aic>
        !          10165: 
        !          10166: I recently installed opus 38.91 on our VAX780 under 4.2BSD. The
        !          10167: installation went smoothly. The files used for the installation appear
        !          10168: to be the most recent available from ucbkim. This includes the flavors
        !          10169: stuff with appropriate modifications (for example, fixing hash.l to use
        !          10170: "vsize" instead of "getlength" on a vector). The flavors stuff I scarfed
        !          10171: TODAY was dated October 2nd I believe. Anyway, I tried out some things
        !          10172: with flavors and, in particular, with "describe"...with the
        !          10173: following result (done with "script"):
        !          10174: =============================================================================
        !          10175: % lisp
        !          10176: Franz Lisp, Opus 38.91
        !          10177: -> (defflavor ob () () :settable-instance-variables)
        !          10178: [autoload /usr/lib/lisp/flavors]
        !          10179: [fasl /usr/lib/lisp/flavors.o]
        !          10180: [fasl /usr/lib/lisp/machacks.o]
        !          10181: [fasl /usr/lib/lisp/lmhacks.o]
        !          10182: [fasl /usr/lib/lisp/flavorm.o]
        !          10183: [fasl /usr/lib/lisp/vanilla.o]
        !          10184: ob
        !          10185: -> (describe 'ob)
        !          10186: [autoload /usr/lib/lisp/describe]
        !          10187: [fasl /usr/lib/lisp/describe.o]
        !          10188: 
        !          10189: ob has property flavor: flavor[17]
        !          10190: Error: Undefined function called from compiled code  defstruct-description-name
        !          10191: <1>: (exit)
        !          10192: =============================================================================
        !          10193: [Well, "defstruct-description-name" is used all over the
        !          10194: "/usr/lib/lisp/struct.l" set of functions...apparently mostly with no
        !          10195: arguments...which, I think, is wrong. One fix made by SMH to "describe.l" 
        !          10196: replaced a call on this macro with one with an argument. But that's NOT this
        !          10197: problem anyway.]
        !          10198: 
        !          10199: (1) Is there a known fix to get the "describe", or anything else that
        !          10200:         uses the "defstruct-description-name" macro, working correctly?
        !          10201: 
        !          10202: (2) Could it be that some sort of extended "defflavor" would load in an
        !          10203:         appropriate file which on-the-fly defines this macro? That is,
        !          10204:         did I do TOO simple a "defflavor"? [For example, doing:
        !          10205: 
        !          10206:                (load '/usr/pub/lisp/struct.l)
        !          10207: 
        !          10208:         allows one to "(pp defstruct-description-name)" showing that
        !          10209:         it requires an argument...without the "load" it is undefined.]
        !          10210: 
        !          10211: (3) Could the copy of the ftpable (???) opus38.91 files we have be out
        !          10212:         of date (seem to be from around June 84)?
        !          10213: 
        !          10214: Any help would be much appreciated. We are attempting to develop
        !          10215: some stuff for use on both an LMI Lisp Machine and the VAX. This has
        !          10216: thrown the proverbial wrench into the work(s)...
        !          10217: 
        !          10218: Russ <Smith@nrl-aic>
        !          10219: Navy Center for Applied Research in Artificial Intelligence (whew!)
        !          10220: 
        !          10221: From [email protected]  Sat Dec  1 15:40:10 1984
        !          10222: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10223:        id AA04698; Sat, 1 Dec 84 15:40:10 pst
        !          10224: Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10225:        id AA03439; Sat, 1 Dec 84 14:28:56 pst
        !          10226: Message-Id: <[email protected]>
        !          10227: Date: 30 Nov 84 22:45:59 EST
        !          10228: From: Sean McLinden  <[email protected]>
        !          10229: Subject: Re: bugs using flavors (and more)
        !          10230: To: [email protected], franz-friends@BERKELEY
        !          10231: Cc: [email protected]
        !          10232: In-Reply-To: Message from "Russ Smith <[email protected]>" of 30 Nov 84 11:50:00 EST
        !          10233: 
        !          10234: 
        !          10235:   There is a bug in the way that describe is compiled according to the
        !          10236:   makefile. Basically the problem is that defstruct-description-name
        !          10237:   is a macro which is NOT compiled so that when you fasl the compiled
        !          10238:   version of struct (as you are compiling describe), you don't get
        !          10239:   the proper definition for defstruct-description-name.
        !          10240: 
        !          10241:   You can either 1). load struct.l when compiling describe.l or
        !          10242:                 2). (declare (macros t)) in struct.l and recompile.
        !          10243: 
        !          10244:   Sean McLinden
        !          10245:   Decision Systems Laboratory
        !          10246: -------
        !          10247: 
        !          10248: From sridhar%[email protected]  Sat Dec  1 17:03:50 1984
        !          10249: Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
        !          10250:        id AA06036; Sat, 1 Dec 84 16:55:15 pst
        !          10251: Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.38)
        !          10252:        id AA08322; Sat, 1 Dec 84 16:50:50 pst
        !          10253: Message-Id: <[email protected]>
        !          10254: Received: from wsu by csnet-relay.csnet id a012949; 1 Dec 84 19:41 EST
        !          10255: Date:     Sat, 1 Dec 84 12:47 PST
        !          10256: From: "S. Sridhar" <sridhar%[email protected]>
        !          10257: To: [email protected]
        !          10258: Cc: sridhar%[email protected]
        !          10259: Subject:  Documentation pblms.
        !          10260: 
        !          10261: Hi,
        !          10262:   I am an ardent Franz hack here at Wash. St. Univ, Pullman.
        !          10263:   I need some specific info on Franz Lisp.
        !          10264: 
        !          10265:  There is no documentation on 'Structures' in the Franz Lisp manual, that
        !          10266: we have here. (This is dated June 1983. The version we have is Opus 38.69,
        !          10267: June 1983). Specifically I need documentaion on all the macros related to
        !          10268: the use of structures like defstruct. I know for sure that these macros
        !          10269: are available on our system, but I am having problems on their usage. The
        !          10270: on-line documentation does not give any help either. Maybe you have an 
        !          10271: updated version of the Franz Lisp manual. Can you help around, please ?
        !          10272: 
        !          10273: As another instance, functions relating to hashtables are available here
        !          10274: but there is no documentation for it. 
        !          10275: 
        !          10276: Thanks.
        !          10277: 
        !          10278: Sridhar
        !          10279: ------
        !          10280: 
        !          10281: From smith@nrl-aic  Mon Dec  3 12:17:10 1984
        !          10282: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10283:        id AA04104; Mon, 3 Dec 84 12:17:10 pst
        !          10284: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10285:        id AA16806; Mon, 3 Dec 84 12:14:27 pst
        !          10286: Date: 3 Dec 1984 06:36-EST
        !          10287: From: Russ Smith <[email protected]>
        !          10288: Subject: followup to "flavors bugs (and more)"
        !          10289: To: franz-friends@BERKELEY
        !          10290: Message-Id: <470921820/smith@nrl-aic>
        !          10291: 
        !          10292: This is a followup to a previous note I sent requesting help with fixing
        !          10293: Opus 38.91 of Franz and Flavors running on a Vax780 under 4.2BSD.
        !          10294: 
        !          10295: First, I want to thank the many people who had helpful suggestions on
        !          10296: what may have been going wrong. Given the small amount of information I
        !          10297: provided on the problem, some of them were remarkably relevant.
        !          10298: 
        !          10299: The problem had to do with certain functions such as "describe" going
        !          10300: south when invoked on a FLAVOR object. The solution was (at least) two
        !          10301: fold. One, which I alluded to in the previous note, had to do with the
        !          10302: distributed file "hash.l" containing invalid calls on the intrinsic
        !          10303: "getlength" function with a vector argument. These calls had to be
        !          10304: changed to "vsize" instead (actually "getlength" could probably have
        !          10305: been redefined to allow vectors...). Whatever, that solved that part.
        !          10306: 
        !          10307: The second solution had to do with how WE at NCARAI were installing
        !          10308: Franz. We have a set of directories for "local" software into which
        !          10309: we wanted to put the "new" Franz. As such, I went through all the
        !          10310: "Makefile"s and changed default directories for such things as the
        !          10311: libraries and objects, etc. While doing this, it was noted that certain
        !          10312: files in the "lisplib" directory had hard-coded the default names for, for
        !          10313: example, the library. Since our library was not in the same place as
        !          10314: this default, these lines were "commented out" (with an "exit")...with
        !          10315: the result that the Franz and Liszt installations did not go as smoothly
        !          10316: as I thought. It turns out that these lines also should be changed to
        !          10317: reflect the appropriate directory. They are in the files "buildlisp.l",
        !          10318: "common1.l", and "fix.l" in the lisplib directory (possibly others exist as
        !          10319: well). The pertinent lines read something like:
        !          10320: 
        !          10321:        (or (boundp 'default-library-directory)
        !          10322:            (setq default-library-directory '/usr/lib/lisp))
        !          10323: 
        !          10324: During the installation (done on a CRT) I was doing something else. Thus
        !          10325: when the mods made (namely changing the "setq" call above into an "exit")
        !          10326: were invoked, I didn't notice later that a number of things which SHOULD have
        !          10327: happened didn't (they'd gone off the screen...). Needless to say, this
        !          10328: caused all sorts of bizarre inconsistencies (especially since our last
        !          10329: installation DID use the default directories...).
        !          10330: 
        !          10331: Anyway, notes for the future:
        !          10332: 
        !          10333:        (1) If ftp'ing Franz from ucbkim be sure to get the stuff in the
        !          10334:            "flavors" directory as well. This contains a new "hash.l"
        !          10335:            modified by SMH to use "vsize" rather than "getlength".
        !          10336: 
        !          10337:        (2) If not using the default directories for the installation,
        !          10338:            change the names in the above files as well to reflect the
        !          10339:            appropriate place(s)...sigh.
        !          10340: 
        !          10341: Yours (with an apparently working Franz+flavors),
        !          10342: 
        !          10343: Russ <Smith@nrl-aic>
        !          10344: Navy Center for Applied Research in Artificial Intelligence (whew!)
        !          10345: 
        !          10346: From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 12:49:49 1984
        !          10347: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10348:        id AA20917; Tue, 4 Dec 84 12:49:49 pst
        !          10349: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10350:        id AA24636; Tue, 4 Dec 84 12:13:23 pst
        !          10351: Message-Id: <[email protected]>
        !          10352: Received: by mit-eddie.Mit-chaos.Arpa id AA19371; Tue, 4 Dec 84 14:50:26 est
        !          10353: Date: Tue, 4 Dec 84 14:50:26 est
        !          10354: From: Steven M. Haflich <smh@mit-eddie>
        !          10355: To: franz-friends@BERKELEY
        !          10356: Subject: the *real* flavor sources (etc.)
        !          10357: 
        !          10358: For some time I have been using and maintaining enhanced versions of the
        !          10359: several Franz lisplib modules which implement various Lisp Machine
        !          10360: compatibilities, most notably, the FLAVOR system and FORMAT output.
        !          10361: jkf@berkeley has authorized me to announce public availability of these
        !          10362: files via anonymous ftp from UCBKIM.  These seven files are compatible
        !          10363: with Opus 38.91, but supersede the versions in the 39.91 distribution.
        !          10364: There are a number of bugfixes and new features.
        !          10365: 
        !          10366: UCBKIM supports FTP with login "anonymous" and any password.  The
        !          10367: files are:
        !          10368:         ~anonymous/pub/flavors/Makefile
        !          10369:                                flavors.l
        !          10370:                                flavorm.l
        !          10371:                                vanilla.l
        !          10372:                                hash.l
        !          10373:                                describe.l
        !          10374:                                format.l
        !          10375: 
        !          10376: The changes are too many to describe in detail.  Many of the FLAVOR
        !          10377: system changes are for compatibility with changes to Franz, although a
        !          10378: few non-working or missing features (but not all) have been bludgeoned
        !          10379: into functionality.  In particular, wrappers work.  The FORMAT module
        !          10380: fixes a number of format directives which apparently never worked.
        !          10381: However, some of the hairier ones are known still to be defective.
        !          10382: 
        !          10383: This "completely unsupported" software is graciously being made
        !          10384: available to all takers without any promises whatever:  there is no
        !          10385: promise of correctness, and no promise of support.  Also, the sources
        !          10386: total 160K and unsuitable for uucp distribution, and I don't have time
        !          10387: to deal with tape requests [sorry].
        !          10388: 
        !          10389: The above notwithstanding, I am as eager as anyone for additional
        !          10390: improvements to the code.  Anyone with additional bugfixes is encouraged
        !          10391: to communicate to me, and I will try to integrate the code.  I will try
        !          10392: to respond to bug reports, but it may be a rather low priority business.
        !          10393: 
        !          10394: Steve Haflich
        !          10395: MIT Experimental Music Studio
        !          10396: ARPA: smh@mit-eddie@mit-mc
        !          10397: UUCP: {ihnp4, decvax!genrad}!mit-eddie!smh
        !          10398: 
        !          10399: 
        !          10400: From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 19:32:49 1984
        !          10401: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10402:        id AA26327; Tue, 4 Dec 84 19:32:49 pst
        !          10403: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10404:        id AA26237; Tue, 4 Dec 84 13:26:17 pst
        !          10405: Message-Id: <[email protected]>
        !          10406: Received: by mit-eddie.Mit-chaos.Arpa id AA20260; Tue, 4 Dec 84 15:44:20 est
        !          10407: Date: Tue, 4 Dec 84 15:44:20 est
        !          10408: From: Steven M. Haflich <smh@mit-eddie>
        !          10409: To: franz-friends@BERKELEY
        !          10410: Subject: fix for describe.l
        !          10411: Cc: MCLINDEN@RUTGERS@MIT-MC, smith@nrl-aic@mit-mc
        !          10412: 
        !          10413: Previous postings have correctly identified the problem (which was fixed
        !          10414: long ago in the versions announced today).  The best fix is to change
        !          10415: the (environment-lmlisp) invocation near the beginning of describe.l to
        !          10416: read as follows, then recompile it:
        !          10417: 
        !          10418:        (environment-lmlisp (compile eval) (files struct flavorm))
        !          10419: 
        !          10420: The struct and flavorm modules do not need to be around when the
        !          10421: compiled describe code is executed, so omitting load from the eval-when
        !          10422: saves some unnecessary fasl's.  Describe, by the way, is useful even
        !          10423: when flavors and defstructs are not being used.  For instance, it will
        !          10424: report the source module in which a compiled function lives.
        !          10425: 
        !          10426: Steve Haflich
        !          10427: smh@mit-eddie@mit-mc
        !          10428: {ihnp4, decvax!genrad}!mit-eddie!smh
        !          10429: 
        !          10430: 
        !          10431: From @MIT-MC:smh@MIT-EDDIE  Tue Dec  4 22:49:05 1984
        !          10432: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10433:        id AA29026; Tue, 4 Dec 84 22:49:05 pst
        !          10434: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10435:        id AA05974; Tue, 4 Dec 84 20:50:44 pst
        !          10436: Message-Id: <[email protected]>
        !          10437: Received: by mit-eddie.Mit-chaos.Arpa id AA24308; Tue, 4 Dec 84 23:50:01 est
        !          10438: Date: Tue, 4 Dec 84 23:50:01 est
        !          10439: From: Steven M. Haflich <smh@mit-eddie>
        !          10440: To: franz-friends@BERKELEY
        !          10441: Subject: Franz documentation for MIT LM code
        !          10442: Cc: sridhar%wsu.csnet@csnet-relay
        !          10443: 
        !          10444: Sorry to report that there really is no official documentation for the
        !          10445: several Franz lisplib modules which implement a measure of compatibility
        !          10446: with Zetalisp, the dialect running on MIT Lisp Machines (and, more or
        !          10447: less, on Symbolics and LMI machines).  The Franz source code was adapted
        !          10448: from the MIT Lisp machine code several years ago; there is still
        !          10449: approximate compatibility, although new features and certain semantic
        !          10450: subtleties have diverged.  Driven partially by natural evolution and
        !          10451: partially by the standardization efforts of Common Lisp, Lisp Machine
        !          10452: compatibility is something of a moving target.
        !          10453: 
        !          10454: But do not despair; there are two standardly available sources for
        !          10455: documentation.  Reading them will give a very usable idea about the
        !          10456: packages.  Unfortunately, a few unimplemented features and semantic
        !          10457: differences will have to be discovered by experimentation or examination
        !          10458: of the source code.  (What do you want for free? :-)
        !          10459: 
        !          10460: (1) If you have available a MIT Lisp Machine Manual, the sections on
        !          10461: defstruct, flavors, format, hash, and loop output are still reasonable
        !          10462: approximations of documentation for the Franz versions.  Incidentally,
        !          10463: the `Blue' MIT Lisp Machine Manual circa 1981 corresponds most closely
        !          10464: with the Franz inplementation, although a few more recent features have
        !          10465: been retrofitted.  If available, Symbolics documentation is probably
        !          10466: only very slightly less good -- the older, the better.
        !          10467: 
        !          10468: (2) For defstruct, hash, and format the Guy Steele <Common Lisp: The
        !          10469: Language>, published by Digital Press (a branch of DEC), is usefully
        !          10470: close to the existing Franz code.  Again, experimentation and
        !          10471: examination of the source code will resolve the details.  Unfortunately,
        !          10472: Flavors and the loop macro are not (yet) part of the Common Lisp
        !          10473: specification, and may well be very different when they are.
        !          10474: 
        !          10475: Unofficially, there is another even better hope.  The MIT Athena project
        !          10476: will be `releasing' these packages into their standard Franz system this
        !          10477: in another month or two.  They are commencing a quick effort to edit
        !          10478: Lisp Machine documentation into proper format for inclusion as
        !          10479: appendixes in the Franz manual.  If at all possible, I will attempt to
        !          10480: get the results publically distributed.  (Translation:  My assistance is
        !          10481: essential to this documentation, so I am in position to insist they be
        !          10482: `reasonable' about it...)  But no promises just yet.
        !          10483: 
        !          10484: Steve Haflich
        !          10485: MIT
        !          10486: 
        !          10487: 
        !          10488: From [email protected]  Thu Dec  6 13:53:03 1984
        !          10489: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10490:        id AA03880; Thu, 6 Dec 84 13:53:03 pst
        !          10491: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10492:        id AA27039; Thu, 6 Dec 84 11:43:13 pst
        !          10493: Received: from CUNYVM.BITNET
        !          10494:        by ucbjade.CC.Berkeley.ARPA (4.19/4.30)
        !          10495:        id AA27252; Thu, 6 Dec 84 11:44:10 pst
        !          10496: Message-Id: <[email protected]>
        !          10497: Received: by CUNYVM     id 8508; Thu, 06 Dec 84 14:41:26 EST
        !          10498: Date:         Thu, 6 Dec 84 14:39 EST
        !          10499: From: Henry Nussbacher <[email protected]>
        !          10500: To: <[email protected]>, <franz-friends@BERKELEY>,
        !          10501:         <ailist-request@sri-ai>, <[email protected]>,
        !          10502:         <[email protected]>, <[email protected]>
        !          10503: 
        !          10504: Can you please register the following user to your lists:
        !          10505: arpalist%cunyvm.BITNET
        !          10506: 
        !          10507: Thank you,
        !          10508: Henry Nussbacher
        !          10509: BITNET Network Information Center
        !          10510: 
        !          10511: From [email protected]  Thu Dec  6 18:20:03 1984
        !          10512: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10513:        id AA07782; Thu, 6 Dec 84 18:20:03 pst
        !          10514: Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10515:        id AA05141; Thu, 6 Dec 84 17:55:14 pst
        !          10516: Received: from thule by rice.ARPA (AA02673); Thu, 6 Dec 84 19:41:33 CST
        !          10517: Received: by thule (AA02845); Thu, 6 Dec 84 19:38:53 cst
        !          10518: Date: Thu, 6 Dec 84 19:38:53 cst
        !          10519: From: Mike Caplinger <[email protected]>
        !          10520: Message-Id: <8412070138.AA02845@thule>
        !          10521: To: franz-friends@BERKELEY
        !          10522: Subject: bug in 68k Opus 38.91 arrays
        !          10523: 
        !          10524: In 68k Opus 38.91, the expression
        !          10525: (array foo flonum-block 4 4)
        !          10526: generates an "Error: IMPROPER USE OF SET".
        !          10527: 
        !          10528: On the VAX, in Opus 38.79, this worked fine.  What's happening?
        !          10529: 
        !          10530: (I am on a Sun, compiled with sun_4_2.)
        !          10531: 
        !          10532:        - Mike
        !          10533: 
        !          10534: From @MIT-MULTICS.ARPA:[email protected]  Sat Dec  8 05:42:09 1984
        !          10535: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10536:        id AA25844; Sat, 8 Dec 84 05:42:09 pst
        !          10537: Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10538:        id AA22892; Sat, 8 Dec 84 05:39:47 pst
        !          10539: Received: from VANDERBILT.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[email protected]>; 08 Dec 1984 08:36:56 est
        !          10540: Date:        06 Dec 84 15:26 CDT
        !          10541: From: David_Linn%[email protected]
        !          10542: Reply-To:    David_Linn%[email protected]
        !          10543: To: "franz-friends"@BERKELEY
        !          10544: Subject:     FranzLISP on the S9000
        !          10545: Message-Id:  <30788@VUCCG1COM>
        !          10546: In-Reply-To: <30731@VUCCG1COM>
        !          10547: 
        !          10548: The AI Group at Vanderbilt would like to join the franz-friends
        !          10549: mailing list. We have version 38.87 running on the IBM Inruments
        !          10550: S9000 under CSOS 1.1, a very non-UNIX opsys. Both interpreter
        !          10551: and compiler are working and a farily large general-purpose
        !          10552: expert system tool set written on a VAX is up and running.
        !          10553: 
        !          10554: 
        !          10555: 
        !          10556: From [email protected]  Mon Dec 10 12:06:53 1984
        !          10557: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10558:        id AA18655; Mon, 10 Dec 84 12:06:53 pst
        !          10559: Received: from USC-ECLC.ARPA (usc-eclc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10560:        id AA04397; Mon, 10 Dec 84 12:04:27 pst
        !          10561: Message-Id: <[email protected]>
        !          10562: Date: Mon 10 Dec 84 12:03:06-PST
        !          10563: From: [email protected]
        !          10564: Subject: array  - space
        !          10565: To: franz-friends@BERKELEY
        !          10566: Cc: [email protected]
        !          10567: 
        !          10568: 
        !          10569: I am working with images stored as fixnum arrays (with delta =1 i.e. four
        !          10570: pixels packed into a word)  aux as unmarked arrays. (I am on a VAX under
        !          10571: Eunice). How do I deallocate the array-space once I am done with it?
        !          10572: (I use small-segment to allocate space for the array).
        !          10573: 
        !          10574: Also I would appreciate any pointers of how to speed up programs with 
        !          10575: nested do loops (order of 512x512 x(5 x 5) itterations).
        !          10576: 
        !          10577: Thanks,
        !          10578: 
        !          10579: -Rakesh Mohan.
        !          10580: -------
        !          10581: 
        !          10582: From [email protected]  Mon Dec 10 15:37:50 1984
        !          10583: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10584:        id AA20942; Mon, 10 Dec 84 15:37:50 pst
        !          10585: Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10586:        id AA08450; Mon, 10 Dec 84 15:35:12 pst
        !          10587: Received: from iapetus by rice.ARPA (AA26746); Mon, 10 Dec 84 17:28:43 CST
        !          10588: Received: by iapetus (AA16942); Mon, 10 Dec 84 17:29:45 CST
        !          10589: Date: Mon, 10 Dec 84 17:29:45 CST
        !          10590: From: Mike Caplinger <[email protected]>
        !          10591: Message-Id: <8412102329.AA16942@iapetus>
        !          10592: To: franz-friends@BERKELEY
        !          10593: Subject: gensym and the compiler
        !          10594: 
        !          10595: How does one get code like the following:
        !          10596: 
        !          10597: ; construct an identity transformation matrix.
        !          10598: (defun tm-new ()
        !          10599:     (let ((name (gensym)))
        !          10600:        (*array name 'flonum-block 4 4)
        !          10601:        (do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
        !          10602:        name)
        !          10603: )
        !          10604: 
        !          10605: to work under the compiler?  Compiled, this refuses to believe
        !          10606: in the existence of name.
        !          10607: 
        !          10608: Do I need to declare it as a lambda?  Is there a way to declare arrays?
        !          10609: 
        !          10610:        - Mike
        !          10611: 
        !          10612: From jkf@ucbmike  Mon Dec 10 16:03:40 1984
        !          10613: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10614:        id AA21396; Mon, 10 Dec 84 16:03:40 pst
        !          10615: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
        !          10616:        id AA08955; Mon, 10 Dec 84 16:01:22 pst
        !          10617: Received: by ucbmike.arpa (4.24ucb/4.33)
        !          10618:        id AA06150; Mon, 10 Dec 84 16:04:09 pst
        !          10619: Date: Mon, 10 Dec 84 16:04:09 pst
        !          10620: From: John Foderaro (on a sun) <jkf@ucbmike>
        !          10621: Message-Id: <[email protected]>
        !          10622: To: [email protected], franz-friends@BERKELEY
        !          10623: Subject: Re: array  - space
        !          10624: Cc: [email protected]
        !          10625: In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST
        !          10626: 
        !          10627:  You would be better off using immediate vectors (vectori) which
        !          10628: are garbage collected.    Items allocated with small-segment aren't
        !          10629: gc'ed.
        !          10630: 
        !          10631: 
        !          10632: 
        !          10633: 
        !          10634: From jkf@ucbmike  Mon Dec 10 17:08:13 1984
        !          10635: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10636:        id AA22000; Mon, 10 Dec 84 17:08:13 pst
        !          10637: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
        !          10638:        id AA10131; Mon, 10 Dec 84 17:05:36 pst
        !          10639: Received: by ucbmike.arpa (4.24ucb/4.33)
        !          10640:        id AA06315; Mon, 10 Dec 84 17:08:19 pst
        !          10641: Date: Mon, 10 Dec 84 17:08:19 pst
        !          10642: From: John Foderaro (on a sun) <jkf@ucbmike>
        !          10643: Message-Id: <[email protected]>
        !          10644: To: [email protected], franz-friends@BERKELEY
        !          10645: Subject: Re: array  - space
        !          10646: Cc: [email protected]
        !          10647: In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST
        !          10648: 
        !          10649:  One small correction: small-segment space is garbage collected and
        !          10650: reclaimed, but only as individual elements: adjacent free elements are
        !          10651: not combined.   Vectors are different: adjacent free vectors are combined
        !          10652: into larger vectors.
        !          10653: 
        !          10654: 
        !          10655: 
        !          10656: From @MIT-MC:smh@MIT-EDDIE  Mon Dec 10 19:02:52 1984
        !          10657: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10658:        id AA23540; Mon, 10 Dec 84 19:02:52 pst
        !          10659: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
        !          10660:        id AA11754; Mon, 10 Dec 84 18:21:17 pst
        !          10661: Message-Id: <[email protected]>
        !          10662: Received: by mit-eddie.Mit-chaos.Arpa id AA03264; Mon, 10 Dec 84 21:20:04 est
        !          10663: Date: Mon, 10 Dec 84 21:20:04 est
        !          10664: From: Steven M. Haflich <smh@mit-eddie>
        !          10665: To: franz-friends@BERKELEY
        !          10666: Subject: re: gensym and the compiler
        !          10667: 
        !          10668: <Mike@rice> wants to know how to make this function work:
        !          10669: 
        !          10670:        ; construct an identity transformation matrix.
        !          10671:        (defun tm-new ()
        !          10672:            (let ((name (gensym)))
        !          10673:                (*array name 'flonum-block 4 4)
        !          10674:                (do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
        !          10675:                name)
        !          10676:        )
        !          10677: 
        !          10678: The problem is that send is a macro (see lisplib/array.l), and at
        !          10679: compile time it is impossible for it to determine exactly the "data
        !          10680: type" of name.  Therefore, it expands the function to:
        !          10681: 
        !          10682:        (defun tm-new ()
        !          10683:            (let ((name (gensym)))
        !          10684:                (*array name 'flonum-block 4 4)
        !          10685:                (do i 0 (1+ i) (= i 4) (name 1.0 i i))
        !          10686:                name)
        !          10687:        )
        !          10688: 
        !          10689: Essentially, it just assumes 'name is a symbol which has an array in its
        !          10690: function binding, or else which symevals (possibly recursively) to
        !          10691: something that is either an array, or a symbol with an array in its
        !          10692: function binding.  When the compiler compiles the expansion, it assumes
        !          10693: that it wants to call the function-binding of name, not the
        !          10694: function-binding of symeval of name.  In the interpreter it happens to
        !          10695: work because eval of a list in the interpreter (but not the compiler) is
        !          10696: defined to repetitively evaluate the car of the list until it finds a
        !          10697: recognizable function or array.  (See chapter 4.)  But note!!  If 'name
        !          10698: also has a function binding, the interpreter will find it instead of the
        !          10699: array!
        !          10700: 
        !          10701: What you really want to do, then, is this:
        !          10702: 
        !          10703:        (defun tm-new ()
        !          10704:            (let ((name (gensym)))
        !          10705:                (*array name 'flonum-block 4 4)
        !          10706:                (do i 0 (1+ i) (= i 4) (funcall name 1.0 i i))
        !          10707:                name)
        !          10708:        )
        !          10709: 
        !          10710: This guarantees that name gets symevaled once before the interpreter
        !          10711: checks for function bindings, which also does the right thing in
        !          10712: compiled code.  Unfortunately, you will have to write this out by hand.
        !          10713: I don't see any way that the send macro can be fixed.  If it always
        !          10714: returned the extra funcall, then this simple case wouldn't work
        !          10715: compiled:
        !          10716: 
        !          10717:        (array foo ...)
        !          10718:        (store foo ...)
        !          10719: 
        !          10720: Did anyone follow any of this?
        !          10721: 
        !          10722: 
        !          10723: From [email protected]  Tue Dec 11 20:05:09 1984
        !          10724: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10725:        id AA06334; Tue, 11 Dec 84 20:05:09 pst
        !          10726: Received: from SUMEX-AIM.ARPA (sumex-aim.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10727:        id AA15218; Tue, 11 Dec 84 20:03:46 pst
        !          10728: Message-Id: <[email protected]>
        !          10729: Date: Tue 11 Dec 84 20:04:16-PST
        !          10730: From: Rene Bach <[email protected]>
        !          10731: Subject: Porting FRANZ to other OS running C ?
        !          10732: To: franz-friends@BERKELEY
        !          10733: 
        !          10734: I am interested in finding out if someone has ported FRANZ to some
        !          10735: other OS than UNIX. A friend of mine is interested in running a LISP
        !          10736: under VMS at no cost. He has C on his machine.
        !          10737: Is this feasible, how much work is involved ?
        !          10738: 
        !          10739: What about porting FRANZ to some UNIX look alike ?  How much work is
        !          10740: involved ?
        !          10741: 
        !          10742: Thanks for any leads
        !          10743: Rene
        !          10744: -------
        !          10745: 
        !          10746: From [email protected]  Tue Dec 11 20:44:19 1984
        !          10747: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10748:        id AA06672; Tue, 11 Dec 84 20:44:19 pst
        !          10749: Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10750:        id AA16044; Tue, 11 Dec 84 20:42:36 pst
        !          10751: Message-Id: <[email protected]>
        !          10752: Date: 11 Dec 84 23:41:49 EST
        !          10753: From: Sean McLinden  <[email protected]>
        !          10754: Subject: Re: Franz documentation for MIT LM code
        !          10755: To: smh%[email protected], franz-friends@BERKELEY
        !          10756: Cc: sridhar%[email protected], [email protected]
        !          10757: In-Reply-To: Message from "Steven M. Haflich <smh@mit-eddie>" of 4 Dec 84 23:50:01 EST
        !          10758: 
        !          10759: 
        !          10760: 
        !          10761:  Regarding the documentation for Franz Lisp and the MIT/Lisp Machine
        !          10762:  compatibility packages:
        !          10763: 
        !          10764:  Another option exists for those who might be interested. We at Decision
        !          10765:  Systems Lab have been using a modified version of Opus 38.89 which in-
        !          10766:  cludes the  defstruct and flavors code already described. It also in-
        !          10767:  cludes an Interlisp compatibility package which allows Interlisp
        !          10768:  records as well as most of the CLISP forms (these are actually very
        !          10769:  easily simulated with LOOP but we chose a strategy which is more
        !          10770:  in keeping with the Interlisp implementation of CLISP involving
        !          10771:  hashed definitions for CLISP forms.
        !          10772: 
        !          10773:  The modified Lisp has all of the up-to-date flavors code and an
        !          10774:  edited version of the manual which describes the format, defstruct,
        !          10775:  and CLISP packages (borrowing heavily from the Laser edition of
        !          10776:  the Common Lisp manual by Guy Steele). It also includes a re-organization
        !          10777:  of much of the older manual into a more coherent form, and a number
        !          10778:  of examples of more difficult concepts.
        !          10779: 
        !          10780:  If there is any interest I can make this publicly available. It would
        !          10781:  be of little value to simply have the additional chapter since it
        !          10782:  refers, heavily, to material in other sections. Also, flavors is not,
        !          10783:  yet included, since the status of flavors in Franz was uncertain up
        !          10784:  to a few months ago.
        !          10785: 
        !          10786:  For those interested, I will not be prepared to answer requests before
        !          10787:  Christmas but after that I'll be around and can handle almost anything.
        !          10788: 
        !          10789:  Sean McLinden
        !          10790:  Decision Systems Laboratory
        !          10791:  University of Pittsburgh
        !          10792: 
        !          10793: -------
        !          10794: 
        !          10795: From @MIT-MC:ZZZ.RLK@MIT-OZ  Wed Dec 12 21:51:39 1984
        !          10796: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10797:        id AA08208; Wed, 12 Dec 84 21:51:39 pst
        !          10798: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10799:        id AA07258; Wed, 12 Dec 84 21:03:56 pst
        !          10800: Message-Id: <[email protected]>
        !          10801: Date: Wednesday, 12 December 1984, 19:53-EST
        !          10802: From: Robert L. Krawitz <ZZZ.RLK@MIT-OZ>
        !          10803: Reply-To: rlk%mit-eecs at mit-mc.arpa
        !          10804: To: franz-friends@BERKELEY
        !          10805: 
        !          10806: Hi.
        !          10807: 
        !          10808: I'm writing a term paper on the procedure call in various languages,
        !          10809: perhaps on various languages on the VAX, perhaps just on the procedure
        !          10810: call in various dialects of Lisp on the Vax.
        !          10811: 
        !          10812: Could someone mail me some info on this subject (i. e. the calling
        !          10813: conventions, how/if the Vax procedure call instructions are used, etc.)
        !          10814: quickly, as this is the last week of classes and I don't want to take
        !          10815: too long on this paper.  Thanks.
        !          10816: 
        !          10817: Robert^Z
        !          10818: 
        !          10819: From psm@mitre-bedford  Mon Dec 17 09:05:35 1984
        !          10820: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10821:        id AA20993; Mon, 17 Dec 84 09:05:35 pst
        !          10822: Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10823:        id AA19421; Mon, 17 Dec 84 09:04:32 pst
        !          10824: Message-Id: <[email protected]>
        !          10825: Date: 17 Dec 1984 11:56:37-EST
        !          10826: From: psm@Mitre-Bedford
        !          10827: To: franz-friends@BERKELEY
        !          10828: Subject: Please add me to your  mailing list.
        !          10829: Cc: psm@Mitre-Bedford
        !          10830: 
        !          10831: Hi,
        !          10832: 
        !          10833: Would you please add me to your mailing list/ user's group.
        !          10834: (I hope this is the right place to make the request & it's not
        !          10835: franz-friends-request or something like that.  Sorry for the
        !          10836: inconvenience if it is.)
        !          10837: 
        !          10838: Peter Mager
        !          10839: (psm@mitre-bedford)
        !          10840: 
        !          10841: From jkf@ucbmike  Mon Dec 17 13:01:48 1984
        !          10842: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10843:        id AA00901; Mon, 17 Dec 84 13:01:48 pst
        !          10844: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
        !          10845:        id AA24456; Mon, 17 Dec 84 13:00:55 pst
        !          10846: Received: by ucbmike.arpa (4.24ucb/4.33)
        !          10847:        id AA15009; Mon, 17 Dec 84 13:03:16 pst
        !          10848: Date: Mon, 17 Dec 84 13:03:16 pst
        !          10849: From: John Foderaro (on a sun) <jkf@ucbmike>
        !          10850: Message-Id: <[email protected]>
        !          10851: To: psm@Mitre-Bedford, franz-friends@BERKELEY
        !          10852: Subject: Re: Please add me to your  mailing list.
        !          10853: Cc: psm@Mitre-Bedford
        !          10854: In-Reply-To: Your message of 17 Dec 1984 11:56:37-EST
        !          10855: 
        !          10856:  I've added you to franz-friends.
        !          10857:  
        !          10858: 
        !          10859: 
        !          10860: From jkf@ucbmike  Mon Dec 17 13:06:53 1984
        !          10861: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10862:        id AA01005; Mon, 17 Dec 84 13:06:53 pst
        !          10863: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
        !          10864:        id AA24568; Mon, 17 Dec 84 13:05:59 pst
        !          10865: Received: by ucbmike.arpa (4.24ucb/4.33)
        !          10866:        id AA15044; Mon, 17 Dec 84 13:08:10 pst
        !          10867: Date: Mon, 17 Dec 84 13:08:10 pst
        !          10868: From: John Foderaro (on a sun) <jkf@ucbmike>
        !          10869: Message-Id: <[email protected]>
        !          10870: To: franz-friends@BERKELEY
        !          10871: Subject: I'll be away
        !          10872: Cc: 
        !          10873: 
        !          10874: 
        !          10875:   For the new few weeks I'll be unable to handle franz-friends requests.
        !          10876: 
        !          10877:   Happy Holidays to all of you.
        !          10878: 
        !          10879:                                        john foderaro
        !          10880:                                        
        !          10881:   
        !          10882: 
        !          10883: 
        !          10884: From @MIT-MC:[email protected]  Mon Dec 17 13:08:08 1984
        !          10885: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10886:        id AA01035; Mon, 17 Dec 84 13:08:08 pst
        !          10887: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10888:        id AA24610; Mon, 17 Dec 84 13:07:10 pst
        !          10889: Message-Id: <[email protected]>
        !          10890: Date: 17 Dec 84 16:02:13 EST
        !          10891: From: Wilson.Harvey@CMU-CS-IUS
        !          10892: Subject: appending to files in lisp?
        !          10893: To: BBoard.Maintainer@CMU-CS-A
        !          10894: 
        !          10895: 
        !          10896: Does anyone have a function that will allow them to append to a file?  I
        !          10897: need to open a file and write some data to it then, at a later time, reopen
        !          10898: the same file and add some more data to it.  The only things that I could
        !          10899: find in Franz were "infile" and "outfile", and "outfile" truncates the file
        !          10900: when called.  It would be nice if the function would create the file if it
        !          10901: didn't already exist, but that is not necessary.
        !          10902: 
        !          10903: Thanks. --Wilson
        !          10904: 
        !          10905: P.S. I tried writing a C-function to handle this, but I didn't have any luck
        !          10906: passing the FILE pointer back into Franz.  It didn't recognize the pointer
        !          10907: as a port, and I don't know how to set it straight.
        !          10908: 
        !          10909: 
        !          10910: From [email protected]  Mon Dec 17 13:31:59 1984
        !          10911: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10912:        id AA01357; Mon, 17 Dec 84 13:31:59 pst
        !          10913: Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10914:        id AA25405; Mon, 17 Dec 84 13:30:56 pst
        !          10915: Message-Id: <[email protected]>
        !          10916: Date:     Mon, 17 Dec 84 16:23:16 EST
        !          10917: From: William K. Cadwallender (LCWSL) <[email protected]>
        !          10918: To: franz-friends@BERKELEY
        !          10919: Subject:  Please change my ID
        !          10920: 
        !          10921: The computer people here at ARDC have changed my ID: I was wkc@ARDC, I am
        !          10922: now cadwall@ARDC. Please update the franz-friends mailer accordingly.
        !          10923:                                Thanks,
        !          10924:                                Bill Cadwallender
        !          10925:                                (now cadwall@ARDC)
        !          10926: 
        !          10927: From liz@tove  Tue Dec 18 12:19:24 1984
        !          10928: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10929:        id AA00302; Tue, 18 Dec 84 12:19:24 pst
        !          10930: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10931:        id AA04349; Tue, 18 Dec 84 11:54:53 pst
        !          10932: Received: by tove.ARPA (4.12/4.7)
        !          10933:        id AA26165; Tue, 18 Dec 84 14:54:41 est
        !          10934: From: Liz Allen <liz@tove>
        !          10935: Message-Id: <[email protected]>
        !          10936: Date: 18 Dec 1984 1454-EST (Tuesday)
        !          10937: To: Wilson.Harvey@CMU-CS-IUS
        !          10938: Cc: franz-friends@BERKELEY
        !          10939: Subject: Re: appending to files in lisp?
        !          10940: In-Reply-To: Your message of 17 Dec 84 16:02:13 EST.
        !          10941:              <[email protected]>
        !          10942: 
        !          10943: To append to a file, use the outfile function's second argument:
        !          10944: 
        !          10945:        (setq oport (outfile '<filename> 'append))
        !          10946: 
        !          10947: This is discussed in the documentation for outfile in the Franz Lisp
        !          10948: Manual.
        !          10949: 
        !          10950:                                -Liz
        !          10951: 
        !          10952: From @MIT-MC:[email protected]  Tue Dec 18 16:46:44 1984
        !          10953: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10954:        id AA02563; Tue, 18 Dec 84 16:46:44 pst
        !          10955: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10956:        id AA10079; Tue, 18 Dec 84 16:15:50 pst
        !          10957: Message-Id: <[email protected]>
        !          10958: Date: 17 Dec 84 23:04:24 EST
        !          10959: From: Wilson.Harvey@CMU-CS-IUS
        !          10960: Subject: appendfile question answered
        !          10961: To: BBoard.Maintainer@CMU-CS-A
        !          10962: 
        !          10963: 
        !          10964: Wow, was that an easy question.  All the responces were equally simple (use
        !          10965: "fileopen" with mode = a, or use "outfile" with the extra argument
        !          10966: "append").
        !          10967: 
        !          10968: I must have an outdated copy of the manual because I could find none of
        !          10969: these "features" documented.  A hearty "Thank you" to all who responded.
        !          10970: 
        !          10971: Wilson
        !          10972: 
        !          10973: 
        !          10974: From [email protected]  Wed Jan  2 03:00:04 1985
        !          10975: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          10976:        id AA08140; Wed, 2 Jan 85 03:00:04 pst
        !          10977: Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
        !          10978:        id AA01144; Wed, 2 Jan 85 02:51:04 pst
        !          10979: Message-Id: <[email protected]>
        !          10980: Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a029713
        !          10981:           ;2 Jan 85 5:57 EST
        !          10982: To: franz-friends@BERKELEY
        !          10983: Cc: johnson@udel-dewey
        !          10984: Subject: franz on 68k-based systems? (esp NCR tower)
        !          10985: Date: 02 Jan 85 05:57:37 EST (Wed)
        !          10986: From: johnson <johnson@udel-dewey>
        !          10987: 
        !          10988: 
        !          10989: Has anyone out there had experience using franz (or similar lisps)
        !          10990: on an NCR tower or tower XP? (or any other 68k-based unix system ?)
        !          10991: 
        !          10992: I am interested in answers to these questions:
        !          10993: 
        !          10994:  1. What version of (franz) lisp are you using.
        !          10995: 
        !          10996:  2. Are there any special problems you've discovered in this system?
        !          10997: 
        !          10998:  3. How does this system perform? (compared to franz on a VAX 11/70,
        !          10999:        assuming you have had experience with both)
        !          11000: 
        !          11001:  4. Where did you obtain your version of (franz) lisp and how?
        !          11002:     (what media, what cost, under what terms or license?)
        !          11003: 
        !          11004:  thanks in advance,
        !          11005:  johnson@udel-ee
        !          11006: 
        !          11007: From sridhar%[email protected]  Thu Jan 24 00:31:15 1985
        !          11008: Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
        !          11009:        id AA12825; Thu, 24 Jan 85 00:31:15 pst
        !          11010: Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.40)
        !          11011:        id AA15268; Thu, 24 Jan 85 00:31:03 pst
        !          11012: Message-Id: <[email protected]>
        !          11013: Received: from wsu by csnet-relay.csnet id a006053; 24 Jan 85 3:16 EST
        !          11014: Date:     Wed, 23 Jan 85 21:50 PST
        !          11015: From: "S. Sridhar" <sridhar%[email protected]>
        !          11016: To: cross%[email protected]
        !          11017: Cc: [email protected]
        !          11018: Subject:  pretty printing
        !          11019: 
        !          11020: Is there any way I can pretty-print Franz lisp function (or files) with all
        !          11021: the comments in tact. Right now when I use the built in pp, it pretty prints
        !          11022: and strips off all comments. I mean is there any built-in function that does
        !          11023: this. Thanks.
        !          11024: 
        !          11025: Sridhar (sridhar@wsu)
        !          11026: 
        !          11027: From [email protected]  Thu Jan 24 05:33:59 1985
        !          11028: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11029:        id AA14557; Thu, 24 Jan 85 05:33:59 pst
        !          11030: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11031:        id AA00666; Thu, 24 Jan 85 05:16:27 pst
        !          11032: Message-Id: <[email protected]>
        !          11033: Date:     Thu, 24 Jan 85 7:59:46 EST
        !          11034: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
        !          11035: To: "S. Sridhar" <sridhar%[email protected]>
        !          11036: Cc: Franz-Friends@BERKELEY
        !          11037: Subject:  Re:  pretty printing
        !          11038: 
        !          11039: Haah,
        !          11040: 
        !          11041: Franz's (read) function trashes all comments on input. [Which means
        !          11042: you can document your data files.]  You have to pretty-print the
        !          11043: original code before Franz gets it.  I don't know of any stand-alone
        !          11044: programs to do this (surely someone has written one).  I use
        !          11045: Berkeley's "vi" editor because it has a lisp mode; all input is
        !          11046: automatically pretty-printed if you say
        !          11047:   :set ai lisp
        !          11048: (ai stands for autoindent)
        !          11049: Another way is to execute the vi "=" command while in lisp mode.  All
        !          11050: of this is documented in the vi manual.  Hope this helps.
        !          11051: 
        !          11052:                                         dsw, fferd
        !          11053:                                         Fred S. Brundick
        !          11054:                                         USABRL, APG, MD.
        !          11055:                                         <fsbrn@brl-voc>
        !          11056: 
        !          11057: From @MIT-MC:smh@MIT-EMS  Thu Jan 24 06:01:33 1985
        !          11058: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11059:        id AA14651; Thu, 24 Jan 85 06:01:33 pst
        !          11060: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11061:        id AA00458; Thu, 24 Jan 85 06:00:41 pst
        !          11062: Message-Id: <[email protected]>
        !          11063: Received: by mit-ems.Mit-chaos.Arpa id AA25956; Thu, 24 Jan 85 08:59:42 est
        !          11064: Date: Thu, 24 Jan 85 08:59:42 est
        !          11065: From: Steven Haflich <smh@mit-ems>
        !          11066: To: franz-friends@BERKELEY, sridhar%wsu.csnet@csnet-relay
        !          11067: Subject: Re: pretty printing
        !          11068: 
        !          11069: Since comments are not part of a Lisp form returned by `read', clearly
        !          11070: no pretty-print function can do what you want.  Certainly a far more
        !          11071: complicated pretty-printer could be written which would be passed an
        !          11072: ascii file to read and which would somehow preserve comments inside the
        !          11073: form in order to regurgitate them during formatting.  The problem has
        !          11074: several complications, however, such as how to handle ascii Lisp text
        !          11075: with conditionalized inclusions (`#+' constructions)...
        !          11076: 
        !          11077: Instead, what you want is probably provided the Lisp-mode `grind'
        !          11078: facilities available in several popular text editors -- in particular,
        !          11079: EMACS.  (I know CCA EMACS works, and believe Gosling EMACS does also.)
        !          11080: In these editors a couple keystrokes will specify a region of text and
        !          11081: apply one of several Lisp-indentation algorithms to it.  They almost
        !          11082: always indent in reasonable ways, and attempt to do reasonable things
        !          11083: with comments, at least.  The ones with which I am familiar will *not*,
        !          11084: however, adjust line length length by moving either comment or Lisp
        !          11085: text from line to line.  This is not a great problem for normal
        !          11086: human-typed text, such as programs, since one tends not to type
        !          11087: absurdly long lines.
        !          11088: 
        !          11089: 
        !          11090: From peck@sri-spam  Wed Feb  6 12:01:17 1985
        !          11091: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11092:        id AA28782; Wed, 6 Feb 85 12:01:17 pst
        !          11093: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11094:        id AA04441; Wed, 6 Feb 85 12:00:09 pst
        !          11095: Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
        !          11096:        id AA08198; Wed, 6 Feb 85 12:00:05 pst
        !          11097: Message-Id: <[email protected]>
        !          11098: Date: 06 Feb 85 11:59:58 PST (Wed)
        !          11099: To: ailist-request@sri-ai, franz-friends@BERKELEY
        !          11100: Subject: AI, Lisp, Graphics on SUN computers?
        !          11101: From: peck@sri-spam
        !          11102: 
        !          11103: I would like to here from anyone using SUN computers 
        !          11104: who can supply answers or comments on any of these issues:
        !          11105:  Is Franz the only (best) lisp available?
        !          11106:  Has anyone used the Maryland Flavors to create useful tools/extensions?
        !          11107:  Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
        !          11108:  Any differential reports of Prolog (Quintus) vs Lisp ?
        !          11109:  Any obvious alternative to SUN? (vendor in same class (Tektronix?))
        !          11110:  Worst or hidden problems, pitfalls, gotcha's, etc.
        !          11111: > Can real AI development (even applications) be supported on SUN's? <
        !          11112: 
        !          11113: From kessler%utah-orion@utah-cs  Wed Feb  6 15:58:12 1985
        !          11114: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11115:        id AA03031; Wed, 6 Feb 85 15:58:12 pst
        !          11116: Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11117:        id AA06871; Wed, 6 Feb 85 13:46:19 pst
        !          11118: Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1)
        !          11119:        id AA03096; Wed, 6 Feb 85 14:37:05 MST
        !          11120: Received: by utah-orion.ARPA (4.42/4.40.1)
        !          11121:        id AA10406; Wed, 6 Feb 85 14:36:22 MST
        !          11122: Date: Wed, 6 Feb 85 14:36:22 MST
        !          11123: From: kessler%utah-orion@utah-cs (Robert Kessler)
        !          11124: Message-Id: <[email protected]>
        !          11125: To: [email protected]
        !          11126: Cc: [email protected], franz-friends@BERKELEY
        !          11127: Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message)
        !          11128: In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed).
        !          11129:             <[email protected]>
        !          11130: 
        !          11131: 
        !          11132:  > I would like to here from anyone using SUN computers 
        !          11133:  > who can supply answers or comments on any of these issues:
        !          11134:  >  Is Franz the only (best) lisp available?
        !          11135: We have finally finished porting Portable Standard LISP (PSL) to yet
        !          11136: another machine.  This time it is now running on the SUN.  Initial
        !          11137: timing measurements indicate that its speed is somewhere between a 
        !          11138: Vax 750 and 780 (all running PSL), and about twice as fast as Franz running
        !          11139: the REDUCE algebra system test on Suns.  We are now running the Gabriel
        !          11140: benchmarks to discover where it fits in the set.  For more details
        !          11141: see the announcement at the end of this message.
        !          11142:  >  Has anyone used the Maryland Flavors to create useful tools/extensions?
        !          11143: PSL provides support for a simple flavors package that seems quite
        !          11144: useful.  However, the current version has no inheritance.
        !          11145:  >  Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
        !          11146: We have oload working which allows you to call externally compiled
        !          11147: routines (like other c sources).  So the interface should be easy to
        !          11148: add (but we haven't done it).
        !          11149:  >  Any differential reports of Prolog (Quintus) vs Lisp ?
        !          11150: None that I know of.
        !          11151:  >  Any obvious alternative to SUN? (vendor in same class (Tektronix?))
        !          11152: PSL also runs on Apollo's and HP Series 200 (both 68K based machines).
        !          11153: We have also ported a simple "educational" version to the 128K
        !          11154: Macintosh which is used in a beginning programming class.  We plan on
        !          11155: moving at least the Standard LISP subset and compiler to the 512K mac
        !          11156: (so if you want to go really cheap...... :-) )
        !          11157:  >  Worst or hidden problems, pitfalls, gotcha's, etc.
        !          11158: We had a lot of problems with the Sun port.  Some were hardware
        !          11159: related, others were differences between Unix 4.2 on the Sun and on the
        !          11160: Vax.  After we get some more experience using PSL on the machine, maybe
        !          11161: we could report more.
        !          11162:  > > Can real AI development (even applications) be supported on SUN's? <
        !          11163: I think so, as long as you can get one with enough memory.  Some of our
        !          11164: applications running on HP 9836's (which doesn't have virtual memory)
        !          11165: really fly (better than a 780 in speed).  So, memory is really a key to
        !          11166: a fast machine.
        !          11167:  > 
        !          11168: Bob.
        !          11169: 
        !          11170:                   PSL 3.2 for the SUN Workstation
        !          11171: 
        !          11172: We are pleased to announce that Portable Standard LISP (PSL) version
        !          11173: 3.2 is now available for the Sun workstation.  PSL is about the power,
        !          11174: speed and flavor  of Franz LISP or  MACLISP, with growing  influence
        !          11175: from Common  LISP.  It  is recognized  as an  efficient and  portable
        !          11176: LISP implementation with  many  more capabilities  than  described in
        !          11177: the  1979 Standard LISP Report.  PSL's main  strength is its
        !          11178: portability across  many different  systems,   including:   Vax  BSD
        !          11179: Unix, Vax VMS,  Extended   Addressing DecSystem-20 Tops-20, Apollo
        !          11180: DOMAIN  Aegis, and HP  Series 200.  A  version for the IBM-370 is in
        !          11181: beta test and two Cray versions are being used on an experimental
        !          11182: basis.  Since PSL generates very efficient code, it is an ideal
        !          11183: delivery vehicle for LISP based applications (we can  also provide  PSL
        !          11184: reseller  licenses for  binary only  and  source distributions).
        !          11185: 
        !          11186: PSL is distributed for the  various systems with executables, all
        !          11187: sources, an approximately  500 page  manual and  release notes.   The
        !          11188: release  notes describe how to install the system and how to rebuild
        !          11189: the various  modules.  We are charging  $750 for the  Sun version of
        !          11190: PSL for Commercial  Site licenses.  Non-profit institutions and all
        !          11191: other versions of PSL will  not be charged a license fee.  We are also
        !          11192: charging a $250 tape distribution fee for each system.
        !          11193: 
        !          11194: PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard,
        !          11195: Rand, Stanford, Columbia and over  250 other sites.   Many existing
        !          11196: programs  and applications have been  adapted to  PSL including
        !          11197: Hearn's REDUCE  computer algebra system and GLISP, Novak's object
        !          11198: oriented LISP dialect.  These  are available from Hearn and Novak.
        !          11199: 
        !          11200: To obtain a copy of the license  and order form, please send a NET
        !          11201: message or letter with your US MAIL address to:
        !          11202: 
        !          11203: Utah Symbolic Computation Group Secretary
        !          11204: University of Utah - Dept. of Computer Science
        !          11205: 3160 Merrill Engineering Building
        !          11206: Salt Lake City, Utah 84112
        !          11207: 
        !          11208: ARPANET: CRUSE@UTAH-20
        !          11209: USENET:  utah-cs!cruse
        !          11210: 
        !          11211: From cas@cvl  Thu Feb 21 11:40:59 1985
        !          11212: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11213:        id AA17380; Thu, 21 Feb 85 11:40:59 pst
        !          11214: Received: from cvl.ARPA (cvl.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11215:        id AA23930; Thu, 21 Feb 85 11:33:27 pst
        !          11216: Received: by cvl.ARPA (4.12/4.7)
        !          11217:        id AA09421; Thu, 21 Feb 85 14:38:26 est
        !          11218: Date: Thu, 21 Feb 85 14:38:26 est
        !          11219: From: cas@cvl (Cliff Shaffer)
        !          11220: Message-Id: <[email protected]>
        !          11221: To: franz-friends@BERKELEY
        !          11222: Subject: database system request
        !          11223: 
        !          11224: 
        !          11225: Does anybody know of a database system written in FRANZ or easily
        !          11226: compatible with FRANZ?  We have written a lot of software for a
        !          11227: geographic information system, and may want to redo the section which
        !          11228: handles random bits of information associated with polygons or points
        !          11229: stored in a map.  Right now we store this information as a property
        !          11230: list on an atom associated with the polygon or point in question.  This
        !          11231: becomes very inefficient when we want to find all such atoms with
        !          11232: a particular value for some arbitrary property.  Equally importantly,
        !          11233: there is very little relationship between the set of properties associated
        !          11234: with each polygon or point, so a system storing a fixed length record
        !          11235: for each polygon, with fields for each piece of information, would not work.
        !          11236: Any suggestions?
        !          11237:                Cliff Shaffer
        !          11238:                cas@cvl
        !          11239: 
        !          11240: From layer@ucbdali  Thu Feb 21 12:54:14 1985
        !          11241: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
        !          11242:        id AA18356; Thu, 21 Feb 85 12:54:14 pst
        !          11243: Received: by ucbdali.ARPA (4.24/4.40)
        !          11244:        id AA16858; Thu, 21 Feb 85 12:53:47 pst
        !          11245: Date: Thu, 21 Feb 85 12:53:47 pst
        !          11246: From: layer@ucbdali (Kevin Layer)
        !          11247: Message-Id: <[email protected]>
        !          11248: Phone: (415) 652-2405
        !          11249: To: cas@cvl, franz-friends@kim
        !          11250: Subject: Re:  database system request
        !          11251: 
        !          11252: You could use the dbm library, as supplied by UNIX (/usr/lib/libdbm.a),
        !          11253: via cfasl and getaddress.
        !          11254: 
        !          11255:        Kevin
        !          11256: 
        !          11257: 
        !          11258: From freemant%[email protected]  Mon Feb 25 04:50:50 1985
        !          11259: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11260:        id AA20175; Mon, 25 Feb 85 04:50:50 pst
        !          11261: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.41)
        !          11262:        id AA24603; Mon, 25 Feb 85 04:43:20 pst
        !          11263: Date: Mon, 25 Feb 85 04:43:17 pst
        !          11264: Message-Id: <[email protected]>
        !          11265: Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST
        !          11266: From: freemant%[email protected]
        !          11267: To: franz-friends@BERKELEY
        !          11268: 
        !          11269: Hello!  Our version of lxref didn't work right when it was passed the -a
        !          11270: option, so I fixed it.  Someone may want to use the -a option on lxref one
        !          11271: of these days, so I am mailing you my fixes in hopes that you will
        !          11272: distribute them.  
        !          11273: 
        !          11274: Things are kind of chaotic around here, so I am not sure that I was working
        !          11275: with the most current version of lxref.  Make sure that your current version
        !          11276: of lxref matches the code that I changed before you edit in my changes.
        !          11277: 
        !          11278: The origional definition of the function process-annotate-file left files
        !          11279: open.  Because the lisp interpreter can only have a finite number of files
        !          11280: open at once, this caused lxref to bomb when it was given a large job to do.
        !          11281: To fix this, I changed the definition of process-annotate-file from:
        !          11282: 
        !          11283: (defun process-annotate-file (filename)
        !          11284:    (let (sourcep outp)
        !          11285:       ; make sure file exists and write annotate file as a
        !          11286:       ; file with the prefix #,
        !          11287:       (if (null (errset (setq sourcep (infile filename))))
        !          11288:         then (msg "will ignore that file " N)
        !          11289:         else ; will write to file.A (erasing the final l)
        !          11290:              (let ((filen (concat "#," filename)))
        !          11291:                 (setq outp (outfile filen))
        !          11292:                 (anno-it sourcep outp)
        !          11293:                 (close outp)
        !          11294:                 ; now mv the original filename to #dfilename
        !          11295:                 ; and the annotated file to the original file
        !          11296:                 (let ((oldcopy (concat "#." filename)))
        !          11297:                    (if (null (errset
        !          11298:                                 (progn (if (probef oldcopy)
        !          11299:                                           then (sys:unlink oldcopy))
        !          11300:                                        (sys:link filename oldcopy)
        !          11301:                                        (sys:unlink filename)
        !          11302:                                        (sys:link filen filename)
        !          11303:                                        (sys:unlink filen))))
        !          11304:                       then (msg "An error occured while mving files around "
        !          11305:                                 N
        !          11306:                                 "files possibly affected "
        !          11307:                                 filename oldcopy filen)))))))
        !          11308: 
        !          11309: to:
        !          11310: 
        !          11311: (defun process-annotate-file (filename)
        !          11312:    (let (sourcep outp)
        !          11313:       ; make sure file exists and write annotate file as a
        !          11314:       ; file with the prefix #,
        !          11315:       (if (null (errset (setq sourcep (infile filename))))
        !          11316:         then (msg "will ignore that file " N)
        !          11317:         else ; will write to file.A (erasing the final l)
        !          11318:              (let ((filen (concat "#," filename)))
        !          11319:                 (setq outp (outfile filen))
        !          11320:                 (anno-it sourcep outp)
        !          11321:                 (close outp)
        !          11322:                 (close sourcep)
        !          11323:                 ; now mv the original filename to #dfilename
        !          11324:                 ; and the annotated file to the original file
        !          11325:                 (let ((oldcopy (concat "#." filename)))
        !          11326:                    (if (null (errset
        !          11327:                                 (progn (if (probef oldcopy)
        !          11328:                                           then (sys:unlink oldcopy))
        !          11329:                                        (sys:link filename oldcopy)
        !          11330:                                        (sys:unlink filename)
        !          11331:                                        (sys:link filen filename)
        !          11332:                                        (sys:unlink filen))))
        !          11333:                       then (msg "An error occured while mving files around "
        !          11334:                                 N
        !          11335:                                 "files possibly affected "
        !          11336:                                 filename oldcopy filen)))))))
        !          11337: 
        !          11338: Note that the only change is the insertion of one close statement.
        !          11339: 
        !          11340: The other bug I found was that find-func miserably failed to do its job
        !          11341: right.  The origional version of the function looked like this:
        !          11342: 
        !          11343: (defun find-func (buf)
        !          11344:    ; first locate first space or tab
        !          11345:    (do ((i 1 (1+ i))
        !          11346:        (max (cxr 0 buf))
        !          11347:        (die))
        !          11348:        ((or (setq die (not (<& i max)))
        !          11349:            (memq (cxr i buf) '(#\space #\tab)))
        !          11350:        (if die
        !          11351:           then nil     ; can find it, so give up
        !          11352:           else ; find first non blank
        !          11353:                (do ((ii i (1+ ii)))
        !          11354:                    ((or (setq die (not (<& ii max)))
        !          11355:                         (not (memq (cxr ii buf) '(#\space #\tab))))
        !          11356:                     (if (or die (eq (cxr ii buf) #\lpar))
        !          11357:                        then nil
        !          11358:                        else ; fid first sep or left paren
        !          11359:                             (do ((iii (1+ ii) (1+ iii)))
        !          11360:                                 ((or (not (<& iii max))
        !          11361:                                      (memq (cxr iii buf)
        !          11362:                                            '(#\space #\tab #\lpar)))
        !          11363:                                  (implode-fun buf ii (1- iii)))))))))))
        !          11364: 
        !          11365: Not unsurprisingly, this code didn't work.  I discarded it and rewrote the
        !          11366: function in a much simpler fashion:
        !          11367: 
        !          11368: (defun find-func (buf)
        !          11369:     (let ((i 1)
        !          11370:          (max (cxr 0 buf))
        !          11371:          (result nil))
        !          11372:         (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab)))
        !          11373:               do (setq i (+ i 1)))
        !          11374:         (loop while (and (not (greaterp i max))
        !          11375:                          (memq (cxr i buf) '(#\space #\tab))) do
        !          11376:               (setq i (+ i 1)))
        !          11377:         (loop until (or (greaterp i max)
        !          11378:                         (memq (cxr i buf) 
        !          11379:                               '(#\space #\tab #.(getcharn '|(| 1)))) do
        !          11380:               (setq result (cons (cxr i buf) result))
        !          11381:               (setq i (+ i 1)))
        !          11382:         (if result then (implode (reverse result)) else nil)))
        !          11383: 
        !          11384: The error in the origional definition of find-func caused the -a option to
        !          11385: always do nothing.  It is surprising that no one caught the fact that the -a
        !          11386: option was useless earlier.  (However, I am not sure that the source that I
        !          11387: was looking at came from your tape, so perhaps it isn't your fault.)  In any
        !          11388: case, my version works.
        !          11389: 
        !          11390: Bye!
        !          11391:                                        Tim Freeman
        !          11392:                                        freemant@rpi
        !          11393: 
        !          11394: From bane@gymble  Wed Feb 27 12:20:08 1985
        !          11395: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11396:        id AA19926; Wed, 27 Feb 85 12:20:08 pst
        !          11397: Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11398:        id AA13078; Wed, 27 Feb 85 12:12:21 pst
        !          11399: Received: by gymble.ARPA (4.12/4.7)
        !          11400:        id AA25775; Wed, 27 Feb 85 15:17:32 est
        !          11401: Date: Wed, 27 Feb 85 15:17:32 est
        !          11402: From: John R. Bane <bane@gymble>
        !          11403: Message-Id: <[email protected]>
        !          11404: To: franz-friends@BERKELEY
        !          11405: Subject: symeval 'feature'
        !          11406: 
        !          11407:        I've just finished a half-hour "It works interpreted but not compiled"
        !          11408: debugging session with a user who was new to compiling Franz, and I have a
        !          11409: complaint. The function 'symeval' works misleadingly differently interpreted
        !          11410: and compiled.
        !          11411: 
        !          11412:        Compiled symeval open-codes into a symbol value-cell reference. This
        !          11413: is fine. Interpreted symeval is implemented as a pointer to 'eval'.  This
        !          11414: loses because something like (symeval '(+ 1 2)) is not an error interpreted,
        !          11415: and it should be because it turns into the worst kind of bug when compiled,
        !          11416: since it'll return some random pointer from cons node space.
        !          11417: 
        !          11418:        This 'feature' was observed in Opus 38.91.
        !          11419: 
        !          11420: From [email protected]  Thu Feb 28 11:37:06 1985
        !          11421: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11422:        id AA04105; Thu, 28 Feb 85 11:37:06 pst
        !          11423: Received: from wisc-ai.arpa (wisc-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11424:        id AA08982; Thu, 28 Feb 85 11:29:20 pst
        !          11425: Date: Thu, 28 Feb 85 13:34:20 cst
        !          11426: From: [email protected] (David Neves)
        !          11427: Message-Id: <[email protected]>
        !          11428: Received: by wisc-ai.arpa; Thu, 28 Feb 85 13:34:20 cst
        !          11429: To: franz-friends@BERKELEY
        !          11430: Subject: franz to vi & back
        !          11431: 
        !          11432: We have a heavily loaded vax on which we run our Lisp classes.  It
        !          11433: seems to me that we could lessen the load by not having VI start
        !          11434: up anew every time the student does a VIL in Franz.  
        !          11435: 
        !          11436: It would be nice to have two processes, one Lisp and the other VI.
        !          11437: There would be a function (like VIL) in Franz that would start up
        !          11438: a VI process if there wasn't one and if there was a VI process just
        !          11439: goto it.  When the student is finished editing the file he/she would
        !          11440: hit a key that would save out the file and return to Lisp (without
        !          11441: killing the VI process).  I believe that Gosling Emacs had something
        !          11442: like this, only more sophisticated.
        !          11443: 
        !          11444: My questions.  Has anyone done this for Franz & VI?  Would this help
        !          11445: the load average on a VAX?  If no one has done it, would it be difficult
        !          11446: to do?
        !          11447: -Thanks, David
        !          11448: 
        !          11449: From moore.losangel%[email protected]  Thu Feb 28 16:20:09 1985
        !          11450: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11451:        id AA08882; Thu, 28 Feb 85 16:20:09 pst
        !          11452: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11453:        id AA05586; Thu, 28 Feb 85 16:12:12 pst
        !          11454: Message-Id: <[email protected]>
        !          11455: Received: from ibm-sj by csnet-relay.csnet id ac15203; 28 Feb 85 19:11 EST
        !          11456: Date: Thu, 28 Feb 85 15:34:11 PST
        !          11457: From: Jim moore <moore.losangel%[email protected]>
        !          11458: To: [email protected], franz-friends@BERKELEY
        !          11459: Subject: Can/does Franz exist on PC/IX or VM/IX?
        !          11460: 
        !          11461: I am looking for a high quality LISP to run under PC(VM)/IX.
        !          11462:  
        !          11463: Is Franzlisp the one?  Who & How?
        !          11464:  
        !          11465: If not, which?
        !          11466:  
        !          11467: Thanks in advance -- Jim Moore
        !          11468:  
        !          11469: (MOORE.LOSANGEL@IBM)
        !          11470:  
        !          11471: p.s. pls reply directly since I'm not on this list.
        !          11472:  
        !          11473: 
        !          11474: From [email protected]  Fri Mar  1 04:29:27 1985
        !          11475: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11476:        id AA17511; Fri, 1 Mar 85 04:29:27 pst
        !          11477: Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11478:        id AA18449; Fri, 1 Mar 85 04:21:31 pst
        !          11479: Message-Id: <[email protected]>
        !          11480: Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009017
        !          11481:           ;1 Mar 85 7:18 EST
        !          11482: To: David Neves <[email protected]>
        !          11483: Cc: franz-friends@BERKELEY, johnson@udel-dewey
        !          11484: Subject: Re: franz to vi & back
        !          11485: In-Reply-To: Your message of Thu, 28 Feb 85 13:34:20 cst.
        !          11486:             <[email protected]>
        !          11487: Date: 01 Mar 85 07:18:11 EST (Fri)
        !          11488: From: johnson@udel-dewey
        !          11489: 
        !          11490: 
        !          11491: Subject: franz to vi & back
        !          11492: 
        !          11493: > We have a heavily loaded vax on which we run our Lisp classes.  It
        !          11494: > seems to me that we could lessen the load by not having VI start
        !          11495: > up anew every time the student does a VIL in Franz.  
        !          11496: > 
        !          11497: > It would be nice to have two processes, one Lisp and the other VI.
        !          11498: > There would be a function (like VIL) in Franz that would start up
        !          11499: > a VI process if there wasn't one and if there was a VI process just
        !          11500: > goto it.  When the student is finished editing the file he/she would
        !          11501: > hit a key that would save out the file and return to Lisp (without
        !          11502: > killing the VI process).  I believe that Gosling Emacs had something
        !          11503: > like this, only more sophisticated.
        !          11504: > 
        !          11505: > My questions.  Has anyone done this for Franz & VI?  Would this help
        !          11506: > the load average on a VAX?  If no one has done it, would it be difficult
        !          11507: > to do?
        !          11508: > 
        !          11509: 
        !          11510: I have developed something similar to what you describe, for franz
        !          11511: running under bsd4.2
        !          11512: 
        !          11513: It was moderately difficult at the time, but I was just learning to
        !          11514: exploit job control.
        !          11515: 
        !          11516: in this system, the user invokes: 
        !          11517: (vif  foo)
        !          11518: to edit the function foo.
        !          11519: 
        !          11520: when he is finished editing, he saves the current buffer by:
        !          11521: :w
        !          11522: then exits the editor by pressing:
        !          11523: ^Z  [NOT wq!!]
        !          11524: 
        !          11525: (getting users o use ^Z rather than wq is the biggest difficulty)
        !          11526: 
        !          11527: the function is the read from a temporary file which is created
        !          11528: by vif.
        !          11529: 
        !          11530: if the user later wishes to modify the SAME function [often the case]
        !          11531: he simply invokes:
        !          11532: (vif)
        !          11533: - and is returned to the [stopped] editing session EXACTLY where
        !          11534: he left it.  
        !          11535: [ providing some motivation for putting up with ^Z ]
        !          11536: 
        !          11537: 
        !          11538: The system people around here aren't too adventurous, so the only people
        !          11539: who use this system are my friends and myself, so I can't say what effect
        !          11540: it has on the load, [but it can only help]
        !          11541: 
        !          11542: one problem:  files in /tmp may accumulate, as there is no way to force
        !          11543: a user to clean up all editing sessions before exiting lisp.
        !          11544: [but that is what /tmp is for!]  you might warn your system people
        !          11545: to remove all VIF files that are over 2days old, or something like that.
        !          11546: 
        !          11547: 
        !          11548: note: this package knows about changes made by [cmu]edit, and may
        !          11549: be simplified if you are using a system where cmuedit is unavailable.
        !          11550: 
        !          11551: 
        !          11552: NOTE!!!!!!
        !          11553: Neither the University of Delaware
        !          11554: nor Apperson H. Johnson
        !          11555: relinquishes any rightts toi this software.
        !          11556: 
        !          11557: Please do NOT transfer the software without written permission
        !          11558: from both The University of Delaware and Apperson H. Johnson.
        !          11559: 
        !          11560: 
        !          11561: **********************************************************
        !          11562: setting up the system:
        !          11563: 
        !          11564: Script started on Fri Mar  1 06:49:30 1985
        !          11565: % make jced
        !          11566: cc  -c jced.c
        !          11567: cc  -c eroar.c
        !          11568: ld -o jcedmod.o -r  jced.o eroar.o
        !          11569: % lisp
        !          11570: Franz Lisp, Opus 38.79
        !          11571: -> [load 'vif]
        !          11572: [load vif.l]
        !          11573: /usr/lib/lisp/nld -N -x -A /usr/ucb/lisp -T 95800 jcedmod.o -e _jced_ -o /tmp/Li8788.0  -lc
        !          11574: t
        !          11575: -> [dumplisp newlisp]
        !          11576: nil
        !          11577: -> (exit)
        !          11578: script done on Fri Mar  1 06:51:45 1985
        !          11579: *******************************************************************
        !          11580: 
        !          11581: "newlisp" is now the lisp to use - you can put it in some directory
        !          11582: in youtr student's path
        !          11583: ----------  here is vif.l  --------------------------------
        !          11584: (setq sccid "#(@)vif.l V1.1    johnson@udel    10/13/84")
        !          11585: (eval-when (compile)
        !          11586:        (msg "vif doen't work compiled!!!\\ "N) (exit))
        !          11587: (declare (localf sccid))
        !          11588: ;
        !          11589: ;  uses job-control to allow ^Z from 'vi' to return to inside of
        !          11590: ;  Lisp function
        !          11591: ;
        !          11592: 
        !          11593: 
        !          11594: ; ::vif::
        !          11595: ;
        !          11596: ;  Usage: (vif [<function-name>])
        !          11597: ;  returns: t if function is loaded without errors, nil otherwise
        !          11598: ;  side-effect: starts vi with temporary file,
        !          11599: ;
        !          11600: ;  does NOT REMOVE FILE UNLESS SUCCESSFUL LOAD HAS BEEN MADE
        !          11601: ;  AND user has "quit" the editor
        !          11602: ;
        !          11603: ;  - allows ~instantaneous return to file being edited if
        !          11604: ;    vi has been exited by ^Z (or whatever the susp character is, [see stty.1])
        !          11605: ;   
        !          11606: ;  NOTE: file and vi session may stay "LIVE" even between invocations!!!
        !          11607: ; eg:
        !          11608: ;
        !          11609: ;  (def jnk '(lambda (x) "i am jnk"))
        !          11610: ;
        !          11611: ;  (vif jnk)
        !          11612: ;    --> vi session, followed by :w, and then ^Z
        !          11613: ;  t
        !          11614: ;  followed by  :
        !          11615: ;     (vif jnk ) 
        !          11616: ;  or:
        !          11617: ;     (vif)
        !          11618: ;   --> INSTANTLY returns to former vi session !!
        !          11619: ;
        !          11620: ;
        !          11621: ;
        !          11622: (declare (special *jced_lastf* *jced_lastc*  %changes))
        !          11623: 
        !          11624: (def vif
        !          11625:   (nlambda (fn)
        !          11626:     (prog (res tf er ppflag)
        !          11627:           (cond
        !          11628:            (fn
        !          11629:             (cond
        !          11630:              ((or (not (boundp '*jced_lastf*))
        !          11631:                   (neq *jced_lastf* (car fn)))
        !          11632:               (setq ppflag t)
        !          11633:               (setq *jced_lastf* (car fn))))))
        !          11634:           (cond ((boundp '*jced_lastf*)
        !          11635:                  (setq tf
        !          11636:                        (substring (concat '/tmp/VF
        !          11637:                                           (concat (syscall 20)
        !          11638:                                                   (concat '_
        !          11639:                                                           *jced_lastf*)))
        !          11640:                                   1))
        !          11641:                  (cond
        !          11642:                   ((and (boundp '%changes)
        !          11643:                         (memq *jced_lastf* %changes)
        !          11644:                         (or (not (boundp '*jced_lastc*))
        !          11645:                             (neq *jced_lastc* (memq *jced_lastf* %changes))))
        !          11646:                    (setq ppflag t)))
        !          11647:                  (cond
        !          11648:                   (ppflag
        !          11649:                    (eval (list 'pp (list 'F tf) *jced_lastf*)))))
        !          11650:                 (t (msg "vif: edit what ??" N) (return nil)))
        !          11651:      lp   (setq res (jced_ tf ""))
        !          11652:           (setq er nil)
        !          11653:           (setq ER%all '(lambda (x)
        !          11654:                                 (setq er t))
        !          11655:                         )
        !          11656:           (cond
        !          11657:            ((not (probef tf))
        !          11658:             (msg "vif: cannot find " tf)
        !          11659:             (cond
        !          11660:              ((eq res 1)
        !          11661:               (msg " want to return to the editor? {y/n} ")
        !          11662:               (cond ((eq (read) 'y) (go lp)))
        !          11663:                          (return nil)))
        !          11664:             (msg " sorry." N)
        !          11665:             (makunbound '*jced_lastf*)
        !          11666:             (return t)))
        !          11667:           (errset (load tf))
        !          11668:           (cond
        !          11669:            ((boundp '%changes)
        !          11670:             (setq *jced_lastc* (memq *jced_lastf* %changes))))
        !          11671:           (cond
        !          11672:            (er (msg "vif: want to fix " *jced_lastf* "? {y/n} ")
        !          11673:                (cond ((eq (read) 'y) (go lp)))))
        !          11674:           (cond ((eq res 0)
        !          11675:                  (makunbound '*jced_lastf*)
        !          11676:                  (syscall 10 tf)
        !          11677:                  (return t))
        !          11678:                 (t (return nil))))))
        !          11679: 
        !          11680: 
        !          11681: ;
        !          11682: ; include modules written in C
        !          11683: (cfasl 'jcedmod.o '_jced_ 'jced_ "integer-function")
        !          11684: 
        !          11685: ;  initialization string for jced
        !          11686: (jced_ ":se lisp
        !          11687: " "edinit")
        !          11688: 
        !          11689: ;  editor to use
        !          11690: (jced_ "/usr/ucb/vi" "editor")
        !          11691: 
        !          11692: --------------- -------     jced.c             ---------------
        !          11693: static char sccid[] = "@(#)jced.c      1.1     johnson@udel 11/2/84";
        !          11694: 
        !          11695: #include  <signal.h>
        !          11696: #include  <sgtty.h>
        !          11697: #include  <errno.h>
        !          11698: #include  <sys/wait.h>
        !          11699: #include  <sys/types.h>
        !          11700: #include  <sys/stat.h>
        !          11701: #include  <sys/file.h>
        !          11702: #include  <stdio.h>
        !          11703: 
        !          11704: #define streq(s1,s2)   (0 == strcmp(s1,s2))
        !          11705: #define file_exist(FN)  (0 == access(FN,F_OK))
        !          11706: static int chpgrp, pgrp;   
        !          11707: static union wait status;
        !          11708: static struct stat st0,st1;
        !          11709: static struct sigvec sv1 = { SIG_IGN, 0, 0};
        !          11710: static struct sigvec sv0;
        !          11711: 
        !          11712: static char curname[128];
        !          11713: static char ed_buf[] = "/usr/ucb/vi";
        !          11714: static char init_buf[] = "";
        !          11715: static char myname_buf[] = "jced_";
        !          11716: static char *editor = ed_buf;
        !          11717: static char *edinit = init_buf;
        !          11718: static char *myname = myname_buf;
        !          11719: 
        !          11720: /*     ::jced_::
        !          11721:  *     
        !          11722:  *     Usage: (jced_ "filename" "")
        !          11723:  *     
        !          11724:  *                     jced_ is a job-control editor
        !          11725:  *
        !          11726:  *     - starts an editor session with "filename"
        !          11727:  *       (or resumes it if there is a 'living' session with that file)
        !          11728:  *     - returns 1 if the session remains alive, 0 if the session is over
        !          11729:  *     
        !          11730:  *     NOTE: if the SECOND argument is not the EMPTY string, 
        !          11731:  *     then the following special calls may apply:
        !          11732:  *     
        !          11733:  *              (jced_ "/usr/ucb/vi" "editor") 
        !          11734:  *     - causes jced to use /usr/ucb/vi as the editor (this is the default)
        !          11735:  *     
        !          11736:  *             : (jced_ ":se bla" "edinit") 
        !          11737:  *     - causes jced cause the editor to pretend that the user typed ":se bla"
        !          11738:  *     every time the editor is invoked (the default is "")
        !          11739:  *
        !          11740:  *             : (jced_ "jced_" "myname") 
        !          11741:  *     - causes jced to use the name "jced_" in its prompts and messages
        !          11742:  *     (this is the default)
        !          11743:  *
        !          11744:  */
        !          11745: int
        !          11746: jced_(fname,cmd)
        !          11747: char *fname, *cmd;
        !          11748: {
        !          11749: union wait  status;
        !          11750: char resp[2];
        !          11751: 
        !          11752: 
        !          11753:        if (*cmd) {
        !          11754:                if (streq(cmd,"editor")) newstring(&editor,fname);
        !          11755:                else if (streq(cmd,"edinit")) newstring(&edinit,fname);
        !          11756:                else if (streq(cmd,"myname")) newstring(&myname,fname);
        !          11757:                else fprintf(stderr,"%s: %s is an unknown command",myname,cmd);
        !          11758:                return(0);
        !          11759:        }
        !          11760: 
        !          11761:        if (*curname) {
        !          11762:                if (*fname &&  !streq(fname,curname)) {
        !          11763:                                if (file_exist(curname))
        !          11764:                                        eroar(unlink(curname),0,"unlink %",curname);
        !          11765:                                kvil_();
        !          11766:                                strcpy(curname,fname);
        !          11767:                                begin_vi(); resume_vi();
        !          11768:                } else {
        !          11769:                        /*
        !          11770:                         * if file has been modified elsewhere,
        !          11771:                         * new editing session is needed
        !          11772:                         */ 
        !          11773:                        if (file_exist(curname)) { 
        !          11774:                                eroar(stat(curname,&st1),0,"stat");
        !          11775:                                if(st0.st_mtime != st1.st_mtime) {
        !          11776:                                        kvil_(); strcpy(curname,fname); begin_vi();
        !          11777:                                }
        !          11778:                        }
        !          11779:                        resume_vi();
        !          11780:                }
        !          11781:        } else if (*fname) {
        !          11782:                        strcpy(curname,fname);
        !          11783:                        begin_vi(); resume_vi();
        !          11784:     } else
        !          11785:                return(0);
        !          11786:                
        !          11787:        return((*curname) ? 1 : 0);
        !          11788: }
        !          11789: 
        !          11790: /*  to be called when a function is modified elsewhwre */
        !          11791: kvil_()
        !          11792: {
        !          11793:        eroar(killpg(chpgrp,SIGKILL),0,"killpg %d",chpgrp);
        !          11794:        wait3(&status,WUNTRACED,0);
        !          11795:        curname[0] = '\0';
        !          11796: }
        !          11797: 
        !          11798: static
        !          11799: begin_vi()
        !          11800: {
        !          11801:        if (chpgrp = fork()) {
        !          11802:                pgrp = getpgrp(0);
        !          11803:                eroar(setpgrp(chpgrp,chpgrp),0,"setpgrp");
        !          11804:        } else {
        !          11805:                fakeinput(edinit);
        !          11806:                execlp(editor,editor,curname,0);
        !          11807:                fprintf(stderr,"%s: exec of %s failed\n",myname,editor);
        !          11808:     }
        !          11809: }
        !          11810: 
        !          11811: 
        !          11812: static
        !          11813: resume_vi()
        !          11814: {
        !          11815: char dum[2];
        !          11816: 
        !          11817:        for (;;) {
        !          11818:                eroar(sigvec(SIGTTOU,&sv1,&sv0),0,"sigvec -IGN TTOU");
        !          11819:                eroar(ioctl(0,TIOCSPGRP,&chpgrp),0,"SPGRP chpgrp");
        !          11820:                if (file_exist(curname))
        !          11821:                        eroar(stat(curname,&st1),0,"stat");
        !          11822:                else
        !          11823:                        st1.st_mtime = 0;
        !          11824:                killpg(chpgrp,SIGCONT);
        !          11825:                wait3(&status,WUNTRACED,0);
        !          11826:                eroar(ioctl(0,TIOCSPGRP,&pgrp),0,"ioctl SPGRP pid");
        !          11827:                eroar(sigvec(SIGTTOU,&sv0,0),0,"sigvec -DFL TTOU");
        !          11828:                if (file_exist(curname))
        !          11829:                        eroar(stat(curname,&st0),0,"stat");
        !          11830:                else
        !          11831:                        st0.st_mtime = st1.st_mtime;
        !          11832: 
        !          11833:                if(!status.w_status) {
        !          11834:                        curname[0] = '\0'; break;
        !          11835:                }
        !          11836:                if(st0.st_mtime == st1.st_mtime) {
        !          11837:                        fprintf(stderr,"%s: %s was not modified, try again? {y/n} ",
        !          11838:                                myname, curname);
        !          11839:                        if (1 == scanf("%1s",dum) && dum[0] == 'n')  break;
        !          11840:                } else 
        !          11841:                        break;
        !          11842:        }
        !          11843: }
        !          11844: 
        !          11845: static
        !          11846: fakeinput(s)
        !          11847: char *s;
        !          11848: {
        !          11849: int i;
        !          11850:        /* pretend s was typed at the terminal */
        !          11851:        for(i=0;s[i]; ++i)
        !          11852:                ioctl(0,TIOCSTI,s+i);
        !          11853: }
        !          11854: 
        !          11855: static
        !          11856: newstring(sptr,s)
        !          11857: char **sptr, *s;
        !          11858: {
        !          11859: char *s2, *malloc();
        !          11860: 
        !          11861:        if (NULL == (s2 = malloc(1 + strlen(s)))) {
        !          11862:                fprintf(stderr,"%s: malloc failed\n",myname);
        !          11863:        } else {
        !          11864:                strcpy(s2,s);
        !          11865:                *sptr = s2;
        !          11866:        }
        !          11867: }
        !          11868: 
        !          11869: ---------------------------  eroar.c  --------------------
        !          11870: 
        !          11871: static char sccid[] = "@(#)eroar.c     1.0     johnson@udel 10/13/84";
        !          11872: 
        !          11873: /*     ::eroar.c::
        !          11874:  *     
        !          11875:  *     error reporter-handler for faulty system function calls
        !          11876:  *     
        !          11877:  *     Usage: eroar( <system-call>, <exit-code>, <printf-pattern>, 
        !          11878:  *                                             <printf-arg>, <printf-arg>,  ...... );
        !          11879:  *     
        !          11880:  *     behavior:
        !          11881:  *             if the system call is successful, returns (1) immediately
        !          11882:  *             else
        !          11883:  *                     prints out the error message (from the printf pattern)
        !          11884:  *                       and prints an error explanation
        !          11885:  *                     if exit-code is non-zero, exits with that code
        !          11886:  *                     else returns (0)
        !          11887:  */
        !          11888: 
        !          11889: 
        !          11890: #include <errno.h>
        !          11891: #include <stdio.h>
        !          11892: #define ERR_BUFMAX 128
        !          11893: 
        !          11894: extern int sys_nerr, errno;
        !          11895: extern char *sys_errlist[];
        !          11896: 
        !          11897: eroar(expr,code,s,p1,p2,p3,p4,p5,p6,p7,p8,p9)
        !          11898: int expr,code; char *s;
        !          11899: {
        !          11900:        static char errbuf[ERR_BUFMAX];
        !          11901:        if (-1 != expr) return(1);
        !          11902:        fprintf(stderr,s,p1,p2,p3,p4,p5,p6,p7,p8,p9);
        !          11903:        fprintf(stderr,": %s\n",
        !          11904:                (0 < errno && errno < sys_nerr) ?
        !          11905:                                sys_errlist[errno] : "UNKNOWN ERROR");
        !          11906:        if (code) exit(code);
        !          11907:        return(0);
        !          11908: }
        !          11909: 
        !          11910: -----------------    makefile -----------------------
        !          11911: 
        !          11912: jced : jcedmod.o
        !          11913: 
        !          11914: jcedmod.o : jced.o eroar.o
        !          11915:        ld -o jcedmod.o -r  jced.o eroar.o
        !          11916: -------------------------------------------------------
        !          11917: 
        !          11918: ... (share a little joke with the world) ...
        !          11919: 
        !          11920: net:           johnson@udel-ee
        !          11921: usmail:        Apperson H. Johnson
        !          11922:                        618 Lehigh Rd. apt S11
        !          11923:                        Newark, De. 19711
        !          11924: --------------------------------------------------------
        !          11925: 
        !          11926: From jshaver@apg-3  Fri Mar  1 13:37:57 1985
        !          11927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11928:        id AA22358; Fri, 1 Mar 85 13:21:35 pst
        !          11929: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11930:        id AA28355; Fri, 1 Mar 85 13:13:39 pst
        !          11931: Message-Id: <[email protected]>
        !          11932: Date:  1 Mar 1985 16:15:48 EST (Friday)
        !          11933: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
        !          11934: Subject: Vax availability
        !          11935: To: franz-friends@BERKELEY
        !          11936: Cc: jshaver@apg-3
        !          11937: 
        !          11938: Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
        !          11939: not on the list.  Please add me to the list.
        !          11940: 
        !          11941: Thank you.
        !          11942: This is an Otrona Attache 1200 bps
        !          11943: 
        !          11944:  
        !          11945: John
        !          11946: 
        !          11947: 
        !          11948: From jshaver@apg-3  Mon Mar  4 06:10:51 1985
        !          11949: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11950:        id AA11236; Mon, 4 Mar 85 06:10:51 pst
        !          11951: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11952:        id AA03832; Mon, 4 Mar 85 06:05:00 pst
        !          11953: Message-Id: <[email protected]>
        !          11954: Date:  4 Mar 1985  9:09:27 EST (Monday)
        !          11955: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
        !          11956: Subject: Returned mail: User unknown
        !          11957: To: franz-friends@BERKELEY
        !          11958: Cc: jshaver@apg-3
        !          11959: 
        !          11960: 
        !          11961: ----BEGINNING OF FORWARDED MESSAGES----
        !          11962: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
        !          11963:        id AA28859; Fri, 1 Mar 85 13:34:56 pst
        !          11964: Received: by ucbkim.ARPA (4.24/4.27)
        !          11965:        id AA00121; Fri, 1 Mar 85 13:37:57 pst
        !          11966: Date:  1 Mar 1985 16:15:48 EST (Friday)
        !          11967: From: MAILER-DAEMON%ucbkim@Berkeley (Mail Delivery Subsystem)
        !          11968: Subject: Returned mail: User unknown
        !          11969: Message-Id: <[email protected]>
        !          11970: To: <jshaver@apg-3>
        !          11971: 
        !          11972:    ----- Transcript of session follows -----
        !          11973: >>> RCPT To:<[email protected]>
        !          11974: <<< 550 <[email protected]>... User unknown
        !          11975: 550 franz-friends-3@ucbmike... User unknown
        !          11976: >>> RCPT To:<[email protected]>
        !          11977: <<< 550 <[email protected]>... User unknown
        !          11978: 550 franz-friends-score@ucbmike... User unknown
        !          11979: 
        !          11980:    ----- Unsent message follows -----
        !          11981: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          11982:        id AA22358; Fri, 1 Mar 85 13:21:35 pst
        !          11983: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          11984:        id AA28355; Fri, 1 Mar 85 13:13:39 pst
        !          11985: Message-Id: <[email protected]>
        !          11986: Date:  1 Mar 1985 16:15:48 EST (Friday)
        !          11987: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
        !          11988: Subject: Vax availability
        !          11989: To: franz-friends@BERKELEY
        !          11990: Cc: jshaver@apg-3
        !          11991: 
        !          11992: Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
        !          11993: not on the list.  Please add me to the list.
        !          11994: 
        !          11995: Thank you.
        !          11996: This is an Otrona Attache 1200 bps
        !          11997: 
        !          11998:  
        !          11999: John
        !          12000: 
        !          12001: 
        !          12002: ----END OF FORWARDED MESSAGES----
        !          12003: Is it something I'm doing?
        !          12004: 
        !          12005: 
        !          12006: From jshaver@apg-3  Mon Mar  4 06:16:15 1985
        !          12007: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12008:        id AA11275; Mon, 4 Mar 85 06:16:15 pst
        !          12009: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12010:        id AA03880; Mon, 4 Mar 85 06:10:25 pst
        !          12011: Message-Id: <[email protected]>
        !          12012: Date:  4 Mar 1985  9:10:31 EST (Monday)
        !          12013: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
        !          12014: Subject: mail request failure
        !          12015: To: franz-friends@BERKELEY
        !          12016: Cc: jshaver@apg-3
        !          12017: 
        !          12018: 
        !          12019: ----BEGINNING OF FORWARDED MESSAGES----
        !          12020: Received: from CMU-CS-A.ARPA (cmu-cs-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12021:        id AA29648; Fri, 1 Mar 85 14:05:23 pst
        !          12022: Message-Id: <[email protected]>
        !          12023: Date: 1 Mar 85 17:8:8 EST
        !          12024: From: Mailer <[email protected]>
        !          12025: To: <@BERKELEY:jshaver@apg-3>
        !          12026: Reply-To: Gripe <[email protected]>
        !          12027: Subject: mail request failure
        !          12028: 
        !          12029:    ----- Transcript of session follows -----
        !          12030: 
        !          12031: Mail being sent from disk area [N900AR0M]
        !          12032: *NMail 1 Mar 85 17:06:02 EST;@UCB-VAX.ARPA:jshaver@apg-3;927920.QED[n900ar0m];mark.stevenson@cmua
        !          12033: 1 Mar 85 17:8:8 EST
        !          12034: ?%No such person as 'mark.stevenson' at CMU-CS-A.
        !          12035: 
        !          12036: 
        !          12037:    ----- Unsent message follows -----
        !          12038: Received: from UCB-VAX.ARPA by CMU-CS-A.ARPA; 1 Mar 85 17:05:57 EST
        !          12039: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
        !          12040:        id AA28701; Fri, 1 Mar 85 13:30:28 pst
        !          12041: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12042:        id AA22358; Fri, 1 Mar 85 13:21:35 pst
        !          12043: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12044:        id AA28355; Fri, 1 Mar 85 13:13:39 pst
        !          12045: Message-Id: <[email protected]>
        !          12046: Date:  1 Mar 1985 16:15:48 EST (Friday)
        !          12047: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
        !          12048: Subject: Vax availability
        !          12049: To: franz-friends@Berkeley
        !          12050: Cc: jshaver@apg-3
        !          12051: 
        !          12052: Is Franz Lisp available for the VAX?   Please respond directly to me, as I am
        !          12053: not on the list.  Please add me to the list.
        !          12054: 
        !          12055: Thank you.
        !          12056: This is an Otrona Attache 1200 bps
        !          12057: 
        !          12058:  
        !          12059: John
        !          12060: 
        !          12061: 
        !          12062: 
        !          12063: ----END OF FORWARDED MESSAGES----
        !          12064: Try a return address of RREINER@Simtel20.  They forward everything to me.
        !          12065: 
        !          12066: 
        !          12067: From [email protected]  Tue Mar  5 08:17:28 1985
        !          12068: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12069:        id AA00161; Tue, 5 Mar 85 08:17:28 pst
        !          12070: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12071:        id AA09879; Tue, 5 Mar 85 08:11:28 pst
        !          12072: Message-Id: <[email protected]>
        !          12073: Date:     Tue, 5 Mar 85 11:13:21 EST
        !          12074: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
        !          12075: To: Franz-Friends@BERKELEY
        !          12076: Cc: Meself <[email protected]>
        !          12077: Subject:  Trace bug
        !          12078: 
        !          12079: Haah,
        !          12080: 
        !          12081: We recently installed some revisions to our 4.2 BSD system, and the
        !          12082: Joseph Lister package is apparently broken.  Since our system
        !          12083: administrators don't use Franz, I poked around in the file trace.l.
        !          12084: An error run is shown below:
        !          12085: 
        !          12086: -> (getsyntax '\;)
        !          12087: vsplicing-macro
        !          12088: -> (trace intersect)
        !          12089: [autoload /usr/lib/lisp/trace]
        !          12090: [load /usr/lib/lisp/trace.l]
        !          12091: [load /usr/lib/lisp/charmac.l]
        !          12092: Error: Unbound Variable: ;;
        !          12093: <1>: (getsyntax '\;)
        !          12094: vcharacter
        !          12095: 
        !          12096: The trace code that is executing is:
        !          12097: 
        !          12098: (eval-when (eval)
        !          12099:   (setq old-read-table-trace readtable)
        !          12100:   (setq readtable (makereadtable t))
        !          12101:   (setq old-uctolc-value (status uctolc))
        !          12102:   (sstatus uctolc nil)         ; turn off case conversion
        !          12103:   (load 'charmac)
        !          12104:   (setsyntax '\; 'macro 'zapline)
        !          12105:   )
        !          12106: 
        !          12107: What I think is happening is that the readtable is being clobbered by
        !          12108: the (makereadtable t) line.  The file charmac.l starts off with a
        !          12109: comment line, but the definition of ';' has changed in the readtable.
        !          12110: I copied trace.l and reversed the last 2 lines so ';' is macro'd to
        !          12111: zapline BEFORE charmac.l is loaded.  I can then load trace.l and
        !          12112: (trace) functions with no trouble.
        !          12113: 
        !          12114: My question is: Why did I have to reverse those lines ??  (trace) used
        !          12115: to work fine.  Is there a problem with (makereadtable) that I need to
        !          12116: fix ??  We are running Opus 38.79.
        !          12117: 
        !          12118:                                         dsw, fferd
        !          12119:                                         Fred S. Brundick
        !          12120:                                         USABRL, APG, MD.
        !          12121:                                         <fsbrn@brl-voc>
        !          12122: 
        !          12123: "Me ears are on the wrong side of me 'ead."
        !          12124: 
        !          12125: From [email protected]  Tue Mar  5 14:55:27 1985
        !          12126: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12127:        id AA00189; Tue, 5 Mar 85 14:55:27 pst
        !          12128: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12129:        id AA16643; Tue, 5 Mar 85 13:15:11 pst
        !          12130: Message-Id: <[email protected]>
        !          12131: Date:     Tue, 5 Mar 85 16:14:14 EST
        !          12132: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
        !          12133: To: Franz-Friends@BERKELEY
        !          12134: Cc: Ferd Brundick <[email protected]>, [email protected]
        !          12135: Subject:  Re:  Trace bug
        !          12136: 
        !          12137: Haah,
        !          12138: 
        !          12139:   >>Why aren't you loading the compiled version of trace?
        !          12140:   >>Would that help?
        !          12141: 
        !          12142: That was the what the person who stumbled onto the bug said.  (I don't
        !          12143: use the trace package myself because everything works the first time
        !          12144: :-).  I don't see how that would matter because compiled code is just
        !          12145: as wrong; it just bombs faster.  Besides, my slightly obsolete Franz
        !          12146: manual says "the trace package ... usually in the file
        !          12147: /usr/lib/lisp/trace.l".  I'm just wondering why the file doesn't work
        !          12148: any more when it used to.  I'd rather fix the problem permanently
        !          12149: instead of patching around it.
        !          12150: 
        !          12151:                                         dsw, fferd
        !          12152:                                         Fred S. Brundick
        !          12153:                                         USABRL, APG, MD.
        !          12154:                                         <fsbrn@brl-voc>
        !          12155: 
        !          12156: "I think I pulled a muscle in me ear."
        !          12157: 
        !          12158: From [email protected]  Tue Mar 19 16:50:09 1985
        !          12159: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12160:        id AA22357; Tue, 19 Mar 85 16:50:09 pst
        !          12161: Received: from MIT-HTVAX.ARPA (mit-htvax.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12162:        id AA05308; Tue, 19 Mar 85 11:49:40 pst
        !          12163: Received: by MIT-HTVAX.ARPA (4.12/4.7) 
        !          12164:        id AA21434; Tue, 19 Mar 85 14:50:20 est
        !          12165: Date: Tue, 19 Mar 85 14:50:20 est
        !          12166: From: Walter Hamscher <[email protected]>
        !          12167: Message-Id: <[email protected]>
        !          12168: To: Franz-Friends@BERKELEY
        !          12169: Subject: Franz -> Common Lisp ?
        !          12170: 
        !          12171: Reply-to: [email protected]
        !          12172: 
        !          12173: Is there a common lisp that runs on 4.2 BSD?  Seems to
        !          12174: me this is  a vacuum that many folks must be trying to fill.
        !          12175: 
        !          12176: I am wondering:
        !          12177: 
        !          12178: (1) Who's working on one?
        !          12179: 
        !          12180:     <<None of the following answers win brownie points:
        !          12181:        (a) DEC.  Their Unix common lisp is only for in-house use.
        !          12182:        (b) CCA.  Ain't ready yet.
        !          12183:        (c) David Betz (XLISP 1.4).  Currently only a small subset.
        !          12184:        (d) NIL.  No Unix implementation planned.>>
        !          12185: 
        !          12186: (2) Is there a common lisp compatability package for franz?
        !          12187: 
        !          12188:        <<Unlikely, I know.  Still, how much of common
        !          12189:        lisp already exists in compatability packages,
        !          12190:        e.g. Lexical scoping :-), Packages, Keyword
        !          12191:        arguments, Pathnames, Bit-arrays?>>
        !          12192: 
        !          12193: (3) Are folks at UCB thinking of spinning off a common
        !          12194:     lisp from the existing franz implementation?
        !          12195: 
        !          12196:        <<Also unlikely but surely the thought has occurred.>>
        !          12197: 
        !          12198: All answers and pointers appreciated.
        !          12199: 
        !          12200:        Thanks,
        !          12201:        Walter Hamscher
        !          12202: 
        !          12203: From shebs@utah-cs  Wed Mar 20 17:27:57 1985
        !          12204: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12205:        id AA08685; Wed, 20 Mar 85 17:27:57 pst
        !          12206: Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12207:        id AA11992; Wed, 20 Mar 85 16:51:20 pst
        !          12208: Received: by utah-cs.ARPA (4.42/4.40.2)
        !          12209:        id AA01825; Wed, 20 Mar 85 17:48:26 MST
        !          12210: Date: Wed, 20 Mar 85 17:48:26 MST
        !          12211: From: shebs@utah-cs (Stanley Shebs)
        !          12212: Message-Id: <[email protected]>
        !          12213: To: Franz-Friends@BERKELEY, [email protected]
        !          12214: Subject: Re:  Franz -> Common Lisp ?
        !          12215: 
        !          12216: We have several versions of compatibility stuff for PSL (and it
        !          12217: would work under Franz without much change).  We're trying to
        !          12218: get CL while retaining the speed of PSL, so we haven't yet
        !          12219: embarked on a full standalone CL...
        !          12220: 
        !          12221:                                                stan shebs
        !          12222: 
        !          12223: From [email protected]  Thu Mar 21 11:05:39 1985
        !          12224: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12225:        id AA18463; Thu, 21 Mar 85 11:05:39 pst
        !          12226: Received: from ucla-locus.arpa (ucla-locus.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12227:        id AA12504; Thu, 21 Mar 85 10:37:45 pst
        !          12228: Date:           Thu, 21 Mar 85 10:35:28 PST
        !          12229: From: Ingrid Zukerman <[email protected]>
        !          12230: To: franz-friends@BERKELEY
        !          12231: Subject:        setq command changes code
        !          12232: Message-Id:     <[email protected]>
        !          12233: 
        !          12234: I have the following problems:
        !          12235: 1. After performing the command (setq x (list ... )), I noticed that
        !          12236:    the code in the function that initializes x was also changed to the
        !          12237:    new value. After consulting with my guru, he pointed out that this
        !          12238:    might be due to a sharing pattern I am not aware of, or to the way
        !          12239:    in which assignments are performed (e.g., by passing a pointer).
        !          12240:    I wasn't able to find this information, so my question is were I
        !          12241:    could find it in order to avoid such occurrences in the future. Of
        !          12242:    course, if somebody up there is terribly curious and wants to look
        !          12243:    at a transcript of the session, I'll be very appreciative.
        !          12244: 2. The most updated copy we have of Franz is Opus 38.5. I hear that it
        !          12245:    is now Opus 38.91. What should I do in order to get an updated copy?
        !          12246:    Please don't advise me to contact the person in charge, because this
        !          12247:    person (who no longer wishes to be in charge) told me to contact you.
        !          12248: Thanks very much.
        !          12249: --Ingrid
        !          12250: 
        !          12251: From franz!schlafly  Mon Mar 25 18:03:33 1985
        !          12252: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12253:        id AA20019; Mon, 25 Mar 85 18:03:33 pst
        !          12254: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
        !          12255:        id AA21825; Mon, 25 Mar 85 17:57:20 pst
        !          12256: Received: by ucbkim.ARPA (4.24/4.27)
        !          12257:        id AA20010; Mon, 25 Mar 85 18:03:19 pst
        !          12258: Received: by franz.uucp (1.2/3.14)
        !          12259:        id AA00961; Mon, 25 Mar 85 17:36:52 pst
        !          12260: Date: Mon, 25 Mar 85 17:36:52 pst
        !          12261: From: franz!schlafly (Roger Schlafly)
        !          12262: Message-Id: <[email protected]>
        !          12263: To: franz-friends@BERKELEY
        !          12264: Subject: programs written in Franz Lisp
        !          12265: 
        !          12266: 
        !          12267: I am compiling a list of expert systems and expert
        !          12268: system building tools which are written in Franz Lisp.
        !          12269: 
        !          12270: I would appreciate it if people would send me:
        !          12271: (1) The name of each such program.
        !          12272: (2) A brief description of what it does.
        !          12273: (3) Whether it is available to the public.
        !          12274: (4) An electronic address for obtaining more information.
        !          12275: 
        !          12276: I will then make this list available to anyone who requests it.
        !          12277: 
        !          12278:        Roger Schlafly
        !          12279:        ucbvax!franz!schlafly
        !          12280: 
        !          12281: 
        !          12282: From franz!schlafly  Mon Mar 25 20:02:47 1985
        !          12283: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12284:        id AA21162; Mon, 25 Mar 85 20:02:47 pst
        !          12285: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
        !          12286:        id AA23786; Mon, 25 Mar 85 19:56:37 pst
        !          12287: Received: by ucbkim.ARPA (4.24/4.27)
        !          12288:        id AA21150; Mon, 25 Mar 85 20:02:36 pst
        !          12289: Received: by franz.uucp (1.2/3.14)
        !          12290:        id AA01276; Mon, 25 Mar 85 19:37:31 pst
        !          12291: Date: Mon, 25 Mar 85 19:37:31 pst
        !          12292: From: franz!schlafly (Roger Schlafly)
        !          12293: Message-Id: <[email protected]>
        !          12294: To: franz-friends@BERKELEY
        !          12295: Subject: programs written in Franz Lisp
        !          12296: 
        !          12297: 
        !          12298: I am compiling a list of expert systems and expert
        !          12299: system building tools which are written in Franz Lisp.
        !          12300: 
        !          12301: I would appreciate it if people would send me:
        !          12302: (1) The name of each such program.
        !          12303: (2) A brief description of what it does.
        !          12304: (3) Whether it is available to the public.
        !          12305: (4) An electronic address for obtaining more information.
        !          12306: 
        !          12307: I will then make this list available to anyone who requests it.
        !          12308: 
        !          12309:        Roger Schlafly
        !          12310:        ucbvax!franz!schlafly
        !          12311: 
        !          12312: 
        !          12313: From carter%[email protected]  Tue Mar 26 12:52:24 1985
        !          12314: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12315:        id AA00886; Tue, 26 Mar 85 12:52:24 pst
        !          12316: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12317:        id AA11893; Tue, 26 Mar 85 12:46:01 pst
        !          12318: Received: from ubc by csnet-relay.csnet id a017378; 26 Mar 85 15:03 EST
        !          12319: Received: from ubc-vision.UUCP by ubc.csnet id AA04906; Tue, 26 Mar 85 12:01:03 pst
        !          12320: Date: Tue, 26 Mar 85 12:00:43 pst
        !          12321: From: Alan Carter <carter%[email protected]>
        !          12322: Message-Id: <[email protected]>
        !          12323: Received: by ubc-vision.UUCP id AA09422; Tue, 26 Mar 85 12:00:43 pst
        !          12324: To: franz-friends@BERKELEY
        !          12325: Subject: Lisp interface to C functions
        !          12326: 
        !          12327: 
        !          12328: 
        !          12329: Does anyone know if there is a problem with calling malloc and free from
        !          12330: C functions which are called by Franz ?
        !          12331: 
        !          12332: 
        !          12333:                                        Alan Carter
        !          12334:                                        [email protected]
        !          12335: 
        !          12336: From mcgeer  Tue Mar 26 16:06:57 1985
        !          12337: Received: by ucbkim.ARPA (4.24/4.27)
        !          12338:        id AA03620; Tue, 26 Mar 85 16:06:57 pst
        !          12339: Date: Tue, 26 Mar 85 16:06:57 pst
        !          12340: From: Rick McGeer (on an aaa-60-s) <mcgeer>
        !          12341: Message-Id: <[email protected]>
        !          12342: To: prolog@ernie, franz-friends
        !          12343: Subject: Lisp is faster than Prolog?
        !          12344: Cc: 
        !          12345: 
        !          12346:        A number of articles in recent IEEE Spectra have discussed Silicon
        !          12347: Compilation in Prolog, and concluded with a statement to the effect: for
        !          12348: performance reasons, we will go to Lisp for a production version.
        !          12349: 
        !          12350:        Is Lisp really faster than Prolog?  I used to think so.  Some time
        !          12351: ago, I wrote a Prolog interpreter in Lisp: after several versions, I gave
        !          12352: up, because I couldn't make my Prolog fast.  Its best speed was 100 LIPS
        !          12353: through the append loop on a 780, or about 7% of the speed of C-Prolog (1500
        !          12354: LIPS, according to the literature.
        !          12355: 
        !          12356:        Then it occured to me that I could not expect my Prolog to run
        !          12357: faster than an equivalent function coded in Lisp.  I coded the function, and
        !          12358: the result was the following:
        !          12359: 
        !          12360: (def my-append
        !          12361:    (lambda (x y)
        !          12362:       (cond (x (cons (car x) (my-append (cdr x) y)))
        !          12363:            (t y))))
        !          12364: 
        !          12365: it can be seen that the time of the computation is invariant with respect to
        !          12366: the second argument.  Hence, for all the tests to be mentioned, the second
        !          12367: argument is '(1 2 3 4 5).
        !          12368: 
        !          12369:        I ran the program on the lists consisting of the first 100, 250, and
        !          12370: 300 integers.  The results were the following:
        !          12371: 
        !          12372: list length    ticks (60/sec)  LIPS equivalent
        !          12373:   100            14              429
        !          12374:   250            29              517
        !          12375:   300            34              529
        !          12376: 
        !          12377: Or about one-third the published speed of of the same function in CProlog on
        !          12378: a 780.  I then wondered how the native Franz append would do.  This function
        !          12379: is compiled, and is optimized for tail recursion, so the experiment is not
        !          12380: really fair to CProlog.  In any case:
        !          12381: 
        !          12382: list length    ticks           LIPS equivalent
        !          12383:   100            3               2000
        !          12384:   250            8               1875
        !          12385:   300           10               1800
        !          12386: 
        !          12387: I don't know what this proves, but I know what it doesn't prove.  The Lisp
        !          12388: used, by the way, was Franz version 38.96 on a Vax 11/780 at the University
        !          12389: of California at Berkeley.  Despite numerous queries to Edinburgh, we still
        !          12390: don't have a version of C-Prolog for comparative measurement here, so I
        !          12391: can't personally vouch for the 1500 LIPS claim.
        !          12392: 
        !          12393:                                                        Rick.
        !          12394: 
        !          12395: 
        !          12396: From chris@maryland  Tue Mar 26 16:18:52 1985
        !          12397: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12398:        id AA03876; Tue, 26 Mar 85 16:18:52 pst
        !          12399: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12400:        id AA16580; Tue, 26 Mar 85 16:12:34 pst
        !          12401: Received: by maryland.ARPA (4.12/4.7)
        !          12402:        id AA23203; Tue, 26 Mar 85 19:17:28 est
        !          12403: Date: Tue, 26 Mar 85 19:17:28 est
        !          12404: From: Chris Torek <chris@maryland>
        !          12405: Message-Id: <[email protected]>
        !          12406: To: carter%[email protected]
        !          12407: Subject: Re:  Lisp interface to C functions
        !          12408: Cc: franz-friends@BERKELEY
        !          12409: 
        !          12410: I believe that there were.  In U of M Franz, we stuck in a version of
        !          12411: malloc and free that uses the Lisp allocator to get unGCable memory,
        !          12412: and a host of problems with the window library went away ... (the
        !          12413: window library uses malloc & free quite, er, freely :-) ).
        !          12414: 
        !          12415: Chris
        !          12416: 
        !          12417: From narain@rand-unix  Tue Mar 26 18:17:38 1985
        !          12418: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12419:        id AA06939; Tue, 26 Mar 85 18:17:38 pst
        !          12420: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12421:        id AA18369; Tue, 26 Mar 85 17:39:36 pst
        !          12422: Received: by rand-unix.ARPA; Tue, 26 Mar 85 17:33:48 pst
        !          12423: From: Sanjai Narain <narain@rand-unix>
        !          12424: Message-Id: <[email protected]>
        !          12425: Date: 26 Mar 85 17:33:41 PST (Tue)
        !          12426: To: Rick McGeer <mcgeer@ucbkim>
        !          12427: Cc: prolog@ernie, franz-friends@ucbkim, narain@rand-unix
        !          12428: Subject: Re: Lisp is faster than Prolog?
        !          12429: In-Reply-To: Your message of Tue, 26 Mar 85 16:06:57 pst.
        !          12430:             <[email protected]>
        !          12431: 
        !          12432: 
        !          12433: Your first comparison of Prolog and Lisp is not very meaningful. You are
        !          12434: comparing a Prolog implemented in Lisp with a Lisp implemented in C.
        !          12435: Perhaps you could try to compare Lisp in Lisp with Prolog in Lisp.
        !          12436: 
        !          12437: In a certain sense, your comparison of Franzlisp and C-Prolog infact
        !          12438: indicates the superiority of C-Prolog. C-Prolog can be used to do append
        !          12439: and all other functional programming at almost the speed of FranzLisp.
        !          12440: However, in C-Prolog, you can do also do deduction, searching, pattern
        !          12441: matching and a lot of other AI-stuff at the same speed. To do these in
        !          12442: Franzlisp you must write Lisp functions and suffer the loss in speed
        !          12443: associated with simulating functionality in a high-level language.
        !          12444: 
        !          12445: -- Sanjai
        !          12446: 
        !          12447: From mcgeer  Tue Mar 26 18:30:58 1985
        !          12448: Received: by ucbkim.ARPA (4.24/4.27)
        !          12449:        id AA07153; Tue, 26 Mar 85 18:30:58 pst
        !          12450: Date: Tue, 26 Mar 85 18:30:58 pst
        !          12451: From: Rick McGeer (on an aaa-60-s) <mcgeer>
        !          12452: Message-Id: <[email protected]>
        !          12453: To: narain@rand-unix
        !          12454: Subject: Re: Lisp is faster than Prolog?
        !          12455: Cc: narain@rand-unix, franz-friends, prolog@ernie
        !          12456: In-Reply-To: Your message of 26 Mar 85 17:33:41 PST (Tue)
        !          12457: 
        !          12458: 
        !          12459:        You misunderstood my message.  Prolog-in-Lisp really isn't under
        !          12460: examination: the only reason I brought it up was that it provided the
        !          12461: original motivation for the experiment (I wanted to determine a limit on the
        !          12462: speed I could expect out of my Prolog, reasoning that it could not possibly
        !          12463: be faster than native-coded Lisp.)
        !          12464: 
        !          12465:        The rest of your letter is essentially correct: the figures imply
        !          12466: that CProlog is at least as fast as Franz, since the relevant test is
        !          12467: interpreted code in each language (i.e., the first set of figures).
        !          12468: However, this should not imply that I believe that Prolog is a "better"
        !          12469: language than Lisp (I don't want to get into *that* debate), or imply
        !          12470: that Lisp has no advantages over Prolog.  Lisp may have real advantages over
        !          12471: Prolog, but there is no reason to believe that speed is one of them.
        !          12472: 
        !          12473:                                        Rick.
        !          12474: 
        !          12475: 
        !          12476: From hilfingr@ucbrenoir  Wed Mar 27 01:06:00 1985
        !          12477: Received: from ucbrenoir.ARPA by ucbkim.ARPA (4.24/4.27)
        !          12478:        id AA11390; Wed, 27 Mar 85 01:06:00 pst
        !          12479: Received: by ucbrenoir.ARPA (4.24/4.42)
        !          12480:        id AA03594; Wed, 27 Mar 85 01:07:16 pst
        !          12481: Date: Wed, 27 Mar 85 01:07:16 pst
        !          12482: From: hilfingr@ucbrenoir (Paul Hilfinger)
        !          12483: Message-Id: <[email protected]>
        !          12484: To: mcgeer@ucbkim, narain@rand-unix
        !          12485: Subject: Re: Lisp is faster than Prolog? A personal plea
        !          12486: Cc: prolog@ernie, franz-friends@ucbkim
        !          12487: In-Reply-To: Your message of 26 Mar 85 17:33:41PST
        !          12488: 
        !          12489: 
        !          12490: Please, please, please stop trying to compare the performance of Lisp and
        !          12491: Prolog by considering micro-benchmarks!  Even in languages that are
        !          12492: essentially "the same" (from my perspective as a semanticist/language
        !          12493: designer or from the perspective of a Prolog programmer, FORTRAN, Pascal,
        !          12494: Modula 2, and Ada are all the same); such benchmarks are imperfect guides.
        !          12495: When comparing Lisp and Prolog, where the programs one might write to do a
        !          12496: particular problem might be radically different in strategy, anything that
        !          12497: compares the performance of tiny programs conveys almost no useful
        !          12498: information.
        !          12499: 
        !          12500: Please, please, please, PLEASE don't try to compare Prolog with Lisp (etc.)
        !          12501: using LIPS as a part of the measure! In comparing Prolog implementations, I
        !          12502: suppose LIPS might be of some interest, but when comparing Lisp with Prolog,
        !          12503: they don't help at all. The reason is simple: if Lisp is not suited for
        !          12504: doing logical inferences (in the Prolog sense) quickly, then the good Lisp
        !          12505: programmer simply does not formulate his solution using logical inferences.
        !          12506: (Patient: Doctor! Doctor! It hurts when I do this. Doctor: Well, then don't
        !          12507: do that.) It's like saying that my APL implementation, which uses lazy
        !          12508: evaluation and a bit of cleverness to compute
        !          12509: 
        !          12510:        +/ ,((iota n) o.= iota n) x A +.x B
        !          12511: 
        !          12512: (the trace of the matrix product of nxn matrices A and B, I think) in time
        !          12513: O(n^2) instead of O(n^3), is "faster" than my FORTRAN implementation, which
        !          12514: requires time O(n^3) to do a direct transcription of this algorithm
        !          12515: (actually forming the full matrix product).  
        !          12516: 
        !          12517: I think it wrong to say
        !          12518: 
        !          12519:    "To do [deduction, searching, pattern matching and other AI-stuff] in
        !          12520:     Franzlisp you must write Lisp functions and suffer the loss in speed
        !          12521:     associated with simulating functionality in a high-level language."
        !          12522: 
        !          12523: because one DOESN'T use simulation if one wants speed, but instead goes
        !          12524: after an entirely different kind of solution (I won't argue that this
        !          12525: solution is "just as easy" as the Prolog solution; there are certainly many
        !          12526: instances in which Prolog solutions are simpler, and I haven't the foggiest
        !          12527: notion what the story is for large systems.)  
        !          12528: 
        !          12529:        * * *
        !          12530: 
        !          12531: Finally, a question.  I was struck by Sanjai Narain's  comment:
        !          12532: 
        !          12533:     "However, in C-Prolog, you can do also do deduction, searching, 
        !          12534:      pattern matching and a lot of other AI-stuff at the same speed."
        !          12535: 
        !          12536: I notice that the Prolog digest is full of interesting puzzles whose
        !          12537: solution involves search. But are these representative? I think pattern
        !          12538: matching is certainly a big part of any Prolog program, but do deduction and
        !          12539: searching really form a big part of actual Prolog applications in practice?
        !          12540: 
        !          12541: I recall an article by Drew McDermott called the "The Prolog Phenonmenon"
        !          12542: that appeared (I think) in SIGArt at some point, maybe July '82. He asked
        !          12543: why it was that Prolog had not died out, as had PLANNER, which also
        !          12544: purported to support searching et al. He said some things on what he liked
        !          12545: and disliked about Prolog, and then made the following comment (emphasis
        !          12546: mine):
        !          12547: 
        !          12548:        "The Europeans went in a different direction [from the Americans
        !          12549:         in reaction to the problems of PLANNER-like languages].  What
        !          12550:         they liked best about logic was its variable-binding machinery.
        !          12551:         Their attitude towards backtracking has been simply that it is a
        !          12552:         programmer's duty to remember that his program will be executed
        !          12553:         backward as well as forward, that his programs must correct bad
        !          12554:         guesses as well as exploit good ones.  If the backwards
        !          12555:         execution blows up, he must debug his program, not rewrite the
        !          12556:         interpreter [the American approach], just as with more prosaic
        !          12557:         kinds of infinite loops.  Once this burden was shifted away
        !          12558:         from the language implementer and onto the programmer, the
        !          12559:         logical [!] next step was to freeze the interpreter design
        !          12560:         and make it as efficient as possible.  THE RESULT IS A 
        !          12561:         PROGRAMMING LANGUAGE, NOT A PROBLEM SOLVER OR THEOREM PROVER;
        !          12562:         it doesn't compete with NOAH, but with Lisp.  And it's my
        !          12563:         impression that it competes pretty well.
        !          12564:         
        !          12565:             "The effect is to reverse the usual images of the American 
        !          12566:         and European computer scientists.  In this case, the Americans
        !          12567:         have pursued impractical theoretical studies, while the
        !          12568:         Europeans have bummed the hell out of a hack."
        !          12569: 
        !          12570: (By "backward execution," he is referring to backtracking, I believe). To
        !          12571: put this another way, one doesn't use Prolog's backtracking to do AI-style
        !          12572: (i.e., very large) search, but rather to do very local and carefully-
        !          12573: controlled "search," in the sense of "search this list (tree, ....) for an
        !          12574: element equal to this one" or "try all permutations of this tiny set for one
        !          12575: that satisfies P." Likewise, one doesn't use it to do what an AI
        !          12576: investigator would call "deduction." One CAN convince the Prolog machinery
        !          12577: to do more general AI-style searching efficiently, but only at the expense
        !          12578: of vastly obscuring the original clear, simple, declarative form of the
        !          12579: program.
        !          12580: 
        !          12581: Not being a real Prolog hacker (yet) I don't really know how accurate this
        !          12582: view is, and would appreciate some reaction (preferably semi-quantitative).
        !          12583: 
        !          12584: 
        !          12585: 
        !          12586: From franz!jkf  Wed Mar 27 08:03:25 1985
        !          12587: Received: by ucbkim.ARPA (4.24/4.27)
        !          12588:        id AA13270; Wed, 27 Mar 85 08:03:25 pst
        !          12589: Received: by franz.uucp (1.2/3.14)
        !          12590:        id AA06162; Wed, 27 Mar 85 07:59:36 pst
        !          12591: Date: Wed, 27 Mar 85 07:59:36 pst
        !          12592: From: franz!jkf (John Foderaro)
        !          12593: Message-Id: <[email protected]>
        !          12594: To: [email protected], [email protected], [email protected]
        !          12595: Subject: Re: Lisp is faster than Prolog? A personal plea
        !          12596: Cc: [email protected], prolog@ernie
        !          12597: In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst
        !          12598: 
        !          12599:  While I find the discussion of Prolog vrs Lisp interesting, please do don't
        !          12600: include franz-friends in on the discussion.  When the mailing list has
        !          12601: strayed off the topic of Franz Lisp in the past,  I've gotten inundated with
        !          12602: complaints.    Thanks.
        !          12603:                                        John Foderaro
        !          12604:                                        
        !          12605: 
        !          12606: 
        !          12607: 
        !          12608: From mcgeer  Wed Mar 27 10:22:15 1985
        !          12609: Received: by ucbkim.ARPA (4.24/4.27)
        !          12610:        id AA15354; Wed, 27 Mar 85 10:22:15 pst
        !          12611: Date: Wed, 27 Mar 85 10:22:15 pst
        !          12612: From: Rick McGeer (on an aaa-60-s) <mcgeer>
        !          12613: Message-Id: <[email protected]>
        !          12614: To: hilfingr@ucbrenoir, narain@rand-unix
        !          12615: Subject: Re: Lisp is faster than Prolog? A personal plea
        !          12616: Cc: franz-friends, prolog@ernie
        !          12617: In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst
        !          12618: 
        !          12619:        Good point, Paul, but I think you're missing something.  First you
        !          12620: plead with us not to use micro-benchmarks, then you point out (correctly)
        !          12621: that the strategy that one would use to write a program in Lisp instead of
        !          12622: Prolog can often differ.  I would think that the implication from the latter
        !          12623: observation is that large programs are fundamentally incomparable, and I
        !          12624: think that that is probably correct.
        !          12625: 
        !          12626:        So if you deny us micro-benchmarks, then we can not measure the
        !          12627: relative performance of these languages at all (or, more precisely, the
        !          12628: standard implementations of these languages on the 11/780).  Hence we might
        !          12629: as well accept the statements "Prolog is faster than Lisp" or "Lisp is faster
        !          12630: than Prolog" or "Lisp is faster than assembler" as essentially meaningless
        !          12631: statements, since we can't quantify any of them.
        !          12632: 
        !          12633:        Let me sputter out making one final point.  LIPS is not all that
        !          12634: bad a measure.  Perhaps if we called it "cycles through the append loop" or
        !          12635: "function calls per second" (essentially identical statements) I think most
        !          12636: people would agree that this is a fair measure of the performance of any
        !          12637: Lisp.  After all, Lisp does nothing other than call functions and manipulate
        !          12638: lists.
        !          12639: 
        !          12640:        I'm certainly not going to take issue with the rest of your letter,
        !          12641: which is really more directed at Sanjai's claims than mine, and walks rather
        !          12642: closer to debates on programming style than any sane man should dare to go.
        !          12643: 
        !          12644: 
        !          12645:        I remain, sir,
        !          12646: 
        !          12647:                                        Y'r obedient servant,
        !          12648: 
        !          12649:                                                Rick McGeer.
        !          12650: 
        !          12651: 
        !          12652: From jeffr@sri-spam  Fri Mar 29 16:22:50 1985
        !          12653: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12654:        id AA09984; Fri, 29 Mar 85 16:22:50 pst
        !          12655: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12656:        id AA04718; Fri, 29 Mar 85 16:16:10 pst
        !          12657: Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
        !          12658:        id AA29100; Fri, 29 Mar 85 16:22:32 pst
        !          12659: Message-Id: <[email protected]>
        !          12660: Date: 29 Mar 85 16:22:30 PST (Fri)
        !          12661: To: franz-friends@BERKELEY
        !          12662: Subject: Problems Forking Around
        !          12663: From: jeffr@sri-spam
        !          12664: 
        !          12665: I am having problems getting child processes forked from Franz to exit
        !          12666: cleanly.  If I execute a simple forking function, such as
        !          12667: 
        !          12668:        (defun fork_test ()
        !          12669:                        (prog (pid)
        !          12670:                (cond ((setq pid (fork)) (return pid)))
        !          12671:                (exit)
        !          12672:        ]
        !          12673: 
        !          12674: from the Franz interpreter, a zombie process is created which doesn't exit
        !          12675: until I exit the interpreter.  The same result holds when fork_test is
        !          12676: called from a compiled Franz daemon which is not associated with a tty.
        !          12677: 
        !          12678: It's Friday and I'm out of ideas; any you have, even if only speculation,
        !          12679: would be greatly appreciated.
        !          12680: 
        !          12681:                                        - Jeff Rininger
        !          12682:                                          SRI International     
        !          12683: 
        !          12684: From larus@ucbdali  Fri Mar 29 16:50:22 1985
        !          12685: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
        !          12686:        id AA10643; Fri, 29 Mar 85 16:50:22 pst
        !          12687: Received: by ucbdali.ARPA (4.24/4.42)
        !          12688:        id AA04603; Fri, 29 Mar 85 16:50:11 pst
        !          12689: Message-Id: <[email protected]>
        !          12690: To: [email protected]
        !          12691: Cc: franz-friends@ucbdali
        !          12692: Subject: Re: Problems Forking Around
        !          12693: In-Reply-To: Your message of 29 Mar 85 16:22:30 PST (Fri).
        !          12694:             <[email protected]>
        !          12695: Date: 29 Mar 85 16:50:02 PST (Fri)
        !          12696: From: larus@ucbdali
        !          12697: 
        !          12698: This is a not-very-well-known bug/feature of Franz/Unix.  Try adding a
        !          12699: (wait) call in the main routine and the zombies will go away.
        !          12700: 
        !          12701: /Jim
        !          12702: 
        !          12703: From [email protected]  Fri Mar 29 18:23:00 1985
        !          12704: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12705:        id AA11898; Fri, 29 Mar 85 18:23:00 pst
        !          12706: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12707:        id AA07034; Fri, 29 Mar 85 18:16:19 pst
        !          12708: Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
        !          12709:        by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1)
        !          12710:        id AA11566; Fri, 29 Mar 85 18:22:39 pst
        !          12711: Received: by ucbruby.CC.Berkeley.ARPA (4.19/4.34.1)
        !          12712:        id AA10320; Fri, 29 Mar 85 18:21:53 pst
        !          12713: Date: Fri, 29 Mar 85 18:21:53 pst
        !          12714: From: [email protected] (Harry Weeks)
        !          12715: Message-Id: <[email protected]>
        !          12716: To: jeffr@sri-spam
        !          12717: Subject: Re: Problems Forking Around
        !          12718: Cc: franz-friends@BERKELEY
        !          12719: 
        !          12720: It is a characteristic of Unix that processes do not really die
        !          12721: until they are waited for.  Your `zombie' process will not die
        !          12722: until you (wait) for it.  The (wait) function returns the dotted
        !          12723: pair (pid . status).  Thus the following examples will spawn
        !          12724: children that immediately die.
        !          12725:                                                --Harry
        !          12726: 
        !          12727: In simplest terms:
        !          12728: 
        !          12729:     (def beget
        !          12730:       (lambda nil
        !          12731:        (cond ((fork) (wait))
        !          12732:              (t (exit 0)))))
        !          12733: 
        !          12734: In more realistic terms:
        !          12735: 
        !          12736:     (def beget
        !          12737:       (lambda nil
        !          12738:        (prog (child)
        !          12739:              (setq child (fork))
        !          12740:              (cond ((null child)
        !          12741:                     ; child branch: (fork) evaluated to nil
        !          12742:                     (exit 0))
        !          12743:                    ((> child 0)
        !          12744:                     ; parent branch: (fork) evaluated to pid
        !          12745:                     (princ "Begot ")
        !          12746:                     (princ child)
        !          12747:                     (princ ".")
        !          12748:                     (terpri)
        !          12749:                     (return (beget:wait child)))
        !          12750:                    ((< child 0)
        !          12751:                     ; error branch
        !          12752:                     (princ "Birth pain.")
        !          12753:                     (terpri)
        !          12754:                     (return child))
        !          12755:                    (t
        !          12756:                     ; impossible branch
        !          12757:                     (princ "Impossible pain.")
        !          12758:                     (terpri)
        !          12759:                     (return -1))))))
        !          12760:     (def beget:wait
        !          12761:       (lambda (child)
        !          12762:        (prog (pvec)
        !          12763:              (setq pvec (wait))
        !          12764:              (cond ((= (car pvec) child)
        !          12765:                     ; child we are waiting for died
        !          12766:                     (return (cdr pvec)))
        !          12767:                    ((< (car pvec) 0)
        !          12768:                     ; error
        !          12769:                     (princ "Wait error.")
        !          12770:                     (terpri)
        !          12771:                     (return (car pvec)))
        !          12772:                    (t
        !          12773:                     ; another child died, keep waiting for ours
        !          12774:                     (return (beget:wait child)))))))
        !          12775: 
        !          12776: From carter%[email protected]  Tue Apr  2 16:48:37 1985
        !          12777: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12778:        id AA15047; Tue, 2 Apr 85 16:48:37 pst
        !          12779: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12780:        id AA26876; Tue, 2 Apr 85 16:48:19 pst
        !          12781: Received: from ubc by csnet-relay.csnet id a008974; 2 Apr 85 19:35 EST
        !          12782: Received: from ubc-vision.UUCP by ubc.csnet id AA06552; Tue, 2 Apr 85 16:28:06 pst
        !          12783: Date: Tue, 2 Apr 85 16:27:59 pst
        !          12784: From: Alan Carter <carter%[email protected]>
        !          12785: Message-Id: <[email protected]>
        !          12786: Received: by ubc-vision.UUCP id AA14795; Tue, 2 Apr 85 16:27:59 pst
        !          12787: To: franz-friends@BERKELEY
        !          12788: Subject: C interface
        !          12789: 
        !          12790: Does anyone know if it is OK to call malloc and free from C functions
        !          12791: called by lisp?
        !          12792:                                -- Alan Carter
        !          12793:                                   [email protected]
        !          12794: 
        !          12795: From dennis%[email protected]  Wed Apr  3 19:05:09 1985
        !          12796: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12797:        id AA09023; Wed, 3 Apr 85 19:05:09 pst
        !          12798: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12799:        id AA24595; Wed, 3 Apr 85 19:04:50 pst
        !          12800: Message-Id: <[email protected]>
        !          12801: Received: from boulder by csnet-relay.csnet id af16243; 3 Apr 85 21:51 EST
        !          12802: Received: by boulder.UCBOULDER (4.30/4.7)
        !          12803:        id AA10745; Wed, 3 Apr 85 09:58:09 mst
        !          12804: Date: Wed, 3 Apr 85 09:58:09 mst
        !          12805: From: Dennis Heimbigner <dennis%[email protected]>
        !          12806: To: carter%[email protected], franz-friends@BERKELEY
        !          12807: Subject: Re:  C interface
        !          12808: 
        !          12809: If I recall correctly, the pre-4.2 malloc did not appear to work
        !          12810: with franz because it assumed that it had control
        !          12811: of all of free memory.  The malloc for 4.2 uses a buddy
        !          12812: system and should not care if, for example, franz
        !          12813: has pre-empted pieces of virtual memory for its own use.
        !          12814: On the other side, franz only looks at the memory
        !          12815: it gets from sbrk, so it doesn't care about malloc'd
        !          12816: areas of virtual memory.
        !          12817: .lp
        !          12818: More to the point, I have been using malloc inside
        !          12819: cfasl'd code and have not yet seen a problem.
        !          12820: 
        !          12821: Dennis Heimbigner
        !          12822: dennis.boulder@csnet-relay.
        !          12823: 
        !          12824: 
        !          12825: From @seismo.ARPA:[email protected]  Fri Apr  5 01:13:08 1985
        !          12826: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12827:        id AA27833; Fri, 5 Apr 85 01:13:08 pst
        !          12828: Received: from seismo.ARPA (css-ring-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          12829:        id AA25779; Fri, 5 Apr 85 01:12:50 pst
        !          12830: Return-Path: <[email protected]>
        !          12831: Received: from prlb2.UUCP by seismo.ARPA with UUCP; Fri, 5 Apr 85 04:12:31 EST
        !          12832: Received: by prlb2.UUCP (4.12/4.7)
        !          12833:        id AA01128; Fri, 5 Apr 85 10:36:51 -0200
        !          12834: Date: Fri, 5 Apr 85 10:36:51 -0200
        !          12835: From: [email protected] (Marc Vauclair)
        !          12836: Message-Id: <[email protected]>
        !          12837: To: franz-friends@BERKELEY
        !          12838: Subject: Profiling options in Franz Lisp. Opus 38.91. UoM Var. 3.5.
        !          12839: 
        !          12840: Does anyone know how to set up profiling in Franz Lisp ?
        !          12841: We have Franz Lisp of University of Maryland : Opus 38.91, UoM Variation 3.5.
        !          12842: 
        !          12843: I have already made the following modifications :
        !          12844: 
        !          12845: 1) as stated in the makefile : ../franz/vax/Makefile I have removed the #
        !          12846:    in :
        !          12847: ------------------------------------------------------------------------------
        !          12848: ProfFlag = # -XP
        !          12849: ProfFlag2 = # -DPROF
        !          12850: ------------------------------------------------------------------------------
        !          12851: 
        !          12852: giving :
        !          12853: 
        !          12854: ------------------------------------------------------------------------------
        !          12855: ProfFlag =  -XP
        !          12856: ProfFlag2 =  -DPROF
        !          12857: ------------------------------------------------------------------------------
        !          12858: 
        !          12859: 2) I've changed in ../franz/vax/Makefile the line :
        !          12860: 
        !          12861: ------------------------------------------------------------------------------
        !          12862:        /lib/cpp $< -I../h |\
        !          12863: ------------------------------------------------------------------------------
        !          12864: 
        !          12865: to :
        !          12866: 
        !          12867: ------------------------------------------------------------------------------
        !          12868:        /lib/cpp ${ProfFlag2} $< -I../h |\
        !          12869: ------------------------------------------------------------------------------
        !          12870: 
        !          12871: 3) I've changed in ../franz/vax/Makefile/qfuncl.c the lines :
        !          12872: 
        !          12873: ------------------------------------------------------------------------------
        !          12874: #ifdef PROF
        !          12875:        .set    indx,0
        !          12876: #define Profile \
        !          12877:        movab   prbuf+indx,r0  \
        !          12878:        .set    indx,indx+4 \
        !          12879:        jsb     mcount
        !          12880: #define Profile2 \
        !          12881:        movl   r0,r5 \
        !          12882:        Profile \
        !          12883:        movl   r5,r0 
        !          12884: #else
        !          12885: #define Profile
        !          12886: #define Profile2
        !          12887: #endif
        !          12888: ------------------------------------------------------------------------------
        !          12889: 
        !          12890: to :
        !          12891: 
        !          12892: ------------------------------------------------------------------------------
        !          12893: #ifdef PROF
        !          12894:        .set    indx,0
        !          12895: #define Profile \
        !          12896:        movab   prbuf+indx,r0 ; \
        !          12897:        .set    indx,indx+4 ; \
        !          12898:        jsb     mcount
        !          12899: #define Profile2 \
        !          12900:        movl   r0,r5 ; \
        !          12901:        Profile ; \
        !          12902:        movl   r5,r0 
        !          12903: #else
        !          12904: #define Profile
        !          12905: #define Profile2
        !          12906: #endif
        !          12907: ------------------------------------------------------------------------------
        !          12908: 
        !          12909: After all these modifications, we have the following error message when
        !          12910: making it slow :
        !          12911: 
        !          12912: ------------------------------------------------------------------------------
        !          12913: 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 
        !          12914: 
        !          12915: 
        !          12916: ../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
        !          12917: mcount: ld:/lib/libc.a(mon.o): multiply defined
        !          12918: *** Error code 2
        !          12919: 
        !          12920: Stop.
        !          12921: *** Error code 1
        !          12922: 
        !          12923: Stop.
        !          12924: ------------------------------------------------------------------------------
        !          12925: 
        !          12926: From franz!schlafly  Fri Apr  5 11:19:37 1985
        !          12927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          12928:        id AA02221; Fri, 5 Apr 85 11:19:37 pst
        !          12929: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
        !          12930:        id AA04091; Fri, 5 Apr 85 11:18:48 pst
        !          12931: Received: by ucbkim.ARPA (4.24/4.27)
        !          12932:        id AA02177; Fri, 5 Apr 85 11:18:45 pst
        !          12933: Received: by franz.uucp (1.2/3.14)
        !          12934:        id AA00261; Fri, 5 Apr 85 10:37:18 pst
        !          12935: Date: Fri, 5 Apr 85 10:37:18 pst
        !          12936: From: franz!schlafly (Roger Schlafly)
        !          12937: Message-Id: <[email protected]>
        !          12938: To: franz-friends@BERKELEY
        !          12939: Subject: Franz Lisp applications
        !          12940: 
        !          12941: 
        !          12942: 
        !          12943: Here is my list of Franz Lisp applications. Enough people
        !          12944: requested copies that I am sending it to all franz-friends.
        !          12945: If anyone sees any notable omissions, please send me a
        !          12946: message and I will augment the list.
        !          12947: 
        !          12948:        Roger Schlafly
        !          12949:        ucbvax!franz!schlafly
        !          12950: 
        !          12951: ============================================================
        !          12952: 
        !          12953: 
        !          12954: 
        !          12955:         AI and Expert System Tools and Applications
        !          12956:            Developed or Running under Franz Lisp
        !          12957: 
        !          12958: 
        !          12959: 
        !          12960: + OPS-5
        !          12961: A rule based  environment  for  developing  expert  systems.
        !          12962: Available  from  Franz Inc. with Franz LISP at no charge, or
        !          12963: at no charge from Carnegie Mellon University.
        !          12964: 
        !          12965: Computer Science  Department,  Carnegie  Mellon  University,
        !          12966: Schenley Park, Pittsburgh PA 15213.  (412) 578-2592
        !          12967: 
        !          12968: + Flavors
        !          12969: An object oriented extension of Lisp, developed at  MIT  and
        !          12970: the  University  of  Maryland.   Used  on the Symbolics Lisp
        !          12971: machines.  Available from Franz Inc. at no  charge  to  pur-
        !          12972: chasers of Franz Lisp.
        !          12973: 
        !          12974: + DUCK
        !          12975: DUCK is an expert systems development environment.
        !          12976: 
        !          12977: Available  from  Smart  Systems  Technology,  6870  Elm  St.
        !          12978: McLean, VA.  22101 (703) 448-8562.
        !          12979: 
        !          12980: + Boyer-Moore Theorem Prover
        !          12981: Available from Prof. Robert Boyer, University of Texas, Aus-
        !          12982: tin.    Computer  Science  Department,  3-28  Painter  Hall,
        !          12983: University of Texas, Austin, Texas 78712.  (512) 471-7316
        !          12984: 
        !          12985: + GLISP
        !          12986: GLISP is a high-level language which is based on Lisp and is
        !          12987: compiled  into  Lisp.  It was developed at the University of
        !          12988: Texas at Austin by Prof. Gordon Novak.  Object-centered pro-
        !          12989: gramming  is  supported.   Message  interpretations  can  be
        !          12990: looked up at compile time  to  produce  efficient  code.   A
        !          12991: window-based  editor,  GEV, is available to inspect and edit
        !          12992: data according to its data structure description.  GLISP  is
        !          12993: available  from  Franz  Inc.  at  no charge to purchasers of
        !          12994: Franz Lisp, or from the University of Texas at Austin, Prof.
        !          12995: Gordon  Novak,  Computer  Science  Department,  3-28 Painter
        !          12996: Hall, University of Texas, Austin, Texas 78712.  (512)  471-
        !          12997: 7316
        !          12998: 
        !          12999: + FRL
        !          13000: A frame representation language for AI development.
        !          13001: 
        !          13002: Available from Steven Rosenberg, Hewlett Packard  (415)  857
        !          13003: 5902
        !          13004: 
        !          13005: + MRS
        !          13006: A logic based knowledge  representation  system.   Available
        !          13007: from Stanford University.
        !          13008: 
        !          13009: Attention: Pattie McCabe SUMEX Computing Facility,  Stanford
        !          13010: University  Medical Center, Room TB105, Stanford, California
        !          13011: 94305, (415) 497-5141
        !          13012: 
        !          13013: + Macsyma
        !          13014: Developed at MIT, Macsyma is a program that carries out sym-
        !          13015: bolic  computation.   It  will solve all those integrals you
        !          13016: learned about in your calculus class, as well as systems  of
        !          13017: differential equations and other mathematical problems.
        !          13018: 
        !          13019: + Reduce
        !          13020: Reduce is similar to  Macsyma.   It  was  developed  at  the
        !          13021: University  of Utah.  Computer Science Department, 3160 Mer-
        !          13022: rill Engineering Bldg.  Salt Lake City, Utah  84112.   (801)
        !          13023: 484-7651 Ext 205
        !          13024: 
        !          13025: +  XCON
        !          13026: Digital Equipment's famous expert system, written in  OPS-5,
        !          13027: originally  ran  on top of Franz Lisp.  XCON configures com-
        !          13028: puters before shipment.
        !          13029: 
        !          13030: + ACE
        !          13031: Automatic Cable Expertise : A knowledge based expert  system
        !          13032: that  provides  trouble-shooting  and diagnostic reports for
        !          13033: telephone company managers.   Developed by Stolfo,  Vesonder
        !          13034: and  others  at  AT&T  Bell Labs. For details see "The Fifth
        !          13035: Generation Challenge" Proceedings ACM '84 Annual Conference.
        !          13036: 
        !          13037: + Slang
        !          13038: A circuit design and analysis tool.  It  has  been  used  to
        !          13039: design  several  integrated  circuits  at  U.C. Berkeley.  A
        !          13040: detailed description is in the masters thesis of Korbin  Van
        !          13041: Dyke at U.C. Berkeley.
        !          13042: 
        !          13043: Available from: Industrial Liason Program, EECS  Department,
        !          13044: University of California, Berkeley CA 94720   (415) 642-0253
        !          13045: 
        !          13046: + Lyra
        !          13047: A VLSI design rule checker.  A description is in the masters
        !          13048: thesis of Michael Arnold  at U.C. Berkeley.
        !          13049: 
        !          13050: + Pearl
        !          13051: A database and AI representation language written  in  Franz
        !          13052: Lisp.   Available from Franz Inc. at no charge to purchasers
        !          13053: of Franz Lisp.
        !          13054: 
        !          13055: + YAPS
        !          13056: Yet Another Production System.  Developed by  Liz  Allen  at
        !          13057: the  University  of  Maryland.   A forward driven production
        !          13058: rule system similar to OPS-5, but  with  added  flexibility.
        !          13059: YAPS  supports  objects in facts, and defines an object that
        !          13060: is a complete production system, so you can have  more  than
        !          13061: one expert around at a time.  See "YAPS: A Production System
        !          13062: Meets Object" by Liz Allen in AAAI-83 for more  information.
        !          13063: YAPS  is  available  at  nominal cost from the Universtiy of
        !          13064: Maryland.  The license fee is $100 for  BSD  4.1,  $250  for
        !          13065: 4.2.   It's  also  Arpanet FTP'able for $100 for either ver-
        !          13066: sion.  Contact Bob Bane on Arpanet at  bane@maryland  or  on
        !          13067: Usenet  at  ...seismo!umcp-cs!bane  or  contact Liz Allen at
        !          13068: [email protected] or seismo!umcp-cs!liz .
        !          13069: 
        !          13070: + GENIE
        !          13071: GENeric Inference  Engine.   An  expert  system  development
        !          13072: tool.   Written by John Dumer, Tim Hanratty, Paul Tanenbaum,
        !          13073: and Fred S. Brundick.  For more information contact: Fred S.
        !          13074: Brundick,
        !          13075: 
        !          13076: + The Berkeley UNIX Consultant
        !          13077: An expert System incorporating a natural language  interface
        !          13078: which  answers  questions  about UNIX.  Under development at
        !          13079: U.C. Berkeley.  USABRL, APG, MD.  <fsbrn@brl-voc>
        !          13080: 
        !          13081: + ROSS and SWIRL
        !          13082: ROSS is an object-oriented language developed  for  building
        !          13083: knowledge  based simulations.  SWIRL is a program written in
        !          13084: ROSS that embeds knowledge about defensive and offensive air
        !          13085: battle  strategies.  Developed by Narain, McArthur and Klahr
        !          13086: at The Rand Corporation, 1700 Main Street, Santa  Monica  CA
        !          13087: 90406.    These  systems  were  implemented  in various LISP
        !          13088: environments including Franz  LISP.   A  comparison  of  hte
        !          13089: various  environments in terms of CPU usage, real-time usage
        !          13090: and user aids can be found in an article by the above in the
        !          13091: proceedings  of  the  1983 International Joint Conference on
        !          13092: Artificial Intelligence, Karlsruhe, W. Germany.
        !          13093: 
        !          13094: From liz@tove  Sat Apr  6 09:35:22 1985
        !          13095: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13096:        id AA13697; Sat, 6 Apr 85 09:35:22 pst
        !          13097: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
        !          13098:        id AA24792; Sat, 6 Apr 85 09:35:09 pst
        !          13099: Received: by tove.ARPA (4.12/4.7)
        !          13100:        id AA10092; Sat, 6 Apr 85 12:36:17 est
        !          13101: Message-Id: <[email protected]>
        !          13102: To: franz!schlafly@BERKELEY (Roger Schlafly)
        !          13103: Cc: franz-friends@BERKELEY
        !          13104: Subject: Re: Franz Lisp applications
        !          13105: In-Reply-To: Your message of Fri, 5 Apr 85 10:37:18 pst.
        !          13106:             <[email protected]>
        !          13107: Date: 06 Apr 85 12:36:04 EST (Sat)
        !          13108: From: Liz Allen <liz@tove>
        !          13109: 
        !          13110: A correction to one of the entries.
        !          13111: 
        !          13112:        From: franz!schlafly@Berkeley (Roger Schlafly)
        !          13113: 
        !          13114:        + Flavors
        !          13115:        An object oriented extension of Lisp, developed at  MIT  and
        !          13116:        the  University  of  Maryland.   Used  on the Symbolics Lisp
        !          13117:        machines.  Available from Franz Inc. at no  charge  to  pur-
        !          13118:        chasers of Franz Lisp.
        !          13119: 
        !          13120: Actually, there are two implmentations of flavors available for
        !          13121: Franz; one written at MIT and the other at Univ of Maryland.  Franz
        !          13122: Inc distributes the one from MIT and we (at UofM) distribute our
        !          13123: version as part of the Maryland software distribution (which includes
        !          13124: Franz 38.91).  For more information about getting our distribution,
        !          13125: contact Bob Bane [email protected] or seismo!umcp-cs!bane.
        !          13126: 
        !          13127:                                -Liz
        !          13128: 
        !          13129: 
        !          13130: From wfi%[email protected]  Tue Apr  9 02:28:37 1985
        !          13131: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13132:        id AA07208; Tue, 9 Apr 85 02:28:37 pst
        !          13133: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13134:        id AA14376; Tue, 9 Apr 85 02:27:14 pst
        !          13135: Message-Id: <[email protected]>
        !          13136: Received: from ucsc by csnet-relay.csnet id ad14837; 9 Apr 85 5:28 EST
        !          13137: Received: by vger.UCSC (4.12/4.7)
        !          13138:        id AA27515; Mon, 8 Apr 85 14:09:04 pst
        !          13139: Date: Mon, 8 Apr 85 14:09:04 pst
        !          13140: From: wfi <@csnet-relay.arpa,@ucsc.CSNET:[email protected] (Wayne F. Iba)>
        !          13141: To: franz-friends@BERKELEY
        !          13142: Subject: franz profiling
        !          13143: Cc: [email protected]
        !          13144: 
        !          13145: 
        !          13146: There is a short note in the documentation of liszt that "if the lisp
        !          13147: system is built with profiling", then using the -p option will allow
        !          13148: use of the UNIX prof command etc.
        !          13149: 
        !          13150: Can someone explain how to rebuild (if necessary) our lisp system
        !          13151: accordingly?
        !          13152: 
        !          13153: Thanks
        !          13154: --wayne (wfi%ucsc.csnet)
        !          13155: 
        !          13156: 
        !          13157: From klahr@rand-unix  Tue Apr  9 10:03:37 1985
        !          13158: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13159:        id AA09758; Tue, 9 Apr 85 10:03:37 pst
        !          13160: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13161:        id AA20618; Tue, 9 Apr 85 10:02:11 pst
        !          13162: Received: by rand-unix.ARPA; Tue, 9 Apr 85 09:41:46 pst
        !          13163: From: Phil Klahr <klahr@rand-unix>
        !          13164: Message-Id: <[email protected]>
        !          13165: Date: 09 Apr 85 09:41:40 PST (Tue)
        !          13166: To: FRANZ-FRIENDS@BERKELEY
        !          13167: Cc: randvax!klahr
        !          13168: Subject: IJCAI-85 Registration -- Please post
        !          13169: 
        !          13170: 
        !          13171: The International Joint Conference on Artificial Intelligence will be
        !          13172: meeting in Los Angeles (at UCLA) August 18-23, 1985.  Conference
        !          13173: brochures (including registration information) have already been mailed
        !          13174: out.  If you have not received one, or would like extras, contact
        !          13175: 
        !          13176:        IJCAI-85
        !          13177:        c/o AAAI
        !          13178:        445 Burgess Drive
        !          13179:        Menlo Park, CA 94025
        !          13180:        415-328-3123 or 415-321-1118
        !          13181: 
        !          13182: Registration will be limited to 5,000 people.  Based on early projections,
        !          13183: up to 7,000 people may wish to attend, so early registration is highly
        !          13184: encouraged (if not necessary).
        !          13185: 
        !          13186: As a bonus, early registrants will receive a substantial reduction in
        !          13187: registration costs.  Through June 28, registration fees are $175 ($80 for
        !          13188: students); for registrations received after June 28 but prior to July 26,
        !          13189: fees will be $225 ($100 for students); and for on-site registration (if
        !          13190: available), fees will be $275 ($125 for students).  Substantial reductions
        !          13191: for early tutorial registrations are also in effect.
        !          13192: 
        !          13193: Further information on the technical conference, the tutorials, the
        !          13194: exhibition, and housing can be found in the conference brochure.
        !          13195: 
        !          13196: From jeffr@sri-spam  Tue Apr  9 16:38:17 1985
        !          13197: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13198:        id AA00472; Tue, 9 Apr 85 16:38:17 pst
        !          13199: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13200:        id AA29765; Tue, 9 Apr 85 16:36:41 pst
        !          13201: Received: by sri-spam.ARPA (4.22/4.16)
        !          13202:        id AA05175; Tue, 9 Apr 85 16:37:20 pst
        !          13203: Date: Tue, 9 Apr 85 16:37:20 pst
        !          13204: From: jeffr@sri-spam (Jeff Rininger)
        !          13205: Message-Id: <[email protected]>
        !          13206: To: franz-friends@BERKELEY
        !          13207: 
        !          13208: Does anyone know of (or have) a Franz function that returns a character
        !          13209: corresponding to a given fixnum representation, but without the pesky
        !          13210: symbol delimiters that `ascii' returns ?
        !          13211: 
        !          13212: From g_keaton%[email protected]  Sat Apr 13 23:33:19 1985
        !          13213: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13214:        id AA22504; Sat, 13 Apr 85 23:33:19 pst
        !          13215: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13216:        id AA13927; Sat, 13 Apr 85 23:32:05 pst
        !          13217: Message-Id: <[email protected]>
        !          13218: Received: from scarolina by csnet-relay.csnet id a013785; 14 Apr 85 2:36 EST
        !          13219: Date:     Fri, 12 Apr 85 13:01 EST
        !          13220: From: Bonnell <g_keaton%[email protected]>
        !          13221: To: FRANZ-FRIENDS@BERKELEY
        !          13222: Subject:  Problems with *process.
        !          13223: 
        !          13224: I am attempting to have a Lisp process talk to a C process using
        !          13225: Lisp's *process function. This function works fine with system commands
        !          13226: such as 'ls' but fails when the C process is a typical user program.
        !          13227: I hope someone has run into similar difficulties and can provide some
        !          13228: enlightenment. We are using a set Sun workstations running Berkley Unix.
        !          13229: The same problem also occurs on our VAX. 
        !          13230: 
        !          13231:                        Thanks,
        !          13232:                                Gar Keaton
        !          13233: 
        !          13234: From narain@rand-unix  Mon Apr 15 11:33:17 1985
        !          13235: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13236:        id AA08082; Mon, 15 Apr 85 11:33:17 pst
        !          13237: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13238:        id AA08871; Mon, 15 Apr 85 11:31:51 pst
        !          13239: Received: by rand-unix.ARPA; Mon, 15 Apr 85 11:29:44 pst
        !          13240: From: Sanjai Narain <narain@rand-unix>
        !          13241: Message-Id: <[email protected]>
        !          13242: Date: 15 Apr 85 11:29:40 PST (Mon)
        !          13243: To: Bonnell <g_keaton%[email protected]>
        !          13244: Cc: FRANZ-FRIENDS@BERKELEY, narain@rand-unix
        !          13245: Subject: Re: Problems with *process.
        !          13246: In-Reply-To: Your message of Fri, 12 Apr 85 13:01 EST.
        !          13247:             <[email protected]>
        !          13248: 
        !          13249: 
        !          13250: I once set up a link between Franzlisp and C-Prolog using process instead of
        !          13251: *process and it worked fine. It was on Vax 11/780, but it was most probably
        !          13252: on an earlier version of Unix, rather than 4.2bsd.
        !          13253: 
        !          13254: -- Sanjai Narain
        !          13255: 
        !          13256: From chin@ucbdali  Sat Apr 20 11:50:19 1985
        !          13257: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
        !          13258:        id AA03799; Sat, 20 Apr 85 11:50:19 pst
        !          13259: Received: by ucbdali.ARPA (4.24/4.45)
        !          13260:        id AA08585; Sat, 20 Apr 85 11:50:12 pst
        !          13261: Date: Sat, 20 Apr 85 11:50:12 pst
        !          13262: From: chin@ucbdali (David N. Chin)
        !          13263: Message-Id: <[email protected]>
        !          13264: To: franz-friends@ucbdali
        !          13265: Subject: profiling
        !          13266: 
        !          13267: Does anyone have a profiling package for FRANZ that provides execution
        !          13268: time statistics?  The prof.l package in the lisplib only provides call
        !          13269: frequency statistics, and the liszt -p option only works if lisp was
        !          13270: created with profiling (not to mention that you would have to recompile
        !          13271: all your code to use it).
        !          13272: 
        !          13273:                                Thanks in advance,
        !          13274:                                David Chin
        !          13275:                                chin@BERKELEY
        !          13276:                                ucbvax!chin
        !          13277: 
        !          13278: From [email protected]  Sun Apr 21 14:13:02 1985
        !          13279: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
        !          13280:        id AA17063; Sun, 21 Apr 85 14:13:02 pst
        !          13281: Received: from mit-eddie.ARPA (mit-eddie.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
        !          13282:        id AA03920; Sun, 21 Apr 85 14:11:39 pst
        !          13283: Received: by mit-eddie.ARPA (4.12/4.8)  id AA03273; Sun, 21 Apr 85 17:11:05 est
        !          13284: Date: Sun, 21 Apr 85 17:11:05 est
        !          13285: From: Steven M. Haflich <[email protected]>
        !          13286: Message-Id: <[email protected]>
        !          13287: To: franz-friends@BERKELEY
        !          13288: Subject: Gnu EMACS customization for Lisp
        !          13289: 
        !          13290: Lisp hackers who use Gnu EMACS might want to try this useful
        !          13291: customization.  It emulates the standard keybinding of CCA EMACS
        !          13292: that makes C-Z (i.e. control-Z) a prefix which both CONTROL- and
        !          13293: META-izes to the following keystroke.  This is particularly useful
        !          13294: for Lisp because most of the special Lisp editing commands are bound
        !          13295: to ESC CONTROL characters.
        !          13296: 
        !          13297: This text can be placed in the personal .emacs file in your home
        !          13298: directory.  The suspend-emacs function previously run by C-Z is
        !          13299: still available as either C-X C-Z or C-Z C-Z .
        !          13300: 
        !          13301: But first: The two "^Z" strings in the text below have been sanitized
        !          13302: to pass through mailers and, as mailed, contain a two character
        !          13303: sequence representing CONTROL-Z to humans.  You will have to edit
        !          13304: them to contain the single literal character C-Z, which can be typed
        !          13305: in EMACS via the two-keystroke sequence: C-Q C-Z .
        !          13306: 
        !          13307: ======================================
        !          13308: (defun c-m-prefix ()
        !          13309:  "Apply both META and CONTROL to the next command character"
        !          13310:  (interactive)
        !          13311:  (command-execute
        !          13312:   (lookup-key esc-map (char-to-string (logand 31 (read-char))))))
        !          13313: 
        !          13314: (define-key global-map "^Z" 'c-m-prefix)
        !          13315: (define-key esc-map "^Z" 'suspend-emacs)
        !          13316: 
        !          13317: From @MIT-MC:[email protected]  Tue Apr 23 17:48:24 1985
        !          13318: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
        !          13319:        id AA18909; Tue, 23 Apr 85 17:48:24 pst
        !          13320: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
        !          13321:        id AA10636; Tue, 23 Apr 85 17:46:11 pst
        !          13322: Message-Id: <[email protected]>
        !          13323: Received: from CMU-CS-IUS.ARPA by MIT-MC.ARPA; 22 APR 85 12:13:41 EST
        !          13324: Date: 22 Apr 85 12:05:53 EST
        !          13325: From: Wilson.Harvey@CMU-CS-IUS
        !          13326: Subject: #ifdef for liszt?
        !          13327: To: BBoard.Maintainer@CMU-CS-A
        !          13328: 
        !          13329: 
        !          13330: Is there anything for the lisp compiler akin to the "#ifdef" statement
        !          13331: for the C compiler?  Can anyone point me to something similar?
        !          13332: Thanks.  -- Wilson
        !          13333: 
        !          13334: 
        !          13335: 
        !          13336: From liz@tove  Wed Apr 24 12:02:32 1985
        !          13337: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
        !          13338:        id AA01778; Wed, 24 Apr 85 12:02:32 pst
        !          13339: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
        !          13340:        id AA02711; Wed, 24 Apr 85 12:00:04 pst
        !          13341: Received: by tove.ARPA (4.12/4.7)
        !          13342:        id AA15012; Wed, 24 Apr 85 15:00:27 est
        !          13343: Message-Id: <[email protected]>
        !          13344: To: Wilson.Harvey@cmu-cs-ius
        !          13345: Cc: franz-friends@BERKELEY
        !          13346: Subject: Re: #ifdef for liszt?
        !          13347: In-Reply-To: Your message of 22 Apr 85 12:05:53 EST.
        !          13348:             <[email protected]>
        !          13349: Date: 24 Apr 85 15:00:16 EST (Wed)
        !          13350: From: Liz Allen <liz@tove>
        !          13351: 
        !          13352:        From: Wilson.Harvey@CMU-CS-IUS
        !          13353: 
        !          13354:        Is there anything for the lisp compiler akin to the "#ifdef" statement
        !          13355:        for the C compiler?  Can anyone point me to something similar?
        !          13356:        Thanks.  -- Wilson
        !          13357: 
        !          13358: The reader has built into it a switch that works in both liszt and
        !          13359: lisp.  You can tell lisp whether or not to read an expression by
        !          13360: putting before that expression something like:
        !          13361: 
        !          13362:        #+feature       
        !          13363:        #-feature
        !          13364:        #+(or feature ...)
        !          13365:        #+(and feature ...)
        !          13366: 
        !          13367: where feature is on iff it is on the "(status features)" list (which
        !          13368: can be modified).  Thus you can do something like this:
        !          13369: 
        !          13370:        #-uomlisp (defun morerecent (file1 file2) ...)
        !          13371: 
        !          13372: since uomlisp is turned only in Franz's that contain all our hacks and
        !          13373: morerecent happens to already be defined in our stuff.  If you look at
        !          13374: the liszt code, you'll see lots of "#+vax"'s and "#+68k"'s where the
        !          13375: code needs to be different, eg:
        !          13376: 
        !          13377:        (defun cc-foo (x y z)
        !          13378:           (bar #+vax vax-arg
        !          13379:                #+68k 68k-arg)
        !          13380:            ...)
        !          13381: 
        !          13382: It can be quite convenient especially when you have two lisps that are
        !          13383: almost the same, you can maintain just one source containing these
        !          13384: things whenever the sources for the different lisps must be different.
        !          13385: 
        !          13386: I know this stuff is documented in the code in charmac.l; I can't
        !          13387: remember right now if it is documented in the Franz reference manual
        !          13388: and I don't have it with me right now to check.
        !          13389: 
        !          13390: 
        !          13391: Hope this helps.
        !          13392: 
        !          13393:                                -Liz
        !          13394: